#203 feat(rules): extend CI/CD-config protection beyond GitHub Actions

[Anonymous]

Originally created by: fu351

Slice

• Repo: doberman-core
• Feature / Slice: F3 (Objective Guardrail) — extend CI/CD-config protection beyond GitHub Actions
• Closes [#92]

What this PR does

.github/workflows/** was the only CI/CD config treated as a sensitive path, so an agent could edit .gitlab-ci.yml, a Jenkinsfile, .circleci/** or azure-pipelines.yml with no AUTH step-up. This closes the gap on both halves of the decision path:

• Sensitive-path globs (engine/rules/paths.py): new CICD_CONFIG_GLOBS for GitLab CI, Jenkins, CircleCI and Azure Pipelines, folded into DEFAULT_SENSITIVE_GLOBS. Paths that previously PASSed silently now step up to AUTH.
• Role boundaries (roles/builtin_roles.yaml): the same globs added to the suspicious set of frontend, backend, fullstack and docs, beside the .github/workflows/** entry each already had.

Carries forward @harshitagrawal2O's glob work from [#164], credited with Co-Authored-By. That PR's CB.3 cost-detector half is out of scope here and stays with [#164].

Deliberate scoping decision — the devops role is left unchanged

The new globs were not added to devops.allowed, even though .github/workflows/** is there. roles.py escalates anything matching no allowed glob to suspicious (the safe default), so a devops agent editing .gitlab-ci.yml gets AUTH from the role rule today via that fall-through. Adding the globs to allowed would remove that AUTH — a loosening, which prime directive 2 forbids — and would leave the protection resting solely on ProtectedPathRule's default glob set staying configured.

Bringing devops to parity with .github/workflows/** is a fair design question, but it lowers a verdict, so it wants an explicit decision rather than riding along here. Filed separately.

Tests added (run in CI)

tests/unit/test_rule_paths.py — 4 tests:

• AUTH required across all five CI systems (ported from [#164])
• raise-only over benign look-alikes — docs/jenkins-migration-guide.md, src/circleci_client.py, config/azure-pipelines-notes.txt still PASS (ported from [#164])
• CICD_CONFIG_GLOBS is a subset of DEFAULT_SENSITIVE_GLOBS (ported from [#164])
• new: non-canonical spellings are still caught — relative-dot prefix, .. traversal and mixed/Windows separators — asserted through the real ProtectedPathRule → canonicalize() path rather than a reimplemented matcher

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) — every change here only raises a verdict; the one case that would not is deliberately excluded above
• [x] Every BLOCK/AUTH carries reason codes + a human explanation (ReasonCode.sensitive_path_access asserted in the new test)
• [x] doberman-core does not import doberman_enterprise (lint-imports: 2 contracts kept, 0 broken)

Edge cases covered / Deviations from plan / Risks introduced

• Benign filenames that merely mention a CI tool are unaffected (covered by test).
• Non-canonical path spellings are covered by the new traversal test.
• Deviation: devops.allowed left alone, as explained above. No other deviation.
• Risk: agents under the frontend / backend / fullstack / docs roles that legitimately edit non-GitHub CI config will now get an AUTH prompt where they previously did not. That is the intended raise.

[Anonymous]

Ticket changed by: fu351

• status: open --> closed