aw-spec-cli 0.1.18 → 0.1.20

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

@@ -95,7 +95,7 @@ workflow:
     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 re-run parity."
+    on_empty_message: "No active feature. Run /appweaver select-feature first (pick or create the feature, e.g. Order or PatientRegistration), then re-run parity."
 
   - id: verify_spec
     action: verify_context

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

@@ -85,7 +85,7 @@
 
 name: aw-spec-plan
 description: "Author the feature's lane plans from the spec and the bounded context's domain model — backend-plan.md when a backend lane is declared, frontend-plan.md when a frontend lane is, both when both are. Lanes come from .appweaver/stacks.json, so one command covers backend-only, frontend-only and full-stack projects; the former separate design-ui command is folded in. It ASKS what it is planning, the way implement asks what it is building: the master (`main`), one of the OPEN CHANGES, or a new plan-only change for a refactor with no spec delta — the argument doubles as the answer, and the menu appears only once a master exists, so a first run bootstraps with no prompt. `main` on a feature that already has masters RE-DERIVES them from the merged spec.md + domain-model.md — the operation finalize-delta's contract assumes when it merges a change's spec and model halves and no lane plan — and is confirmed before it rewrites anything. A change instead gets delta-backend-plan.md / delta-frontend-plan.md inside changes/<CR-id>/ while the masters stay untouched, written against the effective model (the master model, the change's own model delta, and the pending model deltas of LOWER waves, which are its predecessors) and against the feature's real source files from its OKF concept. Master authoring is template-driven: the kit's templates by default, or the code-derived as-built structure when onboard installed an override. Authoring only — a master gates at analyze-plan; a change ships through the CR chain."
-version: 5.0.0
+version: 5.1.0
 agent_agnostic: true
 dialect: aw-spec.orchestrator/v1
 
@@ -164,6 +164,10 @@ vars:
   plan_mode: "bootstrap"       # bootstrap | rederive | delta — reported, not branched on
   domain_model: ""
   domain_model_exists: "false"
+  owned_sections: ""           # the model section(s) this feature answers for — feature-aggregates
+  shared_with_csv: ""          # the other features answering for the same aggregate(s)
+  one_to_one: "true"
+  model_scope_plan: ""         # which part of those sections the domain layer realises
   source_files: []             # the feature's real source files, from its OKF concept
   source_count: "0"
 
@@ -200,18 +204,21 @@ workflow:
   #    project's standards are exactly what they were before the two commands merged.
   #    No blocking gate: an unconfigured project soft-continues (the constitutions still
   #    carry each lane's ratified base).
+  #
+  #    ONLY THE BACKEND'S RULES LOAD HERE. The frontend's used to load alongside them,
+  #    before either lane authored anything, and sticky standards only accumulate — so the
+  #    service plan was authored with `## /aw-spec-plan-ui` in its envelope and the
+  #    experience plan with the service set. Each prompt names its lane, but it said so
+  #    inside an envelope that contradicted it. The UI set now loads at the frontend
+  #    boundary instead, with `replace`, in both places a frontend document is authored:
+  #    tech_select_ui_master before the master frontend sections, and the delta-plan
+  #    module's own swap before the frontend delta plan.
   - id: tech_select
     condition: "{{be_declared}} == true"
     action: include
     module: .appweaver/orchestrator/modules/tech-select.orch.yaml
     with: { command: aw-spec-plan }
 
-  - id: tech_select_ui
-    condition: "{{fe_declared}} == true"
-    action: include
-    module: .appweaver/orchestrator/modules/tech-select.orch.yaml
-    with: { command: aw-spec-plan-ui }
-
   # 2. Resolve the current feature and require its spec.
   - id: feature_paths
     action: execute_script
@@ -238,11 +245,42 @@ workflow:
       - { name: domain_model,        from: "$.domain_model" }
       - { name: domain_model_exists, from: "$.domain_model_exists" }
 
+  # WHICH PART OF THAT MODEL THIS PLAN REALISES. The model is filed by aggregate, and a
+  # feature is a capability scope the developer chose: it may act on several aggregates,
+  # and several features may act on one. Resolved from the spec's Acts-on line, then the
+  # boundary map, then the feature name. on_error: continue — without an answer the
+  # prompt falls back to the model as a whole, which is what it read before.
+  - id: feature_aggregates
+    action: execute_script
+    on_error: continue
+    script: { ref: xref }
+    subcommand: feature-aggregates
+    args: ["--feature-dir", "{{feature_dir}}"]
+    outputs:
+      - { name: owned_sections,  from: "$.owned_sections" }
+      - { name: shared_with_csv, from: "$.shared_with_csv" }
+      - { name: one_to_one,      from: "$.one_to_one" }
+
+  # HOW MUCH OF THOSE SECTIONS THE DOMAIN LAYER CARRIES. A feature that alone answers for
+  # an aggregate realises its whole section. A feature that shares it realises only what
+  # its own requirements act on: the rest is a sibling feature's, and planning it here
+  # would give two plans the same element to realise. The engine has no conditional
+  # prompt text, so the rule is an ordered pair of sets handed to the prompt as one line.
+  - id: model_scope_shared
+    action: set
+    vars:
+      model_scope_plan: "{{owned_sections}}, which this feature SHARES with other features. Realise only the entities, value objects, states and BR-nnn this feature's requirements act on, under the model's names and boundary; an element of that section this feature does not use belongs to another feature and is left out — never redefined, renamed or narrowed"
+  - id: model_scope_sole
+    condition: "{{one_to_one}} == true"
+    action: set
+    vars:
+      model_scope_plan: "{{owned_sections}}. This feature is the only one that answers for it, so the domain layer realises that whole section"
+
   - 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 re-run plan."
+    on_empty_message: "No active feature. Run /appweaver select-feature first (pick or create the feature, e.g. Order or PatientRegistration), then re-run plan."
 
   - id: verify_spec
     action: verify_context
@@ -528,9 +566,10 @@ workflow:
       - THE SPEC AND THE DOMAIN MODEL ARE THE ONLY DOMAIN INPUTS. You have them plus the
         technical standards, and NO domain rule files. Realise what they state, and invent
         no domain rule they omit (an unavoidable new concept → §7 DA-n).
-      - THE DOMAIN LAYER (§1) MUST FOLLOW THE CONTEXT'S DOMAIN MODEL EXACTLY: entities &
-        value objects are its `## Aggregate:` section's entities (SAME names), invariants
-        are its BR-nnn (cite each, never restate), the aggregate boundary is its Boundary
+      - THE DOMAIN LAYER (§1) MUST FOLLOW THE CONTEXT'S DOMAIN MODEL EXACTLY. The
+        section(s) this feature answers for: {{model_scope_plan}}. Within that scope,
+        entities & value objects are the section's entities (SAME names), invariants are
+        its BR-nnn (cite each, never restate), the aggregate boundary is its Boundary
         block, and states are the lifecycle it describes. The model — not the spec — is
         where those facts live; the spec cites them by id. This document records WHERE
         each invariant is ENFORCED, never what it says. Elaborate with domain events /
@@ -628,10 +667,11 @@ workflow:
         textbook layer gets its own section; a layer the feature does not need does NOT
         appear.
       - KEEP THE NEUTRAL ANCHORS (the template pins them): §1.2 is the domain/data MODEL
-        and MUST follow the CONTEXT'S DOMAIN MODEL EXACTLY — entities & value objects are
-        its aggregate section's entities (SAME names), invariants are its BR-nnn (cite
-        each and record WHERE each is enforced), the boundary is its Boundary block,
-        states are its lifecycle; cross-slice references-by-id live here. One §2
+        and MUST follow the CONTEXT'S DOMAIN MODEL EXACTLY for the section(s) this feature
+        answers for — {{model_scope_plan}}. Entities & value objects are the section's
+        entities (SAME names), invariants are its BR-nnn (cite each and record WHERE each
+        is enforced), the boundary is its Boundary block, states are its lifecycle;
+        cross-slice references-by-id live here. One §2
         subsection is the EXTERNAL INTEGRATIONS table (its heading contains "Integration")
         — one port/adapter row per IC-, realising the obligation the spec named.
       - REALISE THE LIFTED CONSTRAINTS (each cites its spec id): CN- → structural ones
@@ -701,9 +741,10 @@ workflow:
         A row whose id is gone is deleted along with what it justified. A spec id or model
         invariant with NO plan element is a GAP — realise it, in the shape the rest of the
         document already uses.
-      - THE DOMAIN LAYER (§1) MUST FOLLOW THE CONTEXT'S DOMAIN MODEL EXACTLY: entities &
-        value objects are its `## Aggregate:` section's entities (SAME names), invariants
-        are its BR-nnn (cite each, never restate), the aggregate boundary is its Boundary
+      - THE DOMAIN LAYER (§1) MUST FOLLOW THE CONTEXT'S DOMAIN MODEL EXACTLY. The
+        section(s) this feature answers for: {{model_scope_plan}}. Within that scope,
+        entities & value objects are the section's entities (SAME names), invariants are
+        its BR-nnn (cite each, never restate), the aggregate boundary is its Boundary
         block, and states are the lifecycle it describes. Where the model has MOVED since
         this plan was written, the model is right and the plan is stale.
       - CARRY THE LEDGERS FORWARD. §7 DA-n architectural decisions and the WA-n
@@ -722,6 +763,23 @@ workflow:
         (the spec ids and BR-nnn that drove it). Do NOT invent a version number — the
         version spine belongs to close-delta.
 
+  # ══════════════ THE LANE SWAP — the frontend's rules replace the backend's ═══
+  # Both tech-select includes used to run up at step 4, before either lane authored
+  # anything, and sticky standards only accumulate — so on a full-stack run the backend
+  # plan was authored with `## /aw-spec-plan-ui` in its envelope and the frontend plan with
+  # the service set. Each prompt names its lane, but it did so inside an envelope that
+  # contradicted it, and the envelope is the half the model cannot argue with.
+  #
+  # `fe_mode != skip` is what makes this the MASTER path's swap and not the delta path's:
+  # fe_mode is only set to a real mode by the master branches above, so on a `plan CR-…`
+  # run this does not fire and the delta module below does its own swap at its own
+  # frontend boundary.
+  - id: tech_select_ui_master
+    condition: "{{fe_mode}} != skip"
+    action: include
+    module: .appweaver/orchestrator/modules/tech-select.orch.yaml
+    with: { command: aw-spec-plan-ui, replace: "true" }
+
   # ═══════════ FRONTEND LANE — bootstrap, greenfield experience template ═══════
   # The experience twin of the service plan, and the MEDIATOR between spec.md and the
   # frontend code. Its sections are the experience, not the four clean-architecture
@@ -993,7 +1051,14 @@ workflow:
       - { name: wave,              from: "$.wave" }
       - { name: predecessor_files, from: "$.predecessor_files" }
       - { name: predecessor_count, from: "$.predecessor_count" }
+      - { name: predecessor_ids,   from: "$.predecessor_ids" }
       - { name: sibling_count,     from: "$.sibling_count" }
+      - { name: sibling_ids,       from: "$.sibling_ids" }
+      # Predecessors AND siblings in one list: the delta plan is authored against both, and
+      # a build_context takes a single `context_from:` variable. Which entries are which is
+      # carried by predecessor_ids / sibling_ids, because the planner's licence over the two
+      # is opposite — a predecessor may be built on, a sibling may only be designed around.
+      - { name: related_docs,      from: "$.related_docs" }
 
   # Author that change's delta plans — one per declared lane whose MASTER exists, inside
   # changes/<CR-id>/ beside its delta-spec. The masters are left UNTOUCHED; the change

package/assets/.appweaver/orchestrator/workflows/aw-spec-recall-delta.orch.yaml

@@ -0,0 +1,319 @@
+# =============================================================================
+# aw-spec-recall-delta (orchestrator) — WITHDRAW a change that never shipped
+#
+# The escape hatch of the CR loop, and the counterpart of close-delta:
+#   close-delta    the change SHIPPED  — archive it and bump the version
+#   recall-delta   the change is WITHDRAWN — archive it and bump NOTHING
+#
+#   specify → plan → analyze-plan-delta → implement → build → analyze-slice-delta
+#       → finalize-delta → analyze-slice → close-delta
+#       └─ recall-delta may end it anywhere BEFORE finalize-delta ────────────┘
+#
+# WHY IT EXISTS. Changes get abandoned: the requirement was dropped, the approach was
+# wrong, a wider refactor swallowed it. Until this stage there was no way to say so. The
+# only mechanism that took a change out of the open set was `cr-archive`, which archives
+# AND bumps the version in one act, so withdrawing one meant either burning a version
+# number on work that shipped nothing or deleting the directory by hand and editing
+# active_version.json — an operation with no record, no gate, and nothing to stop it being
+# done to the wrong change. The archive and the bump are now separable (`cr-archive
+# --recall`), and this stage is the supported way to reach that half.
+#
+# A RECALL IS NOT A ROLLBACK. It withdraws the change's DOCUMENTS — its delta-spec, its
+# delta plans and its model delta, all archived intact under changes/archive/<id>/ beside a
+# RECALLED.md that records the date and the reason. It does NOT revert code: a change that
+# reached /appweaver implement has already generated source files, and reverting those is
+# git's job, not this pipeline's. The output and the marker both say so, because a stage
+# that half-undoes something while sounding like it undid all of it is worse than no stage.
+#
+# TWO REFUSALS, BOTH MECHANICAL AND BOTH READ OFF DISK.
+#
+#   MERGED — finalize-delta has already folded this change into spec.md and the context's
+#   domain-model.md, and appended a Change History row carrying its id. The masters now
+#   describe behaviour that includes it, so withdrawing the change would leave them
+#   describing work no open change accounts for. The remedy for a merged change that should
+#   not have landed is a NEW change that reverses it. Detected from the id's presence in
+#   spec.md, which is that Change History row.
+#
+#   ⏭️ THE UN-MERGE IS DELIBERATELY NOT BUILT (decision, 2026-09-11 — not a missing piece).
+#   Both prerequisites now exist: finalize-delta snapshots both masters to
+#   changes/<id>/pre-merge/, and cr-merge-check can prove no other delta landed in between,
+#   which is exactly the window a restore would be safe in. It is still not built, because a
+#   restore is a whole-file overwrite of two long-lived hand-curated documents, and what it
+#   would NOT roll back is the rest of what finalize-delta did — the OKF cross-reference
+#   edges and the re-authored concept Overview. A command that restores the masters while
+#   leaving the knowledge layer describing the withdrawn change is the kind of half-undo
+#   this stage's own header refuses to be. The snapshot is kept regardless: it is the record
+#   of what the masters said, and an operator who needs it can read it.
+#
+#   DEPENDANTS — a wave is a dependency level. Same wave means independent; a HIGHER wave
+#   means planned and built on top of the lower ones. Withdrawing a lower-wave change
+#   therefore strands every open change above it, so this stage refuses and names them.
+#   `depends_on` is stamped nowhere yet (⌛ with the rest of the parallel-delta merge
+#   fence), so the wave is the only dependency signal that actually exists — and it is the
+#   conservative one, since same-wave siblings are never counted.
+#
+# THE VERSION DOES NOT MOVE. That is the entire point of the stage and the one invariant
+# worth stating twice: a version records what a change SHIPPED as, and a recalled change
+# shipped nothing. Nothing here stamps a header, appends a Change History row, or touches
+# active_version.json's `version` field.
+#
+# Launch:  /appweaver recall-delta [CR-id]   (a bare id skips the prompt)
+# Prereq:  an OPEN change on the active feature that finalize-delta has NOT merged.
+# =============================================================================
+
+name: aw-spec-recall-delta
+description: "Withdraw an open change that will not ship — archive changes/<id>/ and its model delta into changes/archive/<id>/ beside a RECALLED.md recording the date and reason, and drop it from active_version.json's open set WITHOUT bumping the version. Refuses a change finalize-delta already merged into the masters (the remedy there is a new change that reverses it) and one that a higher-wave open change is built on top of. Withdraws documents only — code already generated by implement is not reverted. Invokes no model and generates no code."
+version: 1.0.0
+agent_agnostic: true
+dialect: aw-spec.orchestrator/v1
+
+inputs:
+  user_input:
+    description: "Optional CR id of the change to withdraw. A bare id selects it and skips the prompt; anything else is ignored and the menu is shown."
+    required: false
+    bind: USER_INPUT
+
+scripts:
+  actions:
+    sh:  .appweaver/scripts/bash/aw-spec-actions.sh
+    ps1: .appweaver/scripts/powershell/aw-spec-actions.ps1
+  xref:
+    sh:  .appweaver/scripts/bash/aw-xref.sh
+    ps1: .appweaver/scripts/powershell/aw-xref.ps1
+
+# No standards seed and no domain/tech rule selection: this stage authors nothing, so it
+# has no prompt to govern. It is bookkeeping over changes/ + active_version.json, plus the
+# two refusals.
+standards: []
+
+vars:
+  has_changes: "false"
+  cr_choice: ""
+  cr_id: ""
+  merged: "false"
+  merge_evidence: ""
+  has_dependants: "false"
+  dependant_ids: ""
+  dependant_count: "0"
+  # The two refusal flags, both DOWN by default and raised only by the good state — see
+  # the gates below for why fail-closed is the right default here.
+  not_merged: "false"
+  no_dependants: "false"
+  recall_confirmed: "false"
+  recalled: "false"
+  archived_dir: ""
+  recall_marker: ""
+  open_count: "0"
+
+workflow:
+
+  # 1. Resolve the active feature.
+  - id: feature_paths
+    action: execute_script
+    on_error: continue      # never crash raw on 'no feature set' — the gate below explains it
+    script: { ref: actions }
+    subcommand: feature-paths
+    outputs:
+      - { name: feature,     from: "$.feature" }
+      - { name: feature_dir, from: "$.feature_dir" }
+
+  - 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 feature, e.g. Order or PatientRegistration), then re-run recall-delta."
+
+  # 2. WHICH CHANGES ARE OPEN — the evidence is changes/<CR-id>/ on disk. No synthetic
+  #    rows: `main` is not a change and there is nothing to open here, so the menu is the
+  #    real changes and nothing else. `matched_label` resolves a CR id passed as the
+  #    argument to the whole option string, which is how a bare `recall-delta CR-…` skips
+  #    the prompt entirely.
+  - id: cr_list
+    action: execute_script
+    script: { ref: actions }
+    subcommand: cr-list
+    args: ["--feature-dir", "{{feature_dir}}", "--preselect", "{{USER_INPUT}}"]
+    outputs:
+      - { name: change_options, from: "$.select_options" }
+      - { name: matched_label,  from: "$.matched_label" }
+      - { name: has_changes,    from: "$.has_changes" }
+      - { name: change_count,   from: "$.count" }
+
+  - id: require_changes
+    action: verify_context
+    require_true: has_changes
+    on_false: stop
+    on_false_message: "No open change on this feature — nothing to withdraw. A change is opened by /appweaver specify; one that already shipped was archived by /appweaver close-delta and is under changes/archive/, where a recall does not reach it."
+
+  # 3. WHICH ONE. single_option_confirm so a feature with exactly one open change still
+  #    confirms the id out loud — this stage archives documents, and picking silently is
+  #    how the wrong change gets withdrawn on a feature the operator has two open on.
+  - id: pick_change
+    action: user_select
+    prompt: "Which open change is being WITHDRAWN? Its delta-spec, delta plans and model delta are archived under changes/archive/ and it leaves the open set — with no version bump, because a recalled change ships nothing. Code that /appweaver implement already generated for it is NOT reverted; that is a git operation."
+    options_from_variable: change_options
+    preselect_from: matched_label
+    single_option_confirm: true
+    outputs:
+      - { name: cr_choice, from: selection }
+
+  # 3b. That change's documents, and the clean id back out of the label the pick returned.
+  - id: cr_paths
+    action: execute_script
+    script: { ref: actions }
+    subcommand: cr-paths
+    args: ["--cr-id", "{{cr_choice}}", "--feature-dir", "{{feature_dir}}"]
+    outputs:
+      - { name: cr_id,            from: "$.cr_id" }
+      - { name: cr_dir,           from: "$.cr_dir" }
+      - { name: delta_spec,       from: "$.delta_spec" }
+      - { name: delta_model,      from: "$.delta_model" }
+      - { name: wave,             from: "$.wave" }
+
+  # 4. THE TWO REFUSALS, both answered from disk in one call — see the header for why each
+  #    one is a stop rather than a warning.
+  - id: recall_check
+    action: execute_script
+    script: { ref: actions }
+    subcommand: cr-recall-check
+    args: ["--cr-id", "{{cr_choice}}", "--feature-dir", "{{feature_dir}}"]
+    outputs:
+      - { name: merged,          from: "$.merged" }
+      - { name: merge_evidence,  from: "$.merge_evidence" }
+      - { name: has_dependants,  from: "$.has_dependants" }
+      - { name: dependant_ids,   from: "$.dependant_ids" }
+      - { name: dependant_count, from: "$.dependant_count" }
+
+  # Each refusal is a RAISE then a gate, not a conditional gate: the raise fires only on
+  # the good state, so a value that never arrived (the script errored, the field was
+  # renamed) leaves the flag down and the stage refuses. Fail-closed is the only safe
+  # default for a gate in front of an archive.
+  - id: not_merged_raise
+    condition: "{{merged}} == false"
+    action: set
+    vars: { not_merged: "true" }
+
+  - id: refuse_merged
+    action: verify_context
+    require_true: not_merged
+    on_false: stop
+    on_false_message: "Change {{cr_id}} has already been MERGED — /appweaver finalize-delta folded it into spec.md and the context's domain-model.md, and the spec's Change History carries it: {{merge_evidence}}. The masters now describe behaviour that includes this change, so withdrawing it would leave them describing work no open change accounts for. A recall cannot un-merge, and this stage will not pretend otherwise. If the change should not have landed, finish it (/appweaver analyze-slice → close-delta) and then open a NEW change that reverses it with /appweaver specify — that keeps both the landing and the reversal in the ledger, which is what a reader of the spec needs to see."
+
+  - id: no_dependants_raise
+    condition: "{{has_dependants}} == false"
+    action: set
+    vars: { no_dependants: "true" }
+
+  - id: refuse_dependants
+    action: verify_context
+    require_true: no_dependants
+    on_false: stop
+    on_false_message: "Change {{cr_id}} is at wave {{wave}} and {{dependant_count}} open change(s) sit at a HIGHER wave: {{dependant_ids}}. A higher wave means planned and built ON TOP of the lower ones, so withdrawing this one strands them — their delta plans were authored against a predecessor that would no longer exist. Withdraw the higher-wave change(s) first (/appweaver recall-delta <CR-id>), or re-plan them against the lower waves that remain (/appweaver plan <CR-id>) before recalling this one. Same-wave changes are independent and are not counted here."
+
+  # 5. CONFIRM. Ordered no-first against the kit's usual yes-first convention, and
+  #    deliberately: act_ask takes options[0] non-interactively, so an unattended run
+  #    DECLINES rather than archiving a change nobody was watching. The reason is asked
+  #    for in the same breath because it is what the marker records — a withdrawn change
+  #    with no stated reason is a directory in an archive that nobody can account for later.
+  - id: confirm_recall
+    action: ask
+    prompt: "Withdraw {{cr_id}} (wave {{wave}})? Its documents — {{delta_spec}}, its delta plans and {{delta_model}} — move to changes/archive/{{cr_id}}/ and it leaves the open set. The version does NOT move: this change ships nothing. Any code implement already generated for it stays on disk; revert that with git if it should not remain. Answer no to stop with everything untouched."
+    options: ["no", "yes"]
+    answer_var: recall_answer
+
+  - id: recall_go
+    condition: "{{recall_answer}} == yes"
+    action: set
+    vars: { recall_confirmed: "true" }
+
+  - id: require_confirm
+    action: verify_context
+    require_true: recall_confirmed
+    on_false: stop
+    on_false_message: "Stopped — {{cr_id}} is untouched and still open. Nothing was archived and no version moved. Re-run and answer yes to withdraw it, or carry on with it: /appweaver plan {{cr_id}} to (re)author its delta plans, or /appweaver implement {{cr_id}} to build it."
+
+  - id: ask_reason
+    action: ask
+    prompt: "Why is {{cr_id}} being withdrawn? One line — it is written into changes/archive/{{cr_id}}/RECALLED.md, which is the only record of why this work stopped."
+    options: ["superseded by another change", "requirement dropped", "approach was wrong"]
+    answer_var: recall_reason
+
+  # 6. Pre-execution hooks.
+  - id: resolve_pre_hooks
+    action: execute_script
+    script: { ref: actions }
+    subcommand: resolve-hooks
+    args: ["--phase", "before_recall_cr"]
+    outputs:
+      - { name: before_hooks, from: "$.hooks" }
+  - id: dispatch_pre_hooks
+    action: dispatch_hooks
+    hooks_from_variable: before_hooks
+
+  # 7. THE RECALL. --recall is what separates this from close-delta: the same archive of
+  #    the directory and of the model delta that lives beside the master, plus the
+  #    RECALLED.md marker, and NO version bump. The script refuses an id the ledger does
+  #    not carry and leaves everything in place when it does, so a refusal here is a no-op
+  #    rather than a half-archived change.
+  - id: recall
+    action: execute_script
+    script: { ref: actions }
+    subcommand: cr-archive
+    args: ["--feature-dir", "{{feature_dir}}", "--cr-id", "{{cr_choice}}", "--recall", "--reason", "{{recall_reason}}"]
+    outputs:
+      - { name: recall_ok,      from: "$.ok" }
+      - { name: recalled,       from: "$.recalled" }
+      - { name: archived_dir,   from: "$.archived_dir" }
+      - { name: archived_model, from: "$.archived_model" }
+      - { name: recall_marker,  from: "$.recall_marker" }
+      - { name: version,        from: "$.version" }
+      - { name: active_change,  from: "$.active_change" }
+      - { name: open_count,     from: "$.open_count" }
+
+  - id: verify_recalled
+    action: verify_context
+    require_true: recall_ok
+    on_false: stop
+    on_false_message: "The withdrawal of {{cr_id}} did not complete and nothing was moved — active_version.json does not carry it as an open change. That happens when the change was already closed or recalled, or when its directory exists on disk but was never registered by /appweaver specify. Check {{feature_dir}}/active_version.json against {{feature_dir}}/changes/."
+
+  # 8. Anchor the WITHDRAWAL in the OKF bundle's freshness journal (log.md, OKF §7).
+  #    close-delta logs the ship; this logs the stop, which is exactly as much a part of
+  #    the feature's history. Best-effort + git-aware: a no-op when there is no bundle.
+  - id: xref_log
+    action: execute_script
+    on_error: continue
+    script: { ref: xref }
+    subcommand: log
+    args: ["--note", "CR {{cr_id}} RECALLED — withdrawn before merge ({{recall_reason}}), archived to {{archived_dir}}, version unchanged at {{version}}"]
+    outputs:
+      - { name: xref_log, from: "$.log" }
+
+  # 9. Post-execution hooks.
+  - id: resolve_post_hooks
+    action: execute_script
+    script: { ref: actions }
+    subcommand: resolve-hooks
+    args: ["--phase", "after_recall_cr"]
+    outputs:
+      - { name: after_hooks, from: "$.hooks" }
+  - id: dispatch_post_hooks
+    action: dispatch_hooks
+    hooks_from_variable: after_hooks
+
+outputs:
+  feature: "{{feature}}"
+  feature_dir: "{{feature_dir}}"
+  cr_id: "{{cr_id}}"
+  wave: "{{wave}}"
+  reason: "{{recall_reason}}"
+  archived_dir: "{{archived_dir}}"
+  archived_model: "{{archived_model}}"
+  recall_marker: "{{recall_marker}}"
+  # The number BEFORE and after are the same number — stated as an output because "nothing
+  # moved" is the result this stage exists to produce, and an absent field would read as
+  # an unanswered question rather than an answered one.
+  version: "{{version}}"
+  open_changes_remaining: "{{open_count}}"
+  active_change: "{{active_change}}"
+  note: "Change {{cr_id}} WITHDRAWN — its delta-spec, delta plans and model delta are archived intact at {{archived_dir}}, with the reason recorded in {{recall_marker}}. The version did NOT move and stands at {{version}}: this change shipped nothing, so no number was spent on it. spec.md and the context's domain-model.md never carried it and were not touched. Code that /appweaver implement generated for this change is still on disk — a recall withdraws documents, not source; revert it with git if it should not stay."
+  next: "{{open_count}} change(s) still open on this feature. Carry on with one of them (/appweaver plan <CR-id> → analyze-plan-delta → implement), or with none left the feature is back on its masters: /appweaver plan main re-derives the lane plans from spec.md and the domain model, and /appweaver specify opens a fresh change."

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

@@ -64,7 +64,7 @@ workflow:
     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 re-run run."
+    on_empty_message: "No active feature. Run /appweaver select-feature first (pick or create the feature, e.g. Order or PatientRegistration), then re-run run."
 
   # Require the SERVICE LANE and its source path. Migrations belong to the backend
   # lane by definition, and run-migrate searches that lane's root for the project

package/assets/.appweaver/orchestrator/workflows/aw-spec-select-feature.orch.yaml

@@ -1,17 +1,21 @@
 # =============================================================================
 # aw-spec-select-feature (orchestrator) — pick or create the active FEATURE
 #
-# feature = AGGREGATE (e.g. Order). This is the FIRST step of the spec-anchored
-# pipeline: it fixes the aggregate boundary BEFORE any spec/design exists, so the
-# feature's single spec.md + backend-plan.md and every command (CreateOrder/UpdateOrder =
-# user stories) hang off one directory. It replaces guessing the aggregate out of prose in
-# `specify` — that is why finding #1 (feature=aggregate) is enforced here, not hoped for.
+# A FEATURE IS A CAPABILITY SCOPE THE DEVELOPER CHOOSES (e.g. Order, or
+# PatientRegistration). It may act on several aggregates, and several features may act on
+# one: the aggregates live in the bounded context's domain model and the OKF bundle, above
+# every feature, and the spec names the ones this feature acts on. This is the FIRST step
+# of the spec-anchored pipeline: it fixes the feature's scope BEFORE any spec/plan exists,
+# so its single spec.md + backend-plan.md and every operation (CreateOrder/UpdateOrder =
+# user stories) hang off one directory.
 #
 # The pickable list is TWO merged sources (deduped by name): specs/ sub-folders
-# (features already scaffolded/adopted) AND the OKF bundle's Aggregate concepts —
-# the brownfield feature map `/appweaver onboard` reverse-engineers. So in a
-# brownfield repo you pick a real discovered code feature BEFORE anything is under
-# specs/; on greenfield (no bundle) the list is specs-only, exactly as before.
+# (features already scaffolded/adopted) AND the features the OKF bundle's concepts are
+# known to serve — from the boundary map the developer confirmed, else from each
+# concept's `features:` list. So in a brownfield repo you pick a real discovered code
+# feature BEFORE anything is under specs/. An aggregate is never offered as a feature
+# nobody defined: on greenfield every feature already has its specs/ directory, so the
+# list is specs-only.
 #
 # SCOPED BY THE ACTIVE BOUNDED CONTEXT. When .appweaver/context.json names one, both
 # the listing and the creation happen inside specs/<Context>/ — so a context shows
@@ -22,7 +26,7 @@
 # ZERO LLM: only scripts + one select + (conditionally) one ask. No generation,
 # no standards, no domain-select. Pure, deterministic orchestration/governance.
 #
-#   list-features (specs/ ∪ OKF aggregates) → user_select (existing | "+ create new") → [ask name] → set-feature
+#   list-features (specs/ ∪ features the OKF concepts serve) → user_select (existing | "+ create new") → [ask name] → set-feature
 #
 # Persists .appweaver/feature.json {"feature_directory":"specs/<Feature>"} so every
 # later command operates on it: the forward loop (specify/plan/analyze-plan/implement/
@@ -36,14 +40,14 @@
 # =============================================================================
 
 name: aw-spec-select-feature
-description: Pick an existing feature (aggregate) or create a new one, and store it in .appweaver/feature.json so every AW-Spec command operates on it. Zero LLM — scripts + one selection only.
+description: Pick an existing feature (a capability scope you choose) or create a new one, and store it in .appweaver/feature.json so every AW-Spec command operates on it. Zero LLM — scripts + one selection only.
 version: 1.0.0
 agent_agnostic: true
 dialect: aw-spec.orchestrator/v1
 
 inputs:
   user_input:
-    description: Optional feature (aggregate) name to create or select directly, e.g. Order.
+    description: Optional feature name to create or select directly, e.g. Order or PatientRegistration.
     required: false
     bind: USER_INPUT
 
@@ -85,11 +89,12 @@ workflow:
     on_false_message: >
       {{scope_message}}
 
-  # 1. Enumerate selectable aggregates from TWO merged sources (deduped by name):
-  #    specs/ sub-folders (already scaffolded/adopted) AND the OKF bundle's
-  #    Aggregate concepts — the brownfield feature map onboard reverse-engineers,
-  #    so a not-yet-adopted code feature is pickable before its specs/ dir exists.
-  #    On greenfield (no bundle) the OKF source is empty → specs-only, as before.
+  # 1. Enumerate selectable FEATURES from TWO merged sources (deduped by name):
+  #    specs/ sub-folders (already scaffolded/adopted) AND the features the OKF
+  #    bundle's aggregate concepts serve — the boundary map first, else each concept's
+  #    `features:` list — so a not-yet-adopted code feature is pickable before its
+  #    specs/ dir exists. A concept greenfield implement wrote contributes nothing:
+  #    its features all have specs/ dirs, and its own name is an aggregate.
   #    `select_options` carries the "+ create new" sentinel and (when USER_INPUT
   #    names a not-yet feature) that name injected — a direct arg is one-list select.
   - id: list_features
@@ -108,7 +113,7 @@ workflow:
   #    no prompt; the lone sentinel at bootstrap (no features yet) auto-confirms.
   - id: pick
     action: user_select
-    prompt: "Select a feature (the aggregate, e.g. Order) in {{feature_base}}/ — or create a new one:"
+    prompt: "Select a feature (a capability scope, e.g. Order or PatientRegistration) in {{feature_base}}/ — or create a new one:"
     options_from_variable: select_options
     preselect_from: USER_INPUT
     single_option_confirm: true
@@ -120,9 +125,10 @@ workflow:
     action: ask
     condition: "{{chosen}} == {{new_sentinel}}"
     prompt: >
-      Name the new feature — this is the AGGREGATE root (e.g. Order, Invoice,
-      Customer), NOT a single command. Operations like CreateOrder / UpdateOrder
-      become user stories inside it:
+      Name the new feature — the capability scope you want to specify and build as
+      one unit (e.g. Order, PatientRegistration). It may act on several aggregates, and
+      other features may act on the same ones; its spec names them. Each operation in
+      its scope (e.g. CreateOrder / UpdateOrder) becomes a user story inside it:
     answer_var: typed_name
 
   # 4. Coalesce the target name. The engine has no compound conditions, so this
@@ -136,7 +142,7 @@ workflow:
     condition: "{{chosen}} == {{new_sentinel}}"
     vars: { target_name: "{{typed_name}}" }
 
-  # 5. Create-or-select the aggregate dir + persist it as the active feature.
+  # 5. Create-or-select the feature dir + persist it as the active feature.
   - id: set_feature
     action: execute_script
     script: { ref: actions }
@@ -157,5 +163,5 @@ outputs:
   context: "{{context}}"
   created: "{{created}}"
   spec_exists: "{{spec_exists}}"
-  note: "Active feature set in .appweaver/feature.json — the aggregate boundary for its single spec.md + backend-plan.md. `context` names the bounded context it was created in, and is empty on a repo with no active context (the flat specs/<Feature> layout, which keeps working unchanged)."
+  note: "Active feature set in .appweaver/feature.json — the capability scope that owns its single spec.md + backend-plan.md. `context` names the bounded context it was created in, and is empty on a repo with no active context (the flat specs/<Feature> layout, which keeps working unchanged)."
   next: "/appweaver specify <what this feature does>   (authors {{feature_dir}}/spec.md; each operation = a user story)"