verify-security

# verify-security workflow (v3) ## Overview 1-phase sub-workflow mapping CLAUDE.md "Verify 阶段 — 可选 /cso" onto harnessed runtime (Phase v3.0-3.4 W0.13b — D-04 Stage ④ Verify 7 sub + D-12 gstack 治理关卡 + Pattern A sub-workflow ship)。 | phase | id | upstream | model | capability | gate | | ----- | -- | -------- | ----- | ---------- | ---- | | 1 | `01-cso` | gstack | opus | `{{ capabilities.gstack-cso.cmd }}` | `judgments.stage-routing.verify-security-secrets.fires` | Per-phase config loads from `workflows/verify/security/workflow.yaml`; engine 4-level gate resolver evaluates `phase.has_auth_or_secrets == true` via expr-eval — true 则 invoke gstack `/cso` (OWASP / auth / credentials / secrets 全面审查), false 则 skip。 ## Capability refs Sister `workflows/capabilities.yaml` entries: - `gstack-cso` — Bucket 3 治理关卡 (impl: gstack, cmd: /cso, fires_when: phase.stage == 'verify' AND phase.has_auth_or_secrets == true) ## Gate ref Sister `workflows/judgments/stage-routing.yaml`: - `verify-security-secrets.fires` — `phase.stage == 'verify' and phase.has_auth_or_secrets == true` ## Routing rules - ✅ **触发**: auth flow / session / credentials / API keys / SQL injection 路径 / OWASP top 10 area - ❌ **跳过**: docs / 纯 UI styling / 内部 refactor / non-security PR ## How to invoke !`harnessed checkpoint intent verify-security` > The banner above (when present) means this invocation is REGISTERED with the engine (an intent marker) — not yet compliant: the steps below (prompt → spawn → checkpoint...