#204 roles: decide whether devops should be allowed to touch non-GitHub CI/CD config

[Anonymous]

Originally created by: fu351

What

.github/workflows/** sits in devops.allowed in src/doberman/roles/builtin_roles.yaml, but the other CI/CD config globs added in [#92] (GitLab CI, Jenkins, CircleCI, Azure Pipelines) deliberately were not. That leaves the devops role inconsistent: editing a GitHub Actions workflow is in scope for it, editing a Jenkinsfile is not.

Making them consistent is not a mechanical edit, because of how the matcher works.

Why this needs a decision, not just a patch

roles.py resolves a path with precedence blocked → suspicious → allowed, and anything matching no allowed glob falls through to suspicious as the safe default. So today a devops agent touching .gitlab-ci.yml gets AUTH from the role rule via that fall-through. Adding the globs to devops.allowed would remove that AUTH.

The composite verdict would probably still be AUTH, because ProtectedPathRule contributes AUTH from DEFAULT_SENSITIVE_GLOBS independently and combine() takes the max. But that makes the role's safety depend on a different rule's default glob set staying configured — and a deployment that customises its sensitive globs would lose the step-up entirely for devops. Lowering a verdict is exactly what prime directive 2 (raise-only, never silently loosen) exists to catch.

Difficulty: level-8

Modifies existing risk classification and requires reasoning about how two rules compose. Open with a design comment and get maintainer sign-off on the intended behaviour before writing code.

The question to settle

1. Should devops be able to touch non-GitHub CI config without a role-rule AUTH, matching how .github/workflows/** behaves today? Or
2. Should .github/workflows/** instead be removed from devops.allowed, so all five CI systems consistently escalate for every role?

Option 2 is the raise-only direction and is probably the safer default; option 1 is better ergonomics for a genuine devops agent. Either is defensible — the point is to choose deliberately and record why.

Starting files

• src/doberman/roles/builtin_roles.yaml — the devops role's allowed list
• src/doberman/roles/roles.py — the blocked → suspicious → allowed precedence and the fall-through default
• src/doberman/engine/rules/paths.py — DEFAULT_SENSITIVE_GLOBS / CICD_CONFIG_GLOBS, the independent AUTH contribution

Acceptance criteria

• [ ] A decision comment on this issue, with the reasoning, before implementation
• [ ] Behaviour matches the decision for all five CI systems and every role
• [ ] A test pinning the chosen behaviour for the devops role specifically
• [ ] No verdict is lowered for any currently-covered path — or if one is, it is called out explicitly and justified in the PR
• [ ] ruff check . && ruff format --check . and lint-imports pass
• [ ] pytest passes

How to validate

pytest tests/unit/test_role_matcher.py tests/unit/test_rule_paths.py -v

Safety constraints (do not weaken these)

• Raise-only: guardrails may auto-tighten but must never silently loosen. If the chosen option lowers a verdict for any path, that must be an explicit reviewed decision, not a side effect.
• Fail closed: the fall-through-to-suspicious default exists so an unmatched path escalates. Do not remove that default.

Context

Follow-up from [#92] — see the "Deliberate scoping decision" section in the PR that closed it.

Notes for contributors

New here? Start with CONTRIBUTING.md. Issues are labelled level-1 (docs only) through level-10 (new subsystem) — pick one at your level and climb. Comment to claim an issue before starting.

[Anonymous]

Ticket changed by: fu351

• status: open --> closed