1.7 KiB
name, depth, keywords, description, skeleton, runner, change_control
| name | depth | keywords | description | skeleton | runner | change_control | ||||
|---|---|---|---|---|---|---|---|---|---|---|
| security-patch | Minimal |
|
CVE response | off | true | strict |
security-patch scope
Minimal depth for responding to a CVE or vulnerability fast. It threads a narrow path: understand the code (reverse-engineering), state what the patch must do (requirements-analysis), capture the security constraint (nfr-requirements), fix and test (code-generation, build-and-test), then ship through the deployment stages so the patch actually reaches production.
Change Control defaults to strict: a patch whose inputs move after approval is approved again before it ships.
Why these stages, why skip those
A security patch is urgent, incremental, and must deploy. It skips the
whole design ceremony (ideation, domain-design, units-generation,
nfr-design, infrastructure-design) because the change is targeted. Like the
other incremental scopes it keeps deployment-pipeline and
deployment-execution EXECUTE — a patch that never deploys does not close the
vulnerability. Its distinctive stage is nfr-requirements, which records the
security constraint; requirements-analysis also runs so there is an auditable
statement of the vulnerability and its remediation criteria (the
requirements artifact nfr-requirements and code-generation consume). One of
the three incremental scopes that skip the walking-skeleton ceremony.
Membership
Keyword triggers: security, CVE, vulnerability, patch.
Initialization, reverse-engineering, requirements-analysis,
nfr-requirements, code-generation, build-and-test, deployment-pipeline,
and deployment-execution execute; the rest is SKIP.