aw-spec-cli 0.1.13 → 0.1.15

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

@@ -647,7 +647,7 @@ workflow:
           charter; a later step in this same run authors it, so wire the bullet now), then the
           domain identity/regulatory/interop files → domain principles.
         - `## /aw-spec-specify`      — the FULL domain set (specify models the domain, lifts CN-/DC-/IC-).
-        - `## /aw-spec-design`       — `_None — design loads no domain file. Domain reaches design only through the spec._`
+        - `## /aw-spec-plan`       — `_None — design loads no domain file. Domain reaches design only through the spec._`
         - `## /aw-spec-implement`    — `_None — implement loads no domain file. Domain reaches implement only through design.md._`
         - `## /aw-spec-gate`         — the conformance-checklist set (the *.domain.md files).
       Each bullet is a workspace-relative path `- guardrails/projects/{{domain_slug}}/domain/<file>`.
@@ -1190,11 +1190,11 @@ workflow:
       ONLY a heading you have a generated file for (an absent heading soft-continues → loads
       nothing):
         - `## /aw-spec-specify`         — EXACTLY ONE bullet: `service/domain-modelling.md`, the modelling methodology. NEVER an architecture / persistence / codegen / security file here — specify is the domain phase and any technology rule under this heading breaks its domain purity. Omit the heading only if you did not write domain-modelling.md.
-        - `## /aw-spec-design`          — the as-built architecture / cross-cutting rules the design author mediates the spec against.
+        - `## /aw-spec-plan`          — the as-built architecture / cross-cutting rules the design author mediates the spec against.
         - `## /aw-spec-implement`        — the code-generation / convention set the generator builds against (from design.md).
         - `## /aw-spec-implement-delta`  — the same code-generation set, scoped to a change's delta-design.
         - `## /aw-spec-build`            — the layering + convention rules the compile-fixer respects.
-        - `## /aw-spec-analyze-slice`    — the conformance rules the design↔code gate validates against.
+        - `## /aw-spec-analyze-slice`    — the conformance rules the spec↔code gate validates against.
         - `## /aw-spec-adopt`            — the technical reference set the reversed design mediates against (a subset of design's).
         - `## /aw-spec-constitution`     — the standards a later `/appweaver constitution` re-ratifies the TECHNICAL half from. You authored that half from code evidence before these files existed; this heading is what makes a re-run author from THIS project's rules rather than from an empty set. Ratifiable standards only, no worked `examples/` sample, no domain file.
         - `## /aw-spec-run`              — the runtime / execution conventions the app-run step honors (add ONLY if the code evidences a runtime/hosting concern file; NOT data-migration — migration is the deferred later phase).
@@ -1316,18 +1316,33 @@ workflow:
 
       WIRE THE MAP — EDIT guardrails/projects/{{domain_slug}}/tech-rule-bindings.md IN PLACE.
       It already exists and carries the technical headings you wrote; PRESERVE all of them
-      byte-for-byte. Make exactly two additions:
-        1. A `## /aw-spec-ui-constitution` section, placed after the last technical heading
-           and BEFORE the closing quick-reference table. Bullet ONLY the frontend files you
-           just generated, `frontend/ui-constitution.md` first, each as a workspace-relative
-           path `- guardrails/projects/{{domain_slug}}/frontend/<file>`. Ratifiable lane
-           standards only — no domain file, no technical file, no example. Precede them with
-           a short HTML comment saying what this half ratifies and that the heading is also
+      byte-for-byte. Add THREE headings, in this order, after the last technical heading and
+      BEFORE the closing quick-reference table, then their three rows in that table (same
+      format as the existing rows). Every bullet is a workspace-relative path
+      `- guardrails/projects/{{domain_slug}}/frontend/<file>` naming a file you JUST
+      GENERATED — never a greenfield rule, never a service-lane file, never an example.
+      Precede each heading with a short HTML comment saying what that phase loads and why.
+        1. `## /aw-spec-ui-constitution` — the RATIFIABLE lane standards,
+           `frontend/ui-constitution.md` FIRST. Say in its comment that the heading is also
            the authoritative signal that the project has a frontend lane.
-        2. Its row in the quick-reference table, in the same format as the existing rows.
-      Do NOT add `## /aw-spec-ui-design` or `## /aw-spec-ui-implement`: those commands do not
-      exist yet, and a heading mapping files for a command nobody runs is a claim the kit
-      cannot honour. They arrive with the UI lane's own phases.
+        2. `## /aw-spec-plan-ui` — the DESIGN set /appweaver plan-ui works from when it
+           authors or conforms frontend-plan.md: the generated files covering composition,
+           routing/navigation, client state, interaction states, forms, accessibility,
+           internationalization and performance — whichever of those you actually wrote.
+        3. `## /aw-spec-implement-ui` — the CODE-GENERATION set /appweaver implement-ui
+           builds against: conventions, the client/service pairing, styling/design system,
+           forms, accessibility, internationalization, performance and UI testing — again,
+           whichever you actually wrote.
+      THE TWO PHASE SETS OVERLAP ON PURPOSE. A concern like forms, accessibility, i18n or
+      performance carries a DESIGN half and an IMPLEMENT half of one rule — the design decides
+      the states, affordances and targets; implement realises them. Map such a file under BOTH
+      headings. A rule read by only one phase loses the pairing, and the half that goes unread
+      is the half that goes unbuilt.
+      MAP ONLY WHAT YOU GENERATED. A heading with no matching generated file is omitted
+      entirely rather than bulleted with a path that does not exist — an absent heading
+      soft-continues, a broken bullet is reported as missing on every later run.
+      Do NOT add `## /aw-spec-characterize` or `## /aw-spec-parity`: characterize is
+      opt-on-touch and parity belongs to the deferred migration phase.
 
       Write ONLY inside guardrails/projects/{{domain_slug}}/ (frontend/ + the map edit); modify
       no source. Report the files written, the concerns you found present with the code paths
@@ -1369,6 +1384,55 @@ workflow:
       project as backend-only. Add the heading after the last technical one, bulleting
       frontend/ui-constitution.md first, then the rest of the frontend/ set.
 
+  # The lane's two PHASE headings, probed the same way and for the same reason. Ratifying
+  # the lane is not the same as governing it: with `## /aw-spec-ui-constitution` alone the
+  # generated frontend/ rules reach /appweaver constitution and NOTHING else, so plan-ui
+  # designs the experience from constitution.ui.md alone and implement-ui generates against
+  # nothing — while the rules sit on disk unreferenced. An absent heading soft-continues, so
+  # without these probes that gap is invisible on every run. Announce, don't stop: the files
+  # are written and each heading is one edit away.
+  - id: probe_ui_plan_wiring
+    action: execute_script
+    condition: "{{ui_lane}} == true"
+    on_error: continue
+    script: { ref: actions }
+    subcommand: resolve-tech
+    args: ["--command", "aw-spec-plan-ui"]
+    outputs:
+      - { name: ui_plan_rules, from: "$.candidates" }
+  - id: warn_ui_plan_wiring
+    action: verify_context
+    condition: "{{ui_lane}} == true"
+    require_non_empty: ui_plan_rules
+    on_empty: continue
+    on_empty_message: >
+      guardrails/projects/{{domain_slug}}/tech-rule-bindings.md maps nothing under
+      `## /aw-spec-plan-ui`, so /appweaver plan-ui will author frontend-plan.md with NO
+      code-derived experience rules — only constitution.ui.md — while the files this run
+      generated at guardrails/projects/{{domain_slug}}/frontend/ go unread. Add the heading
+      after `## /aw-spec-ui-constitution`, bulleting the generated composition, routing,
+      client-state, interaction-state, forms, accessibility, i18n and performance rules.
+  - id: probe_ui_impl_wiring
+    action: execute_script
+    condition: "{{ui_lane}} == true"
+    on_error: continue
+    script: { ref: actions }
+    subcommand: resolve-tech
+    args: ["--command", "aw-spec-implement-ui"]
+    outputs:
+      - { name: ui_impl_rules, from: "$.candidates" }
+  - id: warn_ui_impl_wiring
+    action: verify_context
+    condition: "{{ui_lane}} == true"
+    require_non_empty: ui_impl_rules
+    on_empty: continue
+    on_empty_message: >
+      guardrails/projects/{{domain_slug}}/tech-rule-bindings.md maps nothing under
+      `## /aw-spec-implement-ui`, so /appweaver implement-ui will generate UI code against no
+      code-derived conventions. Add the heading bulleting the generated conventions, service
+      pairing, styling, forms, accessibility, i18n, performance and UI-testing rules — the
+      ones that also serve the design phase belong under BOTH headings.
+
   # ═══════════ LANE DECLARATION — read back, never written ═══════════════════════
   # onboard does not declare lanes. It used to: before select-stack was the first
   # command of this sequence, a repo could arrive here with no declaration at all, so