Files
CASAN/AINative_OKR_CASAN5/packages/casan-harness/security/incident-runbook.md
T
thanhnvandClaude Opus 4.8 664bd1f00c feat(plan-01): Phase 1 — relocate harness code to packages/casan-harness (symlink facade)
Physically move the pure-code subtrees out of .specify into the package, leaving
compat symlinks at the old .specify/<dir> paths so every existing reference (internal
CASAN_HARNESS_ROOT + external CI/docker/mjs) keeps resolving. Runtime state stays put.

Moved (git mv): scripts/ tests/ security/ templates/ config/ governance/ memory/
  .specify/<dir>  ->  packages/casan-harness/<dir>   (+ .specify/<dir> symlink)
Stays in .specify (state/governance/domain, handled later): logs/ agentops/ level5/
  init-options.json traceability-map.json

Python `.resolve()` self-location followed the compat symlink into packages and lost
the app root; generate-casan-demo-context.py, generate-agentops-dashboard.py and
dashboard-server.py now walk UP for the `.specify` state marker instead of a fixed
parent depth (fixes "missing trace files" in run-casan4).

Full gate: PASS=64 FAIL=0 SKIP=3 (CASAN_CI_STEP_TIMEOUT_SEC=1200 — track-a ~450s runs
close to the 600s default and can tip over under load; this is timing variance, not a
regression — it passed cleanly with headroom). Runtime log/audit artifacts kept unstaged.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-08 00:06:00 +09:00

1.8 KiB

CASAN Incident Runbook (C7 / V23)

When a gate raises an incident (incident.sh raise <event>), it is classified, recorded to logs/level5/incidents.jsonl, and for HIGH/CRIT the scoped kill-switch is engaged automatically + an alert is dispatched.

Severity → owner → response

Severity Owner (on-call) Auto-action Human step
CRIT security-oncall kill-switch engaged + alert Contain now; verify blast radius; do NOT clear until root cause known
HIGH ops-oncall kill-switch engaged + alert Assess; clear switch only after fix + reviewer sign-off
MED tech-lead recorded + alert Triage within SLA; batch-fix
LOW triage recorded Review in retro

Kill-switch operations

kill-switch.sh status                     # what is engaged
kill-switch.sh check <scope> <id>         # gates honor this (exit 2 = stop)
kill-switch.sh clear <scope> <id> <reason># turn off (production: reviewer-approved)

Scopes: project · model · provider · global (global stops everything).

Event → severity

See incident-severity.map. Examples: secret-to-cloud=CRIT, tool-write-sensitive=CRIT, dependency-postinstall=HIGH, audit-chain-broken=HIGH, cost-budget-exceeded=MED.

Postmortem template (fill after resolution)

  • Incident: <id / timestamp / event / severity>
  • Detection: which gate fired, what signal
  • Blast radius: scope, what was stopped by the kill-switch
  • Root cause:
  • Fix:
  • Prevent recurrence: new test/gate added (link the fail-able check)
  • Kill-switch cleared by: at

Production TODO

Managed alert channel (Slack/PagerDuty) + on-call rota + auto issue creation; kill-switch clear gated by reviewer approval (tie to approval-identity C4).