aw-spec-cli 0.1.13 → 0.1.15

package/assets/.appweaver/orchestrator/workflows/aw-spec-sync-stories.orch.yaml

@@ -0,0 +1,1040 @@
+# =============================================================================
+# aw-spec-sync-stories (orchestrator) — raise and refresh the BACKLOG from the spec
+#
+# Spec-anchored pipeline, spec phase. The spec is the CONTRACT and a story is an
+# execution SLICE over it. The two directions between them each have their own
+# workflow and neither is shared: sync-stories carries the SPEC forward into the
+# backlog; /appweaver update-spec folds a hand-edited STORY back into the contract.
+# Keeping them apart is what stops the spec->story rule having two implementations.
+#
+# WHAT THIS READS. The spec's `## Change History` — the version ledger. Each row names
+# the requirement ids that version touched; each story records the version it last
+# synced at. "What has moved since the backlog was last in step" is therefore a read of
+# rows and one integer comparison, with no diffing, no hashing and no model involved.
+#
+# THE WORK SET is the union of the ids named by every row ABOVE THE LOWEST spec_version
+# across the OPEN stories — not the newest row alone. Those are the same set whenever the
+# backlog is one version behind, which is the ordinary case; they diverge only when a sync
+# was skipped, and that is the case worth getting right. Two specify runs with no sync
+# between them leave the middle version named by no row anyone reads, and its requirements
+# would get no story with nothing to say so. Silent, in the one mechanism built to make
+# staleness loud. `ledger-read` computes it and names the versions it covered.
+#
+# AT v1.0 there is no "since": nothing has moved because nothing has synced. So when NOTHING
+# has synced — an empty backlog, or stories predating the field — the work set is every
+# FR-/BR- the document declares, and the per-group rules below then create only what has no
+# story. A second run over the same spec creates nothing (E42).
+#
+# A BACKLOG THAT IS ENTIRELY CLOSED IS NOT THAT CASE. A closed story carries the version its
+# work was measured against, so it sets the floor exactly as an open one does, and a
+# requirement whose closed story is stamped at or above the version that last moved it is
+# DELIVERED rather than unsliced. Reading the floor from open stories alone made the last
+# story closing look identical to a spec nobody had ever sliced, and one idle re-run then
+# raised a fresh story for every requirement in the feature (E72). Cancelled stories are
+# excluded throughout: abandoned work delivered nothing and settles nothing.
+#
+# FR-/BR- ONLY, throughout. CN-/DC-/IC-/UX- move the contract and belong in the ledger
+# row, but they are constraints a story CARRIES, not slices of work it delivers — they
+# reach the story through its `## Constraints` section and never through `exercises:`.
+#
+# THE SHAPE OF A RUN.
+#   1. the tripwire      spec.md hand-edited with no version row -> REFUSE. Every story
+#                        citing an edited requirement is already silently stale, and
+#                        raising a backlog on top would bury the edit rather than name it.
+#   2. the work set      ledger-read. An empty ledger stops the run with a warning: there
+#                        is no version to sync from, and inventing one raises a backlog
+#                        against a document nobody has committed to.
+#   3. grouping          the one judgment in the workflow. Requirements that belong to one
+#                        slice become one story; a group may hold one id or several. How
+#                        coarsely is steered by the launch line's strategy word.
+#   4. the ask           where a group already has open stories in front of it. Asked, not
+#                        decided — see below.
+#   5. the writes        one file per plan entry, then a deterministic frontmatter stamp.
+#   6. coverage          the spec's Story Coverage block, regenerated from stories/.
+#
+# ONE STORY, IF THAT IS WHAT YOU ASKED FOR. `/appweaver sync-stories single-run` puts the
+# WHOLE work set into a single story — at v1.0 that is the whole spec, on a later run it is
+# the whole update. It is the right shape for a small feature, for a spike, and for the
+# change that is one thing however many requirement ids it happened to move.
+#
+# AND IT IS A REQUEST, NOT A GUARANTEE. Where the work set is too heavy to be picked up as
+# one piece, it is split along its DEPENDENCIES rather than written as a story nobody can
+# start — and the run says both that it split and what came out. A silent split leaves
+# someone believing they have one story when they have six; a silently oversized story is
+# worse, because it is the one that never gets picked up at all.
+#
+# THE ORDER, AND WHY IT IS CALLED A WAVE. Stories leave a sync with no inherent order — an
+# id is minting order, which is not delivery order. So the grouping declares which slices
+# stand behind which, and the arithmetic lays the result out in WAVES: wave N holds the
+# stories whose every dependency sits in a wave below it.
+#
+# The word is doing work. "Order" and "priority" both promise a queue — a first, a second, a
+# third, and a wrong answer whenever two things tie. What is true here is the opposite: TWO
+# STORIES IN THE SAME WAVE ARE UNORDERED WITH RESPECT TO EACH OTHER, which is exactly why
+# they can be picked up in parallel, and a scheme that cannot say "these two are equal"
+# would have to invent a ranking to hide that it cannot. A wave is an ELIGIBILITY LEVEL:
+# wave 1 means nothing has to land first, not "do this first". Nothing waits for a whole
+# wave to finish, and a story becomes startable the moment its own dependencies are done.
+# `wave` is also already the kit's word for this — /appweaver dependency-tree sorts
+# migration units into waves the same way — so the backlog and the migration tree read alike.
+#
+# The edges are a judgment and the levels are not, which is the same split as everywhere
+# else here: the model declares what stands behind what, and backlog-plan computes the
+# levels, breaks any cycle deterministically, and names an edge that resolves to nothing
+# rather than dropping it in silence. `follows:` is NOT an edge — a follow-on carries the
+# REMAINDER of a story in flight, and a remainder is often buildable alongside it.
+#
+# WHY THE ASK. A requirement whose story is already open is the one case with no right
+# default. Rewriting the story keeps one slice of work whole; leaving it alone keeps
+# somebody's context intact and puts the change in a new story beside it. Both are
+# defensible and the machine cannot weigh them, so the author picks — per story, not per
+# run. Declining does not abandon the group: the declined story's requirements withdraw
+# from it and whatever remains still becomes a story.
+#
+# AND WHY IN-FLIGHT IS DIFFERENT. Once `stories/<ID>/` exists somebody has run story-plan
+# and is designing or building against the requirements as they read then. That story is
+# never rewritten. Picking it mints a FOLLOW-ON carrying the change, linked by `follows:`;
+# the original stays open and closes having delivered what it was written to deliver
+# (§5.5). There is no `superseded` status, so completeness stays computable one way: a
+# requirement is delivered when it has NO OPEN STORIES.
+#
+# WHAT THIS DOES NOT WRITE. The Change History table, including its `Stories` cell. That
+# table is inside the region the ledger hashes, so writing it here would be an unledgered
+# edit of the contract by the workflow whose whole job is to react to those. The
+# spec->story relation is held ONCE, in each story's `exercises:`, and the Story Coverage
+# block — which IS fenced out of the hash — is that relation read the other way round.
+#
+# Launch:  /appweaver sync-stories [single-run] [optional guidance on how to slice]
+# Prereq:  /appweaver specify   (the spec and its version row must exist)
+# Next:    /appweaver story-plan <story-id>   (the execution design for one slice)
+# =============================================================================
+
+name: aw-spec-sync-stories
+description: "Raise and refresh the story backlog of the ACTIVE feature from its spec. Reads the spec's Change History ledger to find the requirements that have moved since the backlog was last in step, groups them into execution slices, asks before disturbing a story someone already has open, and writes one story per slice — creating, updating in place, or minting a follow-on where a story plan already exists. Slicing is steered by an opening strategy word: `single-run` puts the whole work set into ONE story, splitting it along its dependencies only where that story could not be picked up as one piece, and reporting the split either way; omitted, the number of slices is decided from the requirements. The grouping declares which slices stand behind which, and the kit computes DELIVERY WAVES from those edges — wave N holds the stories whose every dependency sits below it, so stories sharing a wave have no ordering between them and may be picked up in parallel. Writes `depends_on:` and `wave:` into each story's frontmatter, breaks any declared cycle deterministically, and regenerates the spec's Story Coverage block. Writes no requirements — /appweaver specify and /appweaver update-spec own the contract."
+version: 1.1.0
+agent_agnostic: true
+dialect: aw-spec.orchestrator/v1
+
+inputs:
+  user_input:
+    description: "Optional. An opening STRATEGY word, then optional guidance on how to slice. `single-run` (also `single-story`, `single`) puts the whole work set into ONE story — split along its dependencies only where that story would be too heavy to pick up, and the split is reported. Omit it, or say `auto`, and the number of slices is decided from the requirements alone. Guidance is free prose (\"keep the reporting requirements in one story\", \"split anything touching payments\"); only the FIRST word is read as a strategy, so guidance may use the word \"single\" without changing the mode."
+    required: false
+    bind: USER_INPUT
+
+scripts:
+  actions:
+    sh:  .appweaver/scripts/bash/aw-spec-actions.sh
+    ps1: .appweaver/scripts/powershell/aw-spec-actions.ps1
+
+# The universal operating rules only. A story carries the spec's constraints by id and
+# invents none of its own, so the domain and technical rule corpora have nothing to add
+# here — specify already lifted everything they impose into the document this reads.
+standards:
+  - { path: .appweaver/ai-rules.md }
+
+vars:
+  # A GATE THAT ONLY EXISTS TO STOP. The engine renders a JSON boolean two different ways:
+  # `{{var}}` json-dumps it (`true`/`false`, which is what `condition:` compares against)
+  # while verify_context's require_value stringifies it (`True`/`False`). So a boolean
+  # coming out of a script cannot be gated with require_value/equals — the comparison is
+  # against a spelling the interpolation never produces, and the gate passes whatever the
+  # value is. The test therefore lives in `condition:`, and the step it guards fails
+  # unconditionally: reaching it IS the failure. Used by bootstrap_gate and
+  # ledger_empty_gate below.
+  never: "false"
+
+  # THE LAUNCH LINE, TAKEN APART. slice-mode reads the strategy word off the front of the
+  # input and hands back what is left as guidance, so the prompt below never sees the word
+  # it is being steered by — and guidance that happens to contain it is still guidance.
+  strategy: "auto"           # auto | single
+  strategy_note: ""          # that choice, in words, for the run report
+  guidance: ""               # the input with the strategy word taken off the front
+  slice_directive: ""        # the grouping instruction the strategy selects
+  # A SIGNAL, NOT A LIMIT. Read to the model as the point at which a single story is worth
+  # stopping over, and reported by backlog-plan against the groups that came back. Nothing
+  # refuses a group for exceeding it: how big a slice can be is a fact about the work and
+  # the team, and a hard cap here would split a coherent story to satisfy a number.
+  single_ceiling: "8"
+  split_note: ""             # single-run was asked for — did the work set still split, and why
+  split_reason: ""           # the grouping's own sentence on what made one story undeliverable
+  split_count: "0"
+  oversized_csv: ""          # groups holding more ids than the ceiling
+
+  version: ""                # the spec version the backlog is being brought up to
+  ledger_ok: "true"          # entry tripwire result
+  ledger_state: ""           # clean | unstamped | ledgered_edit | unledgered_edit | rollback | delta_open
+  ledger_error: ""
+  needs_bootstrap: "false"   # an unfinished first draft is not a contract to slice
+  ledger_empty: "true"       # no version row at all -> warn and stop
+  row_count: "0"
+  work_csv: ""               # the requirements this run has to account for
+  work_count: "0"
+  work_any: "false"
+  work_source: ""            # ledger (rows above the floor) | spec (the v1.0 case)
+  work_note: ""              # how the work set was arrived at, in words
+  span_versions_csv: ""      # the versions it spans
+  gap: "false"               # true = more than one version behind; a sync was skipped
+  removed_csv: ""            # ids a row named that the document no longer declares (E1)
+  synced_floor: ""           # the oldest version a story is still sitting at
+  floor_source: ""           # open | closed | none — which stories that floor was read from
+  latest_version: ""
+  backlog_digest: ""         # one line per open story, for the grouping prompt
+  story_count: "0"
+  open_count: "0"
+  groups: []                 # the model's slices
+  groups_digest: ""
+  group_count: "0"
+  unplaced_csv: ""           # work-set ids the grouping left out
+  repeated_csv: ""           # ids it put in two groups
+  any_candidates: "false"    # does any group already have an open story in front of it
+  candidate_ids: []          # the options of the ask
+  candidate_csv: ""
+  ask_digest: ""             # those candidates, worded
+  approved_stories: ""       # the author's answer
+  any_plan: "false"
+  plan: []                   # one entry per story file to write
+  plan_count: "0"
+  plan_digest: ""
+  create_count: "0"
+  update_count: "0"
+  followon_count: "0"
+  skipped_csv: ""            # stories the author declined to disturb
+  plan_notes: ""             # what the arithmetic decided that the counts do not show
+  overflow_csv: ""           # stories the write loop's ceiling will not reach
+  nothing_note: ""           # why a run that wrote nothing wrote nothing — see plan_gate
+  stories_csv: ""            # every story this run wrote
+  wave_digest: ""            # the stories this run wrote, laid out by dependency level
+  wave_count: "0"
+  max_wave: "0"
+  cycle_csv: ""              # dependency edges dropped to break a declared cycle
+  unresolved_deps_csv: ""    # declared dependencies naming no slice and no open story
+  uncovered_csv: ""          # requirements still with no story at all
+  delivered_csv: ""          # requirements whose every story is closed
+
+workflow:
+
+  # 0. THE LAUNCH LINE. Read before anything else because it steers the one judgment step,
+  #    and it depends on nothing — no feature, no spec, no backlog.
+  #
+  #    NOT A `condition:`. The engine compares a whole rendered value, so
+  #    `{{USER_INPUT}} == single-run` matches only an input carrying the strategy and no
+  #    guidance at all — and `/appweaver sync-stories single-run keep the payment rules
+  #    together`, the form the launch line documents, would slice by default while looking
+  #    as though it had been told not to. Silent, and in the one place the author was
+  #    explicit.
+  - id: slice_mode
+    action: execute_script
+    script: { ref: actions }
+    subcommand: slice-mode
+    args: ["--input", "{{USER_INPUT}}"]
+    outputs:
+      - { name: strategy,      from: "$.strategy" }
+      - { name: guidance,      from: "$.guidance" }
+      - { name: strategy_note, from: "$.note" }
+
+  # 0a. THE GROUPING INSTRUCTION THE STRATEGY SELECTS. Two `set` steps rather than two
+  #     prompts: everything else the grouping is told is the same in both modes, and a
+  #     second copy of those rules is a second place for them to drift.
+  - id: directive_auto
+    condition: "{{strategy}} == auto"
+    action: set
+    vars:
+      slice_directive: |
+        SLICING. How many slices there are is yours to decide, from the work itself.
+
+        - A group is what one person can pick up and deliver as a coherent piece of work.
+        - SIZE IS A REASON TO SPLIT, NEVER A REASON TO MERGE. Where one requirement is
+          large enough to be a story on its own, it is one — a group of one is the normal
+          case, not a failure to group. Do not pad a group to make it look substantial.
+
+  - id: directive_single
+    condition: "{{strategy}} == single"
+    action: set
+    vars:
+      slice_directive: |
+        SLICING. ONE STORY was asked for. Put EVERY requirement listed above into a SINGLE
+        group covering the whole work set, and title it for what the feature delivers as a
+        whole rather than for any one part of it.
+
+        - SPLIT ONLY IF THAT STORY COULD NOT BE PICKED UP. The test is whether one person
+          could take it and deliver it as one coherent piece of work — not whether it is
+          tidy, and not the id count: more than {{single_ceiling}} ids in one story is a
+          signal worth stopping on, never a verdict on its own.
+        - IF YOU DO SPLIT, SPLIT ALONG THE DEPENDENCIES. The first group is what everything
+          else is built on and what needs nothing itself; each group after it holds what
+          becomes possible once the ones before it exist. Do not split by theme, by section
+          of the spec, or by id range — a split that does not follow the dependencies
+          produces stories that cannot be started in any order at all, which is a worse
+          answer than the single heavy story it was meant to fix.
+        - SAY WHY, in `split_reason`: one sentence naming what made the single story
+          undeliverable. Somebody asked for one story and is getting several, and they are
+          owed the reason rather than left to infer it from the count.
+
+  # 1. CONSUME the active feature (set by select-feature). No derive-names.
+  - id: feature_paths
+    action: execute_script
+    on_error: continue
+    script: { ref: actions }
+    subcommand: feature-paths
+    outputs:
+      - { name: feature_dir,     from: "$.feature_dir" }
+      - { name: spec_file,       from: "$.spec_file" }
+      - { name: spec_exists,     from: "$.spec_exists" }
+      - { name: needs_bootstrap, from: "$.needs_bootstrap" }
+
+  - id: require_feature
+    action: verify_context
+    require_non_empty: feature_dir
+    on_empty: stop
+    on_empty_message: "No active feature. Run /appweaver select-feature first (pick or create the aggregate, e.g. Order), then /appweaver specify, then re-run sync-stories."
+
+  # 2. AN UNFINISHED FIRST DRAFT IS NOT A CONTRACT. needs_bootstrap covers both "no spec.md"
+  #    and "a specify run that died before writing its v1.0 row" — and the second is the one
+  #    that matters here, because that document IS on disk and does carry requirements. Its
+  #    ledger row is still the template's placeholder, whose "Requirements changed" cell
+  #    literally reads FR-001…FR-00n; syncing off it would raise a backlog against ids
+  #    nobody chose, at a version nobody committed to.
+  - id: bootstrap_gate
+    condition: "{{needs_bootstrap}} == true"
+    action: verify_context
+    require_true: never
+    on_false: stop
+    on_false_message: >
+      {{spec_file}} is an unfinished first draft — specify has not written its v1.0 Change
+      History row, so the document is not yet a contract anything can be sliced against.
+      Re-run /appweaver specify with the same input (it re-authors the draft rather than
+      extending it), then re-run sync-stories.
+
+  # 3. THE ENTRY TRIPWIRE. The ledger is hand-writable, which is the point — a spec can be
+  #    edited by hand — and also its one silent failure: a body edited with no version row
+  #    leaves every story citing an edited requirement stale with nothing to detect it.
+  #    That is precisely the state this workflow exists to resolve, and precisely the one it
+  #    cannot resolve, because the row is what says WHICH requirements moved. Refusing here
+  #    turns the silent case into a message naming the fix (E13).
+  #
+  #    `unstamped` and `ledgered_edit` both pass: the first is a spec that predates the
+  #    ledger, the second is a hand edit that did write its row — exactly the Direction A
+  #    case this workflow is for.
+  #
+  #    No `on_error: continue`: spec-check reports every ledger STATE through its JSON with
+  #    a zero exit, so a non-zero exit is the script itself failing, and continuing past
+  #    that would bind the gate's vars to nothing and produce the refusal with its reason
+  #    blanked out.
+  - id: ledger_check
+    action: execute_script
+    script: { ref: actions }
+    subcommand: spec-check
+    args: ["--feature-dir", "{{feature_dir}}"]
+    outputs:
+      - { name: ledger_ok,    from: "$.ok" }
+      - { name: ledger_state, from: "$.state" }
+      - { name: ledger_error, from: "$.error" }
+      - { name: version,      from: "$.version" }
+
+  - id: ledger_gate
+    action: verify_context
+    require_true: ledger_ok
+    on_false: stop
+    on_false_message: >
+      /appweaver sync-stories cannot read the backlog's anchor: {{ledger_error}}
+      A version row is what tells a story that a requirement it cites has moved, so a spec
+      whose body has changed without one cannot be synced — this run would raise stories
+      for what the LAST row named and leave the hand edit unnamed and unreconciled.
+      Resolve the state above, then re-run. (State: {{ledger_state}}.)
+
+  # 4. THE WORK SET. See the header for why it spans versions rather than reading the
+  #    newest row alone, and for the v1.0 case.
+  - id: ledger_read
+    action: execute_script
+    script: { ref: actions }
+    subcommand: ledger-read
+    args: ["--feature-dir", "{{feature_dir}}"]
+    outputs:
+      - { name: row_count,         from: "$.row_count" }
+      - { name: ledger_empty,      from: "$.ledger_empty" }
+      - { name: work_csv,          from: "$.work_csv" }
+      - { name: work_count,        from: "$.work_count" }
+      - { name: work_any,          from: "$.work_any" }
+      - { name: work_source,       from: "$.work_source" }
+      - { name: work_note,         from: "$.work_note" }
+      - { name: span_versions_csv, from: "$.span_versions_csv" }
+      - { name: gap,               from: "$.gap" }
+      - { name: removed_csv,       from: "$.removed_csv" }
+      - { name: synced_floor,      from: "$.synced_floor" }
+      - { name: floor_source,      from: "$.floor_source" }
+      - { name: latest_version,    from: "$.latest_version" }
+
+  # 4a. AN EMPTY LEDGER STOPS THE RUN. The table is there and carries no version row, which
+  #     means the spec has never been versioned. There is no "since" to sync from, and
+  #     choosing one — the whole document, say — would raise a backlog against requirements
+  #     nobody has committed to a version of. A warning, not a failure: nothing is wrong
+  #     with the document, it simply is not ready to be sliced.
+  - id: ledger_empty_gate
+    condition: "{{ledger_empty}} == true"
+    action: verify_context
+    require_true: never
+    on_false: stop
+    on_false_message: >
+      The Change History table in {{spec_file}} carries no version row, so there is no
+      version for a story to sync at and nothing recording what this spec has changed.
+      Nothing was written. Run /appweaver specify to author or extend the spec — it computes
+      the row from what it actually changed and stamps the document — then re-run
+      /appweaver sync-stories. (If the spec was written by hand, add a row naming the
+      requirement ids it introduced and re-run spec-stamp.)
+
+  # 4b. NOTHING TO DO IS NOT AN ERROR. Every version row is at or below the oldest open
+  #     story's stamp: the backlog is already in step. Stopping here rather than running an
+  #     empty grouping keeps the no-op cheap and the message honest.
+  - id: work_gate
+    action: verify_context
+    require_true: work_any
+    on_false: stop
+    on_false_message: >
+      The backlog is already in step with {{spec_file}} at {{latest_version}} — every
+      requirement a version row names has either been delivered by a closed story or is
+      already carried by an open one synced past it. Nothing was written. ({{work_note}}.)
+
+  # 4c. A REMOVED REQUIREMENT IS A DECISION, NOT A DEFAULT (E1). A row names what a version
+  #     TOUCHED, and that includes ids it deleted. Those leave the work set — there is no
+  #     wording left to write a story from — but every open story citing one is now
+  #     orphaned, delivering a requirement the contract no longer makes. Reported and
+  #     continued: this run can still raise the stories it came to raise, and the orphan
+  #     needs a person, not a rule.
+  - id: removed_notice
+    condition: "{{removed_csv}} != ''"
+    action: verify_context
+    require_value: removed_csv
+    equals: ""
+    on_mismatch: continue
+    on_mismatch_message: >
+      A version row names requirements the spec no longer declares: {{removed_csv}}.
+      They are excluded from this run — a removed requirement has no wording to write a
+      story from — but any OPEN story citing one is now orphaned, and closing it would
+      report a requirement delivered that the contract no longer makes. Decide those by
+      hand: cancel the story, or re-state the requirement via /appweaver specify.
+
+  # 4d. MORE THAN ONE VERSION BEHIND. The span exists precisely so a skipped sync does not
+  #     bury a version, and it does that silently — the middle version's requirements are
+  #     picked up with nothing saying they nearly were not. This says so, because a gap is
+  #     also a fact about how the two documents are being worked: a spec that moved twice
+  #     with no sync between is one whose backlog is not being kept.
+  - id: gap_notice
+    condition: "{{gap}} == true"
+    action: verify_context
+    require_value: span_versions_csv
+    equals: ""
+    on_mismatch: continue
+    on_mismatch_message: >
+      The backlog is more than one version behind: this run spans {{span_versions_csv}},
+      because the oldest {{floor_source}} story is still at {{synced_floor}}. Every requirement those
+      rows name is in the work set, so nothing is lost — but a version in the middle
+      reached no story until now.
+
+  # 5. THE BACKLOG AS IT STANDS. Read once, whole, and only from frontmatter — which is why
+  #    §6.1 puts everything the gates need there. Fed to the grouping step so slices are
+  #    proposed against the work that exists rather than into a vacuum.
+  #    No `on_error: continue`. story-refs exits zero on an empty backlog and on a stories
+  #    directory that does not exist yet, which are the ordinary cases — so a non-zero exit
+  #    is the op itself failing to read the backlog, and grouping against a digest that says
+  #    "no open stories" for that reason proposes slices over work that already exists.
+  - id: backlog_scan
+    action: execute_script
+    script: { ref: actions }
+    subcommand: story-refs
+    args: ["--feature-dir", "{{feature_dir}}"]
+    outputs:
+      - { name: backlog_digest, from: "$.digest" }
+      - { name: story_count,    from: "$.story_count" }
+      - { name: open_count,     from: "$.open_count" }
+
+  # 6. THE ONE JUDGMENT IN THE WORKFLOW. Everything before this is a read and everything
+  #    after it is arithmetic; how coarsely a spec slices into stories is decided here,
+  #    once, in one place (§5.15) — which is why specify writes no stories at all.
+  #
+  #    The spec is in context because grouping is a judgment about the REQUIREMENTS, not
+  #    about their ids: two that share an aggregate invariant belong together and two that
+  #    merely sort next to each other do not.
+  #    No build_context envelope: a sticky context is carried in front of EVERY later model
+  #    step, and every step below already declares the spec itself — so the envelope would
+  #    send it twice per call and once again for each story written. Each step names what it
+  #    reads, which is also the only place a reader has to look.
+  - id: group_query
+    action: agent_query
+    context:
+      - "{{spec_file}}"
+    include_standards: false
+    task: |
+      The specification in context is the contract for this aggregate. These requirements
+      have moved since its story backlog was last in step, and each one needs to reach a
+      story:
+
+        {{work_csv}}
+
+      ({{work_note}}.)
+
+      The backlog as it stands today:
+
+      {{backlog_digest}}
+
+      {{guidance}}
+
+      Group those requirements into EXECUTION SLICES. One group becomes one story.
+
+      {{slice_directive}}
+
+      WHAT BELONGS IN ONE SLICE.
+
+      - A group is what one person can pick up and deliver as a coherent piece of work.
+        Judge that on the requirements themselves, as the spec words them — not on their
+        id numbers, which say nothing about what belongs together.
+      - PUT TOGETHER what cannot honestly be delivered apart: a behaviour and the business
+        rule that constrains it; two requirements that share an aggregate invariant, an
+        entity's lifecycle, or one user-visible outcome. A requirement whose acceptance
+        cannot be demonstrated without another one is in that other one's group.
+      - THAT TEST IGNORES WHERE THE SPEC PUTS THEM. Two requirements that read as one piece
+        of work belong in one group however far apart they are stated, and one that reads
+        as a separate concern stays separate however adjacent it is. The document's section
+        order is how it was written down, not how it gets built.
+      - KEEP APART what merely resembles: two requirements over the same entity that a
+        reviewer could accept independently are two stories. Coupling them buys nothing and
+        makes both wait for the slower half.
+
+      WHAT STANDS BEHIND WHAT.
+
+      - DECLARE THE ORDER. In each group's `depends_on`, name the groups in THIS list that
+        have to land before it — where this slice would be built against something another
+        slice has not delivered yet. An OPEN STORY from the backlog above may be named the
+        same way, by its story id. Empty where nothing has to come first.
+      - THIS IS ABOUT CODE, NOT IMPORTANCE. A group everything else calls into comes first
+        because of what it builds, not because it matters more. Do not name a group merely
+        because it is related, or thematically prior, or bigger: an edge that is not real
+        makes work wait for nothing, and it will not be questioned by anything downstream.
+      - GROUPS WITH NO EDGE BETWEEN THEM END UP AT THE SAME LEVEL and are picked up in
+        PARALLEL. That is the outcome to aim for — order only what genuinely has to be
+        ordered, and leave the rest free to run alongside each other.
+      - NO CYCLES. If two groups each need the other before they can be built, they are not
+        two slices — they are one, and should be one group.
+
+      THE RULES THAT DO NOT BEND.
+
+      - Every id in the list above must appear in EXACTLY ONE group. Not zero: an id left
+        out gets no story and nothing downstream will notice. Not two: two stories both
+        claiming one requirement makes "is this requirement delivered" unanswerable.
+      - Use ONLY the ids listed above. Do not pull in a requirement that has not moved, and
+        do not invent one.
+      - Give each group a title that names the OUTCOME it delivers, in the spec's own
+        vocabulary — what a reviewer would see working, not the ids it covers.
+      - `complexity` is your read of the slice's size: low | medium | high.
+      - `rationale` is one sentence on why these belong together, or why this one stands
+        alone. It is read by a person deciding whether to accept the slicing.
+    schema:
+      split_reason: "<empty unless ONE story was asked for and you returned more than one; then one sentence on what made the single story undeliverable>"
+      groups:
+        - id: g1
+          title: "<the outcome this slice delivers>"
+          requirements: ["FR-001", "BR-002"]
+          depends_on: ["<a group id from this list, or an open story id, that must land first — empty if nothing must>"]
+          complexity: "low|medium|high"
+          rationale: "<why these belong in one story>"
+    # No slicing without a model. Any fixed grouping here would name requirement ids that
+    # exist in one repo and nowhere else, and backlog-plan drops ids outside the work set — so
+    # a "realistic" mock degenerates to this one anyway, having first suggested otherwise. A
+    # mock run therefore exercises the ledger read, the work set and every gate, then stops
+    # at plan_gate saying the grouping produced nothing. That is the honest outcome.
+    mock:
+      groups: []
+      split_reason: ""
+    outputs:
+      - { name: groups,       from: "$.groups" }
+      - { name: split_reason, from: "$.split_reason" }
+
+  # 7. WHICH GROUPS ALREADY HAVE STORIES IN FRONT OF THEM. Deterministic: the model
+  #    proposed the slices, and the arithmetic over them — what each group covers, which
+  #    open stories intersect it, and what the question about each one should say — is
+  #    computed, so the same grouping always produces the same question.
+  - id: plan_scan
+    action: execute_script
+    script: { ref: actions }
+    subcommand: backlog-plan
+    args: ["--feature-dir", "{{feature_dir}}", "--groups", "{{groups}}", "--work", "{{work_csv}}", "--strategy", "{{strategy}}", "--ceiling", "{{single_ceiling}}"]
+    outputs:
+      - { name: group_count,     from: "$.group_count" }
+      - { name: groups_digest,   from: "$.groups_digest" }
+      - { name: unplaced_csv,    from: "$.unplaced_csv" }
+      - { name: repeated_csv,    from: "$.repeated_csv" }
+      - { name: any_candidates,  from: "$.any_candidates" }
+      - { name: candidate_ids,   from: "$.candidate_ids" }
+      - { name: candidate_csv,   from: "$.candidate_csv" }
+      - { name: ask_digest,      from: "$.ask_digest" }
+      - { name: split_note,      from: "$.split_note" }
+      - { name: split_count,     from: "$.split_count" }
+      - { name: oversized_csv,   from: "$.oversized_csv" }
+
+  # 7aa. ONE STORY WAS ASKED FOR AND MORE THAN ONE CAME BACK. A legitimate answer — a slice
+  #      nobody can pick up is not a story, and the split is what the option promises where
+  #      the work set is too heavy. Reported BEFORE the ask, because it changes what the
+  #      author is agreeing to: they asked for one story and are about to approve several.
+  #      Continuing rather than stopping is the point; refusing would leave the only route
+  #      to a large single-story feature being not to use the option at all.
+  - id: split_notice
+    condition: "{{split_count}} != 0"
+    action: verify_context
+    require_value: split_count
+    equals: "0"
+    on_mismatch: continue
+    on_mismatch_message: >
+      {{split_note}}. The stories are written in dependency order and each one names what
+      has to land before it, so the work is still one sequence — it is spread over more
+      stories than the launch line asked for. Reason given: {{split_reason}}
+
+  # 7ab. A SLICE NOBODY CAN PICK UP. The ceiling is a signal and not a limit, so this
+  #      neither refuses nor rewrites: how big a story can be is a fact about the work and
+  #      the team, and a hard cap here would split a coherent story to satisfy a number.
+  #      Said out loud because an oversized story is the one that stays open — it is easier
+  #      to re-slice now than to discover it three weeks in.
+  - id: oversized_notice
+    condition: "{{oversized_csv}} != ''"
+    action: verify_context
+    require_value: oversized_csv
+    equals: ""
+    on_mismatch: continue
+    on_mismatch_message: >
+      These slices carry more than {{single_ceiling}} requirements each: {{oversized_csv}}.
+      Nothing is refused — the count is a signal, not a limit — but a story that large is
+      the one that never gets picked up. Re-run /appweaver sync-stories with guidance on
+      where to divide it if it is genuinely more than one piece of work.
+
+  # 7a. A REQUIREMENT THE GROUPING DROPPED GETS NO STORY, AND THAT IS THE SILENT ONE. The
+  #     prompt above forbids it; this is the check that the model obeyed. Reported rather
+  #     than stopping, because the groups that ARE well formed are still worth writing —
+  #     but the run says which ids it is about to leave uncovered, and spec-coverage at the
+  #     end says so again from the document's own point of view.
+  - id: unplaced_notice
+    condition: "{{unplaced_csv}} != ''"
+    action: verify_context
+    require_value: unplaced_csv
+    equals: ""
+    on_mismatch: continue
+    on_mismatch_message: >
+      The grouping left these requirements out of every slice: {{unplaced_csv}}. No story
+      will be written for them by this run. Re-run /appweaver sync-stories to place them,
+      or raise them by hand with /appweaver user-story.
+
+  - id: repeated_notice
+    condition: "{{repeated_csv}} != ''"
+    action: verify_context
+    require_value: repeated_csv
+    equals: ""
+    on_mismatch: continue
+    on_mismatch_message: >
+      The grouping put these requirements in more than one slice: {{repeated_csv}}. Each
+      has been kept in the FIRST group that claimed it and removed from the others, so no
+      requirement gets two stories both claiming it — which would make "does this
+      requirement still have open stories", the completeness rule, answer for work that was
+      never really duplicated. No coverage is lost; the slicing may not be the one the
+      grouping intended, so it is worth a look at the stories this run wrote.
+
+  # 8. THE ASK. See the header for why this is asked rather than decided. Multi-select,
+  #    per story, because the decision is per story: a group can hold one story the author
+  #    is happy to move and another they will not touch, and a single yes/no would force
+  #    the same answer onto both.
+  #
+  #    A non-interactive run answers with ALL options, which is the settled default in both
+  #    directions and not a shortcut: a not-started story updated in place is §5.4's case 2,
+  #    and an in-flight story picked here mints a follow-on and is never rewritten (§5.5).
+  #    Leaving one out is the choice that needs a person.
+  - id: ask_update
+    condition: "{{any_candidates}} == true"
+    action: ask
+    multi: true
+    prompt: |
+      Some of these requirements already have OPEN stories in front of them.
+
+      {{ask_digest}}
+
+      Pick the stories this sync MAY change.
+
+        PICKED, not started   the story is rewritten to cover its whole group and
+                              restamped at {{latest_version}}.
+        PICKED, in flight     the story is left exactly as it is and a FOLLOW-ON is minted
+                              to carry the change, linked back to it.
+        LEFT OUT              the story is not touched at all, AND the requirements it
+                              already covers withdraw from their group. Whatever is left
+                              of that group still becomes a new story, so a group where
+                              one id has a story you will not move still delivers the rest.
+
+      Which may be changed?
+    options_from: "{{candidate_ids}}"
+    answer_key: approved_stories
+    answer_var: approved_stories
+
+  # 9. THE PLAN: one entry per story FILE, each already carrying its id, its path, and the
+  #    ids it must end up citing. Same op, same groups, same backlog as the scan above, so
+  #    the question the author answered and the work that follows from it cannot disagree
+  #    about what a group contains.
+  - id: plan_build
+    action: execute_script
+    script: { ref: actions }
+    subcommand: backlog-plan
+    args: ["--plan", "--feature-dir", "{{feature_dir}}", "--groups", "{{groups}}", "--work", "{{work_csv}}", "--approved", "{{approved_stories}}", "--version", "{{latest_version}}", "--cap", "200", "--strategy", "{{strategy}}", "--ceiling", "{{single_ceiling}}"]
+    outputs:
+      - { name: plan,           from: "$.plan" }
+      - { name: plan_count,     from: "$.plan_count" }
+      - { name: any_plan,       from: "$.any_plan" }
+      - { name: plan_digest,    from: "$.plan_digest" }
+      - { name: create_count,   from: "$.create_count" }
+      - { name: update_count,   from: "$.update_count" }
+      - { name: followon_count, from: "$.followon_count" }
+      - { name: skipped_csv,    from: "$.skipped_csv" }
+      - { name: stories_csv,    from: "$.stories_csv" }
+      - { name: plan_notes,     from: "$.notes_text" }
+      - { name: overflow_csv,   from: "$.overflow_csv" }
+      - { name: wave_digest,    from: "$.wave_digest" }
+      - { name: wave_count,     from: "$.wave_count" }
+      - { name: max_wave,       from: "$.max_wave" }
+      - { name: cycle_csv,      from: "$.cycle_csv" }
+      - { name: unresolved_deps_csv, from: "$.unresolved_deps_csv" }
+
+  # 9a. NOTHING TO WRITE HAS TWO CAUSES, AND THEY NEED DIFFERENT ANSWERS. Either the author
+  #     declined every story that stood in the way — a decision, not a failure — or the
+  #     grouping produced no slice at all, which means the one judgment step returned
+  #     nothing usable and the run should be repeated. A single message asserting the first
+  #     cause would send someone looking for a decision they never made. Two ordered sets
+  #     rather than a compound condition, the same idiom specify uses for covered_note.
+  - id: nothing_grouping
+    action: set
+    vars:
+      nothing_note: >-
+        the grouping produced no slice for any of them ({{work_count}} requirement(s) went
+        in, {{group_count}} group(s) came out). Nothing was declined and nothing was
+        written — re-run /appweaver sync-stories, and if it comes back empty again, raise
+        the stories by hand with /appweaver user-story
+
+  - id: nothing_declined
+    condition: "{{skipped_csv}} != ''"
+    action: set
+    vars:
+      nothing_note: >-
+        every one of them is already covered by a story you chose not to disturb
+        ({{skipped_csv}}). Those stories keep their existing spec versions, so this sync
+        will be offered again on the next run
+
+  - id: plan_gate
+    action: verify_context
+    require_true: any_plan
+    on_false: stop
+    on_false_message: >
+      Nothing to write for {{work_csv}}: {{nothing_note}}. The backlog is unchanged.
+
+  # 9b. MORE STORIES THAN THE WRITE LOOP WILL WRITE. `over:` stops at max_iterations and
+  #     says nothing — the entries past it are never written and the run still reports
+  #     success, which is the silent failure this whole workflow exists to remove. The cap
+  #     passed to backlog-plan above MUST match write_loop's max_iterations; this is what
+  #     names the stories that fall past it.
+  - id: overflow_notice
+    condition: "{{overflow_csv}} != ''"
+    action: verify_context
+    require_value: overflow_csv
+    equals: ""
+    on_mismatch: continue
+    on_mismatch_message: >
+      The plan holds {{plan_count}} stories and this run writes at most 200 of them. These
+      are not written: {{overflow_csv}}. Their requirements stay in the work set, so a
+      second /appweaver sync-stories run picks them up — or raise write_loop's
+      max_iterations (and the --cap it is passed) if a spec of this size is normal here.
+
+  # 9c. A CYCLE WAS DECLARED AND HAD TO BE BROKEN. Two slices each needing the other before
+  #     it can be built is a statement that they are one slice, and the arithmetic cannot
+  #     merge them — the grouping is the judgment. So the edge closing each cycle is
+  #     dropped, deterministically, and named: a backlog with no order at all is worse than
+  #     one missing an edge somebody can re-add, and an edge dropped in silence is worse
+  #     than both.
+  - id: cycle_notice
+    condition: "{{cycle_csv}} != ''"
+    action: verify_context
+    require_value: cycle_csv
+    equals: ""
+    on_mismatch: continue
+    on_mismatch_message: >
+      The slicing declared stories that depend on each other in a cycle. These edges were
+      dropped so the backlog has an order at all: {{cycle_csv}}. Two slices that each need
+      the other are one slice — check whether those stories should have been written as
+      one, and add the ordering back by hand in `depends_on:` if the cycle was a mistake in
+      the naming rather than in the slicing.
+
+  # 9d. AN EDGE POINTING AT NOTHING. Named rather than dropped in silence, because a
+  #     dependency that resolves to no slice and no open story is usually a real ordering
+  #     claim aimed at the wrong name — and the story it should have pointed at now looks
+  #     free to start.
+  - id: unresolved_deps_notice
+    condition: "{{unresolved_deps_csv}} != ''"
+    action: verify_context
+    require_value: unresolved_deps_csv
+    equals: ""
+    on_mismatch: continue
+    on_mismatch_message: >
+      The slicing named dependencies that match no slice in this run and no open story:
+      {{unresolved_deps_csv}}. They set no order, so any story that was meant to wait for
+      them reads as free to start. Check `depends_on:` on the stories this run wrote.
+
+  # 10. THE WRITES. One pass per plan entry, and each pass is an author step followed by a
+  #     stamp. The three author steps are mutually exclusive on `action`; whichever runs
+  #     writes the whole file.
+  #
+  #     ENTRIES ARRIVE IN WAVE ORDER, so the stories are written in the order they can be
+  #     picked up in — and a run that meets the ceiling below loses the LAST wave rather
+  #     than an arbitrary slice of the backlog.
+  #
+  #     THE STAMP IS NOT A FORMALITY. The frontmatter is the gate surface — spec-coverage,
+  #     check-stories, analyze-slice and close-story all read `exercises:`, `spec_version:`
+  #     and `status:` and none of them opens the body, and `depends_on:` / `wave:` are what
+  #     say which stories can start now. So those fields are written by the
+  #     kit from the plan, not taken on trust from the model that wrote the prose, for the
+  #     same reason the Change History row is computed rather than declared: a model that
+  #     drops one id from `exercises:` produces a story that reads perfectly and is
+  #     invisible to every gate built to protect it.
+  - id: write_loop
+    action: loop
+    over: "{{plan}}"
+    as: p
+    # MUST MATCH the --cap passed to plan_build above, which is what reports the entries
+    # that fall past it. The engine's foreach stops here in silence.
+    max_iterations: 200
+    steps:
+
+      # 10a. CREATE — a group nothing is building yet.
+      - id: create_story
+        condition: "{{p.action}} == create"
+        action: agent_author
+        context:
+          - .appweaver/templates/story-template.md
+          - "{{spec_file}}"
+          - { path: .appweaver/memory/constitution.ui.md, optional: true }
+        output_target: { type: file, path: "{{p.path}}" }
+        task: |
+          Write ONE user story into the template in context, for this slice of the
+          specification:
+
+            story id:      {{p.story}}
+            slice:         {{p.group_title}}
+            requirements:  {{p.requirements_csv}}
+            why one slice: {{p.rationale}}
+            size:          {{p.complexity}}
+            lands after:   {{p.depends_on_csv}}
+            wave:          {{p.wave}}
+
+          Return the COMPLETE story document. Rules:
+
+          - THE SPEC IS THE CONTRACT AND THIS IS A SLICE OF WORK OVER IT. Nothing here
+            changes it. If writing this story exposes something the spec gets wrong or
+            leaves out, say so in Notes and leave the requirement alone — the contract
+            moves through /appweaver update-spec, never through a story.
+          - Frontmatter: set `id:` to {{p.story}}, `exercises:` to exactly
+            [{{p.requirements_csv}}], `status: open`, and `spec_version:` to
+            {{latest_version}}. Give it a `title:` that names the OUTCOME a reviewer would
+            see working, in the spec's vocabulary — not the ids it covers.
+          - `depends_on:` AND `wave:` ARE THE KIT'S, written from the slicing above. Do not
+            set them and do not write anything that contradicts them. What they cannot say
+            belongs in "## Notes": WHY the stories named above have to land first, and what
+            of this slice can be started before they do. A wave is an eligibility level and
+            not a priority — stories sharing one have no ordering between them and are
+            picked up in parallel.
+          - "## Story" is one "As a … I want … so that …", written from the actor the spec
+            names. If the requirements serve different actors, that is a signal the slice
+            is wrong — say so in Notes rather than inventing a role that covers both.
+          - "## Requirements delivered": one line per id, saying what THIS story delivers
+            OF that requirement. A story rarely delivers a whole requirement; name the
+            part. Quote no requirement in full — the spec is the wording.
+          - "## Constraints" IS NOT OPTIONAL AND IS THE HALF MOST OFTEN LOST. Read the
+            spec's Constraints & NFRs (CN-), Data Classification (DC-), Integration
+            Contracts (IC-) and Experience Standards (UX-) sections, and its Experience
+            Scope, and carry BY ID every entry that binds this slice — with one line each
+            saying what this slice has to do about it. Where the slice has a user-facing
+            surface, the UX- standards and the device / browser / assistive-technology
+            floors apply and MUST be listed: prototype, design-ui and implement-ui author
+            from the spec and the story, so a standard not carried here is a standard this
+            slice will be built without. Do NOT add these ids to `exercises:` — that field
+            is FR-/BR- only, because it is the delivery relation, and a constraint is not
+            delivered, it is met. Write "None" only for a class the spec genuinely leaves
+            empty or that genuinely does not touch this slice.
+          - "## Acceptance": checkable statements in the spec's vocabulary, covering every
+            requirement in `exercises:` and every constraint listed above that this slice
+            can be observed to meet. These are what analyze-slice pairs tests against, so
+            each one must be decidable by looking at the running system — never "works
+            correctly", never a restatement of the requirement.
+          - THIS STORY IS THE INPUT TO story-plan, which designs its execution against
+            the current spec and code. Write it so that design pass needs nothing this
+            document does not carry:
+            the actor, the requirement ids, the constraints by id, and acceptance that
+            settles what "done" means. Detail that pins the outcome down, not detail for
+            its own sake.
+          - NO IMPLEMENTATION. No types, endpoints, schemas, frameworks, file layouts or
+            library choices — those are the design phase's, and a story that names them
+            has decided something it has no standing to decide.
+          - Use "## Notes" for sequencing, risks, and what is deliberately OUT of this
+            slice. Leave the template's guidance comments in place.
+
+      # 10b. FOLLOW-ON — the group's story is already being implemented (§5.5). The original
+      #      is in context to be read, never to be rewritten: this file is a NEW story, and
+      #      what makes the pair coherent is that it carries only the remainder.
+      - id: followon_story
+        condition: "{{p.action}} == followon"
+        action: agent_author
+        context:
+          - .appweaver/templates/story-template.md
+          - "{{spec_file}}"
+          - "{{p.prior_path}}"
+          - { path: .appweaver/memory/constitution.ui.md, optional: true }
+        output_target: { type: file, path: "{{p.path}}" }
+        task: |
+          Write a FOLLOW-ON story. {{p.follows}} is open and already being implemented — a
+          story plan exists and someone is building against the requirements as they read
+          when it was written. That story is NOT being changed. This one carries what the
+          spec has moved since.
+
+            new story id:  {{p.story}}
+            follows:       {{p.follows}} ("{{p.prior_title}}", which cites {{p.prior_csv}})
+            slice:         {{p.group_title}}
+            requirements:  {{p.requirements_csv}}
+            why one slice: {{p.rationale}}
+
+          {{p.follows}} is in context. Read it to see what is ALREADY being delivered, and
+          write only the remainder.
+
+          Return the COMPLETE story document. Rules:
+
+          - Frontmatter: `id: {{p.story}}`, `follows: {{p.follows}}`, `exercises:` exactly
+            [{{p.requirements_csv}}], `status: open`, `spec_version: {{latest_version}}`.
+          - THE REMAINDER, NOT THE WHOLE. {{p.follows}} closes having delivered what it was
+            written to deliver, and this story delivers what the spec now asks for beyond
+            that. Say in "## Requirements delivered", per id, what has moved and what this
+            story adds — a reader holding both should see two halves of one requirement,
+            never two stories racing to deliver the same thing.
+          - Both stories stay open and both are legitimate. There is no "superseded": a
+            requirement is delivered when it has NO OPEN STORIES, so the pair is exactly
+            how a mid-flight change is recorded.
+          - Name the dependency honestly in "## Notes": what of {{p.follows}} has to land
+            first, and what can proceed in parallel. `depends_on:` and `wave:` are the
+            kit's — this story is in wave {{p.wave}}, after {{p.depends_on_csv}} — and
+            `follows:` is deliberately NOT an ordering link, because the remainder is often
+            buildable alongside the story it carries the remainder of. Saying which half is
+            which is exactly what "## Notes" is for.
+          - Everything the ordinary story rules require still holds: one "As a … I want …
+            so that …"; "## Constraints" carrying the spec's CN-/DC-/IC-/UX- ids and the
+            Experience Scope floors that bind this slice, by id, never in `exercises:`;
+            "## Acceptance" decidable by looking at the running system; no implementation
+            detail; enough that story-plan can scope its design pass from it directly.
+
+      # 10c. UPDATE — the story is open, no story plan exists, and the author approved it.
+      #      It is rewritten against the spec as it now reads, and it may GAIN requirements:
+      #      the group's unclaimed ids move into it, which is the point of approving it.
+      - id: update_story
+        condition: "{{p.action}} == update"
+        action: agent_author
+        context:
+          - "{{p.path}}"
+          - "{{spec_file}}"
+          - { path: .appweaver/memory/constitution.ui.md, optional: true }
+        output_target: { type: file, path: "{{p.path}}" }
+        task: |
+          The story {{p.story}} is in context, and the specification it slices has moved.
+          Bring it back into step.
+
+            story:              {{p.story}} ("{{p.prior_title}}")
+            it cites today:     {{p.prior_csv}}
+            it must now cite:   {{p.requirements_csv}}
+            its slice:          {{p.group_title}}
+            why one slice:      {{p.rationale}}
+
+          Return the COMPLETE updated story. Rules:
+
+          - EDIT IN PLACE. Keep everything the spec's change did not affect exactly as it
+            reads — wording, ordering, the Notes someone wrote. This story may already be
+            planned around, and an unrelated rewrite costs its reader a re-read for nothing.
+          - Frontmatter: `exercises:` becomes exactly [{{p.requirements_csv}}] and
+            `spec_version:` becomes {{latest_version}}. Leave `id:`, `status:`,
+            `depends_on:`, `wave:`, `follows:`, `work_item:` and `created:` alone.
+            `depends_on:` and `wave:` are rewritten from the slicing by the kit, which KEEPS
+            the dependencies this story already carries rather than replacing them — an edge
+            somebody added by hand may name work outside this feature that the sync has no
+            view of. This story is in wave {{p.wave}}.
+          - WHERE IT GAINED IDS, the story is genuinely bigger: add a "## Requirements
+            delivered" line for each new id, extend "## Acceptance" to cover it, and revisit
+            the "## Story" sentence and the title so they still name what this slice
+            actually delivers. A story whose title stopped describing it is worse than one
+            that was never updated.
+          - WHERE AN ID IT ALREADY CITED HAS CHANGED WORDING, restate what this story
+            delivers of it and re-check every acceptance line that depended on the old
+            reading. That is the whole reason this story is being touched.
+          - "## Constraints" is re-derived, not preserved: read the spec's CN-/DC-/IC-/UX-
+            sections and its Experience Scope again and carry by id what binds the slice as
+            it now stands. A constraint that has left the spec leaves this section; one that
+            has arrived is added, with the acceptance line that shows it is met. Never add
+            these ids to `exercises:`.
+          - NO IMPLEMENTATION DETAIL, and nothing here changes the spec. If the change
+            reveals a problem with the contract, note it and leave the requirement alone.
+
+      # 10d. THE FIELDS THE GATES READ, written from the plan. See the block above 10a.
+      - id: stamp_story
+        action: execute_script
+        script: { ref: actions }
+        subcommand: story-stamp
+        # --title is a FALLBACK, not an override: story-stamp applies it only where the
+        # title is missing or still the template's placeholder, so the one the author wrote
+        # always wins. It exists because a story with no title reads as "(untitled)" in
+        # every later prompt and listing, and losing the name of the work is a needless
+        # way to make the backlog harder to read.
+        # `--depends-on` is a UNION with what the file already carries, not a replacement:
+        # the sync sees one feature's spec, and an edge added by hand may name work outside
+        # it. `--wave` is set outright — it is derived from the union, so re-deriving it is
+        # the only way it stays true.
+        args: ["--feature-dir", "{{feature_dir}}", "--story", "{{p.story}}", "--ids", "{{p.requirements_csv}}", "--version", "{{latest_version}}", "--follows", "{{p.follows}}", "--title", "{{p.group_title}}", "--depends-on", "{{p.depends_on_csv}}", "--wave", "{{p.wave}}"]
+
+  # 11. THE RELATION, READ THE OTHER WAY ROUND. Every story declares what it delivers in
+  #     its own `exercises:`; the spec's Story Coverage block is that relation viewed from
+  #     the requirements, regenerated wholesale from stories/ rather than patched. It sits
+  #     between the AW:COVERAGE markers, which the ledger hash cuts out — so writing it is
+  #     not an unledgered edit of the contract, and this workflow never has to re-stamp a
+  #     document it did not change.
+  - id: coverage
+    action: execute_script
+    on_error: continue
+    script: { ref: actions }
+    subcommand: spec-coverage
+    args: ["--feature-dir", "{{feature_dir}}"]
+    outputs:
+      - { name: uncovered_csv, from: "$.uncovered_csv" }
+      - { name: delivered_csv, from: "$.delivered_csv" }
+
+  - id: resolve_post_hooks
+    action: execute_script
+    script: { ref: actions }
+    subcommand: resolve-hooks
+    args: ["--phase", "after_sync_stories"]
+    outputs:
+      - { name: after_hooks, from: "$.hooks" }
+  - id: dispatch_post_hooks
+    action: dispatch_hooks
+    hooks_from_variable: after_hooks
+
+outputs:
+  feature_directory: "{{feature_dir}}"
+  spec_file: "{{spec_file}}"
+  spec_version: "{{latest_version}}"
+  requirements_synced: "{{work_csv}}"
+  synced_from: "{{work_note}}"
+  versions_covered: "{{span_versions_csv}}"
+  requirements_removed: "{{removed_csv}}"       # named by a row, no longer in the spec (E1)
+  requirements_unplaced: "{{unplaced_csv}}"     # the grouping left these out — no story
+  requirements_uncovered: "{{uncovered_csv}}"   # no story at all, from the spec's own view
+  requirements_delivered: "{{delivered_csv}}"   # every story citing them is closed
+  stories_written: "{{stories_csv}}"
+  stories_untouched: "{{skipped_csv}}"          # you declined these
+  plan_summary: "{{create_count}} created, {{update_count}} updated, {{followon_count}} follow-on"
+  plan_notes: "{{plan_notes}}"
+  slicing_strategy: "{{strategy}} — {{strategy_note}}"
+  slicing_split: "{{split_note}}"               # one story asked for; what actually came out
+  delivery_waves: "{{wave_digest}}"             # wave 1 can be started now; the rest wait
+  dependency_cycles: "{{cycle_csv}}"            # edges dropped to break a declared cycle
+  dependencies_unresolved: "{{unresolved_deps_csv}}"   # edges naming no slice and no story
+  next: "The backlog is in step with spec.md at {{latest_version}}, laid out over {{wave_count}} delivery wave(s). START WITH WAVE 1 — those stories have nothing in front of them, and stories sharing a wave have no ordering between them, so they can be picked up in parallel; a later wave becomes startable as its own dependencies land, not when the whole wave before it finishes. Make sure /appweaver plan (and /appweaver plan-ui where a frontend lane is declared) has been run for this spec version first — a story design reads the feature plan and stops against one the spec has moved past. Then run /appweaver story-plan <story-id> to design one story's execution, then implement. READ THE FIELDS ABOVE FIRST: dependency_cycles and dependencies_unresolved are ordering the run could not honour, and a story that reads as free to start may not be; requirements_removed leaves open stories orphaned and needs deciding by hand; requirements_unplaced and requirements_uncovered are requirements with no story, which no later gate will raise for you; stories_untouched are the ones you declined, and they stay at their old spec version, so this sync will offer them again next run."