pi-gauntlet 4.12.0 → 4.12.2

package/CHANGELOG.md

@@ -1,5 +1,19 @@
 # Changelog
 
+## v4.12.2 - 2026-08-19
+
+- New `skills/shape-ticket/reference/split-axes.md`: the shared split test for tickets and specs - identity test (same precipitating failure / mooted outcome = one concern), user-observable outcome test, closed axis list with pass/fail examples, Never-axis list (fix location, service/repo/layer/team, "keep tickets small"), discovery-conversion exemption, fail-closed release-timing precondition gated on a documented `## Deployment` overrides section.
+- `shape-ticket`: split rule rewritten around that test - one ticket is the default; each proposed slice carries a three-line justification block (root cause / outcome / axis) at the gate; roast brief gains a split-soundness axis with a `split-axis:` finding marker the parent scans from member files directly (the chair cannot clear it; merge auto-applied, pre-merge bodies kept for gate resurrection); two-tier sticky human override (deterministic failures need evidence, member-flag withdrawals resurrect on a plain yes). "Vertical/horizontal" vocabulary retired.
+- `brainstorming`: scope check defaults to one spec; a multi-spec offer must render the three-line justification per spec and pass the shared test; failing splits are never offered.
+- `writing-plans`: scope check splits on documented deploy topology (fail closed) or review-risk isolation - never service/contract/schema count.
+- README: new `## Deployment` gauntlet-overrides section documented (deploy topology is a looked-up fact, never inferred; absent or monolithic topology disables the release-timing split axis).
+
+## v4.12.1 - 2026-08-19
+
+- `check-delivery`: two new `## Delivery` overrides slots - `synthesized AC gaps: block|soft` (default `soft`; `block` runs synthesized ACs through the same verdict matrix as authored ones, so an unexplained gap blocks) and `descope edits: strikethrough` (default none; on gate approval, ratified `proposed descope` AC lines are struck in the ticket body with an evidence-drafted reason, write order body -> comment -> status, surgical patch against the re-fetched body, whole-write manual degradation when no edit-body verb resolves). Single-ticket scope boundary recorded in the skill: sweep/reconciliation passes stay consumer territory.
+- `shape-ticket`: the batched write may include one optional gated Reporter-note comment per approved issue (overflow of demoted Idea material; verbatim at the same single confirmation gate; missing post-comment verb degrades to manual posting, never silently dropped). Roast dispatch failure now retries once with fresh artifacts; a second failure is surfaced inline at the gate (`roast unavailable (dispatch failed twice: <reason>)`) instead of a silent note.
+- README: both skills' contracts synced (slot docs, five-verb custom-tracker contract incl. `post comment`).
+
 ## v4.12.0 - 2026-08-18
 
 - New skill: `check-delivery` - explicit-only post-merge detective control: proves an issue actually shipped (SHA-bound squash-aware default-branch landing, optional deploy-watch + delivery-target check, per-AC evidence with a 6-verdict table and reviewer script) before its tracker status advances; never writes a terminal state; single human-gated batched write with `Delivered: <sha>` marker idempotency; generic across `gh`/`linearis` with a 7-slot `## Delivery` overrides contract so consumer closeout prompts reduce to an overrides block plus a one-line wrapper.

package/README.md

@@ -35,7 +35,7 @@ pi-gauntlet's only hard dependency is pi-cohort - every gate that dispatches a r
 
 Concretely, one change through the gauntlet:
 
-0. *(Optional)* Before there's even a spec, `/skill:shape-ticket` can create or repair a single tracker issue - shaping a raw ask into a Context/Problem/Idea/Acceptance Criteria ticket, gated by an AC integrity check, a cheap council roast, and one human-confirmed write. It's a tool, not a phase: no worktree, no plan/phase tracker, runs from any repo state. It never activates on its own (`disable-model-invocation: true`) - invoke it explicitly.
+0. *(Optional)* Before there's even a spec, `/skill:shape-ticket` can create or repair a single tracker issue - shaping a raw ask into a Context/Problem/Idea/Acceptance Criteria ticket, gated by an AC integrity check, a cheap council roast, and one human-confirmed write that may include one optional gated Reporter-note comment. A failed roast is retried once, then surfaced inline at the gate if it fails again. It's a tool, not a phase: no worktree, no plan/phase tracker, runs from any repo state. It never activates on its own (`disable-model-invocation: true`) - invoke it explicitly.
 1. You describe the change. **`brainstorming`** sets up an isolated worktree, explores the codebase, and turns your description into a written spec. A multi-model critique runs on it automatically. If the spec replaces a known prior spec, brainstorming marks the predecessor with a `> **Superseded by:**` banner under its title (default format, syntax overridable via `.pi/gauntlet-overrides.md`; event-driven only — gauntlet never sweeps historical specs). **You read and approve the spec - human gate 1.** No implementation code exists yet.
 2. **`writing-plans`** decomposes the approved spec into atomic, independently-verifiable tasks, grouped into parallel waves where they don't touch the same files.
 3. **`subagent-driven-development`** executes the plan one task at a time, each in a fresh subagent, behind spec-compliance review then code-quality review. TDD-locked: red, green, refactor.
@@ -144,7 +144,7 @@ Section headers should match skill names (`## verification-before-completion`) o
 
 **Discovery ladder:** skills check three locations, in order, and use the first one found - never merged: `.pi/gauntlet-overrides.md`, then `<repo root>/gauntlet-overrides.md`, then `<repo root>/doc/gauntlet-overrides.md` (`<repo root>` = `git rev-parse --show-toplevel`, or the current directory outside a repo). Pick one location per repo.
 
-**`## Issue tracker` section:** `shape-ticket` resolves tracker access through a capability ladder, and this is its first rung - it overrides the zero-config `gh` (GitHub) / `linearis` (Linear) defaults for any other tracker. Name the CLI's read, search, create, and update commands explicitly. For a Jira CLI, for example:
+**`## Issue tracker` section:** `shape-ticket` resolves tracker access through a capability ladder, and this is its first rung - it overrides the zero-config `gh` (GitHub) / `linearis` (Linear) defaults for any other tracker. Name the CLI's read, search, create, update, and post comment commands explicitly. For a Jira CLI, for example:
 
 ```markdown
 ## Issue tracker
@@ -155,9 +155,18 @@ Use the `jira` CLI (authenticated via `jira login`), not `gh` or `linearis`.
 - search (dup/reversal check): `jira issue search --jql "project = ABC AND text ~ '<query>'"`
 - create: `jira issue create --project ABC --type Task --summary "<title>" --description "<body>"`
 - update: `jira issue edit ABC-123 --summary "<title>" --description "<body>"`
+- post comment (Reporter note only): `jira issue comment ABC-123 --body "<text>"`
 ```
 
-**`## Delivery` section:** `check-delivery` resolves its overrides through the same discovery ladder. Defaults are pessimistic where it matters: an unset `target state` keeps the write comment-only; unset `deploy watch`/`delivery target` skip stage 2 (reported, never silently passed); `browser evidence` defaults to never. The remaining slots have working defaults shown below:
+**`## Deployment` section:** `shape-ticket` (split rule), `writing-plans` (scope check), and `brainstorming` (scope check) read deploy topology from this section: what ships together, what ships independently, and the mechanism. It is a fact to look up, never to infer - when the section is absent, or when it documents a monolithic topology (like the example below), the "separable release timing" split axis is unavailable and splits fail closed to one artifact.
+
+```markdown
+## Deployment
+
+One deploy workflow ships the whole system at once - nothing ships independently.
+```
+
+**`## Delivery` section:** `check-delivery` resolves its overrides through the same discovery ladder. Defaults are pessimistic where it matters: an unset `target state` keeps the write comment-only; unset `deploy watch`/`delivery target` skip stage 2 (reported, never silently passed); `browser evidence` defaults to never. `check-delivery` is single-ticket by design - sweep/reconciliation passes over many tickets stay consumer territory, invoking the skill once per ticket. The remaining slots have working defaults shown below:
 
 | Slot | Meaning | Default (unset) |
 |---|---|---|
@@ -168,6 +177,17 @@ Use the `jira` CLI (authenticated via `jira login`), not `gh` or `linearis`.
 | `browser evidence` | When/how to capture UI evidence (requires a browser tool) | never |
 | `ref convention` | How commits/PRs reference tickets (e.g. `(ref ABC-123)`) | tracker-native forms (`#N`, `Fixes #N`, bare `ABC-123`) |
 | `AC location` | Where ACs live if not the ticket body | ticket body |
+| `synthesized AC gaps` | `block` or `soft` - whether an unmet synthesized AC produces a blocking `unexplained gap` or a non-blocking proposal | `soft` |
+| `descope edits` | `strikethrough` - on gate approval, strike ratified `proposed descope` AC lines in the ticket body | none - no body edits ever |
+
+Malformed slot values fail safe, with one warning per invocation naming the
+bad value: `synthesized AC gaps` treats anything other than `block`/`soft`
+as `soft`; `descope edits` treats anything other than `strikethrough` as
+unset (no body edits). `descope edits` also requires a resolved edit-body
+write verb: when the slot is active and the approval ratifies a `proposed
+descope` but no edit-body verb resolves, the whole batched write (body
+edit, evidence comment, status advance) degrades to manual - none
+auto-posted.
 
 ```markdown
 ## Delivery
@@ -176,6 +196,8 @@ Use the `jira` CLI (authenticated via `jira login`), not `gh` or `linearis`.
 - delivery target: curl -fsS https://staging.example.com/version | grep <sha>
 - timeout: 15m
 - ref convention: (ref ABC-123)
+- synthesized AC gaps: block
+- descope edits: strikethrough
 ```
 
 ## REVIEW.md convention

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-gauntlet",
-  "version": "4.12.0",
+  "version": "4.12.2",
   "description": "Opinionated, gated workflow skills, subagent personas, and runtime extensions for the pi coding agent.",
   "author": "Jacek Juraszek",
   "type": "module",

package/skills/brainstorming/SKILL.md

@@ -109,11 +109,17 @@ Require one of: finish prior work, stash, or explicit "continue here". If the to
 
 ### 2. Scope check
 
-If the request spans multiple independent subsystems (e.g., "build a new ingestion pipeline and a new admin UI and a new auth flow"), stop and flag it:
+One spec is the default. If the request looks like multiple independent concerns (e.g., "CSV import for operators, plus a partner-facing status API" - different actors, different problem statements), test each candidate slice against `../shape-ticket/reference/split-axes.md` (identity test, outcome test, closed axis list, release-timing precondition). A multi-spec offer renders the three-line justification per proposed spec - root cause / outcome / axis:
 
-> "This looks like 2-3 independent specs to me — A, B, C. Should we brainstorm each separately, or is there a tight coupling I'm missing?"
+    root cause: <the precipitating failure or missing capability this slice remedies>
+    outcome: <what a user observes once it ships>
+    axis: <one item from the closed list>
 
-Don't try to design a multi-subsystem monolith in one spec doc.
+a slice failing any part -> one spec, and the failed split is not offered:
+
+> "This looks like 2 independent specs to me - A (axis: <axis>), B (axis: <axis>). Should we brainstorm each separately, or is there a tight coupling I'm missing?"
+
+Never split on service, package, repo, layer, or team boundaries - a single feature, bug, or improvement routinely cuts through many layers, and one spec covers it. A genuinely multi-concern request designed as one spec is still wrong; decompose it, but only along a passing axis.
 
 ### 3. Understand the idea
 
@@ -379,7 +385,7 @@ phase_tracker({ action: "complete", phase: "brainstorm" })
 - About to proceed to `/skill:writing-plans` before the user has approved the spec (proceeding *after* approval is correct; skipping the gate is the violation)
 - About to finish spec-writing for a replacement design without marking the known predecessor (see [Marking superseded specs](#marking-superseded-specs))
 - Spec contains `TODO`, `TBD`, or unnamed components
-- Spec spans multiple independent subsystems with no decomposition flag
+- About to offer a multi-spec split that fails the split test in `../shape-ticket/reference/split-axes.md`, or without its three-line justification per spec
 - User said "this is just a small change" and you accepted it without applying the [Anti-Pattern](#anti-pattern-too-simple-to-need-a-design) check
 
 ## Project overrides

package/skills/check-delivery/SKILL.md

@@ -15,14 +15,16 @@ disable-model-invocation: true
 | Comments amend/contradict the body's ACs | pause for operator resolution, then proceed - never silently pick a reading |
 | Zero ACs after extraction and synthesis | STOP - "cannot verify a ticket that asserts nothing" |
 | Genuine open deliverable PR found | STOP - "work still in flight" |
-| Same shipped SHA already recorded (marker + target state reached) | "already recorded" - no write |
+| Same shipped SHA already recorded (marker + target state reached) | "already recorded" - no write (body-only descope repair excepted - see stage 0) |
 | Deliverable set ambiguous, or not on default branch | STOP - abort, no write |
 | Delivery target configured but unreachable / times out / can't bind to the SHA | STOP - abort, no write |
 | Any AC verdict is `unexplained gap` | Failure path - no delivery write; findings comment offered, gated |
 | All ACs clear (incl. proposals, non-observable, unverified-no-target) | One confirmation gate, then one batched write |
 | No delivery target configured | Stage 2 reported skipped - never silently passed |
 | No target state configured | Comment only - never guesses a workflow state |
-| Missing write capability | Full verification + both write halves emitted for manual execution |
+| Missing write capability | Full verification + every write half that exists this run emitted for manual execution |
+| Unmet synthesized AC | Non-blocking proposal under `synthesized AC gaps: soft` (default); same verdict matrix as authored ACs under `block` |
+| Ratified `proposed descope` + `descope edits: strikethrough` | Body edit joins the batched write: body -> comment -> status |
 
 ## Overview
 
@@ -52,6 +54,17 @@ Explicit invocation only (`/skill:check-delivery <ticket-ref>`), read-only
 against the repository (no builds, no branch/tag/worktree mutation) plus at
 most one batched tracker write, runs from wherever invoked, no worktree.
 
+## Scope boundary
+
+Single-ticket by design: the pipeline's depth (repo-identity preflight,
+stage-1 landed-commit resolution, per-AC evidence binding, one human gate
+with pre-write re-fetch) does not loop soundly - N tickets means N gates,
+or a batch gate that dilutes per-ticket consent. Sweep passes (bucketing
+open tickets, orphan scans for merged-but-unreferenced work) are
+portfolio triage - a different control, inherently project-flavored - and
+stay consumer territory. A consumer sweep may invoke this skill per
+ticket as its verification step.
+
 ## Hard constraint
 
 Input is exactly one tracker ref (`ABC-123`, `#N`, `owner/repo#N`, or a
@@ -77,10 +90,14 @@ Resolved in order:
 4. Ask the user.
 
 Missing **read** capability = STOP. Missing **write** capability degrades
-gracefully: run the full verification, then emit **both halves** of the
-batched write for manual execution - the evidence-comment text, and, when a
-target state is configured, the exact status-advance command - reporting the
-advance as not performed.
+gracefully on ordinary runs: run the full verification, then emit every
+write half that exists this run for manual execution - the
+evidence-comment text, and, when a target state is configured, the exact
+status-advance command - reporting the advance as not performed. When
+`descope edits` is active and the approval ratifies a `proposed descope`
+but no edit-body verb resolves, the **whole** batched write degrades to
+manual instead: body edit, evidence comment, and status advance (when
+configured) all emitted for manual execution, none auto-posted.
 
 **Zero-config verb table** (overrides replace it):
 
@@ -89,6 +106,7 @@ advance as not performed.
 | read issue + comments | `gh issue view <n> --json title,body,comments` | `linearis issues read <id> --with-comments` |
 | post comment | `gh issue comment <n> --body ...` | `linearis issues discuss <id> --body ...` |
 | update state | override-defined only (never invented labels/columns) | `linearis issues update <id> --status <name>` |
+| edit body (only `descope edits`) | `gh issue edit <n> --body ...` | `linearis issues update <id> --description ...` |
 
 ## Verification pipeline
 
@@ -107,9 +125,14 @@ current tracker status first: if it is already in a terminal/done state,
 report that and stop cleanly - no write; a terminal ticket is never
 downgraded to the configured non-terminal target state. Extract ACs
 from the AC section; if none exists, synthesize candidate ACs from the body,
-label them synthesized, and **cap their blocking power** - a synthesized AC
-never produces a blocking `unexplained gap`; unmet ones surface as
-non-blocking proposals at the gate. If a comment amends or contradicts a
+label them synthesized. Their blocking power follows the `synthesized AC
+gaps` slot: under `soft` (the default) a synthesized AC never produces a
+blocking `unexplained gap` - unmet ones surface as non-blocking proposals
+at the gate; under `block` the cap is removed - synthesized ACs run the
+same stage 3 verdict matrix as authored ACs, so an unmet one with no
+sanctioned explanation is a blocking `unexplained gap` (`allowed gap` and
+`proposed descope` remain available outcomes exactly as for authored ACs).
+If a comment amends or contradicts a
 body AC, surface the conflict to the operator and get an explicit
 resolution before proceeding - never silently pick a reading. If
 extraction and synthesis together yield zero candidate ACs, STOP:
@@ -121,6 +144,13 @@ configured) was already reached -> report "already recorded" and stop
 cleanly - success, no write. If the marker exists but the target state
 was not reached, skip the duplicate comment but still offer the status
 write (comment-landed/status-failed repair, per Idempotency below).
+Exception when `descope edits: strikethrough` is configured: if a prior
+run's evidence comment records a `proposed descope` whose matching AC line
+in the body is still unstruck, the run is **not** "already recorded" - it
+short-circuits to a gated body-only repair: the strike is presented at the
+confirmation gate, resolving only the shipped SHA already recorded in the
+marker (no fresh stage 1-3 re-verification); on approval, only the body
+edit executes - no duplicate comment, no status advance.
 
 **Stage 1 - Merge landed.** One ordered algorithm, not a toolbox:
 
@@ -212,7 +242,10 @@ explicit yes-gate as the success path. Never posted unprompted.
 All-clear path -> **one confirmation gate**: present the shipped SHA,
 deliverable set, stage results (including any skip), the per-AC verdict
 table with evidence, the reviewer script, and the exact write about to
-happen. On approval, one batched write:
+happen. On approval, one batched write. The numbered steps below are the
+ordinary-run shape; when a ratified descope strike is in play, the
+body-edit half precedes step 1 - see the `descope edits` paragraph below
+for its mechanics, not repeated here:
 
 1. **Evidence comment** - marker line `Delivered: <sha>` as the first line,
    the deliverable set (PR links), stage 2 outcome (or "skipped: no
@@ -224,13 +257,53 @@ happen. On approval, one batched write:
    state, never invents a label.
 
 Comment first, status last, so a partial failure leaves evidence without a
-misleading state. Before writing, re-fetch the ticket: if ACs or status
-changed since gather, re-present the delta instead of writing. Declining
-the gate = no write, report stays in-session.
+misleading state - this is the stated order for ordinary runs. Before
+writing, re-fetch the ticket: if ACs or status changed since gather,
+re-present the delta instead of writing. Declining the gate = no write,
+report stays in-session.
+
+When `descope edits: strikethrough` is configured and the approval
+ratifies one or more `proposed descope` ACs, the batched write gains a
+body-edit half, ordered **body edit -> evidence comment -> status
+advance** - a partial failure never leaves a status advanced against a
+body still advertising a descoped AC. A failed body-edit half aborts the
+remaining halves outright: the comment and status advance do not run. Any
+partial failure reports exactly which halves landed and which did not.
+The edit strikes exactly the ratified AC lines and nothing else: the AC's
+list item is preserved, its text struck, and a one-line reason appended -
+`- [ ] ~~<AC text>~~ - descoped: <one-line reason>`. The checkbox is
+rendered exactly as found (`- [x]` stays `- [x]`, `- [ ]` stays `- [ ]`) -
+the edit never flips checked state. The reason is one sentence drafted
+from the verdict's evidence, never invented.
+
+Strike-target identity: the target is the AC-section list item whose
+normalized text equals the verdict's AC text - normalize by stripping the
+list marker and checkbox, collapsing internal whitespace, and comparing
+the remaining text case-insensitively. When `AC location` is not
+the ticket body, or no unique matching list item exists (synthesized,
+prose, duplicate, or multi-line ACs), the strike is skipped for that AC,
+reported as skipped at the gate, and the evidence comment carries the
+descope record alone. A line already containing `~~` and `- descoped:`
+counts as struck and is skipped.
+
+Both zero-config edit verbs replace the whole body, so the strike is
+applied as a surgical patch against the freshly re-fetched body at write
+time - never by replaying the gather-time snapshot. If the target lines
+moved or changed, re-present the delta instead of writing.
+
+The exact before/after of the struck lines is presented at the same
+single confirmation gate as the comment and status - one approval covers
+all halves, including every proposed strike; there is no per-strike
+subset selection, so objecting to one strike declines the whole gate this
+round. Descope edits occur only on the all-clear batched write - the
+failure path writes no body edit.
 
 ## Idempotency and concurrency
 
-Append-only, at-least-once. Same shipped SHA already marked -> skip the
+Append-only, at-least-once for comments - a comment is never edited once
+posted. The ratified-descope body strike is the one sanctioned in-place
+body edit; it does not change this comment guarantee. Same shipped SHA
+already marked -> skip the
 duplicate comment, but still offer the status write if the configured
 target state was not reached on the prior run (comment-landed /
 status-failed repair). A newer shipped SHA -> a fresh comment, never an
@@ -252,6 +325,8 @@ the newer SHA.
 | `browser evidence` | When/how to capture UI evidence (requires a browser tool) | never |
 | `ref convention` | How commits/PRs reference tickets (e.g. `(ref ABC-123)`) | tracker-native forms (`#N`, `Fixes #N`, bare `ABC-123`) |
 | `AC location` | Where ACs live if not the ticket body | ticket body |
+| `synthesized AC gaps` | `block` or `soft` - whether an unmet synthesized AC produces a blocking `unexplained gap` or a non-blocking proposal | `soft` |
+| `descope edits` | `strikethrough` - on gate approval, strike ratified `proposed descope` AC lines in the ticket body | none - no body edits ever |
 
 Worked example:
 
@@ -270,6 +345,11 @@ contract: a consumer's closeout prompt reduces to a `## Delivery` block plus
 a one-line wrapper invoking this skill. Worktree cleanup is out of scope -
 that belongs to `finishing-a-development-branch`.
 
+Malformed slot values fail safe, with one warning per invocation naming the
+bad value: `synthesized AC gaps` treats anything other than `block`/`soft`
+as `soft`; `descope edits` treats anything other than `strikethrough` as
+unset (no body edits).
+
 ## Rationalization table
 
 | Excuse | Reality |
@@ -280,6 +360,7 @@ that belongs to `finishing-a-development-branch`.
 | "No target configured, so delivery passed" | Unconfigured is a reported **skip**, never a silent pass |
 | "The ticket says done in a comment" | Ticket narrative is not evidence; only SHA-pinned code or target observations count |
 | "Just move it to Done, the human can reopen" | Never a terminal status - acceptance is the human's move, not this skill's |
+| "The AC was only synthesized, so the gap can't block" | Under `synthesized AC gaps: block`, a synthesized AC runs the same verdict matrix as an authored one - an unexplained gap blocks |
 
 ## Red flags - STOP
 
@@ -298,6 +379,9 @@ that belongs to `finishing-a-development-branch`.
 - Silently picking a reading when a comment amends or contradicts a body AC
 - Continuing verification with zero candidate ACs
 - Advancing past a genuine open deliverable PR
+- Striking an AC line the gate approval did not ratify as `proposed descope`
+- Applying a body edit by replaying the gather-time snapshot instead of
+  patching the re-fetched body
 
 ## Project overrides
 

package/skills/shape-ticket/SKILL.md

@@ -13,7 +13,7 @@ disable-model-invocation: true
 | Free text / vague ask, no ticket ref | Create mode: gather -> dup-check -> draft -> gates -> roast -> confirm -> write (9-step pipeline below) |
 | Issue ref (`#N`, `ABC-123`, URL) | Repair mode: fetch full ticket + 1-hop links -> diff old->new -> gates -> roast -> confirm -> re-fetch and re-diff before write (9-step pipeline below) |
 | Ref + extra text | Repair mode, extra text folded into gather |
-| Ticket already conforms + metadata clean | No-op: report and stop, no gate, no write |
+| Ticket already conforms + metadata clean + no Reporter note proposed | No-op: report and stop, no gate, no write |
 | AC is wishful/tautological | Hard stop for the whole run - no write until fixed or split to discovery |
 | AC is unspecified-but-binding or needs external input | Ticket filed, parked in not-ready state, blocker named |
 | Independent shippable slices detected | Split proposed at the gate, one approval, per-issue subset selection |
@@ -25,7 +25,7 @@ Every path that writes ends at the **same single confirmation gate** - no write
 
 One process, two entry points: **create** a new tracker issue from a prompt, or **repair** an existing one by re-fetching it and proposing a full replacement. Repair is never a silent patch - it is always shown old->new, links and tracker fields preserved. Running this skill on any ticket trues it up; repeated use is a self-healing backlog pass.
 
-**Core principle:** the ticket carries **what and why, never how**. A prescribed solution in the source material is demoted to the **Idea** section as an attributed sketch ("reporter's proposed approach: ...") - never the Problem, never an Acceptance Criterion, never a tracker comment.
+**Core principle:** the ticket carries **what and why, never how**. A prescribed solution in the source material is demoted to the **Idea** section as an attributed sketch ("reporter's proposed approach: ...") - never the Problem, never an Acceptance Criterion, never an *ungated* tracker comment - the one gated Reporter-note comment (step 4) is the sole exception.
 
 **Violating the letter of the rules is violating the spirit of the rules.** "The gate basically happened" is not the gate happening.
 
@@ -41,7 +41,7 @@ It is a tool, not a phase: no `plan_tracker`, no `phase_tracker`, no worktree re
 - **Free text or no argument** -> **create mode**, from the argument plus surrounding conversation.
 - **Ref + extra text** -> repair mode, with the text folded into gather.
 - **Unreadable ref** -> abort repair, offer create mode from any accompanying text. Never guess ticket content from a ref you cannot fetch.
-- **Out of scope**: read-only asks (search, status lookup) and administrative writes (status transitions, posting comments) - use the tracker CLI directly.
+- **Out of scope**: read-only asks (search, status lookup) and administrative writes (status transitions, standalone comment posts) - use the tracker CLI directly; the gated Reporter-note comment inside a create/repair write is the sole comment exception.
 
 ## The pipeline
 
@@ -67,13 +67,27 @@ One question at a time, only when intent is unclear or no AC is derivable. Never
 
 Full replacement body: `Context` / `Problem` / `Idea` / `Acceptance Criteria`, plus optional `Out of scope / Follow-up` and `Post-deployment housekeeping`. Apply the wording rules (below). Preserve links and tracker fields.
 
+The draft may propose **at most one comment per approved issue**, e.g.
+`Reporter note: <demoted detail>`. Overflow test: the Idea section keeps
+exactly one attributed sketch line; any demoted material left over after
+that line is overflow, and the overflow is the comment body (long pasted
+code, verbose repro trails, a full proposed diff are the typical shapes).
+No overflow, no comment - unless the user asks in-session, in which case
+the user-named content is the comment body and stands in for overflow.
+Default off: overrides cannot force a comment absent overflow or an
+in-session ask. In repair mode an existing `Reporter note:` comment
+satisfies the overflow (skip), unless the demoted detail materially changed, in which case a new comment
+is proposed - comments are never edited. In a split, the comment attaches
+only to the issue that retained the demoted Idea material; if none does,
+it is omitted.
+
 ### 5 - Deterministic gates
 
 Before any subagent dispatch, inline and cheap: AC integrity gate, evidence gate, metadata audit, split detection (all below).
 
 ### 6 - No-op check
 
-If the body already conforms AND the metadata audit is clean: report "conforms, no changes proposed" and stop. No write, no confirmation prompt, no roast. A conforming ticket never pays for a dispatch.
+If the body already conforms AND the metadata audit is clean AND no Reporter note is proposed: report "conforms, no changes proposed" and stop. No write, no confirmation prompt, no roast. A conforming ticket never pays for a dispatch - a conforming body with pending overflow still reaches the gate.
 
 ### 7 - Roast
 
@@ -88,13 +102,14 @@ Present, per proposed issue:
 - Metadata changeset: `field: current -> proposed -- why` lines.
 - Evidence list.
 - Roast dispositions: applied / surfaced-ambiguous.
-- Split proposal, if any.
+- Split proposal, if any: per slice, the three-line justification block (see Split rule). A withdrawn split is reported with the `split-axis:` finding that killed it, so the user can re-request it (sticky; see Split rule).
+- Proposed Reporter-note comment, verbatim, if any - one approval covers title + body + metadata + comment; no affirmative on the exact text = no comment.
 
 Number the options. A split offers per-issue subset selection, e.g. "approve 1,3; decline 2". **No affirmative answer on the exact presented diff = no write.**
 
 ### 9 - Write
 
-Immediately before mutation - after approval, not at gate-open. Repair mode: re-fetch the ticket and diff against the exact snapshot the user approved (use tracker version/ETag preconditions where the CLI exposes them); any mismatch (human edited mid-review) loops back to step 8 with the delta. Create mode: no ticket exists yet, so there is nothing to re-fetch or diff - write the approved body as-new. Then one batched write per approved issue; a split is N gated writes under the one approval, honoring subset selection. Mid-batch failure: report exactly what landed; the remaining changeset is preserved for retry.
+Immediately before mutation - after approval, not at gate-open. Repair mode: re-fetch the ticket and diff against the exact snapshot the user approved (use tracker version/ETag preconditions where the CLI exposes them); any mismatch (human edited mid-review) loops back to step 8 with the delta. Create mode: no ticket exists yet, so there is nothing to re-fetch or diff - write the approved body as-new. Then one batched write per approved issue, body first, then the approved Reporter-note comment if any; a split is N gated writes under the one approval, honoring subset selection. Mid-batch failure: report exactly what landed; the remaining changeset is preserved for retry.
 
 ## AC integrity gate
 
@@ -137,9 +152,19 @@ The gate never bans discovery; it forces discovery to be its own honestly-labele
 
 ### Split rule
 
-Detected during the audit: independent deliverables that form separately shippable, separately verifiable AC clusters. Proposed at the confirmation gate (N bodies: one scoped-down original + N-1 new, each old->new or as-new) - one approval covers the batch, with subset selection. Decline -> single issue with the decomposition made explicit as phased AC groups; never a silently accepted monolith.
+Detected during the audit: independent deliverables that form separately shippable, separately verifiable AC clusters. **A split is the exception; one ticket is the default.** Proposed at the confirmation gate (N bodies: one scoped-down original + N-1 new, each old->new or as-new) - one approval covers the batch, with subset selection. Decline -> single issue with the decomposition made explicit as phased AC groups; never a silently accepted monolith.
+
+**Split test.** Apply `reference/split-axes.md` (resolve the path against this skill's own directory): every slice needs its own concern (identity test), a user-observable outcome (outcome test), and one axis from the closed list; the Never-axis list and the release-timing precondition apply as written there. Discovery/delivery pairs from the AC integrity gate's hard-stop conversion are exempt (see the reference).
+
+**Split justification.** Each proposed slice carries three lines at the gate:
+
+    root cause: <the precipitating failure or missing capability this slice remedies>
+    outcome: <what a user observes once it ships>
+    axis: <one item from the closed list>
+
+No block, no split. A block failing the identity or outcome test, or naming a non-axis, fails -> one ticket with phased AC groups. Locational wording anywhere in the block or the metadata rationale ("fix is X-side") is the same failure.
 
-**Hard rule: split boundaries are vertical** - feature/capability slices, each independently shippable and verifiable end-to-end. Never horizontal architecture layers: "backend part" / "frontend part" / "DB migration" tickets are a named anti-pattern - one ticket routinely cuts through many layers.
+**Human override, sticky.** A human re-request of a withdrawn split is sticky for the rest of the run: the merge is not re-applied and the pair is not re-roasted. After a deterministic failure (locational wording, shared precipitating failure, release-timing claimed without documented topology) the re-request needs evidence the classification was factually wrong - approval alone never waives it, and `other` may not proxy a Never axis. After a member-flag withdrawal (`split-axis:` finding) a plain yes suffices - the flag is a judgment call and the human is the jury.
 
 **Over-split guard:** a single undecided parameter that the ticket's own work settles is not a split reason - restate the AC around the observable outcome instead.
 
@@ -148,12 +173,23 @@ Detected during the audit: independent deliverables that form separately shippab
 Inline council dispatch, reusing spec-council config and personas - **not** `/skill:roasting-the-spec` (that skill's contract is spec-file apply mechanics; a tracker draft is not a spec file). No new agents.
 
 1. Resolve `gauntlet_setting({ key: "specCouncil" })` when the tool exists. Verdict `council` -> dispatch `spec-council-member`s in parallel plus a `spec-council-synthesizer` chair. Verdict `worker` (or empty members) -> one fresh `worker` critique. Malformed config -> one warning line, then branch on verdict.
-2. **Dispatch shape**, mirroring `/skill:roasting-the-spec`: write the draft body and the source snapshot (original ticket + comments, or the create-mode inputs) to absolute temp files under `mktemp -d`; delimit untrusted snapshots as data. Dispatch members with `cwd` = repo root, absolute `output` paths per member, run-level `control: { needsAttentionAfterMs: 600000 }` (sits beside `tasks`, not inside each task). Give the chair the member files via `reads`. Member task text: *the draft at `<path>` is the artifact under review; this ticket brief supersedes your spec-axis template - emit the same findings format against the draft; do not edit any file.*
+2. **Dispatch shape**, mirroring `/skill:roasting-the-spec`: write the draft body and the source snapshot (original ticket + comments, or the create-mode inputs) to absolute temp files under `mktemp -d`; delimit untrusted snapshots as data. When a split is proposed, the draft artifact holds all N proposed bodies plus their three-line justification blocks (see Split rule) in one file, not a single body. Dispatch members with `cwd` = repo root, absolute `output` paths per member, run-level `control: { needsAttentionAfterMs: 600000 }` (sits beside `tasks`, not inside each task). Give the chair the member files via `reads`. Member task text: *the draft at `<path>` is the artifact under review; this ticket brief supersedes your spec-axis template - emit the same findings format against the draft; do not edit any file.* Include the absolute path to `reference/split-axes.md` (resolved against this skill's own directory) in each member's task text - members run with `cwd` = the consumer repo, where a package-relative path does not resolve.
 3. **Effort: cheap by default.** Append a `:low` thinking suffix to each member's model string at dispatch (this beats the persona's frontmatter `xhigh` pin). Same for the chair: a configured chair string gets any existing suffix replaced with `:low`; an unconfigured chair is dispatched as the parent's model with `:low` appended. The `worker` fallback carries no thinking pin - it runs at the preset's default. **Full-roast escape:** the user may request a full roast, dispatching all model strings bare/as-configured, restoring the xhigh pins.
-4. **Brief covers two axes**, absorbing the fidelity-review role without a new persona: *fidelity* - compare draft against source intent (original ticket + comments in repair; prompt + answers in create), flag `lost` / `added` / `gap`; and *quality* - problem framing, AC integrity beyond the deterministic gate, scope, wording.
-5. Disposition: unambiguous concrete fixes applied to the draft (one re-pass max); ambiguous findings surfaced at the confirmation gate. Roast edits affect the body draft pre-write only, never a tracker comment, and re-run the deterministic gates (pipeline step 5).
-6. **Runtime conditional (the one allowed):** on a harness with no `gauntlet_setting`/`subagent()` (e.g. Claude Code), dispatch fresh general-purpose subagents via that harness's native facility at low effort, with the same two-axis brief and temp-file artifacts.
-7. Roast dispatch failure -> proceed to the confirmation gate with a "roast unavailable" note (the deterministic gates already ran; the human still adjudicates). **Roast failure never blocks the run.**
+4. **Brief covers three axes**, absorbing the fidelity-review role without a new persona: *fidelity* - compare draft against source intent (original ticket + comments in repair; prompt + answers in create), flag `lost` / `added` / `gap`; and *quality* - problem framing, AC integrity beyond the deterministic gate, scope, wording; and *split soundness* - if the draft proposes a split, test each slice against the split-axes reference (path provided in the task text); an architecture-shaped boundary is reported as a finding line containing the marker `split-axis:` (members keep their existing spec-axis findings template; the marker is a substring flag within it, not a new findings kind), e.g. `- [major] split-axis: <slice> - <why> -> merge`. Members may argue toward one ticket, never propose or endorse a split.
+5. Disposition: unambiguous concrete fixes applied to the draft (one re-pass max); ambiguous findings surfaced at the confirmation gate. Roast edits affect the body draft pre-write only, never posted as a tracker comment, and re-run the deterministic gates (pipeline step 5). Additionally, the parent scans the **member output files directly** for lines containing `split-axis:` (substring match), independent of the chair synthesis; any such finding auto-applies a merge - the split is withdrawn and the draft becomes one ticket with phased AC groups, inside the same one-re-pass budget, and the pre-merge N-body draft is kept alongside: a human re-request of the split at the gate re-presents those N bodies old->new as the approval diff (see the Split rule's sticky override). The chair keeps every other axis; clearing a `split-axis:` finding is not on its path. The same directional rule - toward one ticket, never toward a split - binds the `worker` fallback and the runtime conditional (item 6).
+6. **Runtime conditional (the one allowed):** on a harness with no `gauntlet_setting`/`subagent()` (e.g. Claude Code), dispatch fresh general-purpose subagents via that harness's native facility at low effort, with the same three-axis brief and temp-file artifacts.
+7. **Roast failure and retry.** A roast has failed when the dispatch
+   errored, or the artifact the parent reads - the chair synthesis
+   (council path) or the worker output (worker path) - is missing, empty,
+   or not findings-shaped; partial member loss with a usable chair
+   synthesis is success, not failure. On failure, retry once: re-run the
+   same full configured dispatch with fresh temp artifacts. If the retry
+   also fails, proceed to the confirmation gate with the failure rendered
+   inline in the gate message itself: `roast unavailable (dispatch failed
+   twice: <reason>)` - the human approves knowing review didn't run. The
+   retry is a dispatch retry only - it never grants a second draft-edit
+   re-pass (the one-re-pass limit is unchanged). **Roast failure never
+   blocks the run.**
 
 ## Tracker abstraction and capability ladder
 
@@ -174,10 +210,11 @@ Auth failure at detection time makes that rung dead; continue down the ladder (u
 | search (dup/reversal) | `gh search issues` / `gh issue list --search` (incl. `state:closed`) | `linearis issues search <query>` |
 | create | `gh issue create --title --body [--label]` | `linearis issues create <title> --description ... --team <team>` |
 | update | `gh issue edit <n> --title --body [--add-label/--remove-label]` | `linearis issues update <id> --title ... --description ...` |
+| post comment (Reporter note only) | `gh issue comment <n> --body ...` | `linearis issues discuss <id> --body ...` |
 
 linearis create requires `--team <team>`; it resolves like any other metadata field - named by repo docs/overrides, else asked - never invented.
 
-**Tracker-agnostic contract** required of whatever resolves: read the full ticket incl. comments; write title + body + metadata; search (dup/reversal check); tracker-native reference form for links. Field names, states, and taxonomies come from steps 1-2 of the ladder, never hardcoded in this skill.
+**Tracker-agnostic contract** required of whatever resolves: read the full ticket incl. comments; write title + body + metadata; post a comment; search (dup/reversal check); tracker-native reference form for links. Field names, states, and taxonomies come from steps 1-2 of the ladder, never hardcoded in this skill. If an approved Reporter-note comment has no resolvable post-comment verb, the body write still proceeds; the comment text is emitted for manual posting and reported as not performed - never silently dropped.
 
 **States:** generalized routing - ready (gates pass), not-ready/triage-equivalent (parked, blocker named). **Zero-config GitHub park fallback:** GitHub Issues have no native not-ready state, and this skill never invents labels - so parking writes no state/label; instead the blocker is recorded in the body (a `Blocked on: <missing value / external input>` line under the ACs), and the run report states the ticket is parked-by-convention. A repo-documented triage/not-ready label or status overrides this. Never auto-assign to an active cycle/sprint unless asked.
 
@@ -237,7 +274,7 @@ Read this when applying the AC integrity gate (drafting, repairing, or adjudicat
 | "Skip evidence, the change is trivial" | Evidence is what lets someone other than the author tick the box |
 | "The reporter's fix IS the ticket" | The fix is a sketch in Idea; the ticket is the observable outcome |
 | "Park it quietly so the gate passes" | Parking without naming the missing value hides the defect it exists to surface |
-| "Split by layer to keep tickets small" | Layers are not deliverables - slice vertically or do not split |
+| "Split by layer to keep tickets small" | Layers are not deliverables - apply the split test in `reference/split-axes.md` or keep one ticket |
 | "Write it now, the human said it twice" | Repetition is not confirmation - the gate needs an explicit yes on the presented diff |
 
 ## Edge cases
@@ -245,11 +282,11 @@ Read this when applying the AC integrity gate (drafting, repairing, or adjudicat
 - Unreadable ticket -> abort repair, offer create mode.
 - Ticket changed between gather and write -> re-fetch, diff, re-present, re-ask.
 - Write fails mid-batch -> report exactly what landed; remaining changeset preserved for retry.
-- Conforming ticket -> no-op verdict (requires metadata audit also clean), stop.
+- Conforming ticket -> no-op verdict (requires metadata audit also clean and no Reporter note proposed), stop.
 - Headless run -> stops at the confirmation gate.
 - Ref with no fetch path -> ask; never guess.
 - Split declined -> single ticket with phased AC groups.
-- Roast dispatch failure -> gate with "roast unavailable" note.
+- Roast failure -> retry once; second failure -> gate with `roast unavailable (dispatch failed twice: <reason>)` inline.
 
 ## Red flags - STOP
 

package/skills/shape-ticket/reference/split-axes.md

@@ -0,0 +1,108 @@
+# Split axes: when one request becomes N artifacts
+
+Consumed by `shape-ticket` (one ticket vs N), `brainstorming` (one spec vs N), and
+`writing-plans` (scope check). One artifact is the default; a split must pass every
+test below.
+
+## Scope
+
+This test governs **tickets and specs**. PR and plan decomposition is owned by
+`writing-plans`; one ticket normally ships as one PR. A ticket carrying too many
+concerns is split by this test - never by splitting its PRs, and never by layer.
+
+## Identity test (a) - one concern or two
+
+Two slices are **one** concern when either holds:
+
+- they remediate the same precipitating failure (one trigger, one incident, one
+  missing capability), however many components must change; or
+- landing one makes the other's stated outcome true, moot, or unobservable.
+
+A slice is **distinct** only if it remains independently user-valuable when every
+sibling is never done, and answers a different top-level need from the source
+request. Complementary cause statements are one cause: "A emits something B rejects"
+and "B mishandles what A emits" describe one trigger from two vantage points.
+Rewording a component's internal step as a "cause" does not create a second concern.
+
+For feature and improvement work there is no root cause, so (a) reduces to the
+counterfactual: would each slice still be worth doing alone, and would the requester
+call them two different things? This is a judgment call and is labeled as one - it
+is weaker than the bug-side test, not a mechanical check in disguise.
+
+## Outcome test (b)
+
+Each slice names an outcome a **user** observes. An outcome scoped to a component's
+output ("the exporter emits a recognized identifier") is an internal step, not a
+slice outcome - if a slice's headline outcome or AC is phrased at a component
+boundary, it is an internal step renamed, and the slices merge.
+
+## Closed axis list (c)
+
+| Axis | Passes | Fails |
+|---|---|---|
+| Different actor or user journey | Operator bulk-import UX vs. installer first-run onboarding - different people, neither waits on the other | "API for the operator, UI for the operator" - one journey, two layers |
+| Different data domain or lifecycle | Ingest correctness vs. retention/expiry policy - different data questions, separately valuable | "Write path vs. read path of the same record" - one lifecycle, two halves |
+| Separable release timing | Only with documented topology + a real A-before-B schedule (see precondition below) | "Service A ships from a different repo than service B" - boundary without schedule or topology |
+| Genuinely different problem statements sharing code | Two unrelated reported defects that happen to live in one file | One defect whose fix spans two files |
+| `other - <justification>` | Never auto-qualifies; explicit human approval, and it may not restate or proxy a Never axis | "other - the fix is split across tiers" |
+
+## Never an axis
+
+Where the fix lives; which service, package, repo, or deployable the diff touches;
+which layer (API, UI, DB, worker, ingest, job); which team owns it; "keep tickets
+small". A single feature, bug, concern, or improvement routinely cuts through many
+layers - normal, not a decomposition signal. Two slices sharing one concern are one
+artifact however cleanly the code divides. A Never-axis failure is not waivable by
+rewording; it is waivable only by evidence that the classification was factually
+wrong.
+
+## Discovery-conversion exemption
+
+A discovery/delivery pair produced by the AC integrity gate's hard-stop conversion
+is **not** an audit-detected split and is not subject to this test: one concern
+deliberately sequenced by missing knowledge, with the delivery ticket linked and
+parked not-ready. The exemption covers exactly that forced pair - it is not a
+template for voluntary splits.
+
+## Release-timing precondition (fail closed)
+
+`axis: separable release timing` is available **only** when the resolved gauntlet
+overrides file documents a `## Deployment` section stating independent ship
+cadences, **and** the slices have a real schedule separation (A lands and is
+verified before B starts), **and** each slice is independently verifiable
+end-to-end. No inference from CI workflow files, no ask-and-assume: an undocumented
+or monolithic topology makes the axis **unavailable** and the split fails closed to
+one artifact. The skill may offer to document the topology in overrides; it may not
+treat an in-session answer as the documented fact.
+
+## Fixtures
+
+```
+Fixture 1 - relabeled layer split (must fail)
+  slice 1: root cause: producer emits an unrecognized identifier
+           outcome: the producer emits a recognized identifier
+           axis: different data domain or lifecycle
+  slice 2: root cause: consumer discards the whole run on one bad record
+           outcome: the import run completes
+           axis: different actor or user journey
+  rejected by: identity test (a) - one precipitating failure described from two
+  vantage points; slice 1's outcome is a component-boundary step under (b).
+  correct result: one ticket, phased AC groups (identifier fix, then resilience).
+
+Fixture 2 - deployable boundary (must fail)
+  two slices differing only in which service/repo the diff touches, axis:
+  separable release timing.
+  rejected by: Never-axis list plus the release-timing precondition (no documented
+  `## Deployment`, no A-before-B schedule).
+
+Fixture 3 - legitimate split (must pass)
+  slice 1: root cause: no retry surface exists for failed imports
+           outcome: an operator can retry a failed import from the run list
+           axis: different actor or user journey
+  slice 2: root cause: expired records are never purged
+           outcome: a compliance reviewer sees records disappear after the
+                    retention window
+           axis: different data domain or lifecycle
+  passes: distinct triggers, each independently valuable if the other is never
+  done, user-observable outcomes, non-locational axes.
+```

package/skills/writing-plans/SKILL.md

@@ -69,16 +69,16 @@ Then continue with the normal flow below (Scope Check onward, including Recon).
 
 ## Scope Check
 
-Before writing the plan, check the spec one more time for hidden subsystem boundaries:
+Before writing the plan, check the spec one more time:
 
-- Does this touch 2+ independent services / contracts / schemas?
-- Are there phases where intermediate state needs to be deployable?
+- Does an intermediate state need to be **independently deployable**, under a deploy topology documented in the gauntlet overrides file's `## Deployment` section? Fail closed: undocumented or monolithic topology -> no deployment-driven split.
+- Is there a **review-risk isolation** reason to land part separately (e.g. a large mechanical rename apart from the behavior change that motivated it)?
 
 If yes, decompose into separate plans and call it out:
 
 > "The spec covers A and B. I'd split into two plans, executed in order. OK?"
 
-A single plan should land in one PR worth of work. Multi-PR sequences get separate plans.
+Otherwise one plan. Service, contract, or schema count is not a split signal - one concern routinely spans several. The concern test itself lives in `../shape-ticket/reference/split-axes.md` (resolve the path against this skill's own directory) and was applied upstream at spec time; plans do not re-litigate it. A single plan should land in one PR worth of work.
 
 ## Recon (mandatory)