feat: add CI/CD pipeline policy template with intent fixtures

[4444J99]

Context
AI agents operating inside CI/CD pipelines present distinct risk surfaces:
production deployments, secret access, infrastructure mutation. The existing
policy templates cover risk tiers (low/medium/high), knowledge workers,
endpoint constraints, and skill provenance, but no template addresses the
CI/CD pipeline domain specifically.

What this adds
A starter policy template (examples/policy/ci_cd_pipeline.yaml) with five
deterministic intent fixtures demonstrating all three verdict paths:

• allow: artifact reads (artifact.read at low risk), staging deploys
  (deploy.apply scoped to staging workspace prefixes)
• block: production deploys (deploy.apply at critical risk scoped to
  production workspaces), infrastructure destruction (infra.destroy,
  db.drop, etc.)
• require_approval: secret/vault access (secret.read, vault.read at
  high/critical risk), infrastructure provisioning (infra.create,
  infra.update requiring 2 distinct approvers)

The policy uses fail_closed on critical risk class with required targets
and arg_provenance fields. Default verdict is block.

Files added:

• examples/policy/ci_cd_pipeline.yaml
• examples/policy/intents/intent_ci_read_artifact.json
• examples/policy/intents/intent_ci_deploy_staging.json
• examples/policy/intents/intent_ci_deploy_production.json
• examples/policy/intents/intent_ci_secret_access.json
• examples/policy/intents/intent_ci_infra_destroy.json

Files modified:

• examples/policy/README.md (document new template and expected verdicts)
• scripts/policy_compliance_ci.sh (add 5 test cases + 1 validate case)

Validation

• go build -o ./gait ./cmd/gait
• bash scripts/policy_compliance_ci.sh (all 21 cases pass)
• go test ./... (all packages pass)
• Each intent fixture verified against expected exit codes:
  • intent_ci_read_artifact.json => exit 0 (allow)
  • intent_ci_deploy_staging.json => exit 0 (allow)
  • intent_ci_deploy_production.json => exit 3 (block)
  • intent_ci_secret_access.json => exit 4 (require_approval)
  • intent_ci_infra_destroy.json => exit 3 (block)
• gait policy validate examples/policy/ci_cd_pipeline.yaml --json => exit 0

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b5435747fc

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Narrow read allowlist to artifact-specific tools

Including tool.read in the artifact-read rule allows any generic read call at low/medium risk, not just artifact access. In adapters that surface secret or vault retrieval as tool.read, those requests bypass the require-approval-secret-access rule and are approved as allow, which weakens the template’s stated secret-access guardrail. Restrict this rule to artifact-specific tool names (or add strict target/path constraints) so non-artifact reads do not auto-pass.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Constrain staging deploys by destination scope

The staging deploy allow rule only checks tool name, risk class, and workspace prefix, so a request can still target production infrastructure while presenting workspace as /ci/staging and risk_class as medium, and it will be allowed. Because this rule does not validate destination/target scope, it can authorize production deploy behavior under a staging label; add destination constraints (allowlist/denylist) to enforce true staging-only deploys.

Useful? React with 👍 / 👎.