mandrel 1.82.0 → 1.83.0

package/.agents/skills/core/epic-plan-consolidate/SKILL.md

@@ -30,11 +30,13 @@ allowed_tools:
 ## Role
 
 Senior Project Manager + Orchestrator, acting as a **holistic critic** with
-fresh context. This Skill is deliberately *separate* from
-`epic-plan-decompose-author` (the generator): a same-pass self-critique is the
-weak mode this is built to escape. The generator maps Epic capabilities to
-Stories ~1:1; this critic steps back and looks at the *whole* decomposition
-against the Tech Spec's intentional grouping before any GitHub write.
+fresh context — deliberately *separate* from `epic-plan-decompose-author` (the
+generator) so the pass is a fresh-context review, not a same-pass self-critique.
+
+> **Read [`examples.md`](./examples.md) on demand** for the extended rationale:
+> why this critic runs with fresh context, why scope conservation is your
+> contract rather than a runtime guarantee, and how the below-ceiling
+> coarsening case is reported.
 
 ## When to use
 

package/.agents/skills/core/epic-plan-consolidate/examples.md

@@ -0,0 +1,51 @@
+# epic-plan-consolidate — examples & extended rationale
+
+Read this file on demand. The SKILL.md carries the operating contract (Policy
+Capsule, Inputs / Outputs, Procedure, Constraints); this file carries the
+extended rationale behind the consolidation pass — why it is a separate,
+fresh-context critic and how the scope-conservation invariant is enforced by
+you rather than by the runtime.
+
+## Why a separate fresh-context critic
+
+This Skill acts as a **holistic critic** with fresh context (a Senior Project
+Manager + Orchestrator lens). It is deliberately *separate* from
+`epic-plan-decompose-author` (the generator): a same-pass self-critique is the
+weak mode this is built to escape. The generator maps Epic capabilities to
+Stories ~1:1; this critic steps back and looks at the *whole* decomposition
+against the Tech Spec's intentional grouping before any GitHub write.
+
+## Scope conservation is your contract, not a machine guarantee
+
+Scope conservation is the load-bearing invariant: you MUST NOT add scope,
+invent tickets, or drop acceptance criteria. Every acceptance item and every
+`verify` entry present in the draft MUST survive into the consolidated array
+(possibly re-homed onto a merged Story).
+
+**This is your contract, not a machine guarantee.** There is **no runtime
+acceptance-union diff** on your output. The only deterministic runtime backstop
+the validator applies after you run is the standard ticket-structure
+validation — it does not re-derive the pre-consolidation acceptance/verify
+union, so a critic that silently dropped an acceptance item would **not** be
+caught downstream. (The repo's unit test exercises a *pure model* of the merge
+over an over-fragmented fixture to document the intended invariant; it does not
+inspect this Skill's actual output.) Conserve scope yourself, deliberately, on
+every merge — and if you cannot preserve an item, you have over-reached, so back
+the operation out.
+
+## Ceiling, not target — the below-ceiling coarsening case
+
+Consume the Tech Spec **"Delivery Slicing"** section as a **ceiling, not a
+target** when present: the Architect's proposed N shippable Stories is an
+*upper bound*, not a floor. Cluster the draft's Stories toward that grouping,
+and go **below** N when slices form dependent single-consumer chains — a slice
+whose "Independent? No" row carries no justification (parallelism, risk
+isolation, or delivery-envelope pressure) folds into its consumer. You **never**
+split above N.
+
+When the consolidated count drops **below** the Delivery-Slicing count, the
+consolidation report MUST surface that fact explicitly — e.g.
+`Below ceiling: N (Delivery Slicing) → M (consolidated)` — and attach a one-line
+rationale to each below-ceiling merge (which dependent single-consumer slice
+folded into which consumer, and why it was unjustified), so the operator sees
+the coarsening at the Phase 8.3 advisory diff.

package/.agents/skills/core/epic-plan-decompose-author/SKILL.md

@@ -302,28 +302,10 @@ When the Acceptance Table contains **one or more `Disposition: new` rows**, you
 
 When the Acceptance Table contains **zero `new`-disposition rows** (every row is `updated` or `unchanged`), do NOT emit a scaffold Story — there is nothing to create.
 
-**Worked example.** Epic #42, Acceptance Table with two `new` rows (`AC-1` -> `tests/features/billing/invoice.feature`, `AC-2` -> `tests/features/billing/refund.feature`). The scaffold Story below uses a serialized string `body`, top-level `acceptance`/`verify` arrays, an empty `depends_on`, and tags each scenario with both `@skip` and its namespaced `@epic-42-ac-N` tag:
-
-    {
-      "slug": "scaffold-billing-feature-files",
-      "type": "story",
-      "title": "Scaffold @skip-tagged billing feature files",
-      "depends_on": [],
-      "labels": ["type::story", "persona::qa-engineer"],
-      "acceptance": [
-        "tests/features/billing/invoice.feature and tests/features/billing/refund.feature both exist on the branch",
-        "every Scenario in the two new feature files is preceded by an @skip tag (grep for un-skipped scenarios returns zero matches)",
-        "the invoice.feature scenario carries @epic-42-ac-1 and the refund.feature scenario carries @epic-42-ac-2"
-      ],
-      "verify": [
-        "test -f tests/features/billing/invoice.feature && test -f tests/features/billing/refund.feature (validate)",
-        "test -z \"$(grep -rL '@skip' tests/features/billing/*.feature)\" (validate)",
-        "grep -q '@epic-42-ac-1' tests/features/billing/invoice.feature && grep -q '@epic-42-ac-2' tests/features/billing/refund.feature (validate)"
-      ],
-      "body": "## Goal\nbdd-scaffold: create the @skip-tagged, @epic-42-ac-N-tagged feature files the billing-flows implementation Stories verify against, so wave-0 lands them before any implementation Story runs.\n\n## Changes\n- {\"path\": \"tests/features/billing/invoice.feature\", \"assumption\": \"creates\"}\n- {\"path\": \"tests/features/billing/refund.feature\", \"assumption\": \"creates\"}\n\n## Acceptance\n- [ ] tests/features/billing/invoice.feature and tests/features/billing/refund.feature both exist on the branch\n- [ ] every Scenario in the two new feature files is preceded by an @skip tag\n- [ ] the invoice.feature scenario carries @epic-42-ac-1 and the refund.feature scenario carries @epic-42-ac-2\n\n## Verify\n- test -f tests/features/billing/invoice.feature && test -f tests/features/billing/refund.feature (validate)\n- test -z \"$(grep -rL '@skip' tests/features/billing/*.feature)\" (validate)\n- grep -q '@epic-42-ac-1' tests/features/billing/invoice.feature && grep -q '@epic-42-ac-2' tests/features/billing/refund.feature (validate)\n"
-    }
-
-The implementation Stories that later un-skip and flesh out these scenarios each carry `depends_on: ["scaffold-billing-feature-files"]`, placing them in a later wave than the scaffold. They MUST NOT add the `@epic-42-ac-N` tag themselves — it is already present from the scaffold pass; their job is to remove `@skip` once the scenario passes.
+> **Read [`examples.md`](./examples.md) on demand** for a fully worked wave-0
+> scaffold Story (Epic #42, two `new` rows) showing the serialized string
+> `body`, the top-level `acceptance`/`verify` arrays, the empty `depends_on`,
+> and the paired `@skip` + `@epic-<id>-ac-N` tagging.
 
 ### SCOPE-OVERLAP FLAGGING (docs/runbook downstream of config work)
 

package/.agents/skills/core/epic-plan-decompose-author/examples.md

@@ -0,0 +1,47 @@
+# epic-plan-decompose-author — examples & extended rationale
+
+Read this file on demand while authoring the ticket array. The SKILL.md carries
+the operating contract (Policy Capsule, Inputs / Outputs, Procedure, the
+authoring guidance that complements the rendered decomposer prompt, and
+Constraints); this file carries the worked WAVE-0 BDD scaffold Story and the
+extended reasoning behind it.
+
+## WAVE-0 BDD scaffold Story — worked example
+
+The contract lives in SKILL.md under **WAVE-0 BDD SCAFFOLD STORY**: when the
+Epic body's `## Acceptance Table` carries one or more `Disposition: new` rows,
+emit **exactly one** dedicated wave-0 scaffold Story whose sole job is to create
+those `.feature` files with `@skip`-tagged scenarios (each also carrying its
+namespaced `@epic-<id>-ac-N` tag) BEFORE any implementation Story runs.
+
+**Worked example.** Epic #42, Acceptance Table with two `new` rows
+(`AC-1` -> `tests/features/billing/invoice.feature`,
+`AC-2` -> `tests/features/billing/refund.feature`). The scaffold Story below
+uses a serialized string `body`, top-level `acceptance`/`verify` arrays, an
+empty `depends_on`, and tags each scenario with both `@skip` and its namespaced
+`@epic-42-ac-N` tag:
+
+    {
+      "slug": "scaffold-billing-feature-files",
+      "type": "story",
+      "title": "Scaffold @skip-tagged billing feature files",
+      "depends_on": [],
+      "labels": ["type::story", "persona::qa-engineer"],
+      "acceptance": [
+        "tests/features/billing/invoice.feature and tests/features/billing/refund.feature both exist on the branch",
+        "every Scenario in the two new feature files is preceded by an @skip tag (grep for un-skipped scenarios returns zero matches)",
+        "the invoice.feature scenario carries @epic-42-ac-1 and the refund.feature scenario carries @epic-42-ac-2"
+      ],
+      "verify": [
+        "test -f tests/features/billing/invoice.feature && test -f tests/features/billing/refund.feature (validate)",
+        "test -z \"$(grep -rL '@skip' tests/features/billing/*.feature)\" (validate)",
+        "grep -q '@epic-42-ac-1' tests/features/billing/invoice.feature && grep -q '@epic-42-ac-2' tests/features/billing/refund.feature (validate)"
+      ],
+      "body": "## Goal\nbdd-scaffold: create the @skip-tagged, @epic-42-ac-N-tagged feature files the billing-flows implementation Stories verify against, so wave-0 lands them before any implementation Story runs.\n\n## Changes\n- {\"path\": \"tests/features/billing/invoice.feature\", \"assumption\": \"creates\"}\n- {\"path\": \"tests/features/billing/refund.feature\", \"assumption\": \"creates\"}\n\n## Acceptance\n- [ ] tests/features/billing/invoice.feature and tests/features/billing/refund.feature both exist on the branch\n- [ ] every Scenario in the two new feature files is preceded by an @skip tag\n- [ ] the invoice.feature scenario carries @epic-42-ac-1 and the refund.feature scenario carries @epic-42-ac-2\n\n## Verify\n- test -f tests/features/billing/invoice.feature && test -f tests/features/billing/refund.feature (validate)\n- test -z \"$(grep -rL '@skip' tests/features/billing/*.feature)\" (validate)\n- grep -q '@epic-42-ac-1' tests/features/billing/invoice.feature && grep -q '@epic-42-ac-2' tests/features/billing/refund.feature (validate)\n"
+    }
+
+The implementation Stories that later un-skip and flesh out these scenarios each
+carry `depends_on: ["scaffold-billing-feature-files"]`, placing them in a later
+wave than the scaffold. They MUST NOT add the `@epic-42-ac-N` tag themselves —
+it is already present from the scaffold pass; their job is to remove `@skip`
+once the scenario passes.

package/.agents/skills/core/epic-plan-premortem/SKILL.md

@@ -28,14 +28,15 @@ allowed_tools:
 
 ## Role
 
-Senior Engineer + Architect, acting as a **fresh-context pre-mortem critic**.
-This Skill is deliberately *separate* from `epic-plan-decompose-author` (the
-generator) and from `epic-plan-consolidate` (the scope-preserving merge critic):
-a same-pass self-critique is the weak mode this is built to escape. The
-generator maps Epic capabilities to Stories against the spec text; this critic
-opens the **actual cited code** and asks "if I tried to deliver this exact
-backlog, where would it rework?" — before any GitHub write makes the rework
-expensive.
+Senior Engineer + Architect, acting as a **fresh-context pre-mortem critic** —
+deliberately *separate* from `epic-plan-decompose-author` (the generator) and
+`epic-plan-consolidate` (the scope-preserving merge critic) so it is a
+fresh-context, code-reading review, not a same-pass self-critique.
+
+> **Read [`examples.md`](./examples.md) on demand** for the extended rationale:
+> why this critic opens the actual cited code, why it is additive-recommendation
+> (not scope-preserving) unlike consolidation, and the three predicted-rework
+> finding classes in full.
 
 ## When to use
 

package/.agents/skills/core/epic-plan-premortem/examples.md

@@ -0,0 +1,53 @@
+# epic-plan-premortem — examples & extended rationale
+
+Read this file on demand. The SKILL.md carries the operating contract (Policy
+Capsule, Inputs / Outputs, Procedure, Constraints); this file carries the
+extended rationale behind the pre-mortem critic — why it is a separate,
+fresh-context, code-reading pass and how its three predicted-rework finding
+classes differ from the structural gates.
+
+## Why a separate fresh-context code-reading critic
+
+This Skill acts as a Senior Engineer + Architect in the role of a
+**fresh-context pre-mortem critic**. It is deliberately *separate* from
+`epic-plan-decompose-author` (the generator) and from `epic-plan-consolidate`
+(the scope-preserving merge critic): a same-pass self-critique is the weak mode
+this is built to escape. The generator maps Epic capabilities to Stories
+against the spec text; this critic opens the **actual cited code** and asks "if
+I tried to deliver this exact backlog, where would it rework?" — before any
+GitHub write makes the rework expensive.
+
+**You MUST read the actual cited code surfaces.** This is the load-bearing
+difference between this critic and the structural file-assumption gate: that
+gate proves a path **exists** (or does not); this critic reads what the file
+actually **contains**. A pre-mortem that did not open the cited files has not
+run.
+
+## Not scope-preserving (unlike consolidation)
+
+Unlike `epic-plan-consolidate` (merge-and-rewire only), this critic MAY
+recommend splitting an under-specified Story, tightening or rewording an
+acceptance criterion, or flagging an over-specified Story — because it only
+*recommends* in a report; it never applies the change itself. The conservation
+invariant belongs to consolidation; this pass is deliberately a separate,
+additive-recommendation lens. It never writes to GitHub, never persists
+`tickets.json`, and never flips a label — re-authoring on its findings is the
+author skill's job (the workflow re-runs `epic-plan-decompose-author` on the
+report before the persist call).
+
+## The three predicted-rework finding classes
+
+Hunt for the three classes the structural gates cannot catch:
+
+1. **Unverifiable acceptance criteria** — an AC no `verify[]` command or
+   readable code state can prove. Recommend a concrete verify command or a
+   reworded, checkable AC.
+2. **Over- or under-specified Stories** — a Story whose `acceptance[]` is far
+   broader or narrower than its `changes[]` footprint and the cited code
+   support. Recommend a split (under-specified: one Story doing the work of
+   several) or a tightening.
+3. **Semantically-wrong assumptions** — the cited file exists (so the
+   file-assumption gate passes) but does not contain the seam / export /
+   function / data shape the Story assumes — the file-assumption gate passes,
+   the work would still rework. Recommend the corrected target or an explicit
+   "create the seam first" Story.

package/.agents/skills/core/epic-plan-spec-author/SKILL.md

@@ -181,88 +181,28 @@ before reaching for names that appear only in the documentation. Write to
 
 #### Delivery Slicing section (authoritative ceiling for Phase 8 consolidation)
 
-The Tech Spec MUST carry a `## Delivery Slicing` section in which the Architect
-— who holds the full design — proposes how the Epic's enumerated capabilities
-**cluster into N shippable Stories**. This section is the intentional grouping
-the Phase 8 consolidation pass
+The Tech Spec MUST carry a `## Delivery Slicing` section proposing how the
+Epic's enumerated capabilities **cluster into N shippable Stories** — the
+intentional grouping the Phase 8 consolidation pass
 ([`epic-plan-consolidate`](../epic-plan-consolidate/SKILL.md)) reconciles the
-decomposer's draft against before any GitHub write. Without it, the decompose
-phase maps Epic capabilities to Stories ~1:1 and cannot produce a coarser,
-holistic plan; with it, the consolidation critic has a well-defined reference
-instead of a guess.
-
-**The proposed count is a ceiling, not a target.** Consolidation reconciles
-the draft *toward* your grouping, but it treats the count as an upper bound: it
-may **merge below** your proposed count when slices form dependent
-single-consumer chains, and it **never splits above** it. Over-slicing here
-therefore locks in fragmentation only when the extra slices are genuinely
-independent — so keep a slice separate only when it earns its own delivery
-session.
-
-**Write the Delivery Slicing section before any other section — it is the
-primary input to Phase 8 consolidation.** Author it first so the rest of the
-spec (Core Components, API Changes, Data Models) hangs off a deliberate
-slicing decision rather than being reverse-engineered into one at the end.
-Drafting it last is exactly how the model omits it under the weight of the
-other sections.
-
-Author the section as a table — one row per proposed slice — naming the
-capability cluster each slice would deliver, what ships in it, and whether it
-can ship independently. Use **noun phrases** for slice names ("Foundation",
-"Transport seam", "Send helper") so they map cleanly onto Feature titles in the
-resulting decomposition — never verb phrases ("Add transport") or file names
-("`sender.ts`"). Do **not** coarsen the Epic's capability enumeration to produce
-the slicing: the granularity lever is *this* grouping recommendation, not a
-dumbed-down Epic enumeration.
-
-**What "Independent?" means:** can this slice ship to production and provide
-value *without the next slice landing*? A `Yes` slice is releasable on its own;
-a `No` slice only becomes valuable once a later slice lands on top of it.
-
-**"Independent? No" is a smell that must be justified.** A dependent,
-single-consumer slice (one that only feeds the next slice) folds into its
-consumer by default — it is not worth its own delivery session's hydration,
-branch, PR, and CI ceremony. Mark a slice `No` only when you can name a
-one-line reason to keep it separate anyway: **parallelism** (two `No` slices
-that can be delivered concurrently by different sessions), **risk isolation**
-(a blast-radius or reviewability reason to land it as its own reviewable PR),
-or **delivery-envelope pressure** (folding it in would push the consumer past a
-single-session sizing envelope). Absent such a justification, do not author the
-slice as its own row — fold it into its consumer and let the merged slice carry
-the combined capability.
-
-Worked example:
-
-```text
-## Delivery Slicing
-
-Proposed shippable slices (consolidation ceiling for Phase 8):
-
-| Slice          | What ships                                              | Independent? |
-| -------------- | ------------------------------------------------------ | ------------ |
-| Foundation     | Config schema, types, and the no-op default path       | Yes          |
-| Transport seam | The pluggable transport interface + in-memory adapter  | Yes          |
-| Send helper    | The send() helper + retries, built on the transport    | No (justified: risk isolation) |
-
-- **Foundation** folds Epic capabilities "config surface" + "type model" — they
-  share a reason to exist and ship as one reviewable PR.
-- **Transport seam** is the pluggable boundary; it provides value on its own
-  (in-memory adapter is usable for tests) so it is independently shippable.
-- **Send helper** depends on the transport seam landing first, so it is *not*
-  independent. It stays its own slice only because the retry/backoff logic is a
-  large, high-blast-radius surface worth isolating in its own reviewable PR
-  (risk isolation). Absent that justification it would fold into Transport
-  seam — a bare "depends on the previous slice" is not a reason to keep it
-  separate.
-```
-
-The consolidation pass degrades gracefully when this section is absent (it
-falls back to cohesion + single-Story-Feature rules only), so authoring it is
-how the Architect steers the decomposition toward fewer, right-sized Stories.
-Because the count is a **ceiling**, an over-sliced table is coarsened back
-during consolidation — but only where the extra slices are dependent
-single-consumer chains, so an unjustified `No` slice is the one you should fold
-in yourself rather than leaning on the consolidator to catch.
+decomposer draft against before any GitHub write. Author it as a table (one row
+per slice: `Slice | What ships | Independent?`), using **noun-phrase** slice
+names, and **write it before any other section** — it is the primary input to
+consolidation and the section the model most often omits when it drafts it last.
+
+- **The count is a ceiling, not a target.** Consolidation may merge below it
+  (dependent single-consumer chains) but never splits above it.
+- **"Independent?"** answers: can this slice ship to production and provide
+  value without the next slice landing? Mark a slice `No` only with a one-line
+  justification (parallelism, risk isolation, or delivery-envelope pressure);
+  an unjustified dependent single-consumer slice folds into its consumer.
+- Do **not** coarsen the Epic's capability enumeration to produce the slicing;
+  the grouping recommendation is the granularity lever.
+
+> **Read [`examples.md`](./examples.md) on demand** for the worked Delivery
+> Slicing table and the extended rationale behind these rules (what
+> "Independent?" means, why an unjustified `No` slice is a smell, and how the
+> consolidation pass degrades gracefully when the section is absent).
 
 #### Tech Spec system prompt (authoritative)
 

package/.agents/skills/core/epic-plan-spec-author/examples.md

@@ -0,0 +1,91 @@
+# epic-plan-spec-author — examples & extended rationale
+
+Read this file on demand while authoring the Tech Spec. The SKILL.md carries
+the operating contract (Policy Capsule, Inputs / Outputs, Procedure, the two
+authoritative system prompts, and Constraints); this file carries the worked
+Delivery Slicing example and the extended rationale behind the slicing rules.
+
+## Delivery Slicing — extended rationale
+
+The Tech Spec MUST carry a `## Delivery Slicing` section in which the Architect
+— who holds the full design — proposes how the Epic's enumerated capabilities
+**cluster into N shippable Stories**. This section is the intentional grouping
+the Phase 8 consolidation pass
+([`epic-plan-consolidate`](../epic-plan-consolidate/SKILL.md)) reconciles the
+decomposer's draft against before any GitHub write. Without it, the decompose
+phase maps Epic capabilities to Stories ~1:1 and cannot produce a coarser,
+holistic plan; with it, the consolidation critic has a well-defined reference
+instead of a guess.
+
+**The proposed count is a ceiling, not a target.** Consolidation reconciles
+the draft *toward* your grouping, but it treats the count as an upper bound: it
+may **merge below** your proposed count when slices form dependent
+single-consumer chains, and it **never splits above** it. Over-slicing here
+therefore locks in fragmentation only when the extra slices are genuinely
+independent — so keep a slice separate only when it earns its own delivery
+session.
+
+**Write the Delivery Slicing section before any other section — it is the
+primary input to Phase 8 consolidation.** Author it first so the rest of the
+spec (Core Components, API Changes, Data Models) hangs off a deliberate
+slicing decision rather than being reverse-engineered into one at the end.
+Drafting it last is exactly how the model omits it under the weight of the
+other sections.
+
+Author the section as a table — one row per proposed slice — naming the
+capability cluster each slice would deliver, what ships in it, and whether it
+can ship independently. Use **noun phrases** for slice names ("Foundation",
+"Transport seam", "Send helper") so they map cleanly onto Feature titles in the
+resulting decomposition — never verb phrases ("Add transport") or file names
+("`sender.ts`"). Do **not** coarsen the Epic's capability enumeration to produce
+the slicing: the granularity lever is *this* grouping recommendation, not a
+dumbed-down Epic enumeration.
+
+**What "Independent?" means:** can this slice ship to production and provide
+value *without the next slice landing*? A `Yes` slice is releasable on its own;
+a `No` slice only becomes valuable once a later slice lands on top of it.
+
+**"Independent? No" is a smell that must be justified.** A dependent,
+single-consumer slice (one that only feeds the next slice) folds into its
+consumer by default — it is not worth its own delivery session's hydration,
+branch, PR, and CI ceremony. Mark a slice `No` only when you can name a
+one-line reason to keep it separate anyway: **parallelism** (two `No` slices
+that can be delivered concurrently by different sessions), **risk isolation**
+(a blast-radius or reviewability reason to land it as its own reviewable PR),
+or **delivery-envelope pressure** (folding it in would push the consumer past a
+single-session sizing envelope). Absent such a justification, do not author the
+slice as its own row — fold it into its consumer and let the merged slice carry
+the combined capability.
+
+### Worked example
+
+```text
+## Delivery Slicing
+
+Proposed shippable slices (consolidation ceiling for Phase 8):
+
+| Slice          | What ships                                              | Independent? |
+| -------------- | ------------------------------------------------------ | ------------ |
+| Foundation     | Config schema, types, and the no-op default path       | Yes          |
+| Transport seam | The pluggable transport interface + in-memory adapter  | Yes          |
+| Send helper    | The send() helper + retries, built on the transport    | No (justified: risk isolation) |
+
+- **Foundation** folds Epic capabilities "config surface" + "type model" — they
+  share a reason to exist and ship as one reviewable PR.
+- **Transport seam** is the pluggable boundary; it provides value on its own
+  (in-memory adapter is usable for tests) so it is independently shippable.
+- **Send helper** depends on the transport seam landing first, so it is *not*
+  independent. It stays its own slice only because the retry/backoff logic is a
+  large, high-blast-radius surface worth isolating in its own reviewable PR
+  (risk isolation). Absent that justification it would fold into Transport
+  seam — a bare "depends on the previous slice" is not a reason to keep it
+  separate.
+```
+
+The consolidation pass degrades gracefully when this section is absent (it
+falls back to cohesion + single-Story-Feature rules only), so authoring it is
+how the Architect steers the decomposition toward fewer, right-sized Stories.
+Because the count is a **ceiling**, an over-sliced table is coarsened back
+during consolidation — but only where the extra slices are dependent
+single-consumer chains, so an unjustified `No` slice is the one you should fold
+in yourself rather than leaning on the consolidator to catch.

package/.agents/skills/skills.index.json

@@ -1,5 +1,5 @@
 {
-  "generatedAt": "2026-07-04T00:29:42.907Z",
+  "generatedAt": "2026-07-04T23:12:38.376Z",
   "generator": "generate-skills-index.js@1",
   "skills": [
     {
@@ -567,8 +567,8 @@
       "tier": "stack",
       "category": "qa",
       "path": ".agents/skills/stack/qa/qa-explore-driving/SKILL.md",
-      "description": "Conventions for agent-driven exploratory QA driving — how the agent itself drives a surface during `/qa-explore` (agent-led), as opposed to the human-led `/qa-assist`. Use when the agent explores a running app via the browser MCP (navigation-first, the default) or walks a static surface (the documented interim until consumer persona-seeding lands), under a strictly read-only capture invariant. The exploration procedure lives in `.agents/workflows/qa-explore.md`; this skill is the driving-conventions reference it leans on.",
-      "policyCapsuleBullets": 8,
+      "description": "Conventions for agent-driven exploratory QA driving — how the agent itself drives a surface during `/qa-explore` (agent-led), as opposed to the human-led `/qa-assist`. Use when the agent explores a running app via the browser MCP (navigation-first, the default) — including authenticated deployed surfaces reached through the resolved environment's sign-in seam — or walks a static surface (the documented interim where no seam resolves), under a strictly read-only capture invariant. The exploration procedure lives in `.agents/workflows/qa-explore.md`; this skill is the driving-conventions reference it leans on.",
+      "policyCapsuleBullets": 9,
       "allowedTools": null,
       "vendor": null
     },

package/.agents/skills/stack/qa/qa-explore-driving/SKILL.md

@@ -4,9 +4,10 @@ description:
   Conventions for agent-driven exploratory QA driving — how the agent itself
   drives a surface during `/qa-explore` (agent-led), as opposed to the
   human-led `/qa-assist`. Use when the agent explores a running app via the
-  browser MCP (navigation-first, the default) or walks a static surface (the
-  documented interim until consumer persona-seeding lands), under a strictly
-  read-only capture invariant. The exploration procedure lives in
+  browser MCP (navigation-first, the default) — including authenticated
+  deployed surfaces reached through the resolved environment's sign-in seam —
+  or walks a static surface (the documented interim where no seam resolves),
+  under a strictly read-only capture invariant. The exploration procedure lives in
   `.agents/workflows/qa-explore.md`; this skill is the driving-conventions
   reference it leans on.
 ---
@@ -16,9 +17,10 @@ description:
 ## Policy Capsule
 
 - Drive the running app **by default** through the browser MCP, navigation-first: start at a root and reach each surface only via UI affordances — never URL-jump to a deep link.
-- Treat **static driving** (reading source, routes, and rendered markup without a live runtime) as the **documented interim** method, chosen at Plan time when a live runtime is not reachable — never the silent fallback.
+- Resolve the target **environment** at Plan time (via `resolveQaEnvironment`) and record its name in the ledger; each environment keys its own `baseUrl`, `signInSeam`, and `allowWrites`.
+- Treat **static driving** (reading source, routes, and rendered markup without a live runtime) as the **documented interim** method, chosen at Plan time **only where no seam resolves** for the target environment — never the silent fallback.
 - Hold the **read-only capture invariant** absolutely: the agent makes no source edits and no product mutations while driving; the only write is appending to the `temp/qa/<sessionId>` ledger.
-- Authenticated driving depends on **consumer persona-seeding infrastructure that this Epic does not deliver**; without it, drive only the unauthenticated surface or fall back to static, and record the gap — never enter real credentials or fabricate a session.
+- Authenticated driving follows the resolved environment's **`signInSeam`**: sign in through a dev `url` seam (persona name substituted into the template) or a `skill` seam (a stored `credentialRef` read by the named sign-in skill), with **mandatory redaction** of all captured evidence. Never type real credentials inline or fabricate a session; where an environment resolves no seam, drive the unauthenticated surface or fall back to static and record the gap.
 - Pick the driving method explicitly in the Plan phase (drive vs. static) and record it in the ledger; do not switch methods mid-surface without a new Plan note.
 - Every phase transition and every GitHub write is HITL-gated; the agent drives and captures, but never files or promotes findings autonomously.
 - Broken navigation, a missing affordance, or a guard redirect loop is a **finding**, not a workaround — record it and move on; do not route around it with a direct URL.
@@ -65,15 +67,14 @@ state rather than an artifact of a deep link.
 
 ## 2. Static Driving — the Documented Interim
 
-Static driving is the **explicitly documented interim** method for when a live
-runtime is not reachable — most commonly because authenticated driving needs
-consumer persona-seeding infrastructure that does not yet exist (§ 4). It walks
-the surface from source, route definitions, and rendered markup rather than a
-running browser.
+Static driving is the **explicitly documented interim** method for when **no
+seam resolves** for the target environment — the resolved environment carries
+no `signInSeam` the agent can drive through (§ 4). It walks the surface from
+source, route definitions, and rendered markup rather than a running browser.
 
 - **Choose it at Plan time, never silently.** Static is a deliberate Plan-phase
-  decision recorded in the ledger ("method: static, reason: no reachable
-  authenticated runtime"), not an unannounced fallback the agent slips into
+  decision recorded in the ledger ("environment: preview, method: static,
+  reason: no seam resolves"), not an unannounced fallback the agent slips into
   when the browser MCP hiccups.
 - **It is interim, not equivalent.** Static driving cannot exercise real
   authorization, routing guards, or runtime console/network signal. Treat its
@@ -81,10 +82,10 @@ running browser.
   same coverage a driven pass would.
 - **Same read-only invariant.** Static driving reads source and routes; it makes
   no edits. The read-only capture invariant (§ 3) applies identically.
-- **Promote to driving when the runtime lands.** Static is the bridge until the
-  consumer's persona-seeding infrastructure (§ 4) makes authenticated driving
-  possible. When that lands, re-run the surface driven; do not leave a surface
-  permanently static when it could be driven.
+- **Promote to driving when a seam lands.** Static is the bridge until the
+  target environment resolves a `signInSeam` (§ 4) that makes driven
+  authenticated exploration possible. When that lands, re-run the surface
+  driven; do not leave a surface permanently static when it could be driven.
 
 ## 3. The Read-Only Capture Invariant
 
@@ -109,29 +110,42 @@ and the Epic's security considerations — it is not a soft preference.
   (ticket creation, promotion) happen only behind an operator confirmation gate.
   The agent never files or promotes findings autonomously.
 
-## 4. Authenticated Driving Depends on Consumer Infra (Not Delivered Here)
-
-Driving an **authenticated** surface requires signing in as a seeded persona.
-That seeding — provisioning a test persona with the right org, role, and data
-so the agent can reach a logged-in surface navigation-first — is **consumer
-persona-seeding infrastructure that this Epic does not deliver**. It is an
-explicit non-goal of the `/qa-explore` rebuild.
-
-- **Unauthenticated surface only, by default.** Without persona-seeding infra in
-  the consumer project, drive only the surface reachable without sign-in, or
-  fall back to static driving (§ 2) for the authenticated surface. Record the
-  gap in the ledger so the partial coverage is visible.
-- **Never enter real credentials.** The agent MUST NOT type real usernames,
-  passwords, or tokens to reach an authenticated surface, and MUST NOT fabricate
-  or forge a session. This is a hard security boundary, not a convenience to
+## 4. Authenticated Driving Follows the Per-Environment Seam
+
+Driving an **authenticated** surface requires signing in. The resolved target
+environment (via `resolveQaEnvironment`, § Policy Capsule) carries the
+`signInSeam` the agent drives through — the same discriminated-union shape
+`qa-harness` resolves via its contract. When a seam resolves, authenticated
+deployed surfaces are **driven**, not statically deferred.
+
+- **Drive the authenticated surface through the seam.** When the target
+  environment carries a `signInSeam`, sign in via that seam and then reach the
+  authenticated surface navigation-first — including authenticated **deployed**
+  hosts. The two seam kinds:
+  - **`kind: 'url'` (dev impersonation).** Substitute the persona **name** into
+    the seam's URL template and navigate there. The persona name is the sole
+    input; no per-persona auth material is read.
+  - **`kind: 'skill'` (procedural / credential).** Invoke the named consumer
+    sign-in skill, which reads a per-persona **`credentialRef`** — an indirect
+    handle to a stored credential, never an inline secret. Read the skill's
+    `SKILL.md` and follow it.
+- **Never enter real credentials inline.** The agent MUST NOT type real
+  usernames, passwords, or tokens to reach an authenticated surface, and MUST
+  NOT fabricate or forge a session. Sign-in flows only through the seam, which
+  consumes a persona name or a `credentialRef` indirection — never a
+  hand-typed secret. This is a hard security boundary, not a convenience to
   work around.
-- **The dependency is the consumer's to satisfy.** When a consumer wants driven
-  authenticated exploration, the consumer supplies a dev sign-in seam and seeded
-  personas (the same shape `qa-harness` resolves via its contract). Until then,
-  authenticated coverage is static or deferred — say which in the ledger.
-- **Surface the gap, don't paper over it.** A surface that could not be driven
-  because authenticated seeding is absent is itself a coverage signal worth
-  recording, not a silent skip.
+- **Redaction is mandatory.** Every captured evidence string — console,
+  network, headers — passes through the shared redaction path (§ 3) before it
+  reaches disk or GitHub; bearer tokens, session cookies, `Authorization`
+  headers, and PII are masked. Authenticated driving raises the stakes on
+  redaction, it does not relax it.
+- **Static only where no seam resolves.** When the target environment resolves
+  **no** `signInSeam`, drive only the unauthenticated surface or fall back to
+  static driving (§ 2), and record the gap in the ledger so the partial
+  coverage is visible. A surface that could not be driven because the
+  environment carries no seam is itself a coverage signal worth recording, not
+  a silent skip.
 
 ## 5. Cross-References