#215 fix(roles): make CI config escalate consistently for the devops role

[Anonymous]

Originally created by: fu351

Slice

• Repo: doberman-core
• Feature / Slice: Feature 4 (Agent Role Policy & Boundaries) — devops CI-config consistency fix
• Plan reference: doberman_implementation_plan.md

What this PR does

The devops role listed .github/workflows/** under allowed, but not the other four CI systems (GitLab, Jenkins, CircleCI, Azure Pipelines) that were added to every other built-in role's suspicious list in [#203]. That meant a devops agent editing .gitlab-ci.yml got an AUTH step-up from the role rule while editing .github/workflows/ci.yml did not — inconsistent, and the sole role treating GitHub Actions as fully in-scope.

Removes the .github/workflows/** entry from devops.allowed only. With no allowed glob covering it, a GitHub Actions path now falls through to the role matcher's safe default (suspicious → AUTH), the same as the other four CI systems already do for devops and for every other role.

This raises a verdict, on purpose: a devops agent now gets an AUTH step-up when editing a GitHub Actions workflow where it previously did not. The accepted tradeoff is one extra prompt for an agent whose job is CI/CD, versus leaving a role boundary that silently deferred to the protected-path rule for one CI system but not the other four. devops's genuinely-owned paths (infra/**, deploy/**, docker/**, **/*.tf) are untouched and remain allowed.

Tests added (run in CI)

• tests/unit/test_role_matcher.py::test_devops_ci_configs_escalate_for_every_ci_system — all five CI systems (.github/workflows/ci.yml, .gitlab-ci.yml, Jenkinsfile, .circleci/config.yml, azure-pipelines.yml) classify as RoleBoundary.suspicious for devops
• tests/unit/test_role_matcher.py::test_devops_owned_infra_paths_remain_allowed — regression guard: infra/main.tf, deploy/run.sh, docker/Dockerfile still classify as RoleBoundary.allowed

Public-release safety (doberman-core only)

• [x] Contains nothing from the "not allowed" list: no enterprise/hosted code, no proprietary detection, no customer data, no secrets, no commercial-license code
• [x] Core still builds/tests/runs with NO enterprise package installed

Security checklist

• [x] Fails closed on error / uncertainty
• [x] No secret, full file, or unredacted prompt logged or committed
• [x] Any guardrail/learning change is raise-only (no silent loosening) — this only raises devops's GitHub Actions verdict from allowed to suspicious
• [x] Every BLOCK/AUTH carries reason codes + a human explanation (unchanged — role-boundary AUTH already carries role_out_of_scope)
• [x] doberman-core does not import doberman_enterprise

Edge cases covered / Deviations from plan / Risks introduced

• Verified no existing test pinned the old devops-may-touch-.github/workflows/** behavior (none found).
• No deviations from the requested change; no other role, glob, or file touched.
• Risk: none beyond the intended UX cost (one extra AUTH prompt for devops agents editing GitHub Actions workflows).

Closes [#204]

[Anonymous]

Ticket changed by: fu351

• status: open --> closed