aw-spec-cli 0.1.23 → 0.1.24

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

@@ -9,17 +9,23 @@
 #                              → onboard <BoundedContext> (once per context)
 #                                                          ← you are here
 #
-# Three passes over the code. The generated document explains each of them to the
-# operator reading it; the wording lives in the template
+# It reads back the model the greenfield sequence writes — bounded context →
+# aggregate → feature → operation — from the code: the module folder is the context,
+# a declared aggregate-root type is the aggregate, a UI features/<Feature>/ folder is
+# the capability, and a slice under the module's Features/ is one operation (a user
+# story), never a feature. Three passes; the generated document explains each to the
+# operator reading it, in the wording of the template
 # .appweaver/templates/proposed-inventory-template.md, overridable per project:
-#   A  aggregate identification — what must stay consistent together. Three
-#      strategies (structure / reference graph / persistence), each offered only
-#      where the evidence for it exists, each reporting its own numbers.
-#   B  the seam overlay — what can be cut over together. Always runs, over
-#      application/API/UI only. Emits signals, never decisions.
-#   C  the proposal — 1:1 aggregate-to-feature by default, splits proposed with
-#      their evidence and never applied, grouped into bounded contexts and
-#      ordered into dependency waves.
+#   A  the aggregates. Four strategies — domain (the roots the code declares),
+#      structure, reference graph, persistence — each offered only where its
+#      evidence exists, each reporting its own numbers. Declared roots that
+#      operations act on are chosen ahead of any measured strategy.
+#   B  the operations and their seams — each operation's route, the aggregate it
+#      acts on, whether it creates one. Emits signals, never decisions.
+#   C  the features — one per UI feature folder, holding the operations it calls;
+#      shared reads join every feature on their aggregate; what no capability
+#      claims falls back to one feature per aggregate. Many-to-many within a
+#      context, ordered by which feature creates each aggregate.
 #
 # The deliverable is `specs/proposed-inventory.md` — an EDITABLE document. The
 # operator renames, moves, merges, splits and re-orders in that file, then runs
@@ -29,7 +35,7 @@
 # It does NOT author specs, plans or governance (that is onboard, per context)
 # and never modifies source.
 #
-# Launch:  /appweaver inventory [structure|reference|persistence] [focus hints]
+# Launch:  /appweaver inventory [domain|structure|reference|persistence] [focus hints]
 #          /appweaver inventory apply
 # =============================================================================
 
@@ -44,9 +50,11 @@ inputs:
     description: >-
       Either the literal word `apply` — validate the edited specs/proposed-inventory.md
       and regenerate the machine map — or an optional Pass A strategy name
-      (structure | reference | persistence) to force, plus free-text focus hints.
-      With no argument, the highest-coverage available strategy is proposed and the
-      operator confirms it from a menu carrying each strategy's measured numbers.
+      (domain | structure | reference | persistence) to force, plus free-text focus
+      hints. With no argument, `domain` is proposed where the code declares aggregate
+      roots that operations act on, and otherwise the highest-coverage available
+      strategy; the operator confirms it from a menu carrying each strategy's
+      measured numbers.
     required: false
     bind: USER_INPUT
 
@@ -96,10 +104,16 @@ workflow:
       - { name: wave_count,       from: "$.wave_count" }
       - { name: cycle_count,      from: "$.cycle_count" }
       - { name: contexts_ordered, from: "$.contexts_ordered" }
+      - { name: aggregate_count,  from: "$.aggregate_count" }
+      - { name: operation_count,  from: "$.operation_count" }
+      - { name: orphaned_count,   from: "$.orphaned_count" }
       - { name: apply_problems,   from: "$.problems" }
+      - { name: apply_error,      from: "$.error" }
 
   # A rejected edit names the row it could not resolve. Stopping here is the
   # point: a map built from a half-understood file would be onboarded silently.
+  # apply exits non-zero on a rejection; `on_error: continue` still binds the JSON
+  # it printed, which is where the rejected rows (or the missing file) are named.
   - id: apply_gate
     action: verify_context
     condition: "{{mode}} == apply"
@@ -107,7 +121,7 @@ workflow:
     equals: "true"
     on_mismatch: stop
     on_mismatch_message: >
-      specs/proposed-inventory.md could not be applied: {{apply_problems}}
+      specs/proposed-inventory.md could not be applied: {{apply_problems}}{{apply_error}}
       Fix those rows and re-run /appweaver inventory apply. The Aggregate column
       must name an aggregate the scan found; every Depends On value must name a
       Feature that exists in the same table.
@@ -176,19 +190,23 @@ workflow:
       - { name: split_candidates,  from: "$.split_candidates" }
       - { name: contexts_ordered,  from: "$.contexts_ordered" }
       - { name: strategy_options,  from: "$.strategy_options" }
+      - { name: proposal_error,    from: "$.error" }
 
-  # 2b. Substance gate. Zero features is the one outcome that leaves onboard with
-  #     nothing to do, and it is reported as what it is rather than as a crash.
-  - id: require_features
+  # 2b. Substance gate. A scan with nothing to propose is the one outcome that
+  #     leaves onboard with nothing to do. propose reports it as ok=false with the
+  #     reason and writes neither file, so this stop leaves no empty map behind for
+  #     onboard to read, and a map from an earlier run stays as it was.
+  - id: require_proposal
     action: verify_context
     condition: "{{mode}} == propose"
-    require_true: feature_count
-    on_false: stop
-    on_false_message: >
-      No candidate features were found in {{root}}. Every Pass A strategy either
-      returned nothing or was unavailable for want of evidence. Point
-      /appweaver inventory at a subtree that holds application source, or check
-      that the lane declaration names the right path.
+    require_value: proposal_ok
+    equals: "true"
+    on_mismatch: stop
+    on_mismatch_message: >
+      /appweaver inventory found nothing to propose. {{proposal_error}}
+      Check that the service lane in .appweaver/stacks.json names the directory
+      that holds the application source (/appweaver select-stack re-declares it),
+      then re-run /appweaver inventory.
 
   # 3. THE STRATEGY PICK. Offered from the probe, each option carrying its own
   #    measured numbers — features found, share of source covered, how many
@@ -199,9 +217,11 @@ workflow:
     action: user_select
     condition: "{{mode}} == propose"
     prompt: >
-      Pass A found these candidate boundaries. Which evidence should the feature
-      map be built from? (`{{chosen_strategy}}` is proposed: highest coverage,
-      ties broken by fewest single-file candidates.)
+      Pass A found these candidate aggregates. Which evidence should the map be
+      built from? (`{{chosen_strategy}}` is proposed: the roots the code declares
+      where operations act on them, otherwise the highest coverage, ties broken by
+      fewest single-file candidates. Coverage is how much code a strategy placed,
+      not whether it placed it right — compare the aggregate counts too.)
     options_from_variable: strategy_options
     preselect_from: chosen_strategy
     single_option_confirm: true
@@ -227,6 +247,9 @@ workflow:
       - { name: coverage_pct,     from: "$.coverage_pct" }
       - { name: split_candidates, from: "$.split_candidates" }
       - { name: contexts_ordered, from: "$.contexts_ordered" }
+      - { name: aggregate_count,  from: "$.aggregate_count" }
+      - { name: operation_count,  from: "$.operation_count" }
+      - { name: orphaned_count,   from: "$.orphaned_count" }
 
   # 5. Hooks, after the map exists and before the operator is handed it.
   - id: resolve_pre_hooks
@@ -264,7 +287,10 @@ outputs:
   coverage_pct: "{{coverage_pct}}"
   split_candidates: "{{split_candidates}}"
   contexts_ordered: "{{contexts_ordered}}"
+  aggregates: "{{aggregate_count}}"
+  operations: "{{operation_count}}"
+  orphaned_operations: "{{orphaned_count}}"
   # 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."
+  next: "{{context_count}} bounded context(s), {{aggregate_count}} aggregate(s), {{feature_count}} feature(s) and {{operation_count}} operation(s) were proposed from `{{chosen_strategy}}` evidence ({{coverage_pct}}% of source covered), ordered into {{wave_count}} dependency wave(s). {{orphaned_count}} operation(s) fell to a per-aggregate default beside real capabilities — the proposal's Needs a decision section lists them. 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, make a feature act on another aggregate by adding a row, move an operation by editing the Operations cells, 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."