cyber-sdd 0.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.claude-plugin/plugin.json +17 -0
- package/.codex-plugin/plugin.json +17 -0
- package/.plugin/plugin.json +17 -0
- package/README.md +159 -0
- package/agents/sdd-automaton.md +97 -0
- package/agents/sdd-impl-judge.md +214 -0
- package/agents/sdd-scanner.md +120 -0
- package/agents/sdd-spec-judge.md +224 -0
- package/agents/sdd-warden.md +101 -0
- package/package.json +24 -0
- package/skills/align-spec/README.md +20 -0
- package/skills/align-spec/SKILL.md +111 -0
- package/skills/align-spec/scripts/align-spec.mts +187 -0
- package/skills/architect-impl-governance/README.md +46 -0
- package/skills/architect-impl-governance/SKILL.md +45 -0
- package/skills/architect-spec-governance/README.md +48 -0
- package/skills/architect-spec-governance/SKILL.md +59 -0
- package/skills/blast-estimate/README.md +47 -0
- package/skills/blast-estimate/SKILL.md +133 -0
- package/skills/blast-estimate/scripts/blast-estimate.mts +583 -0
- package/skills/builder-impl-governance/README.md +47 -0
- package/skills/builder-impl-governance/SKILL.md +47 -0
- package/skills/builder-spec-governance/README.md +49 -0
- package/skills/builder-spec-governance/SKILL.md +36 -0
- package/skills/check-partition-quality/README.md +22 -0
- package/skills/check-partition-quality/SKILL.md +51 -0
- package/skills/check-partition-quality/scripts/check-partition-quality.mts +336 -0
- package/skills/check-plan-safety/README.md +17 -0
- package/skills/check-plan-safety/SKILL.md +60 -0
- package/skills/check-plan-safety/scripts/check-plan-safety.mts +145 -0
- package/skills/check-project-specs/README.md +19 -0
- package/skills/check-project-specs/SKILL.md +69 -0
- package/skills/check-project-specs/scripts/check-project-specs.mts +217 -0
- package/skills/check-scenario-overlap/README.md +19 -0
- package/skills/check-scenario-overlap/SKILL.md +74 -0
- package/skills/check-scenario-overlap/scripts/check-scenario-overlap.mts +249 -0
- package/skills/check-spec-structure/README.md +17 -0
- package/skills/check-spec-structure/SKILL.md +66 -0
- package/skills/check-spec-structure/scripts/check-spec-structure.mts +346 -0
- package/skills/collision-ladder/README.md +18 -0
- package/skills/collision-ladder/SKILL.md +83 -0
- package/skills/collision-ladder/scripts/collision-ladder.mts +657 -0
- package/skills/combat-log-governance/README.md +13 -0
- package/skills/combat-log-governance/SKILL.md +257 -0
- package/skills/concept-index/README.md +13 -0
- package/skills/concept-index/SKILL.md +38 -0
- package/skills/concept-index/scripts/concept-index.mts +245 -0
- package/skills/discover-plans/README.md +16 -0
- package/skills/discover-plans/SKILL.md +74 -0
- package/skills/discover-plans/scripts/discover-plans.mts +212 -0
- package/skills/discover-specs/README.md +15 -0
- package/skills/discover-specs/SKILL.md +76 -0
- package/skills/discover-specs/scripts/discover-specs.mts +396 -0
- package/skills/doctrine-loop/README.md +15 -0
- package/skills/doctrine-loop/SKILL.md +97 -0
- package/skills/formation-loop/README.md +17 -0
- package/skills/formation-loop/SKILL.md +140 -0
- package/skills/gate-validation-governance/README.md +12 -0
- package/skills/gate-validation-governance/SKILL.md +87 -0
- package/skills/impl-producer-governance/README.md +48 -0
- package/skills/impl-producer-governance/SKILL.md +85 -0
- package/skills/init/README.md +27 -0
- package/skills/init/SKILL.md +68 -0
- package/skills/init/scripts/wire-statusline.mts +276 -0
- package/skills/lifecycle-governance/README.md +11 -0
- package/skills/lifecycle-governance/SKILL.md +168 -0
- package/skills/manage/README.md +9 -0
- package/skills/manage/SKILL.md +62 -0
- package/skills/manage-ignore/README.md +19 -0
- package/skills/manage-ignore/SKILL.md +52 -0
- package/skills/manage-ignore/scripts/manage-ignore.mts +294 -0
- package/skills/manage-scenario-bridge/README.md +20 -0
- package/skills/manage-scenario-bridge/SKILL.md +60 -0
- package/skills/manage-scenario-bridge/scripts/manage-scenario-bridge.mts +156 -0
- package/skills/manage-spec-anchors/README.md +18 -0
- package/skills/manage-spec-anchors/SKILL.md +56 -0
- package/skills/manage-spec-anchors/scripts/manage-spec-anchors.mts +328 -0
- package/skills/mission-graph/README.md +15 -0
- package/skills/mission-graph/SKILL.md +67 -0
- package/skills/mission-graph/scripts/mission-graph.mts +844 -0
- package/skills/oracle-spec-governance/README.md +45 -0
- package/skills/oracle-spec-governance/SKILL.md +45 -0
- package/skills/ownership-governance/README.md +65 -0
- package/skills/ownership-governance/SKILL.md +104 -0
- package/skills/pause-mission/README.md +18 -0
- package/skills/pause-mission/SKILL.md +112 -0
- package/skills/place-node/README.md +12 -0
- package/skills/place-node/SKILL.md +47 -0
- package/skills/place-node/scripts/place-node.mts +157 -0
- package/skills/plan-retirement/README.md +32 -0
- package/skills/plan-retirement/SKILL.md +90 -0
- package/skills/plan-retirement/scripts/retire-plans.mts +196 -0
- package/skills/plugin-contract-governance/README.md +12 -0
- package/skills/plugin-contract-governance/SKILL.md +112 -0
- package/skills/remediation-governance/README.md +46 -0
- package/skills/remediation-governance/SKILL.md +78 -0
- package/skills/resolve-governances/README.md +18 -0
- package/skills/resolve-governances/SKILL.md +50 -0
- package/skills/resolve-governances/scripts/resolve-governances.mts +515 -0
- package/skills/resolve-tracking/SKILL.md +64 -0
- package/skills/resolve-tracking/scripts/resolve-tracking.mts +213 -0
- package/skills/resume-mission/README.md +12 -0
- package/skills/resume-mission/SKILL.md +53 -0
- package/skills/scaffold-project-spec/README.md +7 -0
- package/skills/scaffold-project-spec/SKILL.md +192 -0
- package/skills/sdd/README.md +7 -0
- package/skills/sdd/SKILL.md +92 -0
- package/skills/solution-producer-governance/README.md +9 -0
- package/skills/solution-producer-governance/SKILL.md +44 -0
- package/skills/spec-format-governance/README.md +73 -0
- package/skills/spec-format-governance/SKILL.md +114 -0
- package/skills/spec-gate/README.md +26 -0
- package/skills/spec-gate/SKILL.md +201 -0
- package/skills/spec-gate/scripts/check-spec-state.mts +601 -0
- package/skills/spec-gate/scripts/check-suite.mts +501 -0
- package/skills/spec-gate/scripts/classify-edit-class.mts +411 -0
- package/skills/spec-producer-governance/README.md +7 -0
- package/skills/spec-producer-governance/SKILL.md +86 -0
- package/skills/spec-structure-governance/README.md +40 -0
- package/skills/spec-structure-governance/SKILL.md +169 -0
- package/skills/ssa-lowering/README.md +26 -0
- package/skills/ssa-lowering/SKILL.md +181 -0
- package/skills/start-mission/README.md +7 -0
- package/skills/start-mission/SKILL.md +115 -0
- package/skills/suite-format-governance/README.md +75 -0
- package/skills/suite-format-governance/SKILL.md +299 -0
- package/skills/suite-format-governance/references/rubric.md +313 -0
- package/skills/touch-set-correction/README.md +16 -0
- package/skills/touch-set-correction/SKILL.md +67 -0
- package/skills/touch-set-correction/scripts/touch-set-correction.mts +418 -0
- package/skills/verify-scenarios/README.md +17 -0
- package/skills/verify-scenarios/SKILL.md +109 -0
- package/skills/verify-scenarios/scripts/verify-scenarios.mts +386 -0
|
@@ -0,0 +1,140 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: formation-loop
|
|
3
|
+
description: "Partial Skill: invoke by name only — the SDD formation loop, the Architect's outer loop run by the Warden — invoked by the formation-loop delegate, not triggered by users directly."
|
|
4
|
+
user-invocable: false
|
|
5
|
+
metadata:
|
|
6
|
+
internal: true
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# SDD Formation Loop
|
|
10
|
+
|
|
11
|
+
The **structure outer loop** of the SDD model. Owned by the **Architect** and run by its delegate,
|
|
12
|
+
the **Warden** (`sdd-warden`), parallel to the conductor running the mission loop. It fires
|
|
13
|
+
**post-mission**, **corpus-wide and continuous**, and asks one question and only one — **is what we
|
|
14
|
+
have organized right?** Its standing subject is `corpus/` + `project-spec/` and the whole organization: it evolves how
|
|
15
|
+
the corpus is **arranged**, never what it says.
|
|
16
|
+
|
|
17
|
+
Load `sdd:combat-log-governance` for any provenance it touches; the floor + gradient the Warden
|
|
18
|
+
renders its per-act verdict against are the conductor's autonomy bar (`start-mission`) — this skill
|
|
19
|
+
defers both and never restates them.
|
|
20
|
+
|
|
21
|
+
## Corpus-wide, never the per-spec gate
|
|
22
|
+
|
|
23
|
+
This is the load-bearing distinction. The Architect appears in **two** places that must never be
|
|
24
|
+
conflated:
|
|
25
|
+
|
|
26
|
+
| | **Formation loop** (this skill) | **The gate's Architect-backward face** |
|
|
27
|
+
|---|---|---|
|
|
28
|
+
| Scope | the **whole corpus** | **one spec** |
|
|
29
|
+
| Cadence | **continuous**, across missions | **point-in-time**, at one spec's gate |
|
|
30
|
+
| Question | is the corpus **organized** right? | does **this change** fit structurally? |
|
|
31
|
+
| Acts | audit node-shape, split, reconcile | one approve/pause/reject structural verdict |
|
|
32
|
+
|
|
33
|
+
Every run produces a **finding set covering every spec in the corpus**; a structural pass scoped to
|
|
34
|
+
one spec is **not** a formation run. When asked to act as the per-spec gate structural check, the
|
|
35
|
+
loop **declines** and renders no per-spec gate verdict.
|
|
36
|
+
|
|
37
|
+
## Input — corpus structure + discovery, never the combat log
|
|
38
|
+
|
|
39
|
+
The Warden reads what the corpus **is**, never what a mission **did**. Its **primary** input is
|
|
40
|
+
structural: the corpus **structure** and **discovery** (`corpus/` + `project-spec/`). To stay efficient rather than
|
|
41
|
+
cold-scanning the whole corpus every run, it may consult the durable **public trail** (CR-source
|
|
42
|
+
conclusions + changesets + git history) **forward** via a cursor to learn what shipped recently and
|
|
43
|
+
prioritize the structural pass there first. It reads **never** the combat log (the doctrine loop's
|
|
44
|
+
input, retired at retro) and **never** live subagent context — like the other outer loops it fires
|
|
45
|
+
strictly post-mission.
|
|
46
|
+
|
|
47
|
+
**Read the declared strategy before judging.** Each project spec's root `spec.md` carries a
|
|
48
|
+
**placement map** naming the layout strategy it chose (`capability-first | mirror-source | …`). Read
|
|
49
|
+
it and judge structural fit **against that**, never against a default: a project that declared
|
|
50
|
+
`mirror-source` is not misplaced for mirroring its source tree. **Never infer the strategy from the
|
|
51
|
+
tree** — that makes the audit circular (the shape the corpus has becomes the standard it is judged
|
|
52
|
+
by) and, on a half-migrated corpus, judges it against the layout it is migrating away from. A map
|
|
53
|
+
naming no strategy is judged against the **capability-first** default, and the missing declaration
|
|
54
|
+
is itself a finding. **Read the map's routing table too, not only its strategy:** a node placed by an
|
|
55
|
+
explicit routing-table row (the "concept of kind K lives in home H" taxonomy and its tie-breaks) is
|
|
56
|
+
correctly placed even where the strategy's own derivation would put it elsewhere, so report a node
|
|
57
|
+
misplaced only when it **neither** follows the declared strategy **nor** matches a routing-table row
|
|
58
|
+
— judging on the strategy alone raises false findings against placements a human already adjudicated. A declared layout settles *where a node goes*; it never licenses a capability to
|
|
59
|
+
scatter across nodes. (Strategy is policy — read it; homes are data — derive them.)
|
|
60
|
+
|
|
61
|
+
## The intra-spec structural acts
|
|
62
|
+
|
|
63
|
+
It acts on each spec's **structure**, not its content — one project is **one spec**, so structural
|
|
64
|
+
maintenance is **intra-spec**. A station is **not** a dependency — formation depends on the corpus
|
|
65
|
+
structure and discovery (`corpus/` + `project-spec/`), not on any given station skill.
|
|
66
|
+
|
|
67
|
+
| Act | Trigger | Station (`corpus/` + `project-spec/`) | Output |
|
|
68
|
+
|---|---|---|---|
|
|
69
|
+
| **Audit node-shape** | a formation pass fires post-mission | `check-spec-structure` | a finding set: untagged-node (blocking) + oversized-node (advisory), each naming the node |
|
|
70
|
+
| **Split an oversized node** | the Warden's `@rubric` breadth-vs-depth judgment routes an oversized-node's shape profile to breadth-overflow | `check-spec-structure` | a sub-node split; depth-overflow instead down-levels via the scenario→test bridge (`verify-scenarios`) or is redesigned — the engine emits only the profile, never the route |
|
|
71
|
+
| **Reconcile drift / contradiction** | prose↔suite drift, or two nodes contradict | `align-spec` | a reconcile finding (drift fixed by direction; contradiction → align the losing side) |
|
|
72
|
+
| **Dedupe cross-node scenario overlap** | the same behavior is specified in two nodes' suites — a hard collision the scenario rung cannot see (spec-level SSA) | `check-scenario-overlap` | a dedup finding naming both nodes; the Warden's `@rubric` arm confirms real overlap and **assigns a single owning node** (one behavior = one scenario in one node) |
|
|
73
|
+
|
|
74
|
+
A node **within** the granularity heuristic raises **no** oversized finding; a concept-tagged node
|
|
75
|
+
raises **no** untagged finding; nodes (or governances) that **agree** raise **no** reconcile finding;
|
|
76
|
+
two nodes that specify **no** shared behavior raise **no** dedup finding. The acts are evidence-gated,
|
|
77
|
+
not run unconditionally.
|
|
78
|
+
|
|
79
|
+
Alongside its findings a pass surfaces an **advisory layout-quality signal** — the scheduler's
|
|
80
|
+
**false-conflict rate** doubles as a **partition-quality metric**: a layout that keeps node↔folder
|
|
81
|
+
clean holds the rate low, and one that scatters a single concern across folders drives it up. Read
|
|
82
|
+
the signal **against the strategy the project declared** — a high rate under `mirror-source` means the
|
|
83
|
+
source tree itself scatters the concern, which is a different finding from a capability-first spec
|
|
84
|
+
drifting toward layers. But the rate measures the same thing either way: **node <-> capability
|
|
85
|
+
alignment**, which the scheduler depends on and which no declaration suspends (ADR-0025). The signal
|
|
86
|
+
is **advisory** — it **gates no mission**; it points the Warden and Council at a degrading partition
|
|
87
|
+
so the **declared** layout can be re-asserted, or deliberately re-declared.
|
|
88
|
+
|
|
89
|
+
**Measuring it, when a pass wants the number.** `sdd:check-partition-quality` computes this signal
|
|
90
|
+
from the project's git history — the parallelizable share of change pairs under the declared layout,
|
|
91
|
+
against a shuffled control, optionally compared with a candidate cut. **Opt-in**: it reads `git log`,
|
|
92
|
+
so a pass runs it deliberately rather than every time, and its output is a measurement, never a
|
|
93
|
+
verdict. Read its headline (the parallelizable share) and ignore its labelled diagnostics — both
|
|
94
|
+
reward a coarser partition for being coarse.
|
|
95
|
+
|
|
96
|
+
## The Warden's self-clear-vs-escalate verdict
|
|
97
|
+
|
|
98
|
+
The Warden is **rubric-subject**, exactly as the conductor is at a gate, and has **no direct user
|
|
99
|
+
channel**. For **each structural act** it applies the full floor + gradient
|
|
100
|
+
(the conductor's autonomy bar, `start-mission`) — the floor (**Clearance** for a narrowing act; **Compatibility**
|
|
101
|
+
when the act's semver class exceeds the ceiling; **Conflict** for a contested reconciliation) plus
|
|
102
|
+
the gradient (**blast** magnitude, **novelty**, **confidence**) — and renders its own verdict:
|
|
103
|
+
|
|
104
|
+
- **Self-clear** the reversible, derivable, low-blast acts — a coverage-preserving split, a refactor
|
|
105
|
+
or consistency fix. The Warden acts **in-session** and leaves a **provisional, agent-attributed
|
|
106
|
+
marker** that is never final until the Council ratifies the trail; a Council reject unwinds it.
|
|
107
|
+
- **Escalate** the narrowing, contested, or class-exceeding acts. The escalated finding re-enters as
|
|
108
|
+
a **new CR** (`intake/`) naming the artifacts; it does not land until the Council ratifies.
|
|
109
|
+
- **narrowing** — a reconcile or split that drops scenarios → **Clearance**;
|
|
110
|
+
- **contested** — a reconciliation whose winning claim is contested → **Conflict**;
|
|
111
|
+
- **class-exceeding** — a structural change whose semver class exceeds the ceiling →
|
|
112
|
+
**Compatibility**;
|
|
113
|
+
- a **destructive** act (it deprecates a node) → **escalates regardless** of contract-impact
|
|
114
|
+
class.
|
|
115
|
+
|
|
116
|
+
It is **not** true that every act is proposed-and-ratified: the reversible/derivable acts self-clear
|
|
117
|
+
under the provisional marker; the narrowing/contested/class-exceeding ones emit a CR.
|
|
118
|
+
|
|
119
|
+
## Stations, not status — and the frozen-contract guard
|
|
120
|
+
|
|
121
|
+
The Warden runs stations in-session and **never** writes a spec's `status`. The frozen-contract
|
|
122
|
+
guard is keyed on **contract impact**, not the bare fact that a `.feature` is frozen:
|
|
123
|
+
|
|
124
|
+
- a split that **preserves every scenario verbatim narrows nothing** — it self-clears **even on a
|
|
125
|
+
frozen `.feature`**, leaving the provisional marker; no freeze re-open needed;
|
|
126
|
+
- a split that **alters or drops scenario truth is a narrowing** — it shards a frozen contract only
|
|
127
|
+
with a Council-ratified freeze re-open;
|
|
128
|
+
- a **deprecating act is destructive** — it **escalates regardless** of contract-impact class.
|
|
129
|
+
|
|
130
|
+
## Altitude discipline — route, do not decide
|
|
131
|
+
|
|
132
|
+
Formation owns corpus **structure** only and emits **no** out-of-loop decision:
|
|
133
|
+
|
|
134
|
+
- a **build-or-deprecate** request → routed to `campaign/` (Product); it makes no
|
|
135
|
+
build-or-deprecate decision itself;
|
|
136
|
+
- a **process lesson** → routed to `doctrine/` (Process); it emits no process edit itself;
|
|
137
|
+
- a **per-spec gate structural check** → **declined**; formation does not run as the gate check.
|
|
138
|
+
|
|
139
|
+
Cross-capability outcome scenarios (a split or reconcile carried end-to-end) live in
|
|
140
|
+
`../workflows/`; the loop and verdict behaviors are in `formation/formation.feature`.
|
|
@@ -0,0 +1,12 @@
|
|
|
1
|
+
# gate-validation-governance
|
|
2
|
+
|
|
3
|
+
Internal SDD governance (`user-invocable: false`). The **gate-legality** contract — what makes a
|
|
4
|
+
spec's state legal and how a gate records its verdict: the legal `(status, markers,
|
|
5
|
+
.feature, approval)` tuples, the per-node `spec-type` checks, derived sync (no stored flag), approval
|
|
6
|
+
attribution, and the no-resolvable-producer fail-closed rule.
|
|
7
|
+
|
|
8
|
+
A fixed-universal SDD governance, invariant per role. Loaded by spec-gate, the conductor, and the
|
|
9
|
+
spec-judge. It carries **no leash** — the self-clear-vs-escalate bar is the conductor's autonomy bar
|
|
10
|
+
(baked into `start-mission`). The field schema/transitions are `sdd:lifecycle-governance`;
|
|
11
|
+
write-ownership is `sdd:ownership-governance`; the mechanical authority is the `check-spec-state`
|
|
12
|
+
script in `spec-gate`. Not triggered by users directly.
|
|
@@ -0,0 +1,87 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: gate-validation-governance
|
|
3
|
+
description: "Partial Skill: invoke by name only — the SDD gate-legality contract. Loaded by spec-gate, the conductor, and the spec-judge, not user-triggered."
|
|
4
|
+
user-invocable: false
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# SDD Gate-Validation Governance
|
|
8
|
+
|
|
9
|
+
What makes a spec's state legal, and how a gate records its verdict. The field schema and transitions
|
|
10
|
+
are in `sdd:lifecycle-governance`; this skill is the legality layer on top of them. It carries **no
|
|
11
|
+
leash** — the self-clear-vs-escalate bar that derives how far an agent may self-assert is the
|
|
12
|
+
conductor's autonomy bar (baked into `start-mission`), a hard floor + a three-dimension gradient.
|
|
13
|
+
|
|
14
|
+
## Legal-state tuples
|
|
15
|
+
|
|
16
|
+
The mechanical authority is `spec-gate/scripts/check-spec-state.mts` — run it
|
|
17
|
+
(`node <skill>/scripts/check-spec-state.mts`) to enforce; if `node` is unavailable, apply the same
|
|
18
|
+
rules by reading frontmatter. The `(status, markers, .feature, approval)` tuple of the root
|
|
19
|
+
`spec.md` — plus the durable gate lines globbed from its sibling `ledger/` shards (a legacy `ledger.jsonl` still counts) — is **illegal** when:
|
|
20
|
+
|
|
21
|
+
- `status: approved` with no `.feature` — a spec requires a frozen `.feature` to be approved.
|
|
22
|
+
- `status: approved` or `implemented` with any `<!-- open: -->` markers — markers block the gate.
|
|
23
|
+
- `approval` names a gate other than `spec` or `impl`.
|
|
24
|
+
- an `approval.<gate>` has a `verdict` other than `approve`, `pause`, or `reject`.
|
|
25
|
+
- an `approval.<gate>` is `verdict: pause` carrying a `by` — a pause is always the agent's act and omits `by`.
|
|
26
|
+
- an `approval.<gate>` is `verdict: approve` with no `by` — an approve must record its approver.
|
|
27
|
+
- an `approval.<gate>` is `by: agent` with no `why` block — a self-assertion must record its derivation.
|
|
28
|
+
- an `approval.<gate>` has a `cause` other than `dimension` or `ceiling` — the stop cause is a closed enum.
|
|
29
|
+
- an `approval.<gate>` is `verdict: pause` on a gate the spec has already passed (spec once `approved`/`implemented`, impl once `implemented`).
|
|
30
|
+
- `status: approved` or `implemented` with no `approval.spec` `verdict: approve` + `by` — the spec gate has no recorded ratification.
|
|
31
|
+
- `status: implemented` with no `approval.impl` `verdict: approve` + `by` — the impl gate has no recorded ratification.
|
|
32
|
+
- `status: approved` or `implemented` with no `gate` line `gate: spec`, `verdict: approve` in the sibling `ledger/` shards — **the durable gate floor is missing**. The `approval` map is the overwritten current-state twin; the ledger line is the **immutable durable twin**, so a status advance with no ledger gate line is an unenforced gate.
|
|
33
|
+
- `status: implemented` with no `gate` line `gate: impl`, `verdict: approve` in the ledger — the impl-gate durable floor is missing.
|
|
34
|
+
|
|
35
|
+
`implemented` is backed by the impl gate's runtime suite run, not a stored flag (ADR-0017); its
|
|
36
|
+
static guard here is the recorded `approval.impl` ratification. Open markers at `draft` are permitted
|
|
37
|
+
(they block only the *gate*, not the draft state). A `draft` requires **no** ledger shard (no gate
|
|
38
|
+
has run); the durable floor applies only once a gate has advanced the status.
|
|
39
|
+
|
|
40
|
+
Reject illegal tuples **before** any other gate work. If `check-spec-state.mts` changes, this list
|
|
41
|
+
follows it — the script is the source of truth, this prose is the readable mirror.
|
|
42
|
+
|
|
43
|
+
## Per-node `spec-type` checks
|
|
44
|
+
|
|
45
|
+
Same fail-closed class, enforced by the same helper. A capability node README's `spec-type` marker
|
|
46
|
+
must agree with its shape (`sdd:spec-format-governance`):
|
|
47
|
+
|
|
48
|
+
- `spec-type: reference` with a sibling `.feature` — illegal (a reference artifact is suite-less by design).
|
|
49
|
+
- `spec-type: reference` with no `## Subject` section — illegal (the reference descriptor is required).
|
|
50
|
+
- `spec-type: behavioral` with no `## Use Cases` section — illegal (a behavioral spec maps use cases to scenarios).
|
|
51
|
+
- a node README carrying any **lifecycle field** (`status`, `project-path`, `approval`, `produced-by`,
|
|
52
|
+
or a retired `aligned` / `spec-layout` / `strategy`) — illegal: lifecycle frontmatter is
|
|
53
|
+
**root-`spec.md`-only** (`sdd:lifecycle-governance`); a node carries only its `spec-type` marker.
|
|
54
|
+
|
|
55
|
+
## The two gates
|
|
56
|
+
|
|
57
|
+
| Gate | Transition | Object judged |
|
|
58
|
+
|---|---|---|
|
|
59
|
+
| spec gate | Draft → Approved | `spec.md` + the `.feature` (no implementation required) |
|
|
60
|
+
| impl gate | Approved → Implemented | the implementation vs the frozen `.feature` |
|
|
61
|
+
|
|
62
|
+
`producer ≠ judge` survives the gate fold: even though gates are no longer a fixed station, the judge
|
|
63
|
+
stays a distinct actor from the producer, and never patches what it grades.
|
|
64
|
+
|
|
65
|
+
## Sync is derived, not stored (no `aligned` flag)
|
|
66
|
+
|
|
67
|
+
There is no `aligned` field (ADR-0017). "Synced" is two properties at two layers, each derived or
|
|
68
|
+
judged — never a stored boolean:
|
|
69
|
+
|
|
70
|
+
- **Contract layer** (`spec.md` ↔ `.feature`) — **judged** at the spec gate by the Builder coverage
|
|
71
|
+
lens; implementation is not required, and spike code is excluded as scaffolding.
|
|
72
|
+
- **Impl layer** (impl ↔ frozen `.feature`) — derived by **running the frozen suite**; the impl gate
|
|
73
|
+
advances to `implemented` only when **every** impl-judge passes, else it stays `approved` and
|
|
74
|
+
surfaces the blocker.
|
|
75
|
+
- **Per-node settled state** is the **`@frozen`** scan; **what is in flux now** is the `.plan.md`
|
|
76
|
+
todos.
|
|
77
|
+
|
|
78
|
+
`status` alone carries the lifecycle — no segment-level toggle.
|
|
79
|
+
|
|
80
|
+
## No-resolvable-producer fails closed
|
|
81
|
+
|
|
82
|
+
A required production role **always** resolves to a real producer — a plugin agent or the SDD default
|
|
83
|
+
for that role. When a gate runs and a required role has **no resolvable producer** (not a plugin
|
|
84
|
+
agent and not even an SDD default), the gate **fails closed** with a blocker; it advances nothing.
|
|
85
|
+
This is a **structural** error, the same fail-closed class as a malformed `produced-by` entry or an
|
|
86
|
+
off-enum `cause` (defined in `sdd:combat-log-governance`). Distinct from availability: a recorded
|
|
87
|
+
producer whose plugin is merely uninstalled is **flagged**, not blocked.
|
|
@@ -0,0 +1,48 @@
|
|
|
1
|
+
# impl-producer-governance
|
|
2
|
+
|
|
3
|
+
This is an internal SDD governance about the default procedure for building an implementation.
|
|
4
|
+
|
|
5
|
+
When a change request reaches the build phase and no plugin covers the domain, the conductor spawns
|
|
6
|
+
a generic builder for the **impl-producer** role. This governance is the procedure that builder
|
|
7
|
+
follows: read the frozen contract, build against it, author one verification per frozen scenario,
|
|
8
|
+
and never touch the contract itself. It loads alongside the resolved **builder** and **architect**
|
|
9
|
+
impl-gate bars (to self-align and to author the verification) and `ownership-governance` (who may
|
|
10
|
+
write what). The grader stays separate: a cold impl-judge runs the verification this role authored —
|
|
11
|
+
this role never declares its own pass.
|
|
12
|
+
|
|
13
|
+
## What it requires — the procedure
|
|
14
|
+
|
|
15
|
+
| Step | What it demands |
|
|
16
|
+
| --- | --- |
|
|
17
|
+
| **Read the contract** | Read the suite in full, `Given` steps included. In `implement` mode it is frozen — the fixed bar. In `explore` mode it is a draft — spike to probe it; a behavior the suite omits is reported as a `CONTENT_GAP`, never written into the spec or suite. |
|
|
18
|
+
| **Build against the suite** | A `Given` is a test vector: conform to each scenario's `Then`, owe nothing to its `Given`'s apparatus. Draw illustrations from domains the suite does not probe; special-case no literal a `Given` names; self-check with the swap test. |
|
|
19
|
+
| **Author the verification** | One check per frozen scenario, anchored to the scenario — never free-authored from your own sense of done. Prefer executing the frozen scenario directly, so the oracle stays spec-owned and only the glue is producer-authored. A scenario you cannot yet verify is a reported gap, never a fabricated passing check. |
|
|
20
|
+
| **Verify as high as it doesn't hurt** | Pick each scenario's verification level to maximize confidence until cost, fragility, or feasibility bites: a cheap base, a thin e2e cap on the paths that matter, and boundary (the external mocked at its seam) as the honest substitute where e2e is infeasible or unsafe. Record the level and why. Where the domain has a deterministic inner layer, also cover its combinatorial space with unit tests — the pyramid's base, separate from the per-scenario duty. |
|
|
21
|
+
| **Never modify the contract** | `spec.md` and the suite are off-limits (four-eyes). A behavior-changing gap is a `CONTENT_GAP` / `BLOCKER`, never an in-place edit. A `@pinned` scenario is never changed or removed without user authorization. |
|
|
22
|
+
|
|
23
|
+
The builder reports back a structured output the conductor collects: status, artifacts written,
|
|
24
|
+
verification written (one per frozen scenario, each with its level and why), content gaps, and
|
|
25
|
+
observations routed to their owners.
|
|
26
|
+
|
|
27
|
+
## Usage
|
|
28
|
+
|
|
29
|
+
- **impl-producer (the spawned generic builder):** loaded via the harness when the conductor
|
|
30
|
+
dispatches the impl-producer role and no plugin covers the domain and no model-tuned producer is
|
|
31
|
+
named. This is a procedure the builder follows, not a bar graded at a gate — the grading happens
|
|
32
|
+
afterward, when the cold impl-judge runs the verification this procedure produced.
|
|
33
|
+
|
|
34
|
+
## Related governances
|
|
35
|
+
|
|
36
|
+
This governance owns *how the default builder works*. Its neighbors own the bars and contracts it
|
|
37
|
+
works under:
|
|
38
|
+
|
|
39
|
+
- **`builder-impl-governance`** — the Builder bar at the impl gate: does the implementation meet the
|
|
40
|
+
frozen contract. This procedure applies that bar; it does not define it.
|
|
41
|
+
- **`architect-impl-governance`** — the Architect bar at the impl gate: structural fit of the
|
|
42
|
+
implementation. Same relation — applied here, defined there.
|
|
43
|
+
- **`ownership-governance`** — the write-ownership matrix behind the never-edit-the-contract rule
|
|
44
|
+
and the `@pinned` authorization path.
|
|
45
|
+
- **`suite-format-governance`** — how the `.feature` suite is written, including the
|
|
46
|
+
Given-is-a-test-vector doctrine this procedure builds under.
|
|
47
|
+
|
|
48
|
+
Internal SDD governance (`user-invocable: false`). Not triggered by users directly.
|
|
@@ -0,0 +1,85 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: impl-producer-governance
|
|
3
|
+
description: "Partial Skill: invoke by name only"
|
|
4
|
+
user-invocable: false
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Impl-Producer Governance — the default build procedure
|
|
8
|
+
|
|
9
|
+
The procedure the **spawned builder** follows when the conductor runs the **impl-producer** role from
|
|
10
|
+
the SDD default — no plugin covers the domain and no model-tuned producer is named, so the conductor
|
|
11
|
+
spawns a generic builder that loads this and builds. Load alongside: the resolved **builder** +
|
|
12
|
+
**architect** impl bars (to self-align and to author the verification) and `sdd:ownership-governance`.
|
|
13
|
+
The grader is separate — a cold impl-judge runs the verification this role authored; this role never
|
|
14
|
+
declares its own pass.
|
|
15
|
+
|
|
16
|
+
## Inputs (folded in by the conductor)
|
|
17
|
+
|
|
18
|
+
```
|
|
19
|
+
DOMAIN, DOMAIN_PATH, SPEC_PATH, FEATURE_PATH, SOLUTION_PATH
|
|
20
|
+
MODE: explore | implement
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
## Procedure
|
|
24
|
+
|
|
25
|
+
1. **Read the contract.** Read the suite — every scenario in full, `Given` steps included. In
|
|
26
|
+
`implement` mode it is **frozen**: build against it as the fixed bar. In `explore` mode it is a
|
|
27
|
+
**draft**: spike to probe it; a discovery that the chosen solution needs a behavior the suite
|
|
28
|
+
omits returns as a `CONTENT_GAP` / `OBSERVATIONS`, never written into `spec.md` or the suite.
|
|
29
|
+
|
|
30
|
+
2. **Build against the suite,** applying the builder + architect bars. **A `Given` is a test
|
|
31
|
+
vector** (`sdd:suite-format-governance`): conform to each scenario's `Then`; owe nothing to its
|
|
32
|
+
`Given`'s apparatus. Draw every illustration from a domain the suite does not probe; special-case
|
|
33
|
+
no literal a `Given` names. Self-check with the **swap test**.
|
|
34
|
+
|
|
35
|
+
3. **Author the verification** — one check per frozen scenario, anchored to the scenario, never
|
|
36
|
+
free-authored from your own sense of done. **Prefer executing the frozen scenario directly** (the
|
|
37
|
+
suite as the runnable check) so the oracle stays spec-owned and only the glue is
|
|
38
|
+
producer-authored. Where a unit-test mapping is unavoidable, the expected outcome comes from the
|
|
39
|
+
frozen scenario, never your sense of done — the impl-judge re-derives that oracle (ADR-0016). A
|
|
40
|
+
scenario you cannot yet verify is a reported gap, never a fabricated passing check.
|
|
41
|
+
|
|
42
|
+
4. **Verify as high as it doesn't hurt.** Choose each scenario's verification **level** to maximize
|
|
43
|
+
confidence until cost, fragility, or feasibility bites: a cheap base, a **thin e2e cap** on the
|
|
44
|
+
paths that matter, **boundary** (the external mocked at its seam) as the honest substitute where
|
|
45
|
+
e2e is infeasible or unsafe. **Record the level and why.** Where the domain has a deterministic
|
|
46
|
+
inner layer, also cover its combinatorial space (truth tables, matrices) with unit tests drawn from
|
|
47
|
+
the inner rules — the pyramid's base, separate from the per-scenario duty. A non-deterministic
|
|
48
|
+
subject has no such layer — verify at the acceptance level only.
|
|
49
|
+
|
|
50
|
+
5. **Never modify `spec.md` or the suite** — four-eyes. A behavior-changing gap is a
|
|
51
|
+
`CONTENT_GAP` / `BLOCKER`, never an in-place edit. Never change or remove a `@pinned` scenario —
|
|
52
|
+
propose it and surface for user authorization (`sdd:ownership-governance`).
|
|
53
|
+
|
|
54
|
+
## Responding to a `change` verdict
|
|
55
|
+
|
|
56
|
+
Load `sdd:remediation-governance` — the findings are **evidence, not a work order**. It carries the
|
|
57
|
+
four rules (substantiate before acting · state the rule and sweep, scope-aware · re-derive against the
|
|
58
|
+
rule governing the artifact · account for provenance, where a regression stops the loop) and the
|
|
59
|
+
`REMEDIATION` trace this role returns in its `Output` below.
|
|
60
|
+
|
|
61
|
+
## Output (the conductor collects)
|
|
62
|
+
|
|
63
|
+
```
|
|
64
|
+
REMEDIATION: <per finding answered: verdict, rule, swept, ruled-out, provenance — `sdd:remediation-governance`; omit when no verdict was answered>
|
|
65
|
+
STATUS: complete | needs-input | blocked
|
|
66
|
+
ARTIFACTS_WRITTEN: [ paths ]
|
|
67
|
+
VERIFICATION_WRITTEN: [ paths ] # one per frozen scenario, each with its level + why
|
|
68
|
+
CHANGES_MADE: <what was built>
|
|
69
|
+
QUESTIONS: [ batched, when needs-input ]
|
|
70
|
+
CONTENT_GAPS: [ { artifact, location, gap } ]
|
|
71
|
+
OBSERVATIONS: [ { owner: architect | strategist, note, evidence } ]
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
## Key points (read-check)
|
|
75
|
+
|
|
76
|
+
1. **Read the frozen suite in full**; build against it; a needed behavior it omits is a
|
|
77
|
+
`CONTENT_GAP`, never an in-place edit.
|
|
78
|
+
2. **A `Given` is a test vector** — conform to the `Then`, owe nothing to the apparatus (swap test);
|
|
79
|
+
no absorption.
|
|
80
|
+
3. **Author one check per frozen scenario** anchored to it; prefer running the scenario directly so
|
|
81
|
+
the oracle stays spec-owned; an unverifiable scenario is a reported gap.
|
|
82
|
+
4. **Verify as high as it doesn't hurt** — record level + why; deterministic combinatorics go to unit
|
|
83
|
+
tests (the pyramid base).
|
|
84
|
+
5. **Never modify `spec.md` / the suite; never touch a `@pinned` scenario without user
|
|
85
|
+
authorization.**
|
|
@@ -0,0 +1,27 @@
|
|
|
1
|
+
# init
|
|
2
|
+
|
|
3
|
+
The onboarding front door for an SDD project — offers SDD's opt-in, repo-scoped conveniences and
|
|
4
|
+
wires the ones the user enables into operational config. v1 offers exactly one: the **mission
|
|
5
|
+
statusline**, which surfaces the current mission phase in the Claude Code status line while a
|
|
6
|
+
mission runs. A user-invocable setup skill (sibling to `start-mission` / `manage`); it opens no CR
|
|
7
|
+
and invokes no gate.
|
|
8
|
+
|
|
9
|
+
- **Skill contract:** [`SKILL.md`](./SKILL.md)
|
|
10
|
+
- **Script:** [`scripts/wire-statusline.mts`](./scripts/wire-statusline.mts)
|
|
11
|
+
- **Tests:** [`scripts/wire-statusline.test.mts`](./scripts/wire-statusline.test.mts) (`node:test`)
|
|
12
|
+
|
|
13
|
+
```bash
|
|
14
|
+
node scripts/wire-statusline.mts --root . --detect
|
|
15
|
+
node scripts/wire-statusline.mts --root . --wire --mode own-line
|
|
16
|
+
node scripts/wire-statusline.mts --root . --wire --mode same-line # --no-global-base to shadow deliberately
|
|
17
|
+
```
|
|
18
|
+
|
|
19
|
+
The engine writes only project `.claude/settings.json` (never the global settings file) and, in a
|
|
20
|
+
git repo, `.gitignore`. It composes with — never replaces — an existing `statusLine` command, and
|
|
21
|
+
re-running it is idempotent (no duplicated segment, no duplicated gitignore entry). Because a
|
|
22
|
+
project `statusLine` replaces the global one in Claude Code, `--detect` reads the global settings
|
|
23
|
+
(read-only) for a command the wiring would shadow, and a fresh wire wraps that global command as
|
|
24
|
+
the composed base by default. The reader it
|
|
25
|
+
wires falls through to nothing beyond the composed base when `.agents/sdd/statusline` is absent —
|
|
26
|
+
the conductor (realized by `../start-mission/`) is the only writer of that file's value, during the
|
|
27
|
+
mission loop.
|
|
@@ -0,0 +1,68 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: init
|
|
3
|
+
description: Use this skill to onboard SDD's opt-in repo-scoped conveniences — currently the mission statusline, which surfaces the current mission phase in the Claude Code status line while a mission runs. Trigger on "set up the statusline", "configure the SDD status line", "onboard SDD conveniences", or "init sdd".
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# init
|
|
7
|
+
|
|
8
|
+
The **onboarding front door** for an SDD project — the place a repo opts into SDD's optional, repo-scoped conveniences. Unlike `sdd:sdd` (the gateway) and `sdd:manage` (thin classifiers that write no repo files), `init` is a **setup skill**: it writes operational config, never spec/contract state. It **opens no CR** and **invokes no gate**.
|
|
9
|
+
|
|
10
|
+
`sdd:manage`'s Setup & discovery group loads this skill for a bare "set up / configure the statusline" request.
|
|
11
|
+
|
|
12
|
+
## v1 capability — the mission statusline
|
|
13
|
+
|
|
14
|
+
While a mission runs, the conductor (`start-mission`) overwrites `.agents/sdd/statusline` with the current phase on each transition and clears it on every exit. This skill wires the **reader**: a Claude Code `statusLine` command in **project** `.claude/settings.json` that renders that file. It never writes or clears the runtime value itself — only the conductor does.
|
|
15
|
+
|
|
16
|
+
### 1. Offer, and ask consent
|
|
17
|
+
|
|
18
|
+
Ask the user whether to enable the mission statusline. **On decline, write nothing** — no settings change, no `.gitignore` entry — and stop.
|
|
19
|
+
|
|
20
|
+
### 2. Ask the display mode
|
|
21
|
+
|
|
22
|
+
On enable, ask whether the mission status should render:
|
|
23
|
+
|
|
24
|
+
- **own-line** — its own row, beneath any existing status line output
|
|
25
|
+
- **same-line** — appended to the end of the existing status line output
|
|
26
|
+
|
|
27
|
+
### 3. Detect a global statusline
|
|
28
|
+
|
|
29
|
+
Before wiring, run the read-only detection — Claude Code's project `statusLine` **replaces** the global one (no merge), so a fresh project wiring would silently shadow a status line living in `~/.claude/settings.json`:
|
|
30
|
+
|
|
31
|
+
```bash
|
|
32
|
+
node "<skill>/scripts/wire-statusline.mts" --root . --detect
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
It reports the project statusLine (absent | wired | foreign), the global statusLine (present | absent), and the shadow risk. On a shadow risk (project absent, global present), tell the user wiring will shadow their global status line and ask:
|
|
36
|
+
|
|
37
|
+
- **compose it** (default) — the global command is wrapped as the base, the piped status input flows through to it, and the global line keeps rendering. Warn when project `.claude/settings.json` is committed: composing copies the global command text into it, which may be machine-specific.
|
|
38
|
+
- **shadow it** — wire with no base (pass `--no-global-base` below).
|
|
39
|
+
|
|
40
|
+
No shadow risk → proceed straight to wiring.
|
|
41
|
+
|
|
42
|
+
### 4. Wire the reader
|
|
43
|
+
|
|
44
|
+
Run the engine to compose the reader into project settings and (in a git repo) gitignore the status file:
|
|
45
|
+
|
|
46
|
+
```bash
|
|
47
|
+
node "<skill>/scripts/wire-statusline.mts" --root . --wire --mode own-line
|
|
48
|
+
node "<skill>/scripts/wire-statusline.mts" --root . --wire --mode same-line # add --no-global-base to shadow deliberately
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
The engine:
|
|
52
|
+
|
|
53
|
+
- writes **only** `.claude/settings.json` and, only in a git repo, `.gitignore` — the global `~/.claude/settings.json` is read for detection only, **never written**
|
|
54
|
+
- **composes, never stomps**: an existing project `statusLine` command's output is preserved as the wrapped base; the SDD segment is added around it (a new row for own-line, an appended segment for same-line). No project command → a fresh wire wraps the detected **global** command as the base by default (`--no-global-base` opts out); no command anywhere → it creates one.
|
|
55
|
+
- a project `statusLine` always wins as the base; re-running recovers the base from the wired command and never re-consults the global settings; a malformed global settings file counts as no global statusLine
|
|
56
|
+
- the wired command reads `.agents/sdd/statusline` and falls through to nothing beyond the composed base when the file is absent — no heartbeat, no polling, just a read
|
|
57
|
+
- adds `.agents/sdd/statusline` to `.gitignore` idempotently when the folder is a git repo; skips when it is not
|
|
58
|
+
- is **idempotent**: re-running (same or a different mode) rewrites the one managed block, never stacking a second SDD segment or duplicating the gitignore line
|
|
59
|
+
|
|
60
|
+
When `node` is absent, an agent performs the same edit by hand: read `.claude/settings.json`, wrap any existing project `statusLine.command` as a POSIX `sh` subshell base — when the project defines none, read `~/.claude/settings.json` (read-only) and, with the user's consent from step 3, wrap its `statusLine.command` as the base instead — append the mode-specific read-and-render logic for `.agents/sdd/statusline`, and add the gitignore line when the folder is a git repo — never touch the global settings file.
|
|
61
|
+
|
|
62
|
+
### Report
|
|
63
|
+
|
|
64
|
+
State whether the statusline was enabled or declined, the chosen mode (if enabled), whether a global statusline was detected and composed as the base (or deliberately shadowed), and whether the gitignore entry was added, already present, or skipped (not a git repo).
|
|
65
|
+
|
|
66
|
+
## Boundaries
|
|
67
|
+
|
|
68
|
+
Writes **only** operational config (`.claude/settings.json`, `.gitignore`) — never a `spec.md`, `status`, `approval`, or freeze. Opens no CR, invokes no gate. Never wires the **global** settings file — SDD is repo-scoped, a user's global status line is theirs; the global file is read only to detect a statusLine to compose against, never written. Does not move `scaffold-project-spec` / `manage-spec-anchors` / `manage-ignore` into itself. Never writes or clears the statusline **value** — that is the conductor's during the mission loop.
|