aw-spec-cli 0.1.21 → 0.1.23

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

@@ -128,7 +128,7 @@
 
 name: aw-spec-implement
 description: "Generate the aggregate's source files and paired tests from its lane plans — the backend lane from backend-plan.md when a backend stack is declared, the frontend lane from frontend-plan.md when a frontend stack is, both when both are. One command covers backend-only, frontend-only and full-stack projects and absorbs the former implement-ui and implement-delta. Self-detecting off the changes on disk — with none open it generates from the master plans; with one or more open it ASKS which change and generates only what that change's delta plans mark ADDED or MODIFIED, leaving the masters untouched. Every lane is gated on its own source path, its own plan and its own scaffolded project, and a lane missing any of them is reported and skipped rather than failing the other lane; each runnable lane confirms before it writes. Model-driven, and it does not read the spec — analyze-plan already conformed the plans to it. The plan says WHAT to build; the bounded context's domain-model.md, in context alongside it, says what the domain IS — the entity names, the boundary and the text of every invariant the plan cites by id — joined on the delta path by that change's own model delta, since the master is not merged until finalize-delta. The stack binds here from the lane declaration and the constitution halves; the plans stay technology-agnostic."
-version: 3.7.0
+version: 3.10.0
 agent_agnostic: true
 dialect: aw-spec.orchestrator/v1
 
@@ -207,10 +207,18 @@ vars:
   be_files: []
   # COMPLETENESS, per lane — see step 8b and the checks after each lane generates.
   be_element_names: ""
+  be_existing_text: "  (not resolved)"
+  be_reserved: ""
+  be_collisions: ""
+  be_collisions_text: "none"
+  be_existing_count: "0"
   be_elements: []
   be_more_files: []
   be_elements_more: []
   be_complete: "true"
+  be_outcome: ""            # complete | already-implemented | gaps | no-plan-elements
+  be_satisfied: "false"     # the lane was already fully realised, so this run wrote nothing
+  be_coverage_note: ""
   be_completion_ran: "false"
   be_gap_names: ""
   be_gaps_text: "none"
@@ -224,10 +232,18 @@ vars:
   fe_mode: "skip"              # skip | bootstrap | delta
   fe_files: []
   fe_element_names: ""
+  fe_existing_text: "  (not resolved)"
+  fe_reserved: ""
+  fe_collisions: ""
+  fe_collisions_text: "none"
+  fe_existing_count: "0"
   fe_elements: []
   fe_more_files: []
   fe_elements_more: []
   fe_complete: "true"
+  fe_outcome: ""
+  fe_satisfied: "false"
+  fe_coverage_note: ""
   fe_completion_ran: "false"
   fe_gap_names: ""
   fe_gaps_text: "none"
@@ -287,6 +303,7 @@ workflow:
       - { name: be_ecosystem,   from: "$.backend_ecosystem" }
       - { name: be_build,       from: "$.backend_build" }
       - { name: be_test,        from: "$.backend_test" }
+      - { name: be_reserved,    from: "$.backend_reserved_csv" }
       - { name: fe_declared,    from: "$.frontend_declared" }
       - { name: fe_lane_id,     from: "$.frontend_lane_id" }
       - { name: fe_source_path, from: "$.frontend_source_path" }
@@ -298,6 +315,7 @@ workflow:
       - { name: fe_ecosystem,   from: "$.frontend_ecosystem" }
       - { name: fe_build,       from: "$.frontend_build" }
       - { name: fe_test,        from: "$.frontend_test" }
+      - { name: fe_reserved,    from: "$.frontend_reserved_csv" }
 
   - id: require_lanes
     action: verify_context
@@ -680,17 +698,60 @@ workflow:
     action: execute_script
     script: { ref: actions }
     subcommand: plan-coverage
-    args: ["--plan", "{{be_plan}}", "--kind", "backend", "--mode", "{{be_mode}}", "--list-only"]
+    args: ["--plan", "{{be_plan}}", "--kind", "backend", "--mode", "{{be_mode}}", "--list-only", "--reserved", "{{be_reserved}}"]
     outputs:
-      - { name: be_element_names, from: "$.names_text" }
+      - { name: be_element_names,   from: "$.names_text" }
+      - { name: be_collisions,      from: "$.collisions_csv" }
+      - { name: be_collisions_text, from: "$.collisions_text" }
   - id: fe_plan_elements
     condition: "{{fe_go}} == true"
     action: execute_script
     script: { ref: actions }
     subcommand: plan-coverage
-    args: ["--plan", "{{fe_plan}}", "--kind", "frontend", "--mode", "{{fe_mode}}", "--list-only"]
+    args: ["--plan", "{{fe_plan}}", "--kind", "frontend", "--mode", "{{fe_mode}}", "--list-only", "--reserved", "{{fe_reserved}}"]
     outputs:
-      - { name: fe_element_names, from: "$.names_text" }
+      - { name: fe_element_names,   from: "$.names_text" }
+      - { name: fe_collisions,      from: "$.collisions_csv" }
+      - { name: fe_collisions_text, from: "$.collisions_text" }
+
+  # 8c. THE CODE THAT IS ALREADY THERE, per lane, from the aggregate's OKF concept. This
+  #     is the step that WRITES code, and it was the only one that resolved no source at
+  #     all — plan, delta-plan, analyze-slice, build and run all read the real tree this
+  #     way. Without it a lane extending a shared aggregate had to go and discover the
+  #     established conventions for itself, or not bother, which is how two features end
+  #     up spelling the same pattern two ways.
+  #
+  #     A PATH LIST, not file contents: the generation steps declare `tools: Read` and open
+  #     what they need, because a brownfield tree does not fit in a payload. Nothing is
+  #     truncated — a file left off the list is a file the model does not know to EXTEND
+  #     and may regenerate instead.
+  #
+  #     `--under` narrows the concept to the lane's own two subtrees. A concept spans every
+  #     lane that realises the aggregate, so without it the backend pass is handed the UI's
+  #     files — a subtree it is forbidden to write into two rules later.
+  #
+  #     Read-only, and greenfield-safe: no concept yet exits 0 with count 0, which is the
+  #     first feature on a fresh tree and blocks nothing.
+  - id: be_existing_code
+    condition: "{{be_go}} == true"
+    action: execute_script
+    on_error: continue
+    script: { ref: xref }
+    subcommand: concept-paths
+    args: ["--feature-dir", "{{feature_dir}}", "--under", "{{be_source_path}}", "--under", "{{be_test_path}}"]
+    outputs:
+      - { name: be_existing_text,  from: "$.paths_text" }
+      - { name: be_existing_count, from: "$.count" }
+  - id: fe_existing_code
+    condition: "{{fe_go}} == true"
+    action: execute_script
+    on_error: continue
+    script: { ref: xref }
+    subcommand: concept-paths
+    args: ["--feature-dir", "{{feature_dir}}", "--under", "{{fe_source_path}}", "--under", "{{fe_test_path}}"]
+    outputs:
+      - { name: fe_existing_text,  from: "$.paths_text" }
+      - { name: fe_existing_count, from: "$.count" }
 
   # 9. Each generating lane's code-generation rule files → sticky standards (configuration,
   #    not hardcoded). Loaded only for a lane that is actually going to generate, and the
@@ -782,6 +843,30 @@ workflow:
         not even to consume a contract. Do not create a parallel source tree because the
         layout inside them is unfamiliar; if the plan needs a place they have no home for,
         STOP and surface it.
+      - NAMES THIS STACK ALREADY DEFINES: {{be_collisions_text}}.
+        Where that list is not `none`, the plan's name is RIGHT and stays exactly as the
+        plan spells it — it is the ubiquitous language, and renaming a domain type to
+        dodge a framework one is never the answer. What changes is how it is WRITTEN at
+        the use site: qualify it with its own enclosing namespace segment, every time.
+        In C# that is `Domain.Route`, not a bare `Route`, wherever the type is named —
+        declarations, parameters, return types, generic arguments and doc comments.
+        The conflict is INVISIBLE in the file: the framework name arrives through an
+        implicit/ambient import and appears in no line of it, so a bare name looks fine,
+        compiles in your head, and fails the build as an ambiguous reference (C# CS0104).
+        Do not add a `using` alias and do not fully qualify the whole namespace path —
+        one convention, so two features never disambiguate the same name two ways.
+      - THE CODE THAT IS ALREADY THERE. This aggregate already has {{be_existing_count}} file(s) in
+        this lane, listed from its OKF concept:
+        {{be_existing_text}}
+        READ the ones your elements touch BEFORE writing anything. They are this
+        codebase's established conventions — the identifier pattern, the persistence and mapping shape, the endpoint
+        and handler wiring, the error and DTO style — and new code follows
+        them rather than introducing a second way of doing the same thing. A listed file
+        that one of your elements maps onto is EXTENDED: add the member, leave every
+        existing member byte-for-byte alone, and never regenerate, rename or move it.
+        Nothing is left off that list, so a path not on it does not exist yet. A count of
+        0 means this is the aggregate's first code in this lane and the conventions come
+        from the loaded standards instead.
       - A MISSING TEST PROJECT IS CREATED, NEVER A REASON TO SKIP THE TESTS. When
         `{{be_test_path}}` holds no test project yet, create one there as the loaded
         testing standard describes, referencing the production project it tests, and
@@ -918,6 +1003,30 @@ workflow:
         paired tests under `{{be_test_path}}`. Those subtrees are this lane's, and a file
         outside them belongs to another lane or to no lane at all. NEVER write into the
         frontend lane's subtree.
+      - NAMES THIS STACK ALREADY DEFINES: {{be_collisions_text}}.
+        Where that list is not `none`, the plan's name is RIGHT and stays exactly as the
+        plan spells it — it is the ubiquitous language, and renaming a domain type to
+        dodge a framework one is never the answer. What changes is how it is WRITTEN at
+        the use site: qualify it with its own enclosing namespace segment, every time.
+        In C# that is `Domain.Route`, not a bare `Route`, wherever the type is named —
+        declarations, parameters, return types, generic arguments and doc comments.
+        The conflict is INVISIBLE in the file: the framework name arrives through an
+        implicit/ambient import and appears in no line of it, so a bare name looks fine,
+        compiles in your head, and fails the build as an ambiguous reference (C# CS0104).
+        Do not add a `using` alias and do not fully qualify the whole namespace path —
+        one convention, so two features never disambiguate the same name two ways.
+      - THE CODE THAT IS ALREADY THERE. This aggregate already has {{be_existing_count}} file(s) in
+        this lane, listed from its OKF concept:
+        {{be_existing_text}}
+        READ the ones your elements touch BEFORE writing anything. They are this
+        codebase's established conventions — the identifier pattern, the persistence and mapping shape, the endpoint
+        and handler wiring, the error and DTO style — and new code follows
+        them rather than introducing a second way of doing the same thing. A listed file
+        that one of your elements maps onto is EXTENDED: add the member, leave every
+        existing member byte-for-byte alone, and never regenerate, rename or move it.
+        Nothing is left off that list, so a path not on it does not exist yet. A count of
+        0 means this is the aggregate's first code in this lane and the conventions come
+        from the loaded standards instead.
       - A MISSING TEST PROJECT IS CREATED, NEVER A REASON TO SKIP THE TESTS. When
         `{{be_test_path}}` holds no test project yet, create one there as the loaded
         testing standard describes and register it wherever `{{be_test}}` discovers tests
@@ -961,17 +1070,17 @@ workflow:
       - { name: be_files, from: "$.files" }
       - { name: be_elements, from: "$.elements" }
 
-  - id: verify_be_files
-    condition: "{{be_go}} == true"
-    action: verify_context
-    require_non_empty: be_files
-    on_empty: stop
-    on_empty_message: "The backend lane generated no files. Ensure {{be_plan}} is a FILLED plan (not the empty template) and that it passed its gate — /appweaver analyze-plan for a master, /appweaver analyze-plan-delta for a change — then re-run implement."
-
-  # PARTIAL GENERATION. A non-empty file list is not a finished lane: a pass that stopped
-  # part-way returns the files it did write. plan-coverage checks every plan element two
-  # ways — the lane's code must name each identifier the plan introduces, and the model's
-  # own report must say each element is done — and whatever fails either check gets ONE
+  # WHAT THIS LANE ACTUALLY DID, judged on the code rather than on the file count. An empty
+  # file list has two opposite meanings — the lane is already built, or the pass achieved
+  # nothing — and only the code tells them apart, so plan-coverage runs FIRST and the gate
+  # below reads its verdict. `--generated` carries the file list: empty makes this the
+  # already-implemented probe, judged on the code alone, because an element no scan can
+  # confirm (a port, an adapter) was confirmed by the run that created it.
+  #
+  # PARTIAL GENERATION. A non-empty file list is not a finished lane either: a pass that
+  # stopped part-way returns the files it did write. Coverage then checks every plan element
+  # two ways — the code must name each identifier the plan introduces, and the model's own
+  # report must say each element is done — and whatever fails either check gets ONE
   # completion pass in the same envelope. What is still missing after it stops the run at
   # step 10b, once both lanes have had their turn.
   - id: be_coverage
@@ -979,11 +1088,33 @@ workflow:
     action: execute_script
     script: { ref: actions }
     subcommand: plan-coverage
-    args: ["--plan", "{{be_plan}}", "--kind", "backend", "--mode", "{{be_mode}}", "--source-path", "{{be_source_path}}", "--test-path", "{{be_test_path}}", "--reported", "{{be_elements}}"]
+    args: ["--plan", "{{be_plan}}", "--kind", "backend", "--mode", "{{be_mode}}", "--source-path", "{{be_source_path}}", "--test-path", "{{be_test_path}}", "--reported", "{{be_elements}}", "--generated", "{{be_files}}"]
     outputs:
       - { name: be_complete,  from: "$.ok" }
+      - { name: be_outcome,   from: "$.outcome" }
       - { name: be_gap_names, from: "$.gap_names_csv" }
       - { name: be_gaps_text, from: "$.gaps_text" }
+      - { name: be_coverage_note, from: "$.message" }
+
+  # NOTHING TO DO IS AN OUTCOME, not a failure. A lane whose every plan element is already
+  # realised writes no files, and that is the correct result of re-running implement on a
+  # finished feature — the other lane may still have work, and the OKF merge and the edges
+  # downstream are reconcile-on-write, so the run carries on.
+  - id: be_satisfied_flag
+    condition: "{{be_outcome}} == already-implemented"
+    action: set
+    vars: { be_satisfied: "true" }
+
+  # The one empty-file case that IS unexplained: a plan no element could be read from
+  # proves nothing about the code, so a pass that wrote nothing against it has no evidence
+  # either way. That is the template-not-filled case the old file-count gate was reaching
+  # for, and it is the only one left that stops the run here.
+  - id: verify_be_evidence
+    condition: "{{be_outcome}} == no-plan-elements"
+    action: verify_context
+    require_non_empty: be_files
+    on_empty: stop
+    on_empty_message: "The backend lane generated no files, and no plan element could be read from {{be_plan}} — so there is no evidence of what it should have built. The usual cause is an unfilled plan (still the empty template) or one whose headings do not follow the plan template. Fill it with /appweaver plan, check it with /appweaver analyze-plan (analyze-plan-delta for a change), then re-run implement."
   - id: be_completion_flag
     condition: "{{be_complete}} == false"
     action: set
@@ -1025,6 +1156,7 @@ workflow:
     args: ["--plan", "{{be_plan}}", "--kind", "backend", "--mode", "{{be_mode}}", "--source-path", "{{be_source_path}}", "--test-path", "{{be_test_path}}", "--reported", "{{be_elements}}", "--reported", "{{be_elements_more}}"]
     outputs:
       - { name: be_complete,  from: "$.ok" }
+      - { name: be_outcome,   from: "$.outcome" }
       - { name: be_gap_names, from: "$.gap_names_csv" }
       - { name: be_gaps_text, from: "$.gaps_text" }
 
@@ -1124,6 +1256,30 @@ workflow:
         gap in the service surface is a contract delta raised back to that lane. Do not
         create a parallel source tree because the layout inside this one is unfamiliar; if
         the plan needs a place this subtree has no home for, STOP and surface it.
+      - NAMES THIS STACK ALREADY DEFINES: {{fe_collisions_text}}.
+        Where that list is not `none`, the plan's name is RIGHT and stays exactly as the
+        plan spells it — it is the ubiquitous language, and renaming a domain type to
+        dodge a framework one is never the answer. What changes is how it is WRITTEN at
+        the use site: qualify it with its own enclosing namespace segment, every time.
+        In C# that is `Domain.Route`, not a bare `Route`, wherever the type is named —
+        declarations, parameters, return types, generic arguments and doc comments.
+        The conflict is INVISIBLE in the file: the framework name arrives through an
+        implicit/ambient import and appears in no line of it, so a bare name looks fine,
+        compiles in your head, and fails the build as an ambiguous reference (C# CS0104).
+        Do not add a `using` alias and do not fully qualify the whole namespace path —
+        one convention, so two features never disambiguate the same name two ways.
+      - THE CODE THAT IS ALREADY THERE. This aggregate already has {{fe_existing_count}} file(s) in
+        this lane, listed from its OKF concept:
+        {{fe_existing_text}}
+        READ the ones your elements touch BEFORE writing anything. They are this
+        codebase's established conventions — the component and screen layout, the server-action and data-fetch shape,
+        the state and error handling, the locale-catalogue mechanics — and new code follows
+        them rather than introducing a second way of doing the same thing. A listed file
+        that one of your elements maps onto is EXTENDED: add the member, leave every
+        existing member byte-for-byte alone, and never regenerate, rename or move it.
+        Nothing is left off that list, so a path not on it does not exist yet. A count of
+        0 means this is the aggregate's first code in this lane and the conventions come
+        from the loaded standards instead.
       - A MISSING TEST SETUP IS CREATED, NEVER A REASON TO SKIP THE TESTS. When the lane
         has no test project or test runner yet, set one up inside the lane's paths as the
         loaded testing standard describes, so that `{{fe_test}}` runs the tests you write.
@@ -1233,6 +1389,30 @@ workflow:
         paired tests under `{{fe_test_path}}`. NEVER touch the service lane's code, not
         even to add a field the UI wants — a gap in the service surface is a contract delta
         raised back to that lane, never worked around in the client.
+      - NAMES THIS STACK ALREADY DEFINES: {{fe_collisions_text}}.
+        Where that list is not `none`, the plan's name is RIGHT and stays exactly as the
+        plan spells it — it is the ubiquitous language, and renaming a domain type to
+        dodge a framework one is never the answer. What changes is how it is WRITTEN at
+        the use site: qualify it with its own enclosing namespace segment, every time.
+        In C# that is `Domain.Route`, not a bare `Route`, wherever the type is named —
+        declarations, parameters, return types, generic arguments and doc comments.
+        The conflict is INVISIBLE in the file: the framework name arrives through an
+        implicit/ambient import and appears in no line of it, so a bare name looks fine,
+        compiles in your head, and fails the build as an ambiguous reference (C# CS0104).
+        Do not add a `using` alias and do not fully qualify the whole namespace path —
+        one convention, so two features never disambiguate the same name two ways.
+      - THE CODE THAT IS ALREADY THERE. This aggregate already has {{fe_existing_count}} file(s) in
+        this lane, listed from its OKF concept:
+        {{fe_existing_text}}
+        READ the ones your elements touch BEFORE writing anything. They are this
+        codebase's established conventions — the component and screen layout, the server-action and data-fetch shape,
+        the state and error handling, the locale-catalogue mechanics — and new code follows
+        them rather than introducing a second way of doing the same thing. A listed file
+        that one of your elements maps onto is EXTENDED: add the member, leave every
+        existing member byte-for-byte alone, and never regenerate, rename or move it.
+        Nothing is left off that list, so a path not on it does not exist yet. A count of
+        0 means this is the aggregate's first code in this lane and the conventions come
+        from the loaded standards instead.
       - A MISSING TEST SETUP IS CREATED, NEVER A REASON TO SKIP THE TESTS: set one up
         inside the lane's paths so that `{{fe_test}}` runs the tests you write, and name
         any file outside them you had to edit for that in your summary.
@@ -1266,24 +1446,32 @@ workflow:
       - { name: fe_files, from: "$.files" }
       - { name: fe_elements, from: "$.elements" }
 
-  - id: verify_fe_files
-    condition: "{{fe_go}} == true"
-    action: verify_context
-    require_non_empty: fe_files
-    on_empty: stop
-    on_empty_message: "The frontend lane generated no files. Ensure {{fe_plan}} is a FILLED plan (not the empty template) and that it passed its gate — /appweaver analyze-plan for a master, /appweaver analyze-plan-delta for a change — then re-run implement."
-
-  # PARTIAL GENERATION — the frontend twin of the backend check above.
+  # WHAT THIS LANE ACTUALLY DID — the frontend twin of the backend check above, including
+  # the already-implemented probe and the one empty-file case that still stops the run.
   - id: fe_coverage
     condition: "{{fe_go}} == true"
     action: execute_script
     script: { ref: actions }
     subcommand: plan-coverage
-    args: ["--plan", "{{fe_plan}}", "--kind", "frontend", "--mode", "{{fe_mode}}", "--source-path", "{{fe_source_path}}", "--test-path", "{{fe_test_path}}", "--reported", "{{fe_elements}}"]
+    args: ["--plan", "{{fe_plan}}", "--kind", "frontend", "--mode", "{{fe_mode}}", "--source-path", "{{fe_source_path}}", "--test-path", "{{fe_test_path}}", "--reported", "{{fe_elements}}", "--generated", "{{fe_files}}"]
     outputs:
       - { name: fe_complete,  from: "$.ok" }
+      - { name: fe_outcome,   from: "$.outcome" }
       - { name: fe_gap_names, from: "$.gap_names_csv" }
       - { name: fe_gaps_text, from: "$.gaps_text" }
+      - { name: fe_coverage_note, from: "$.message" }
+
+  - id: fe_satisfied_flag
+    condition: "{{fe_outcome}} == already-implemented"
+    action: set
+    vars: { fe_satisfied: "true" }
+
+  - id: verify_fe_evidence
+    condition: "{{fe_outcome}} == no-plan-elements"
+    action: verify_context
+    require_non_empty: fe_files
+    on_empty: stop
+    on_empty_message: "The frontend lane generated no files, and no plan element could be read from {{fe_plan}} — so there is no evidence of what it should have built. The usual cause is an unfilled plan (still the empty template) or one whose headings do not follow the plan template. Fill it with /appweaver plan-ui, check it with /appweaver analyze-plan (analyze-plan-delta for a change), then re-run implement."
   - id: fe_completion_flag
     condition: "{{fe_complete}} == false"
     action: set
@@ -1326,6 +1514,7 @@ workflow:
     args: ["--plan", "{{fe_plan}}", "--kind", "frontend", "--mode", "{{fe_mode}}", "--source-path", "{{fe_source_path}}", "--test-path", "{{fe_test_path}}", "--reported", "{{fe_elements}}", "--reported", "{{fe_elements_more}}"]
     outputs:
       - { name: fe_complete,  from: "$.ok" }
+      - { name: fe_outcome,   from: "$.outcome" }
       - { name: fe_gap_names, from: "$.gap_names_csv" }
       - { name: fe_gaps_text, from: "$.gaps_text" }
 
@@ -1475,10 +1664,19 @@ outputs:
   frontend_files: "{{fe_files}}"
   # Every plan element realised, per lane — `true` for a lane that did not generate.
   # `*_completion_pass` says whether the first pass left gaps a second one had to close.
+  # `*_outcome` is the one word for what the lane did: complete (it generated and every
+  # element is realised), already-implemented (it wrote nothing because nothing was left
+  # to write), gaps, or no-plan-elements. `*_satisfied` is that second case alone.
   backend_complete: "{{be_complete}}"
+  backend_outcome: "{{be_outcome}}"
+  backend_satisfied: "{{be_satisfied}}"
+  backend_coverage: "{{be_coverage_note}}"
   backend_completion_pass: "{{be_completion_ran}}"
   backend_more_files: "{{be_more_files}}"
   frontend_complete: "{{fe_complete}}"
+  frontend_outcome: "{{fe_outcome}}"
+  frontend_satisfied: "{{fe_satisfied}}"
+  frontend_coverage: "{{fe_coverage_note}}"
   frontend_completion_pass: "{{fe_completion_ran}}"
   frontend_more_files: "{{fe_more_files}}"
   domain_model: "{{domain_model}}"     # the master model every generating lane read
@@ -1493,5 +1691,5 @@ outputs:
   plan_gate_at: "{{gate_at}}"
   plan_gate_verdict: "{{gate_verdict}}"
   plan_gate_routed_to_specify: "{{gate_routed_csv}}"   # open spec/model gaps this code does not cover
-  note: "Lanes come from .appweaver/stacks.json — backend declared {{be_declared}} (ready {{be_runnable}}, implemented {{be_go}}), frontend declared {{fe_declared}} (ready {{fe_runnable}}, implemented {{fe_go}}). A declared lane that was skipped printed its reason above and did not stop the other one; an undeclared lane produces nothing and that is not a failure. Each generating lane read its PLAN for what to build and {{domain_model}} for what the domain is — plus {{delta_model}} on the delta path, since the master model does not carry the change until finalize-delta merges it. Every one of those documents was READ and none was written: this phase generates code and nothing else. On the bootstrap path the plans were checked against analyze-plan's receipt before anything generated (tracked={{gate_tracked}}, fresh={{gate_fresh}}, gated {{gate_at}}) — tracked=false means this feature has never passed analyze-plan since the gate began recording what it proved, which is an unknown rather than a stale plan and blocks nothing; run /appweaver analyze-plan once to start the record."
+  note: "Lanes come from .appweaver/stacks.json — backend declared {{be_declared}} (ready {{be_runnable}}, implemented {{be_go}}), frontend declared {{fe_declared}} (ready {{fe_runnable}}, implemented {{fe_go}}). A declared lane that was skipped printed its reason above and did not stop the other one; an undeclared lane produces nothing and that is not a failure. Each generating lane read its PLAN for what to build and {{domain_model}} for what the domain is — plus {{delta_model}} on the delta path, since the master model does not carry the change until finalize-delta merges it. Every one of those documents was READ and none was written: this phase generates code and nothing else. Each lane's outcome is backend={{be_outcome}}, frontend={{fe_outcome}} — `already-implemented` means the lane wrote no files because every plan element was already realised in its source path, which is the correct result of re-running implement on a finished feature and not a failure. On the bootstrap path the plans were checked against analyze-plan's receipt before anything generated (tracked={{gate_tracked}}, fresh={{gate_fresh}}, gated {{gate_at}}) — tracked=false means this feature has never passed analyze-plan since the gate began recording what it proved, which is an unknown rather than a stale plan and blocks nothing; run /appweaver analyze-plan once to start the record."
   next: "This run was mode `{{mode}}`, change `{{active_change}}` (empty on the bootstrap path). BOOTSTRAP → /appweaver build → analyze-slice → run. DELTA → /appweaver build → analyze-slice-delta {{active_change}} → finalize-delta → analyze-slice → close-delta, with the change still OPEN throughout — compile first, then analyze-slice-delta verifies that every element the delta plans marked ADDED or MODIFIED is actually in the code with a paired test (the gate that catches a lane you declined at the prompt above), then finalize-delta merges it into spec.md + the context's domain-model.md while leaving it open, analyze-slice verifies the slice against those merged masters while a red result is still recoverable, and close-delta LAST archives the change and bumps the version."

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

@@ -264,18 +264,7 @@ outputs:
   coverage_pct: "{{coverage_pct}}"
   split_candidates: "{{split_candidates}}"
   contexts_ordered: "{{contexts_ordered}}"
-
-next: >
-  {{feature_count}} feature(s) across {{context_count}} bounded context(s) were
-  proposed from `{{chosen_strategy}}` evidence ({{coverage_pct}}% of source
-  covered), ordered into {{wave_count}} dependency wave(s).
-
-  READ AND EDIT specs/proposed-inventory.md — it is the boundary map, and it is
-  yours. Rename features and contexts, move a feature to another context, merge
-  two by giving them one name, split one by adding a row with the same Aggregate,
-  and set Depends On to change the order. {{split_candidates}} split(s) were
-  PROPOSED with their evidence and none were applied.
-
-  Then run `/appweaver inventory apply` to validate those edits and regenerate the
-  machine map, and onboard the contexts one at a time in the order it reports:
-  {{contexts_ordered}}
+  # Sits INSIDE outputs: — the engine resolves and returns wf["outputs"] only, so a
+  # next: at the document's top level is parsed and then dropped, and the workflow
+  # ends with no suggested successor at all.
+  next: "{{feature_count}} feature(s) across {{context_count}} bounded context(s) were proposed from `{{chosen_strategy}}` evidence ({{coverage_pct}}% of source covered), ordered into {{wave_count}} dependency wave(s). READ AND EDIT specs/proposed-inventory.md — it is the boundary map, and it is yours. Rename features and contexts, move a feature to another context, merge two by giving them one name, split one by adding a row with the same Aggregate, and set Depends On to change the order. {{split_candidates}} split(s) were PROPOSED with their evidence and none were applied. Then run /appweaver inventory apply to validate those edits and regenerate the machine map. Next: /appweaver onboard <Context> — once per bounded context, one at a time, in the order inventory apply reports: {{contexts_ordered}}. Then /appweaver adopt <Feature> per feature you are about to change."

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

@@ -2210,4 +2210,4 @@ outputs:
   ui_delta_design_template_files: "{{ui_delta_design_template_files}}"
   technical_validation_ok: "{{technical_ok}}"
   domain_validation_ok: "{{domain_ok}}"
-  next: "Onboarded bounded context {{bc}} ({{bc_feature_count}} feature(s): {{bc_features}}). Its aggregate concepts ({{bc_aggregates}}) are in {{bundle_dir}}, each keyed `bounded_context: {{bc}}` and listing the features that act on it — the bundle is the project's knowledge, one concept per aggregate, never one per feature — and its specs tree now exists at {{bc_dir}}/ with a directory per feature ({{feature_dirs}}) — EMPTY on purpose: the directory says the feature is known, and the documents that describe it are written per feature by /appweaver adopt and per context by /appweaver specify. {{bc}} is now the ACTIVE bounded context (.appweaver/context.json), so /appweaver select-feature lists exactly these features and nothing from a neighbouring context; switch with /appweaver select-bounded-context. ONBOARD RUNS ONCE PER CONTEXT: contexts already done — {{onboarded_contexts}}; still open — {{remaining_contexts}}; the order the map gives is {{contexts_ordered}}. Run /appweaver onboard <NextContext> for each remaining one, or with no argument to take the next one automatically. THE PROJECT TIER IS WRITTEN ONCE, BY THE FIRST CONTEXT (this run was first: {{is_first}}). That tier is the PROVISIONAL governance scaffold — the split constitution, the domain rule set at guardrails/projects/{{domain_slug}}/domain/*.domain.md + domain-rule-bindings.md, each declared LANE\'s rule set and constitution half, the activated domain {{active_domain}}, and the code-derived design / delta-design / domain-model template overrides in .appweaver/templates/overrides/. A later context does NOT re-author any of it: re-deriving project principles from one context\'s evidence is the scoping bias the governance tier exists to avoid. Amend it with /appweaver constitution. ONE HALF AND ONE RULE SET PER LANE: service_lane / ui_lane report which lanes .appweaver/stacks.json declared, and the declaration is what decided. A lane declared (none) in select-stack gets none of it, which is the correct outcome and not an omission. LANE DECLARATION: read, never written — select-stack is its sole writer, and this run scanned the source paths it named (scanned_service_root / scanned_ui_root); scanned_backend_files / scanned_ui_files report each. ui_source_evidence_found false means the UI lane\'s declared path held nothing a scan recognises as UI, so its governance is thin — move the source path with /appweaver select-stack and re-run. The build/test/run commands on each lane are that PROFILE\'s defaults and may not match a legacy layout — review them. Because the domain is activated, resolve-domain + resolve-tech route the WHOLE forward pipeline to these code-derived rules — never another project\'s rules as a fallback. THE BOUNDARIES CAME FROM THE MAP, not from this run: /appweaver inventory proposed them and you confirmed them in specs/proposed-inventory.md. To change a boundary, edit that file and run /appweaver inventory apply — a context whose concepts already exist is not re-onboarded. Develop an EXISTING feature just-in-time: /appweaver adopt <Feature> reverse-engineers its spec.md + design.md + source-map.md and deepens the OKF concept of the aggregate it acts on. Develop a NEW feature straight through the forward pipeline (/appweaver specify → plan → implement). Then drive every change through the CR delta loop (/appweaver specify → plan → analyze-plan-delta → implement → build → analyze-slice-delta → finalize-delta → analyze-slice → close-delta). If a validation_ok is false, its constitution half needs a manual touch (see its Sync Impact Report)."
+  next: "Onboarded bounded context {{bc}} ({{bc_feature_count}} feature(s): {{bc_features}}). Its aggregate concepts ({{bc_aggregates}}) are in {{bundle_dir}}, each keyed `bounded_context: {{bc}}` and listing the features that act on it — the bundle is the project's knowledge, one concept per aggregate, never one per feature — and its specs tree now exists at {{bc_dir}}/ with a directory per feature ({{feature_dirs}}) — EMPTY on purpose: the directory says the feature is known, and the documents that describe it are written per feature by /appweaver adopt and per context by /appweaver specify. {{bc}} is now the ACTIVE bounded context (.appweaver/context.json), so /appweaver select-feature lists exactly these features and nothing from a neighbouring context; switch with /appweaver select-bounded-context. ONBOARD RUNS ONCE PER CONTEXT: contexts already done — {{onboarded_contexts}}; still open — {{remaining_contexts}}; the order the map gives is {{contexts_ordered}}. Run /appweaver onboard <NextContext> for each remaining one, or with no argument to take the next one automatically. THE PROJECT TIER IS WRITTEN ONCE, BY THE FIRST CONTEXT (this run was first: {{is_first}}). That tier is the PROVISIONAL governance scaffold — the split constitution, the domain rule set at guardrails/projects/{{domain_slug}}/domain/*.domain.md + domain-rule-bindings.md, each declared LANE\'s rule set and constitution half, the activated domain {{active_domain}}, and the code-derived design / delta-design / domain-model template overrides in .appweaver/templates/overrides/. A later context does NOT re-author any of it: re-deriving project principles from one context\'s evidence is the scoping bias the governance tier exists to avoid. Amend it with /appweaver constitution. ONE HALF AND ONE RULE SET PER LANE: service_lane / ui_lane report which lanes .appweaver/stacks.json declared, and the declaration is what decided. A lane declared (none) in select-stack gets none of it, which is the correct outcome and not an omission. LANE DECLARATION: read, never written — select-stack is its sole writer, and this run scanned the source paths it named (scanned_service_root / scanned_ui_root); scanned_backend_files / scanned_ui_files report each. ui_source_evidence_found false means the UI lane\'s declared path held nothing a scan recognises as UI, so its governance is thin — move the source path with /appweaver select-stack and re-run. The build/test/run commands on each lane are that PROFILE\'s defaults and may not match a legacy layout — review them. Because the domain is activated, resolve-domain + resolve-tech route the WHOLE forward pipeline to these code-derived rules — never another project\'s rules as a fallback. THE BOUNDARIES CAME FROM THE MAP, not from this run: /appweaver inventory proposed them and you confirmed them in specs/proposed-inventory.md. To change a boundary, edit that file and run /appweaver inventory apply — a context whose concepts already exist is not re-onboarded. Develop an EXISTING feature just-in-time: /appweaver adopt <Feature> reverse-engineers its spec.md + backend-plan.md + source-map.md and deepens the OKF concept of the aggregate it acts on. Develop a NEW feature straight through the forward pipeline — /appweaver select-feature FIRST (specify and every stage after it read the active feature and STOP without one), then specify → plan → analyze-plan → implement → build → analyze-slice → run. Then drive every change through the CR delta loop (/appweaver specify → plan → analyze-plan-delta → implement → build → analyze-slice-delta → finalize-delta → analyze-slice → close-delta). If a validation_ok is false, its constitution half needs a manual touch (see its Sync Impact Report)."

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

@@ -154,6 +154,10 @@ vars:
   # answer; master_exists is what makes the menu appear at all.
   master_exists: "false"       # a DECLARED lane's master plan was already on disk
   plan_target: "main"          # main | delta — the answer to the one question this phase asks
+  # The OKF edges this run publishes from the master service plan (main path only).
+  record_master_edges: "false"
+  xref_edge_count: "0"
+  xref_stubbed: "[]"           # used siblings that had no concept yet and were stubbed
   plan_choice: ""              # the raw selection (a label): the MAIN row, a change, or the NEW row
   main_label: ""               # cr-list --include-main's exact label, to test the selection against
   new_label: ""                # cr-list --include-new's
@@ -1069,6 +1073,41 @@ workflow:
     action: include
     module: .appweaver/orchestrator/modules/delta-plan.orch.yaml
 
+  # 6b. CROSS-SLICE EDGES, from the document that states them. `aw-xref record` reads the
+  #     MASTER service plan — §1 References-by-id and the External integrations table — and
+  #     writes a Cross-References row into every sibling aggregate this one uses. Its input
+  #     is the plan and nothing else, yet it used to run only at implement: until a feature
+  #     was BUILT it contributed no edges, so `xref list` answered "0 downstream users" for
+  #     an aggregate a planned feature already depended on, and `xref tree` sorted the two
+  #     into the same wave. The information was in this document the whole time.
+  #
+  #     MAIN PATH ONLY. On the delta path the master plan still holds the PRE-change
+  #     dependencies, so recording here would publish stale references; finalize-delta
+  #     records them after the change merges, which is the same reason implement skips it.
+  #     Reconcile-on-write, so re-recording at implement is idempotent and a dependency
+  #     dropped by a later re-derivation self-heals. Best-effort: never fails the authoring.
+  - id: record_edges_clear
+    action: set
+    vars: { record_master_edges: "false" }
+  - id: record_edges_main
+    condition: "{{plan_target}} == main"
+    action: set
+    vars: { record_master_edges: "true" }
+  - id: record_edges_no_lane
+    condition: "{{be_mode}} == skip"
+    action: set
+    vars: { record_master_edges: "false" }
+  - id: xref_record
+    condition: "{{record_master_edges}} == true"
+    action: execute_script
+    on_error: continue
+    script: { ref: xref }
+    subcommand: record
+    args: ["--feature-dir", "{{feature_dir}}", "--design", "{{backend_plan}}", "--origin", "auto"]
+    outputs:
+      - { name: xref_edge_count, from: "$.edge_count" }
+      - { name: xref_stubbed,    from: "$.stubbed" }
+
   # ═══════════ HANDOFF — authoring only; the gates are SEPARATE stages ═══════
   #   • MAIN (bootstrap or re-derivation) → /appweaver analyze-plan (spec↔plan
   #     conformance gate) → implement. No change is opened either way.

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

@@ -95,10 +95,14 @@ vars:
   has_dependants: "false"
   dependant_ids: ""
   dependant_count: "0"
-  # The two refusal flags, both DOWN by default and raised only by the good state — see
+  wave_problem: ""            # which changes could not be ordered, and why that ends the check
+  unordered_ids: ""
+  unordered_count: "0"
+  # The three refusal flags, all 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"
+  wave_ordering_ok: "false"
   recall_confirmed: "false"
   recalled: "false"
   archived_dir: ""
@@ -170,7 +174,7 @@ workflow:
       - { 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
+  # 4. THE THREE REFUSALS, all 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
@@ -178,11 +182,16 @@ workflow:
     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" }
+      - { 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" }
+      - { name: wave,             from: "$.wave" }
+      - { name: wave_ordering_ok, from: "$.wave_ordering_ok" }
+      - { name: wave_problem,     from: "$.wave_problem" }
+      - { name: unordered_ids,    from: "$.unordered_ids" }
+      - { name: unordered_count,  from: "$.unordered_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
@@ -199,6 +208,18 @@ workflow:
     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."
 
+  # WAVE ORDERING IS A PRECONDITION OF THE FENCE BELOW, not a finding of it. The dependant
+  # test is `their wave > mine`, and a wave that cannot be read used to answer that as 1, so
+  # an unstamped change failed the test and was not counted — recall then withdrew the
+  # ground from under a change it could not see, which is the failure this stage exists to
+  # prevent. Waves have no ceiling, so unlike the merge fence there is no floor that makes
+  # an unordered neighbour harmless: every one of them holds recall until it is stamped.
+  - id: require_wave_ordering
+    action: verify_context
+    require_true: wave_ordering_ok
+    on_false: stop
+    on_false_message: "Recall REFUSED — the wave fence cannot order change {{cr_id}}, so it cannot tell you what was built on top of it: {{wave_problem}}. Withdrawing a change that something else was planned against is exactly what this stage refuses to do blind. A wave is stamped by a script; `**Wave**: [N]` is the unfilled template line, which means the stamp never ran on that document. Stamp each one — `.appweaver/scripts/bash/aw-spec-actions.sh cr-wave-derive --cr-id <CR-id> --stamp` derives the wave from that change's own `## Depends on` section and writes it — then re-run /appweaver recall-delta {{cr_id}}."
+
   - id: no_dependants_raise
     condition: "{{has_dependants}} == false"
     action: set

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

@@ -80,4 +80,6 @@ outputs:
   domain_rule_bindings: "{{map_path}}"
   domain_rule_bindings_exists: "{{map_exists}}"
   note: "Active project '{{domain}}' persisted to .appweaver/domain.json. It selects TWO rule maps under guardrails/projects/{{domain}}/ — domain-rule-bindings.md (DOMAIN rules; read by constitution + specify only, because the spec is the pivot) and tech-rule-bindings.md (TECHNICAL rules; read by 10 workflows incl. design, implement, build and run). The rule FILES themselves live in shared corpora — guardrails/technology/<stack>/ and guardrails/domain/<industry>/ — and the maps are what bind this project to them, so two projects can share a corpus and differ only in their maps and their own three requirements files. domain_rule_bindings_exists reports the domain half only. A map that is absent, or a command with no heading in one, loads nothing for that class and SOFT-CONTINUES — an absent heading is a valid state, never a failure."
-  next: "/appweaver select-feature   (then specify — the per-feature path). Re-run /appweaver select-domain any time to switch projects; it rebinds both maps at once."
+  # constitution comes BEFORE select-feature: it reads the domain rule map this
+  # workflow just bound, and specify declares its domain half as REQUIRED context.
+  next: "/appweaver constitution → select-feature → specify. /appweaver constitution authors the constitution halves from the domain rule map this run just bound — specify declares constitution.domain.md as REQUIRED context, and plan and implement read constitution.technical.md (plus constitution.ui.md on a frontend lane), so it runs before the first feature rather than after. /appweaver select-feature then picks the feature to build; every stage from specify onward reads that active feature and stops without it. Re-run /appweaver select-domain any time to switch projects; it rebinds both maps at once, and /appweaver constitution picks the new bindings up on its next run."