feat(work-items): add mini-SDLC pipeline-shape SSOT + wire work Step 5 to it

plugins/work-items/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/claude-code-plugin-manifest.json",
   "name": "work-items",
-  "version": "0.19.0",
+  "version": "0.20.0",
   "description": "Manages development work items through a provider-neutral tracker seam that ships with the plugin (bundled dispatcher plus github and local-markdown adapters; seam plugin-dir canonical, adapters consumer-local-first): dashboard, taxonomy-labeled creation, a race-safe assignee-plus-lease claim protocol, recurring-schedule checks, TODO scanning, stale-lease auditing, plan decomposition into vertical-slice items, and raw-intake triage (issues and unsolicited PRs through raw, verified, briefed, autonomous-eligible states). The re-runnable setup skill binds the provider (.work-item-tracker.json), seeds the recurring-schedule seam (.github/recurring-schedule.json), and remaps canonical role labels.",
   "author": {
     "name": "Melodic Software",

plugins/work-items/CHANGELOG.md

@@ -3,6 +3,32 @@
 All notable changes to the `work-items` plugin are documented here. Format follows
 [Keep a Changelog](https://keepachangelog.com/en/1.1.0/); this plugin uses semantic versioning.
 
+## [0.20.0]
+
+### Added
+
+- **Mini-SDLC pipeline-shape SSOT — `reference/pipeline-shape.md` (`#613`, stage 1 of `#513`).** The
+  work lane had no durable definition of the *shape* of the pipeline it runs per item — the lane
+  catalog, the implementer ≠ reviewer ≠ verifier invariant, and the depth tiers lived only as evolving
+  prose and per-issue plans, so the shape drifted and could not be scaled or reviewed in one place. A
+  new reference doc owns that stable policy: the fixed lane set (explore → research → plan →
+  devil's-advocate → implement → test → review → verify, with the re-anchor slot reserved), the
+  "variation in depth, never in shape" principle, the role-separation invariant, and placeholder depth
+  tiers carried as a plan field. It is a reversible reference-doc STOPGAP (form/location/name left to
+  the operator per `#513`) and points at the return-payload contract (`#496`) and convention-gap
+  protocol (`#554`) rather than restating them. **Scope note:** this stage lands the shape and the
+  wire-in only — the depth-scaling dispatcher and the separated-reviewer/verifier runtime are later
+  `#513` stages, so the doc defines the target shape and makes no claim that the runtime already
+  depth-scales or fully separates roles today.
+
+### Changed
+
+- **`work` Step 5 dispatches against the pipeline-shape SSOT (`#613`).** The execute sub-step now
+  points the dispatched chain at `reference/pipeline-shape.md` for the lane shape, additively — the
+  existing instruction to follow the consuming project's own development workflow and domain rules is
+  retained; the chain runs the shape *within* the consumer's workflow and rules, never in place of
+  them.
+
 ## [0.19.0]
 
 ### Added

plugins/work-items/reference/pipeline-shape.md

@@ -0,0 +1,84 @@
+# Mini-SDLC pipeline shape — the work lane's per-issue execution shape
+
+The single source of truth for the **shape** of the per-item pipeline the `/work-items:work` lane is
+being built to run: which lanes exist, the role-separation invariant they are to enforce, and how depth
+(never shape) scales per item. `work` Step 5 points the dispatched chain at this document for that shape
+instead of carrying its own workflow prose; the per-item *sizing* of these lanes is authored in the
+item's plan, not here.
+
+This document owns the durable **policy**. It is not a claim about what the runtime does today: the
+staged work that wires each lane's full realization is tracked under `#513` (the mini-SDLC umbrella) —
+this shape is the target those stages build to.
+
+## Status — reference-doc STOPGAP
+
+Form, location, and name are **not locked** (mini-SDLC umbrella `#513`, OPERATOR DECISION 1). This ships
+as a reference doc so the policy has one home now, reversibly: it is promotable to a `work-items`
+orchestration skill later without moving the policy. Revisit trigger: the operator ratifies the final
+form. **If promoted to a skill, flag the naming collision** with `session-flow:orchestrate` and
+`implementation:implement-dispatch` before choosing a skill name.
+
+## Principle — variation in depth, never in shape
+
+Every item traverses the **same** lanes in the same order. A trivial item and a sprawling one differ
+only in the **depth** each lane runs at — never in which lanes run. A lane is never skipped; what
+collapses is its *realization* (a dispatched fresh-context subagent → an inline lightweight check →
+the consumer's own workflow step for that stage when no lane skill is installed; N rounds → one) down
+to its minimum, but the lane itself always runs. Depth is the throughput lever; shape is invariant.
+
+## The lane catalog
+
+Each lane runs once per item, in this order. A lane is *composed from* the installed skill catalog —
+the skills named are its reference realization (published as sibling plugins in this marketplace), not
+a re-specification of their contracts. `work-items` installs standalone and hard-depends on none of
+them: where a lane's skill is not installed, the lane is to degrade to the consumer's own workflow for
+that stage (the Step 5 anchor) rather than dead-end.
+
+| Lane | Composed from | What the lane owns |
+|---|---|---|
+| Explore | `discovery:explore` | Read the code and context the item touches before any change. |
+| Research | `discovery:research` | Ground decisions in current authoritative sources, not recall. |
+| Plan | `planning:plan` | Produce the approach, test strategy, and the per-item lane **sizing** this shape scales by. |
+| Devil's advocate | `planning:devils-advocate` | Stress-test the plan's assumptions before implementation begins. |
+| Implement | `implementation:implement` / `implementation:implement-dispatch` | Make the change; the implementer never reviews or verifies its own output. |
+| Test | `testing:*`, `tdd:principles`, `toolchain:*` | Prove the change against a spec the implementer may not weaken. |
+| Review | `review:code-reviewer` / `review:quality-gate` | Review the diff via a reviewer **distinct from the implementer**, before the PR opens. |
+| Verify | `verification:*` | Confirm the result against evidence via a **fresh-context verifier**, distinct from the implementer. |
+
+The **re-anchor slot** (`re-anchor:*`) is reserved: the re-anchor set is a periodic anchor across lane
+execution rather than a human-invoked extra. Its placement in the sequence is left for a later `#513`
+stage; this document reserves the slot and does not yet define its cadence.
+
+## The separation invariant
+
+**Implementer ≠ reviewer ≠ verifier.** Under this shape the agent that writes a change is not the agent
+that reviews its diff, nor the agent that verifies its result: implement, review, and verify are
+distinct roles, to be carried by distinct ephemeral fresh-context agents. This is the invariant the
+whole shape exists to hold — the sizing may collapse a lane's depth, but it may never collapse two of
+these three roles into one agent.
+
+## Depth tiers
+
+Depth tiers name **depth levels, not lane subsets** — a deeper tier runs every lane more thoroughly, a
+shallower tier runs every lane more cheaply; no tier omits a lane. The tier **names** are placeholders
+here (mini-SDLC umbrella `#513`, OPERATOR DECISION 2), left for the operator to ratify:
+
+| Tier (placeholder) | Depth intent |
+|---|---|
+| `<tier-shallow>` | Each lane at minimum depth — inline lightweight checks, single-round. |
+| `<tier-standard>` | Each lane dispatched, single-pass. |
+| `<tier-deep>` | Each lane dispatched with fresh-context subagents and multiple rounds where the lane supports them. |
+
+The tier for an item is **plan-driven with orchestrator override** — carried as a field in the item's
+plan (not a label), matching the sizing heuristic settled in the `#513` ACCEPTED decision brief. The
+dispatcher that reads the tier and sizes the worker chain is a later `#513` stage; this document defines
+the tiers it reads.
+
+## Contracts this shape composes
+
+- **Return-payload contract** — `#496`: subagents in the chain return only identifiers, verdict, and
+  parked-payload pointers upward; chatty coordination stays low in the chain. The dispatcher tier is to
+  follow this contract when summarizing to the orchestrator.
+- **Convention-gap protocol** — `#554`: when a lane hits a decision with no governing convention, the
+  answer is never invent-and-proceed. Surface it, discuss, create the convention, human signs off
+  (interim-unblock + tracked-convention-decision template).

plugins/work-items/skills/work/SKILL.md

@@ -178,7 +178,7 @@ On user confirmation ("yes"):
 
 1. **Suggest branch name.** Propose `<type>/<N>-<slug>` so `/pull-request create` can auto-inject `Closes #N` from the branch parse. Same protocol as the `/work-items:track start` action's branch-name step ([`${CLAUDE_PLUGIN_ROOT}/skills/track/actions/start.md`](${CLAUDE_PLUGIN_ROOT}/skills/track/actions/start.md) "Suggest branch name") — branch `<type>` vocabulary derived from the item's issue type (native Issue Type preferred, `type:*` label fallback), slug from title (kebab-case, 40-char cap), existing-branch detection, multi-claim 3-option (switch / stay+cover-both / skip). Agent emits `git checkout -b ...` for the user; never executes itself.
 
-1. **Execute — orchestrator-dispatch is the default (`#451`).** For autonomous execution the default posture is orchestrator, not inline editor: this skill picks and claims the item, then **dispatches a scope-fenced implementation subagent** that does the source edits in its **own out-of-tree worktree** (lifecycle owned by `/source-control:worktree`, one per pick), collects the return, verifies it, and does the bookkeeping. **The orchestrator never edits source itself.** All dispatch *mechanics* — worker-brief composition, orchestrator-never-edits, verify-returns-against-evidence, and the concurrent-wave cap — are owned by `/implementation:implement-dispatch`; chain to it rather than re-describing them here. An interactive, all-inline run instead uses `/implementation:implement`. Whichever path runs, the executing surface MUST follow every step of the consuming project's development workflow (a workflow skill, a `CLAUDE.md` workflow section, or team convention) and read the project's rules for the item's domain first — no shortcuts, no skipping research, no surface-level execution; dispatch is only *how* that workflow is carried out. **Autonomous branch/worktree provisioning is deferred to `#572`:** the seam that puts an autonomous run onto a non-default branch/worktree *before* the dispatch preflight — together with the orchestrator-owned PR-creation timing and whether a CI-found fix re-dispatches to the original worker or a fresh subagent — spans `work`, `/implementation:implement-dispatch`, and `/source-control:worktree`; until it lands, this path is not guaranteed end-to-end from a default-branch checkout without operator-provided branch setup.
+1. **Execute — orchestrator-dispatch is the default (`#451`).** For autonomous execution the default posture is orchestrator, not inline editor: this skill picks and claims the item, then **dispatches a scope-fenced implementation subagent** that does the source edits in its **own out-of-tree worktree** (lifecycle owned by `/source-control:worktree`, one per pick), collects the return, verifies it, and does the bookkeeping. **The orchestrator never edits source itself.** All dispatch *mechanics* — worker-brief composition, orchestrator-never-edits, verify-returns-against-evidence, and the concurrent-wave cap — are owned by `/implementation:implement-dispatch`; chain to it rather than re-describing them here. An interactive, all-inline run instead uses `/implementation:implement`. Whichever path runs, the executing surface MUST follow every step of the consuming project's development workflow (a workflow skill, a `CLAUDE.md` workflow section, or team convention) and read the project's rules for the item's domain first — no shortcuts, no skipping research, no surface-level execution; dispatch is only *how* that workflow is carried out. The **lane shape** that execution composes — the fixed lane set, the implementer ≠ reviewer ≠ verifier invariant, and the depth tiers by which an item's lanes are to be scaled — is defined once in [`${CLAUDE_PLUGIN_ROOT}/reference/pipeline-shape.md`](${CLAUDE_PLUGIN_ROOT}/reference/pipeline-shape.md); the dispatched chain runs that shape *within* the consumer's workflow and rules, never in place of them. **Autonomous branch/worktree provisioning is deferred to `#572`:** the seam that puts an autonomous run onto a non-default branch/worktree *before* the dispatch preflight — together with the orchestrator-owned PR-creation timing and whether a CI-found fix re-dispatches to the original worker or a fresh subagent — spans `work`, `/implementation:implement-dispatch`, and `/source-control:worktree`; until it lands, this path is not guaranteed end-to-end from a default-branch checkout without operator-provided branch setup.
 
    **The dispatch brief carries the PR contract forward (`#462`).** So a worker knows the target up front instead of discovering it through red CI, the brief relays what `/source-control:pull-request` will require at PR time — that skill owns the PR body shape, the `Closes #N` closing-keyword injection, and merge style; do **not** redefine them here. The brief enumerates the consuming-project obligations the worker must satisfy: per-plugin version bump plus the matching CHANGELOG entry, the attribution trailer plus session link, and a `## Related` section — alongside the `Closes #N` the branch name carries.