@event4u/agent-config 9.8.0 → 9.10.0

package/docs/contracts/adr-prompt-driven-execution.md

@@ -1,186 +0,0 @@
----
-stability: stable
----
-
-# ADR — Prompt-Driven Execution: `/work` and the confidence-band gate
-
-> **Status:** Decided · R2 Phases 1–6 shipped · 2026-04-28
-> **Context:** [`implement-ticket-flow.md`](implement-ticket-flow.md)
-> **Builds on:** [`adr-work-engine-rename.md`](adr-work-engine-rename.md) —
-> the universal-dispatcher refactor that this entrypoint slots into.
-> **Defers to:** [`adr-product-ui-track.md`](adr-product-ui-track.md) for
-> UI- and mixed-intent prompts; this ADR is backend-only.
-
-## Decision
-
-A second top-level slash command, **`/work`**, drives a free-form prompt
-through the same `work_engine` dispatcher that backs `/implement-ticket`.
-The two commands differ only in the input envelope they build:
-
-| Command | Subcommand | Envelope | Trigger |
-|---|---|---|---|
-| `/implement-ticket` | `./agent-config implement-ticket` | `input.kind="ticket"` | Ticket id, URL, or pasted ticket payload |
-| `/work` | `./agent-config work` | `input.kind="prompt"` | Free-form goal — no ticket id, no AC yet |
-
-The engine routes on `input.kind` at the dispatcher boundary; downstream
-directives (`memory`, `analyze`, `plan`, `implement`, `test`, `verify`,
-`report`) are envelope-agnostic.
-
-## Why this was a real question
-
-Roadmap 1 shipped a ticket-shaped contract: the engine assumed
-`state.ticket["acceptance_criteria"]` would always be populated by the
-caller. R2 broke that assumption — a free-form prompt arrives as a
-single string with no AC and no scope boundary. Three options were on
-the table:
-
-1. **One command, two modes** — overload `/implement-ticket` with a
-   `--prompt` flag. Rejected: the slash-command surface is the public
-   contract, and the dispatch decision (ticket vs. prompt) belongs at
-   the entrypoint, not behind a flag.
-2. **Two commands, two engines** — fork the dispatcher. Rejected:
-   doubles the maintenance surface and re-introduces the
-   ticket-as-name-lock that
-   [`adr-work-engine-rename.md`](adr-work-engine-rename.md) just
-   removed.
-3. **Two commands, one engine, two envelopes (chosen)** — `/work` and
-   `/implement-ticket` are sibling envelope-builders over the same
-   `work_engine`. Adopted because it preserves the freeze-guard on
-   `/implement-ticket` (R1 goldens stay byte-equal) and keeps a single
-   place to add R3's UI-intent envelope later.
-
-## Naming — `/work` over `/do`, `/execute`, `/build`
-
-Phase 1 locked the name. Considered alternatives:
-
-| Name | Rejected because |
-|---|---|
-| `/do` | Prefix-collision with `/do-and-judge`, `/do-in-steps` — surfaces as ambiguous in autocomplete and command-routing |
-| `/execute` | Reads as "run this artisan command for me" rather than "drive an end-to-end flow" |
-| `/build` | Dominated by build-system semantics in most ecosystems (CI builds, asset builds) |
-| `/work` | Pairs naturally with the underlying `work_engine` module name; reads as "do the work end-to-end" |
-
-`/do` lost on prefix-collision alone — even if the read was lean, the
-autocomplete failure is an everyday cost. `/work` was the next-best
-option that also matches the engine module name.
-
-## Confidence-band gate (the load-bearing piece of R2)
-
-A free-form prompt has no AC contract. Before R2, every downstream
-gate would either trip on missing AC or fabricate one silently. The
-gate solves this with a **deterministic, heuristic-only scorer** at the
-`refine` boundary.
-
-**Single source of truth:**
-[`scripts/work_engine/scoring/confidence.py`](../../dist/agent-src/templates/scripts/work_engine/scoring/confidence.py).
-The rubric, dimension definitions, weights, and band thresholds live in
-that module. SKILL.md, this ADR, and `implement-ticket-flow.md` cite
-the module — they do **not** re-derive the values. Tuning happens by
-editing the constants and re-capturing goldens.
-
-**Rubric shape** (5 dimensions × 0–2, sum / 10 → band):
-
-- `goal_clarity` · `scope_boundary` · `ac_evidence` ·
-  `stack_data` · `reversibility`
-
-**Band-action mapping:**
-
-| Band | Score | Engine outcome | Agent surface |
-|---|---|---|---|
-| `high` | `≥ 0.8` | `SUCCESS` | Silent proceed; AC + assumptions land in delivery report |
-| `medium` | `0.5 ≤ score < 0.8` | `PARTIAL` | Assumptions-report halt; user confirms or edits, engine re-runs |
-| `low` | `< 0.5` | `BLOCKED` | One clarifying question on the weakest dimension (per `ask-when-uncertain` Iron Law) |
-
-**Why heuristic, not LLM:** the score must be reproducible across
-replays — the freeze-guard harness pins expected outcomes per fixture,
-and an LLM-based scorer would drift between runs. Heuristics also
-remove a network dependency from the gate.
-
-## AC projection — the engine fix Phase 5 surfaced
-
-Downstream gates (`analyze`, `plan`) read
-`state.ticket["acceptance_criteria"]` — a slot the prompt envelope
-never sets directly. R2's first SUCCESS path through `refine` populated
-`state.input.data.reconstructed_ac` only, so `analyze` blocked with
-`ticket lost its acceptance criteria` even on a clean high-band run.
-
-Fixed at the refine boundary: `directives/backend/refine.py::_run_prompt`
-mirrors `data["reconstructed_ac"]` into `state.ticket["acceptance_criteria"]`
-(as an independent list copy) before SUCCESS branches. Two regression
-tests pin the contract on the high-band and medium-band release paths.
-
-This is intentionally a **boundary** projection, not a parallel field
-of truth: prompt envelopes carry one canonical AC list, and downstream
-gates read the same slot regardless of envelope kind.
-
-## Golden-Transcript contract
-
-Phase 5 captured `GT-P1..GT-P4` against the live engine and pinned them
-alongside the R1 goldens:
-
-- `GT-P1` — high-band happy path (6 cycles → exit 0)
-- `GT-P2` — medium-band release after assumption confirmation (7 cycles → exit 0)
-- `GT-P3` — low-band one-question halt (2 cycles → exit 1)
-- `GT-P4` — UI-intent rejection with R3 pointer (2 cycles → exit 1)
-
-`task golden-replay` runs all 9 transcripts (R1 + R2) on every PR. The
-R1 freeze-guard from
-[`adr-work-engine-rename.md`](adr-work-engine-rename.md) stays in force
-— GT-1..GT-5 remain byte-equal across the R2 changes.
-
-## Deferred to Roadmap 3
-
-R2 deliberately does **not** ship:
-
-- `directives/ui/` and `directives/mixed/` — UI-shaped prompts are
-  rejected at the band-action gate (`stack_data` scores `0`) with a
-  `@agent-directive: r3-pointer` halt.
-- Existing-UI-audit pre-step, design-review polish loop, microcopy /
-  a11y / states directives.
-- `input.kind="diff"` and `input.kind="file"` resolvers.
-
-The rejection path (`GT-P4`) pins this boundary so an R3 dispatcher
-addition doesn't silently widen `/work`'s surface.
-
-## Tradeoffs accepted
-
-- **Two top-level commands** sharing a state file. Mitigated by the
-  envelope-collision halt: a `.work-state.json` carrying `input.kind="ticket"`
-  refuses an incoming `/work` invocation, and vice versa.
-- **Heuristic scorer drift** as the rubric matures — `goal_clarity` is
-  the most likely dimension to be retuned. Mitigated by the
-  freeze-guard: every threshold change re-captures `GT-P1..P4` and a
-  PR reviewer signs off.
-- **No telemetry** — confidence scores are not aggregated. A
-  false-medium / false-low rate would only surface through user
-  reports. Telemetry is deferred indefinitely (roadmap "Future-track
-  recipe — deferred").
-
-## Non-goals
-
-- Does **not** change `/implement-ticket` behavior — R1 contract pinned
-  by `GT-1..GT-5`.
-- Does **not** introduce auto-git operations (`/commit`, `/create-pr`
-  remain user-gated per `scope-control`).
-- Does **not** pin a removal date for any R1 surface.
-- Does **not** route UI-intent prompts — that's R3.
-
-## Consequences — unblocks
-
-- **R3** (`road-to-product-ui-track.md`) can register `directives/ui/`
-  and `directives/mixed/` against the existing dispatcher; the
-  envelope shape and the band-action gate are already in place.
-- Future entrypoints (`/refactor`, `/spike`, …) can compose by
-  building a third envelope kind without touching the dispatch core.
-- Memory entries cited from prompt runs land under the same retrieval
-  surface as ticket runs — the engineering-memory contract is
-  envelope-agnostic.
-
-## Follow-ups (not part of this ADR)
-
-- Tune confidence thresholds against real-world prompts as usage
-  grows; refresh `GT-P1..P4` on any change.
-- Decide whether `assumptions_confirmed` should expire on long-running
-  flows (currently sticky for the lifetime of the state file).
-- Revisit telemetry once R3 lands — UI directives may produce richer
-  signals than backend-only flows.

package/docs/contracts/adr-settings-sync-engine.md

@@ -1,128 +0,0 @@
----
-stability: beta
-keep-beta-until: 2026-08-12
----
-
-# ADR — Settings sync engine: stdlib-only round-trip
-
-> **Status:** Decided · 2026-05-04
-> **Context:** Additive Settings Sync roadmap — review round 2
-> (Self-Review + AI Council, Anthropic + OpenAI) flagged the
-> 735-line `scripts/sync_yaml_rt.py` as potential NIH burden vs.
-> adopting `ruamel.yaml` as a third-party dependency.
-> **Builds on:** [`docs/guidelines/agent-infra/layered-settings.md`](../guidelines/agent-infra/layered-settings.md)
-> § Sync rules — defines the additive-merge-with-user-line-preservation
-> contract this engine implements.
-
-## Decision
-
-`.agent-settings.yml` synchronization uses a **custom, stdlib-only
-round-trip parser + emitter** in [`scripts/sync_yaml_rt.py`](../../src/scripts/sync_yaml_rt.py),
-not `ruamel.yaml` or any other third-party YAML library.
-
-The engine implements a narrow YAML subset (block-mappings, scalars,
-flow-list values, comments, CRLF/LF) that covers the full surface of
-`.agent-settings.yml` plus its template (`src/config/agent-settings.template.yml`).
-Out-of-subset YAML — anchors, aliases, multi-document streams, complex
-keys, nested flow mappings — is **not supported** and raises `ValueError`.
-
-The merge layer (additive walk, max-index insertion, scalar→section
-guard, healer for legacy `_user._user.foo` corruption, EOL
-normalization) sits on top of the parser and is custom regardless of
-the parser choice.
-
-## Why this was a real question
-
-Three options were on the table:
-
-1. **`ruamel.yaml` for parse + emit, custom merge on top.** Rejected.
-2. **`PyYAML` for parse, custom emitter for round-trip.** Rejected
-   earlier in the roadmap — PyYAML's parser drops comments and
-   formatting before the merger ever sees them.
-3. **Custom stdlib-only parser + emitter + merger.** Chosen.
-
-### Why ruamel.yaml does not match the contract
-
-The driving requirement from `layered-settings.md` is **verbatim
-user-line preservation** — every byte of every line in the user's
-file is preserved unless that line carries a key the merger is
-explicitly editing. Tests pin this contract by asserting byte-identity
-across two consecutive sync runs (`test_user_block_round_trip_is_idempotent`,
-`test_three_level_idempotent`).
-
-`ruamel.yaml` is a round-trip-aware library, not a verbatim one — it
-re-parses into an in-memory model and **re-emits** through its own
-emitter. This re-emit normalizes:
-
-| Behavior | ruamel.yaml | Custom engine |
-|---|---|---|
-| User-line bytes (whitespace, quoting, blanks) | re-emitted, may shift | preserved 1:1 |
-| Mixed CRLF/LF in user file | normalized to one EOL (typically platform default) | detected + normalized to the user's predominant EOL |
-| `personal: null` blocking template-section injection | requires custom merge logic regardless | scalar guard in `_merge_into` |
-| Legacy `_user._user.foo.bar` healer (one-off migration) | requires custom logic regardless | `heal_user_block` |
-| Synthetic header rendering for newly-inserted template keys | re-emits the entire file | only renders the new subtree |
-| Unknown user blocks at top level | preserved as data, but indent / quoting may shift on emit | preserved verbatim |
-| 3rd-party dependency in distribution package | +1 (`ruamel.yaml` + transitive `ruamel.yaml.clib`) | 0 |
-
-The rows where the libraries diverge are exactly the rows the test
-suite asserts on.
-
-### Cost analysis
-
-| Axis | Custom engine | ruamel.yaml |
-|---|---|---|
-| Lines of code | 735 (engine) + 335 (merge/heal) = 1070 | ~400 (parser+emitter saved) + 335 (merge/heal stays) + adapter glue = ~735 |
-| Net code saved | — | ~335 lines |
-| 3rd-party deps | 0 | +2 (`ruamel.yaml`, `ruamel.yaml.clib`) |
-| Runtime YAML surface | narrow (documented subset) | full YAML 1.2 |
-| Verbatim guarantee | yes | no |
-| Performance | irrelevant — cold-path, runs on profile change | irrelevant |
-
-The 335-line saving is real but offset by a stronger contract (verbatim)
-and a 0-dep posture. The package is a distribution-layer library
-(`composer.json` `type: library`, `package.json` thin manifest); it
-already restricts itself to stdlib for portability across consumer
-projects, several of which lock Python deps tightly.
-
-## Consequences
-
-- **Maintenance:** the engine must keep covering the YAML subset its
-  template + user files exercise. Any new template feature (e.g. a
-  block-style nested list) is a parser change, not a config change.
-- **Error surface:** YAML outside the subset (anchors, complex keys)
-  surfaces as a friendly `ValueError` from `_rt.sync()`, caught by
-  `sync_agent_settings.main` and turned into exit code 2 with a
-  user-readable message. Documented in
-  `tests/test_sync_agent_settings.py::test_malformed_user_yaml_exits_2_with_message`.
-- **Test debt:** `tests/test_sync_round_trip.py` (34 tests) and
-  `tests/test_sync_agent_settings.py` (15 tests) are the contract.
-  Any parser change must keep those green and is the entry point
-  for new fixtures under `tests/fixtures/sync_yaml_rt/`.
-
-## Revisit triggers
-
-This decision is revisited (new ADR with successor link) when **any**
-of the following holds:
-
-1. `.agent-settings.yml` schema gains a YAML feature outside the
-   supported subset (anchors, multi-doc, complex keys, nested flow
-   mappings) — the cost of extending the parser exceeds the cost of
-   adopting ruamel.
-2. The verbatim-preservation contract is relaxed (e.g. consumers
-   accept that sync can re-format) — the driver for the custom engine
-   is gone.
-3. The 0-dep posture for Python tooling is dropped at the package level
-   — the marginal cost of one more dep collapses.
-4. A maintenance bug surfaces in the engine that would have been
-   prevented by ruamel's mature spec coverage.
-
-## See also
-
-- [`docs/guidelines/agent-infra/layered-settings.md`](../guidelines/agent-infra/layered-settings.md)
-  § Sync rules — the contract this engine implements.
-- [`scripts/sync_yaml_rt.py`](../../src/scripts/sync_yaml_rt.py) module
-  docstring — the supported YAML subset, listed exhaustively.
-- `tests/test_sync_round_trip.py` — verbatim, scalar-guard, healer,
-  CRLF, and synthetic-header pinning.
-- `tests/test_sync_agent_settings.py` — CLI integration, profile
-  override, malformed-input exit code.

package/docs/contracts/adr-user-types-axis.md

@@ -1,127 +0,0 @@
----
-stability: beta
-keep-beta-until: 2026-08-14
----
-
-# ADR — Runtime user-types axis (review lens, parallel to personas)
-
-> **Status:** Decided · 2026-05-15
-> **Source:** user-authored brief (no council session — direct user spec)
-> **Sibling axis (distinct layer):** [`adr-install-user-type-axis`](adr-install-user-type-axis.md) — install-time `personal.user_type` filter; same vocabulary, different layer
-
-## Context
-
-The persona axis (`personas/`) was overloaded with two semantics:
-
-1. **Methodology lenses** — `qa`, `senior-engineer`, `critical-challenger`,
-   `developer`, `product-owner`. These voices answer: *how* we review.
-2. **End-user simulations** — proposals like `galabau-field-crew`,
-   `truck-driver`, `metalworking-shop`. These voices answer: *who*
-   experiences the software.
-
-Mixing the two collapses the taxonomy. A `qa` reviewer applies QA
-methodology regardless of which end-user the software serves. A
-`galabau-field-crew` is not a review methodology — it is the end-user
-viewpoint a methodology reviewer should adopt while reviewing.
-
-The composition the system needs is orthogonal:
-
-```
-/refine-ticket --personas=qa --user-type=truck-driver PROJ-123
-```
-
-QA methodology applied through a truck-driver end-user lens. Two
-axes, one orthogonal product.
-
-## Decision
-
-Split into a parallel axis. Add `.agent-src.uncondensed/user-types/`
-as a first-class directory mirroring the persona pipeline:
-
-- Source dir: `.agent-src.uncondensed/user-types/`
-- Schema doc: [`user-type-schema`](user-type-schema.md) — 7-section spine, ≤ 120 lines
-- JSON schema: [`scripts/schemas/user-type.schema.json`](../../src/scripts/schemas/user-type.schema.json)
-- Linter: `scripts/skill_linter.py § lint_usertype`
-- CLI surface: `/refine-ticket --user-type=<id>` (single id in v1)
-- Composition: `--user-type=` and `--personas=` compose orthogonally
-
-Persona surface is **byte-identical** after this work. No persona
-moves, no schema change to `persona-schema.md` or `persona.schema.json`,
-no behaviour change to `--personas=`. The three seed user-types
-(`galabau-field-crew`, `metalworking-shop`, `truck-driver`) are born
-as user-types — existing personas stay as personas.
-
-## Consequences
-
-**Additive surface:**
-
-- One new CLI flag (`--user-type=`)
-- One new schema doc + JSON schema
-- One new linter hook (`lint_usertype` + classifier branch)
-- One new directory (`user-types/`) projected the same way `personas/`
-  is
-- Three seed files at merge time; consumer projects add their own
-  domain-specific user-types under `dist/agent-src/user-types/`
-
-**Locked v1 boundaries:**
-
-- CLI-only. Skills do NOT declare a default `user-types:` frontmatter
-  key in v1. Migration path to v2: if usage patterns show > 3 skills
-  citing the same user-type default, add the key and the audit script
-  to mirror `recommended_for_user_types` discipline (smaller surface
-  now, additive later).
-- Single user-type per invocation (`--user-type=<id>`, not a list).
-  Multi-user-type composition deferred to v2 with a one-line note —
-  it requires synthesis logic that does not exist yet and would block
-  v1 on a non-load-bearing nice-to-have.
-- **Review lens only.** User-types never provide trade execution
-  instructions. Guardrails encoded in every file's `Anti-Patterns`
-  section per [`user-type-schema § 5`](user-type-schema.md#-5--guardrails-encoded-in-every-anti-patterns-block).
-- **Anti-Generic Quality Bar.** Every user-type encodes ≥ 5 concrete,
-  domain-specific review points and ≥ 3 Unique Questions no other
-  persona asks verbatim. Generic prose is rejected at lint or review
-  time.
-
-## Alternatives considered
-
-**Alt-1 — Extend persona schema with a `subtype: end-user` discriminator.**
-Rejected. Same physical file, two semantics, two enforcement paths
-inside one linter hook. Scales worse: every persona-consuming surface
-(`--personas=`, `lint_persona`, `audit_persona_coverage.py`) would
-need a branch on `subtype` to know whether the artefact is a
-methodology lens or an end-user lens. The clean axis split is a
-single fork-point at the classifier; the subtype fork-point recurs at
-every consumption site.
-
-**Alt-2 — Reuse the existing `user-types/` (install-time) directory
-for runtime lenses.** Rejected. The install-time axis stores YAML
-configs filtering *which skills load*; the runtime axis stores
-Markdown lenses filtering *whose viewpoint a review adopts*. Same
-vocabulary, completely different content shape (YAML key-value vs.
-Markdown prose + frontmatter), completely different consumer
-(`scripts/install.sh` vs. `refine-ticket`). Co-locating them would
-force a single `kind:` discriminator on a directory whose two halves
-do not share a schema. The separation is in different physical paths
-(`user-types/` root vs. `.agent-src.uncondensed/user-types/`) and
-the vocabulary overlap is deliberate per [`adr-install-user-type-axis`](adr-install-user-type-axis.md).
-
-**Alt-3 — Defer the axis until end-user lenses prove themselves in
-the field.** Rejected. The methodology / end-user overload is already
-producing taxonomy drift in the persona README (review-lens vs
-end-user examples mixing). Splitting now is cheaper than splitting
-after three more end-user "personas" land.
-
-## Migration
-
-No migration. v1 ships with three seed user-types born under the new
-axis. Existing personas (`qa`, `developer`, `senior-engineer`,
-`product-owner`, `stakeholder`, `critical-challenger`, `ai-agent`,
-plus specialists) stay put. The `personas/README.md` gains one
-cross-link sentence pointing readers at the parallel axis when their
-intent is end-user simulation rather than methodology review.
-
-## See also
-
-- [`user-type-schema`](user-type-schema.md) — locked shape, 7-section spine, size budget, quality bar
-- [`persona-schema`](persona-schema.md) — sister axis (untouched by this ADR)
-- [`adr-install-user-type-axis`](adr-install-user-type-axis.md) — install-time `personal.user_type` filter (distinct layer)

package/docs/contracts/adr-wing4-context-spine.md

@@ -1,126 +0,0 @@
----
-stability: beta
-keep-beta-until: 2026-08-12
----
-
-# ADR — Wing-4 context-spine: Money / Strategy / Ops slot extension
-
-> **Status:** Decided · 2026-05-13
-> **Builds on:** [`context-spine.md`](context-spine.md) — tri-slot cross-wing
-> contract (`product`, `team`, `repo`) locked at 3 by council Q1
-> (2026-05-05 KEEP-3, unified-senior-roles iter 1) plus the wing-scoped
-> track established by [`adr-gtm-context-spine.md`](adr-gtm-context-spine.md).
-> **Defers to:** [`cross-wing-handoff.md`](cross-wing-handoff.md) — typed
-> handoff contract; orthogonal to slot membership.
-
-## Decision
-
-The context-spine adds **three Wing-4-specific slots** under
-`agents/context-spine/`: `fiscal-period`, `org-stage`,
-`regulatory-regime`. The schema enum in
-[`scripts/schemas/skill.schema.json`](../../src/scripts/schemas/skill.schema.json)
-extends from
-`{product, team, repo, channel-stage, funnel-stage, customer-segment}`
-to additionally include
-`{fiscal-period, org-stage, regulatory-regime}`.
-
-The KEEP-3 lock from council Q1 still applies to **cross-wing slots**.
-The Wing-4 slots are **wing-scoped** under § 5 of the contract: they
-exist for the Money / Strategy / Ops cluster (Block O–S, 18 skills)
-and the Wing-4 personas (Block T, 4 personas). Engineering,
-Foundation, and GTM wings do not opt into them.
-
-| Slot | Path | Typical content |
-|---|---|---|
-| `fiscal-period` | `agents/context-spine/fiscal-period.md` | Reporting cadence (monthly · quarterly · annual · multi-year-plan), fiscal-year start, close-window timing. Read by O1 (`unit-economics`), O2 (`forecasting`), O3 (`runway-cognition`), O4 (`scenario-modeling`). |
-| `org-stage` | `agents/context-spine/org-stage.md` | Stage label (seed · series-A · series-B · growth · public), funding posture, headcount band, governance posture. Read by P1 (`build-buy-partner`), P4 (`vision-articulation`), Q1 (`org-design`), Q2 (`comp-banding`), S2 (`hiring-loop-design`). |
-| `regulatory-regime` | `agents/context-spine/regulatory-regime.md` | Active regimes (none · GDPR · HIPAA · SOC2 · PCI · CCPA), data-residency posture, breach-notification timer. Read by P5 (`contracts-cognition`), P6 (`privacy-review`), P7 (`data-handling-judgment`). |
-
-## Why this was a real question
-
-Three options were on the table:
-
-1. **Force-fit into existing slots.** Stuff fiscal cadence into
-   `team`, stage into `repo`, regulatory regime into `product`.
-   Rejected: each slab is owned by a different wing and Wing-4 reads
-   would mix tenant-of-record semantics (stage is not codebase
-   shape, regulatory regime is not product scope).
-2. **Wing-4-only frontmatter key.** Add `wing4_spine: [...]` parallel
-   to `context_spine`. Rejected for the same reason as Wing-3 ADR:
-   two spines duplicate the read-discipline mechanism, the lint
-   gate, and the skill-author cognitive load.
-3. **Extend the spine, scope the slots.** Accepted: same mechanism,
-   same lint gate, same opt-in discipline; slot names carry the
-   wing scope (`fiscal-period`, `org-stage`, `regulatory-regime`
-   are visibly Money / Strategy / Ops shaped).
-
-## Citation-evidence gating — prospective
-
-Per § 5 wing-scoped track, the citation chain is **prospective**: the
-roadmap (J1 → O / P / Q / S → T) ships citing skills in the same
-iteration. The ADR is the gating artefact (not the citations); each
-Block O / P / Q / S skill cites ≥ 1 of the three new slots in its
-frontmatter or carries a one-line ADR-opt-out comment in the skill
-body.
-
-The J2 linter (council Q7 boundary tests) enforces stage-agnosticism,
-which is orthogonal — a skill can cite `org-stage` for context
-without prescribing stage-specific thresholds (e.g. `runway-cognition`
-reads the stage to colour heuristics, but the procedure must remain
-readable across seed and public).
-
-## Migration plan for the existing senior catalog
-
-- **No retrofitting required.** Existing senior skills keep their
-  current `context_spine` declarations. Wing-3 skills MAY add a
-  Wing-4 slot if their cognition genuinely reads it (e.g. a Growth
-  PM reading `regulatory-regime` to scope activation experiments);
-  they MUST NOT be retrofitted mechanically.
-- **Opt-out for off-wing skills.** Engineering / Foundation senior
-  skills do not need to mention the Wing-4 slots in any way. The
-  schema accepts subsets — declaring only `[product, team]` remains
-  valid.
-- **Slot-file authoring is consumer-side.** The package ships the
-  contract; consumer projects fill
-  `agents/context-spine/fiscal-period.md` etc. when adopting Wing-4
-  skills. Missing slot file is graceful per § 4 of the contract.
-
-## Counter-evidence the agent should listen for
-
-Three signals that this decision is wrong and the ADR needs revisiting:
-
-1. **Off-wing skills start declaring Wing-4 slots.** If an
-   Engineering skill cites `org-stage`, the slot is misnamed or the
-   wing boundary is leaking. Re-scope the slot or rename it.
-2. **Wing-4 skills consistently ignore the slot they declared.** If
-   Block P privacy skills declare `regulatory-regime` but never
-   quote it in their procedure, the slot is decorative and should be
-   deleted.
-3. **A fourth Wing-4 slot is proposed within the same iteration.**
-   That is slot-sprawl on the same wing — Block J2 boundary tests
-   should reject the addition until a follow-up ADR documents why
-   three slots are insufficient.
-
-## Distinction from Wing-3 ADR
-
-`adr-gtm-context-spine.md` extends the spine with **flow-state slots**
-(funnel stage, channel stage, customer segment) — slabs that change
-*every quarter* as the GTM motion evolves. Wing-4 extends the spine
-with **constraint slots** (fiscal cadence, org stage, regulatory
-regime) — slabs that change *every fundraise / audit / boundary
-expansion*. Both extensions follow § 5 wing-scoped track; their
-combined accept means the spine schema now declares 9 slots (3
-cross-wing + 3 Wing-3 + 3 Wing-4). Any fourth slot at any wing
-re-opens the slot-sprawl risk and needs a separate ADR.
-
-## See also
-
-- [`context-spine.md`](context-spine.md) § 2 (slot table — extended),
-  § 5 (slot-add policy — wing-scoped track).
-- [`adr-gtm-context-spine.md`](adr-gtm-context-spine.md) — Wing-3
-  reference ADR this one composes against.
-- [`scripts/schemas/skill.schema.json`](../../src/scripts/schemas/skill.schema.json)
-  — `context_spine.items.enum` extended in this ADR.
-- [`.agent-src.uncondensed/rules/skill-quality.md`](../../.agent-src.uncondensed/rules/skill-quality.md)
-  § Senior-Tier Required Structure — the four blocks every senior
-  skill ships independently of spine opt-in.