aw-spec-cli 0.1.26 → 0.1.28

package/assets/.appweaver/orchestrator/rev-templates/tech-rule-bindings.skeleton.md

@@ -7,9 +7,9 @@
   placeholder for a service/ file the author actually generated from THIS
   project's CODE.
 
-  Wire ONLY files you generated (all under guardrails/projects/[project]/service/).
+  Wire ONLY files you generated (all under guardrails/[project]/service/).
   Never list a file you did not write. Never list a path belonging to another
-  project (guardrails/projects/<other>/**) — that one is another project's
+  project (any other project folder under guardrails/, e.g. guardrails/project-specific/**) — that one is another project's
   rules, not this one's.
 -->
 # [PROJECT_NAME] — Command → Technical-Rule-File Map (as-built)
@@ -21,12 +21,16 @@ files), and the CODE-DERIVED replacement for the greenfield technical map.
 
 **The model:** the technical rule files (this project's own architecture / persistence /
 concurrency / testing / security-posture set, reverse-engineered from the code into
-`guardrails/projects/[project]/service/`) are CONFIGURATION — tune this map, not the workflows. The
+`guardrails/[project]/service/`) are CONFIGURATION — tune this map, not the workflows. The
 technology base itself (`constitution.technical.md`) is NOT listed here — every consumer still
 refers to it directly, as-is.
 
-- All paths are workspace-relative and live in `guardrails/projects/[project]/service/`.
+- All paths are workspace-relative and live in `guardrails/[project]/service/`.
 - `resolve-tech --command <name>` collects the `- ` bullets under `## /<name>`.
+- `plan`, `implement` and `adopt` are keyed per lane, not per command: the service lane's set
+  sits under `## /aw-spec-<command>-backend`, the frontend lane's under
+  `## /aw-spec-<command>-frontend` (adopt reverses a frontend plan under
+  `## /aw-spec-plan-frontend`, so it has no frontend heading of its own).
 - **`## /aw-spec-specify` is the MODELLING-METHODOLOGY slot** — exactly one file,
   `service/domain-modelling.md`: HOW this code expresses a domain model. Never an architecture /
   persistence / codegen / security file; those would break specify's domain purity. Every other
@@ -41,39 +45,33 @@ refers to it directly, as-is.
      (what marks an aggregate root, entity vs value object, where invariants live, the context
      boundary), NOT what the model is (that is the domain set's domain-model.domain.md, wired
      via domain-rule-bindings). No technology rule may appear under this heading. -->
-- guardrails/projects/[project]/service/domain-modelling.md
+- guardrails/[project]/service/domain-modelling.md
 
-## /aw-spec-plan
+## /aw-spec-plan-backend
 <!-- The as-built architecture / cross-cutting technical rules the SERVICE lane's plan author
      mediates the spec against. NO domain file here — domain reaches plan only as spec ids and
      the context's domain-model.md. -->
-- guardrails/projects/[project]/service/[as-built-architecture].md
-- guardrails/projects/[project]/service/[each generated architecture/cross-cutting rule].md
+- guardrails/[project]/service/[as-built-architecture].md
+- guardrails/[project]/service/[each generated architecture/cross-cutting rule].md
 
-## /aw-spec-implement
+## /aw-spec-implement-backend
 <!-- The framework / code-generation rule set the SERVICE lane's generator builds against
-     (from backend-plan.md). -->
-- guardrails/projects/[project]/service/[each generated codegen/convention rule].md
-
-## /aw-spec-implement-delta
-<!-- The same set for the service lane on the DELTA path. `implement` is one command: it keys
-     this heading when it is generating a change's delta plan and the one above when it is
-     generating the master, so repeat the bullets here to keep both paths identical. -->
-- guardrails/projects/[project]/service/[each generated codegen/convention rule].md
+     (from backend-plan.md), on both the master and the delta path. -->
+- guardrails/[project]/service/[each generated codegen/convention rule].md
 
 ## /aw-spec-build
 <!-- The layering + convention rules the compile-fixer respects. -->
-- guardrails/projects/[project]/service/[as-built-architecture].md
+- guardrails/[project]/service/[as-built-architecture].md
 
 ## /aw-spec-analyze-slice
 <!-- The plan↔code conformance gate's TECHNICAL checklist (validate, don't author). -->
-- guardrails/projects/[project]/service/[testing/convention rule to validate against].md
+- guardrails/[project]/service/[testing/convention rule to validate against].md
 
-## /aw-spec-adopt
+## /aw-spec-adopt-backend
 <!-- Brownfield reverse-engineering: the technical REFERENCE set the reversed BACKEND plan
      mediates the reversed spec ↔ existing code against — the CODE wins, these are reference
-     only. A slice's reversed frontend-plan.md is authored under `## /aw-spec-plan-ui`. -->
-- guardrails/projects/[project]/service/[architecture/cross-cutting reference rule].md
+     only. A slice's reversed frontend-plan.md is authored under `## /aw-spec-plan-frontend`. -->
+- guardrails/[project]/service/[architecture/cross-cutting reference rule].md
 
 ## /aw-spec-constitution
 <!-- The set the TECHNICAL half of the split constitution is RE-ratified from when /appweaver
@@ -84,25 +82,25 @@ refers to it directly, as-is.
      service/ files that carry a ratifiable standard, NOT every generated file, and NO worked examples/
      sample (the ratified half is one declarative line per principle). NO domain file — the domain
      half's sources are the DOMAIN map's ## /aw-spec-constitution. -->
-- guardrails/projects/[project]/service/[ratifiable technical standard].md
+- guardrails/[project]/service/[ratifiable technical standard].md
 
 ## /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). -->
-- guardrails/projects/[project]/service/[runtime/hosting rule].md
+- guardrails/[project]/service/[runtime/hosting rule].md
 
 <!-- THE FRONTEND LANE'S THREE HEADINGS. They are NOT written by the step that authors this
      map; onboard's frontend rule-set step APPENDS them here, after the technical headings and
      before the quick-reference table, and only where a UI lane is declared. A backend-only
      repo never gets them.
-       ## /aw-spec-ui-constitution — the ratifiable lane standards (frontend/ui-constitution.md
+       ## /aw-spec-ui-constitution      — the ratifiable lane standards (frontend/ui-constitution.md
           first). Also the authoritative signal that this project HAS a frontend lane: a later
           /appweaver constitution reads it to decide whether to author constitution.ui.md.
-       ## /aw-spec-plan-ui         — the lane rules the FRONTEND lane of `plan` authors
+       ## /aw-spec-plan-frontend        — the lane rules the FRONTEND lane of `plan` authors
           frontend-plan.md against: composition, navigation, client state, interaction states,
           forms, accessibility, the published-surface binding. `adopt` reverses a slice's
           frontend-plan.md under the same set.
-       ## /aw-spec-implement-ui    — the lane rules the FRONTEND lane of `implement` generates
+       ## /aw-spec-implement-frontend   — the lane rules the FRONTEND lane of `implement` generates
           code against, on both the master and the delta path: component conventions, state and
           data fetching, styling, forms, testing.
      A file carrying both a planning half and a generating half is listed under both; the lane
@@ -120,11 +118,10 @@ refers to it directly, as-is.
 | Command | Technical rule files | Role |
 |---|---|---|
 | /aw-spec-specify | 1 | the as-built modelling methodology the domain model is expressed in — no technology |
-| /aw-spec-plan | [n] | as-built architecture the service lane's plan author mediates the spec against |
-| /aw-spec-implement | [n] | code-generation set the service lane builds against (from backend-plan.md) |
-| /aw-spec-implement-delta | [n] | the same set for the service lane when implement is generating a change's delta plan |
+| /aw-spec-plan-backend | [n] | as-built architecture the service lane's plan author mediates the spec against |
+| /aw-spec-implement-backend | [n] | code-generation set the service lane builds against (from backend-plan.md), both paths |
 | /aw-spec-build | [n] | layering + convention rules the compile-fixer respects |
 | /aw-spec-analyze-slice | [n] | conformance rules the plan↔code gate validates against |
-| /aw-spec-adopt | [n] | technical reference set for the reversed backend plan (brownfield) |
+| /aw-spec-adopt-backend | [n] | technical reference set for the reversed backend plan (brownfield) |
 | /aw-spec-constitution | [n] | the standards the technical constitution half is re-ratified from |
 | /aw-spec-run | [n] | runtime/execution conventions the app-run step honors (only if evidenced) |

package/assets/.appweaver/orchestrator/rev-templates/technical-constitution.skeleton.md

@@ -46,8 +46,8 @@ Sync Impact Report
   - …
 - Dependent artifacts:
   - constitution.domain.md — ⚠ authored next; continues at [N+1]
-  - guardrails/projects/[project]/domain/domain-constitution.md — [✅/⚠] domain charter source
-  - guardrails/projects/[project]/service/ — [✅/⚠] technical rule set
+  - guardrails/[project]/domain/domain-constitution.md — [✅/⚠] domain charter source
+  - guardrails/[project]/service/ — [✅/⚠] technical rule set
 - TODOs: [none mechanical | …]
 -->
 # [PROJECT_NAME] Constitution — Technical Base

package/assets/.appweaver/orchestrator/rev-templates/technical-rule-file.skeleton.md

@@ -6,7 +6,7 @@ concern: "[concern-slug]"
 <!--
   rev-templates/technical-rule-file.skeleton.md — SHAPE-ONLY reference for ONE
   generated technical rule file in the project's service/ folder
-  (guardrails/projects/[project]/service/<concern>.md). It is the TECHNICAL twin of
+  (guardrails/[project]/service/<concern>.md). It is the TECHNICAL twin of
   domain-rule-file.skeleton.md. Write one such file per TECHNOLOGY concern the
   CODE ACTUALLY exhibits (evidenced-only, lean) — e.g. as-built-architecture,
   persistence, concurrency, testing, security-posture, api-surface, eventing,

package/assets/.appweaver/orchestrator/rev-templates/ui-constitution.skeleton.md

@@ -59,8 +59,8 @@ Sync Impact Report
 - Experience concerns DELIBERATELY OMITTED (lack of as-built evidence):
   - [CONCERN] — [what the code shows instead, or that it shows nothing]
 - Dependent artifacts:
-  - guardrails/projects/[project]/frontend/ — [✅/⚠] generated lane rule set
-  - guardrails/projects/[project]/tech-rule-bindings.md — [✅/⚠] `## /aw-spec-ui-constitution`
+  - guardrails/[project]/frontend/ — [✅/⚠] generated lane rule set
+  - guardrails/[project]/tech-rule-bindings.md — [✅/⚠] `## /aw-spec-ui-constitution`
 - TODOs: [none mechanical | …]
 -->
 # [PROJECT_NAME] Constitution — User Experience Base
@@ -103,7 +103,7 @@ Sync Impact Report
 <!-- Form: the lane's AS-BUILT layout under its own root — where components, screens/pages,
      routing, client state, styling and assets actually live, named as THIS code names them.
      Do not impose a folder taxonomy the code does not use. This layout sits entirely under
-     the lane's root and never adds to the service lane's structure. -->
+     the lane root folder and never adds to the service lane's structure. -->
 
 ## [UI_CONVENTIONS_SECTION_NAME]
 

package/assets/.appweaver/orchestrator/rev-templates/ui-delta-design-template.skeleton.md

@@ -80,11 +80,14 @@ it serves.]
 
 <!-- New screens, components, state, interactions or contract bindings.
      "Section" names a section of THIS project's master frontend plan — the same
-     section titles the generated frontend plan template carries. -->
+     section titles the generated frontend plan template carries. A binding row's
+     element LEADS with the operation id the service names the endpoint by — implement
+     checks it against the exported API document. -->
 
 | Section (§ in frontend-plan.md) | Element | Kind | Serves |
 |---|---|---|---|
 | [§ of the master's own structure] | `[element]` | [screen / component / state / binding] | US-[n] · FR-[nnn] |
+| Contract Binding (§5) | `[OperationId]` · `[VERB] [/route]` | binding | IC-[nnn] |
 
 ## MODIFIED — existing UI elements
 

package/assets/.appweaver/orchestrator/rev-templates/ui-design-template.skeleton.md

@@ -222,11 +222,13 @@ does none.]
      the API contracts backend-plan.md states — never its internals: no table,
      handler or persistence assumption crosses this line. Where the surface does
      not name an operation yet, bind against the spec's own IC-/FR- surface and
-     record that as a §8 assumption. -->
+     record that as a §8 assumption. The OPERATION ID is the endpoint's name in the
+     service's published API document (as backend-plan.md records it) — implement
+     finds the endpoint by it; `—` where none is named yet. -->
 
-| Screen / component | Operation (from the contract) | Sends (field shape) | Receives (field shape) | Failure handling | Serves |
-|---|---|---|---|---|---|
-| `[Screen]` | `[operation]` | [field: type, …] | [field: type, …] | [§4 state] | FR-00X · IC-00X |
+| Screen / component | Operation id | Operation (from the contract) | Sends (field shape) | Receives (field shape) | Failure handling | Serves |
+|---|---|---|---|---|---|---|
+| `[Screen]` | `[OperationId]` | `[operation]` | [field: type, …] | [field: type, …] | [§4 state] | FR-00X · IC-00X |
 
 **Contract deltas needed**: [anything the experience requires that the contract
 does not offer — raised back to the service lane, never worked around in the

package/assets/.appweaver/orchestrator/workflows/_smoke.orch.yaml

@@ -5,13 +5,15 @@
 # Exercises every extended construct in one run: inputs, set (raw object),
 # execute_script (read-only subcommand), verify_context gates, ask
 # (non-interactive default), foreach + while loops + break, agent_query
-# (mock:), agent_author (mock content), build_context, include
-# (domain-select module), dispatch_hooks (empty).
+# (mock:), agent_author (mock content), build_context, agent_generate (the
+# mock writes SmokeGenerated.cs), agent_review (mock: pass when the files
+# exist), include (domain-select module), dispatch_hooks (empty).
 #
 # Run:
 #   python3 .appweaver/orchestrator/orchestrator.py \
 #     .appweaver/orchestrator/workflows/_smoke.orch.yaml --non-interactive --json
-# Expected: status ok, echo=hello, sum of foreach passes, smoke.md written.
+# Expected: status ok, echo=hello, sum of foreach passes, smoke.md and
+# SmokeGenerated.cs written, review_pass=true.
 # =============================================================================
 
 name: orch-smoke
@@ -138,6 +140,40 @@ workflow:
     action: verify_context
     required_files: ["{{out_dir}}/smoke.md"]
 
+  # agent_generate — the edit step: the agent writes the file itself and reports
+  # files[]. The mock names the file after the task's first `backtick` word and
+  # writes it under out_dir; a reported path not on disk is dropped before binding,
+  # so the non-empty gate proves the file was written.
+  - id: gen_file
+    action: agent_generate
+    tools: "Read,Write,Edit"
+    permission_mode: acceptEdits
+    task: |
+      Write exactly one file, {{out_dir}}/SmokeGenerated.cs, holding the single
+      line `SmokeGenerated` and nothing else. Write nothing outside {{out_dir}}.
+    outputs:
+      - { name: gen_files, from: "$.files" }
+  - id: gate_gen
+    action: verify_context
+    require_non_empty: gen_files
+    on_empty: stop
+    on_empty_message: "agent_generate wrote nothing, or files[] binding is broken"
+
+  # agent_review — read-only review of the files the generation reported; the
+  # mock passes when every reviewed file exists
+  - id: review_file
+    action: agent_review
+    review_of_var: gen_files
+    task: Check that the file holds the single line SmokeGenerated. Decide pass/fail.
+    outputs:
+      - { name: review_pass,   from: "$.pass" }
+      - { name: review_issues, from: "$.issues" }
+  - id: gate_review
+    action: verify_context
+    require_true: review_pass
+    on_false: stop
+    on_false_message: "agent_review result binding is broken"
+
   # F9: include — the shared domain-select module (read-only script + asks;
   # non-interactive: gate→continue, mode→all)
   - id: domain
@@ -156,5 +192,7 @@ outputs:
   mode: "{{mode}}"
   seen: "{{seen}}"
   q_items: "{{q_items}}"
+  generated: "{{gen_files}}"
+  review_pass: "{{review_pass}}"
   domain: "{{domain}}"
   note: "all engine constructs exercised"

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

@@ -141,7 +141,7 @@ workflow:
     on_false: stop
     on_false_message: >
       No .NET host/startup project found — nothing named Program.cs under `{{host_search}}`,
-      the source path the backend lane declares, nor elsewhere in this repository. Wiring a
+      the lane root folder the backend lane declares, nor elsewhere in this repository. Wiring a
       component means editing a host project's startup registration, so there has to be one
       to edit. If this is a .NET repository, scaffold it first with /appweaver foundation.
       If it is not — this lane's ecosystem is `{{host_eco}}` — then this catalogue's runbooks

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

@@ -37,7 +37,7 @@
 # active_version.json (v1.0) so the CR loop works immediately after.
 #
 # GOVERNANCE RECONCILE (the JIT contract, gap-fix #1) — ⏸ HELD, OFF BY DEFAULT.
-# onboard established the PROJECT constitution + guardrails/projects/<project>/ rule set
+# onboard established the PROJECT constitution + guardrails/<project>/ rule set
 # from the whole-repo SCAN, with per-feature specifics marked PROVISIONAL. The reconcile
 # block below carries this feature's real evidence (BR-/CN-/DC-/IC- ids, code coordinates)
 # INTO that scaffold — upgrading provisional → evidenced. It RECONCILES, never re-authors:
@@ -55,7 +55,7 @@
 #
 # Adopt does NOT generate code and does NOT modify source — writes land under
 # specs/<Context>/<Feature>/, in the context's specs/<Context>/domain-model.md, and in the
-# aggregate's OKF concept; the constitution halves and guardrails/projects/<project>/ are
+# aggregate's OKF concept; the constitution halves and guardrails/<project>/ are
 # written only when the reconcile block below is enabled.
 # Fidelity checks spec/design ↔ CODE; the Adopt review is REPORTED for out-of-band
 # closure — it blocks only on structural failures (unmapped code / fabricated spec/design).
@@ -111,7 +111,7 @@ scripts:
 # Sticky standards seed = the UNIVERSAL always-on rule only (ai-rules). The TECHNICAL/
 # architecture set for the reversed DESIGN step (mirrors aw-spec-design) is no longer
 # hardcoded here — it is now CONFIGURATION, loaded per-command from
-# guardrails/projects/<project>/tech-rule-bindings.md under "## /aw-spec-adopt" by the
+# guardrails/<project>/tech-rule-bindings.md under "## /aw-spec-adopt-backend" by the
 # tech-select module (see the tech_select step below). The reversed SPEC step runs
 # include_standards:false and takes its domain frame from constitution.domain.md via
 # build_context — so design never sees a domain rule file (rule partition preserved); the
@@ -335,7 +335,7 @@ workflow:
     on_false_message: "No concept for the aggregate '{{aggregate_primary}}' — the one feature '{{feature_name}}' acts on — in the onboard bundle under {{bundle_dir}}. If its bounded context has not been onboarded, run /appweaver onboard <Context> first; {{bundle_dir}}/aggregates/index.md lists each aggregate with the features that act on it. If '{{feature_name}}' is a NEW feature (no existing code), do NOT adopt it — author it through the forward pipeline (/appweaver specify → plan → implement), which onboard already made brownfield-ready."
 
   # Governance prerequisite: the reverse steps below are authored AGAINST the project
-  # onboard established (the constitution halves + guardrails/projects/<project>/ rule set).
+  # onboard established (the constitution halves + guardrails/<project>/ rule set).
   # Resolve the active domain now and require its rule map to exist — without it there is
   # no code-derived rule set for tech_select to load, no domain frame for the reversed
   # spec, and nothing for the reconcile block to upgrade when it is enabled. Reconciling
@@ -363,10 +363,10 @@ workflow:
     action: verify_context
     require_true: rulemap_exists
     on_false: stop
-    on_false_message: "No active governance for adopt to work against — run /appweaver onboard first. onboard establishes the PROJECT constitution + guardrails/projects/<project>/ rule set (provisional-from-scan) and activates it. Reversing '{{feature_name}}' without that scaffold would author the spec and design against no code-derived rules at all, and leave them with no governance home."
+    on_false_message: "No active governance for adopt to work against — run /appweaver onboard first. onboard establishes the PROJECT constitution + guardrails/<project>/ rule set (provisional-from-scan) and activates it. Reversing '{{feature_name}}' without that scaffold would author the spec and design against no code-derived rules at all, and leave them with no governance home."
 
   # TECHNICAL rule files → sticky standards (configuration, not hardcoded). tech-select
-  # reads guardrails/projects/<project>/tech-rule-bindings.md under "## /aw-spec-adopt" and
+  # reads guardrails/<project>/tech-rule-bindings.md under "## /aw-spec-adopt-backend" and
   # loads that reference set into the sticky standards for reverse_plan
   # (include_standards:true) — the reversed SPEC and MODEL steps turn it off
   # (include_standards:false), keeping them free of architecture (rule partition). No domain
@@ -377,7 +377,7 @@ workflow:
   - id: tech_select
     action: include
     module: .appweaver/orchestrator/modules/tech-select.orch.yaml
-    with: { command: aw-spec-adopt }
+    with: { command: aw-spec-adopt-backend }
 
   # 2. Scaffold the living docs. The SPEC reuses the forward spec-template (it is
   #    tech-agnostic WHAT/WHY — no architectural bias). The BACKEND PLAN scaffolds from the
@@ -821,13 +821,13 @@ workflow:
   # THE FRONTEND'S RULES REPLACE THE BACKEND'S before the lane's plan is authored — the
   # swap the forward `plan` makes at the same boundary. Sticky standards only accumulate,
   # so without it the UI plan was authored under the service rule set and none of the
-  # lane's own. `## /aw-spec-plan-ui` is the set the forward plan authors this same
+  # lane's own. `## /aw-spec-plan-frontend` is the set the forward plan authors this same
   # document under, so a reversed frontend plan and a planned one answer to one rule set.
   - id: tech_select_ui
     condition: "{{ui_lane}} == true"
     action: include
     module: .appweaver/orchestrator/modules/tech-select.orch.yaml
-    with: { command: aw-spec-plan-ui, replace: "true" }
+    with: { command: aw-spec-plan-frontend, replace: "true" }
 
   - id: ctx_reverse_ui_plan
     condition: "{{ui_lane}} == true"
@@ -1058,6 +1058,7 @@ workflow:
     action: agent_generate
     tools: "Read,Write,Edit"
     permission_mode: acceptEdits
+    include_standards: false                       # the lane rule sets are for the plans; the concept is the aggregate's, in neither lane
     task: |
       COMPLETE the OKF concept of the aggregate '{{aggregate_primary}}' at {{concept_path}} —
       the aggregate this run adopted the feature '{{feature_name}}' over. onboard wrote it
@@ -1119,7 +1120,7 @@ workflow:
   # ═══════════ GOVERNANCE RECONCILE — upgrade onboard's PROVISIONAL scaffold ═══
   # ⏸ HELD 2026-07-29: every step in this block is gated on `reconcile_governance`
   #   (default "false"), so adopt currently does NOT touch the constitution halves
-  #   or the guardrails/projects/<project>/ rule set — onboard's provisional scaffold
+  #   or the guardrails/<project>/ rule set — onboard's provisional scaffold
   #   is left as-is. Flip the var to "true" (workflow vars) to restore the behaviour.
   # Now that this feature is reversed to a TRUSTWORTHY spec (real BR-/CN-/DC-/IC- ids)
   # + design (real code coordinates), reconcile that evidence INTO the governance
@@ -1145,7 +1146,7 @@ workflow:
       - { path: "{{spec_file}}" }                                          # the feature's real BR-/CN-/DC-/IC-
       - { path: "{{backend_plan}}" }
       - { path: "{{feature_dir}}/source-map.md" }
-      - { path: "guardrails/projects/{{gov_domain}}/domain-rule-bindings.md", optional: true }
+      - { path: "guardrails/{{gov_domain}}/domain-rule-bindings.md", optional: true }
       - { path: .appweaver/RULE-PARTITION.md }                                       # the rule-partition authority (which command reads what)
   - id: reconcile_pack
     condition: "{{reconcile_governance}} == true"   # HELD — governance reconcile paused (see vars)
@@ -1153,12 +1154,12 @@ workflow:
     tools: "Read,Write,Edit"
     permission_mode: acceptEdits
     task: |
-      RECONCILE the domain rule-file set in guardrails/projects/{{gov_domain}}/domain/ with the
+      RECONCILE the domain rule-file set in guardrails/{{gov_domain}}/domain/ with the
       newly-adopted feature '{{feature_name}}'. onboard authored these rule files from the
       whole-repo scan with per-feature specifics marked `PROVISIONAL — reconciled at
       adopt`. READ this feature's reversed spec.md + backend-plan.md + source-map.md (in
       context — the real evidence) and the EXISTING rule files under
-      guardrails/projects/{{gov_domain}}/.
+      guardrails/{{gov_domain}}/.
 
       RECONCILE, do NOT re-author:
       - UPGRADE the provisional entries this feature now evidences: replace a
@@ -1174,7 +1175,7 @@ workflow:
       - Preserve the RULE PARTITION in domain-rule-bindings.md (constitution / specify / gate get
         the domain files; design / implement get None). Keep each file's frontmatter and
         note in `generated_by` that adopt reconciled '{{feature_name}}'.
-      Write ONLY inside guardrails/projects/{{gov_domain}}/. Report the files changed/added.
+      Write ONLY inside guardrails/{{gov_domain}}/. Report the files changed/added.
     outputs:
       - { name: pack_reconciled, from: "$.files" }
 
@@ -1250,7 +1251,7 @@ workflow:
       - { path: "{{constitution_domain_file}}" }
       - { path: "{{constitution_technical_file}}" }
       - { path: "{{spec_file}}" }
-      - { path: "guardrails/projects/{{gov_domain}}/domain-rule-bindings.md", optional: true }
+      - { path: "guardrails/{{gov_domain}}/domain-rule-bindings.md", optional: true }
   - id: reconcile_domain
     condition: "{{reconcile_governance}} == true"   # HELD — governance reconcile paused (see vars)
     action: agent_author
@@ -1351,4 +1352,4 @@ outputs:
   composed_file: "{{composed_file}}"
   technical_reconcile_ok: "{{technical_ok}}"
   domain_reconcile_ok: "{{domain_ok}}"
-  next: "Adopted {{feature_name}} (spec.md + backend-plan.md + source-map.md, v1.0) and wrote {{aggregate_sections}} — the model section(s) for the aggregate(s) it acts on, resolved from the {{aggregate_source}} — in the bounded context `{{context}}`'s shared {{domain_model}}. The spec cites BR-nnn by id, the model carries their text, so this slice is checkable by the same gates as a greenfield one and analyze-plan's check 4 now has a model to check against. A section another feature over the same aggregate wrote first was EXTENDED, never duplicated; every other section is untouched. COMPLETED the OKF concept of {{aggregate_primary}} (deepened + linked the deep artifacts; {{xref_edge_count}} cross-slice edge(s) recorded). UI HALF: ui_lane={{ui_lane}} — where it is true this slice also has frontend-plan.md, reversed from the {{ui_count}} UI file(s) the feature map attributes to it; where it is false the repo declared no frontend lane, or this aggregate owns no part of its surface, and a service-only adoption is the correct outcome rather than a gap. In the second case, where a frontend lane IS declared, the feature records lanes=[backend] in its active_version.json (feature_lanes shows it), so plan and the analyze gates treat the frontend lane as absent for THIS feature; run `aw-spec-actions feature-lanes --clear` if it later gains a UI. The SHARED UI surface (app shell, layout, design system) belongs to no slice and stays in {{bundle_dir}}/architecture/frontend.md. NOTE — governance reconcile is currently HELD (reconcile_governance=false): this run did NOT modify the constitution halves or the guardrails/projects/{{gov_domain}}/ rule set, so they keep onboard's provisional scaffold. Close any items in {{feature_dir}}/adopt-review-report.md out of band. The slice is now a NORMAL feature: refine via /appweaver analyze-plan, 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 change edits untested legacy behaviour with blast radius, characterize just that surface first (optional on-touch fence). To restore governance reconcile, set reconcile_governance to \"true\" in the workflow vars."
+  next: "Adopted {{feature_name}} (spec.md + backend-plan.md + source-map.md, v1.0) and wrote {{aggregate_sections}} — the model section(s) for the aggregate(s) it acts on, resolved from the {{aggregate_source}} — in the bounded context `{{context}}`'s shared {{domain_model}}. The spec cites BR-nnn by id, the model carries their text, so this slice is checkable by the same gates as a greenfield one and analyze-plan's check 4 now has a model to check against. A section another feature over the same aggregate wrote first was EXTENDED, never duplicated; every other section is untouched. COMPLETED the OKF concept of {{aggregate_primary}} (deepened + linked the deep artifacts; {{xref_edge_count}} cross-slice edge(s) recorded). UI HALF: ui_lane={{ui_lane}} — where it is true this slice also has frontend-plan.md, reversed from the {{ui_count}} UI file(s) the feature map attributes to it; where it is false the repo declared no frontend lane, or this aggregate owns no part of its surface, and a service-only adoption is the correct outcome rather than a gap. In the second case, where a frontend lane IS declared, the feature records lanes=[backend] in its active_version.json (feature_lanes shows it), so plan and the analyze gates treat the frontend lane as absent for THIS feature; run `aw-spec-actions feature-lanes --clear` if it later gains a UI. The SHARED UI surface (app shell, layout, design system) belongs to no slice and stays in {{bundle_dir}}/architecture/frontend.md. NOTE — governance reconcile is currently HELD (reconcile_governance=false): this run did NOT modify the constitution halves or the guardrails/{{gov_domain}}/ rule set, so they keep onboard's provisional scaffold. Close any items in {{feature_dir}}/adopt-review-report.md out of band. The slice is now a NORMAL feature: refine via /appweaver analyze-plan, 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 change edits untested legacy behaviour with blast radius, characterize just that surface first (optional on-touch fence). To restore governance reconcile, set reconcile_governance to 'true' in the workflow vars."

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

@@ -458,7 +458,13 @@ workflow:
           UNRESOLVED by definition: report it so it is closed here rather than at
           integration;
           (d) a contract the service delta REMOVES or narrows that the master frontend plan
-          still uses is a HIGH gap — the experience delta has to carry the matching change.
+          still uses is a HIGH gap — the experience delta has to carry the matching change;
+          (e) OPERATION IDS MATCH. Every binding row the experience delta adds or changes
+          leads with an operation id, and that id is the one the service delta's table or
+          the master backend plan gives the endpoint, spelled exactly. A binding with no id,
+          or with an id neither names, is a HIGH `contract` gap on lane `frontend`; a
+          service-delta row with no operation id is one on lane `backend`. Implement finds
+          each endpoint by this id in the service's exported API document.
 
           CHECK 4 — THE EFFECTIVE MODEL. It is domain-model.md PLUS this change's model
           delta PLUS the model deltas of every LOWER-WAVE change in context (its

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

@@ -470,7 +470,13 @@ workflow:
           discovered at integration;
           (d) the frontend plan cites the service's published surface and does NOT restate,
           re-derive or contradict it, and states no server-side behaviour or persistence
-          assumption.
+          assumption;
+          (e) OPERATION IDS MATCH. Every §5 row's Operation id is the one the backend plan's
+          §3 gives that endpoint, spelled exactly, and every §3 endpoint has one, unique
+          across the plan. A §5 row with no id (`—` without a DA-n) or with an id §3 does not
+          name is a HIGH `contract` gap on lane `frontend`; a §3 endpoint with no id, or two
+          endpoints sharing one, is one on lane `backend`. Implement finds each endpoint by
+          this id in the service's exported API document.
 
           CHECK 4 — the plans → domain-model.md (when the model is in context; skip if it
           is not):

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

@@ -158,7 +158,7 @@ workflow:
     with: { command: aw-spec-analyze-slice }
 
   # 1. WHICH LANES EXIST. Declaration only — this gate reads code, it does not write it, so
-  #    it has no reason to require a source path on disk.
+  #    it has no reason to require a lane root folder on disk.
   - id: lane_resolve
     action: execute_script
     on_error: continue
@@ -448,7 +448,7 @@ workflow:
       the pre-existing slice.
 
       CHECK 7 — PLACEMENT. Every file this change added or edited sits under the lane that
-      owns it: this lane's production code under its source path `{{be_source_path}}`, its
+      owns it: this lane's production code under its lane root folder `{{be_source_path}}`, its
       tests under its test path `{{be_test_path}}`. A service-lane element written into the
       frontend lane's subtree — or outside every lane's paths — is a HIGH `placement` gap.
       One edit outside them is allowed: registering a test project this change created in
@@ -542,7 +542,7 @@ workflow:
       gap. Judge it only over what this change touched.
 
       CHECK 7 — PLACEMENT. Every file this change added or edited sits under this lane's
-      source path, `{{fe_source_path}}`, or — for a test — its test path, `{{fe_test_path}}`.
+      lane root folder, `{{fe_source_path}}`, or — for a test — its test path, `{{fe_test_path}}`.
       A file written into the service lane's subtree is a HIGH `placement` gap — a gap in the
       service surface is a contract delta raised back to that lane, never a client-side edit
       to it. The one edit allowed outside them is the test setup this change had to create,

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

@@ -85,7 +85,7 @@ scripts:
 
 # No hardcoded technical standards seed. The technical rule files the code/conformance
 # passes check against (testing + coding-standards) are now CONFIGURATION, loaded per-
-# command from guardrails/projects/<project>/tech-rule-bindings.md under "## /aw-spec-analyze-slice"
+# command from guardrails/<project>/tech-rule-bindings.md under "## /aw-spec-analyze-slice"
 # by the tech-select module (see the tech_select step below). The DOMAIN gate overlays are
 # still loaded separately, as before (resolve_gate_overlays → load_gate_overlays). This gate
 # does not reference constitution.technical.md. The seed below is behaviour-only — the kit's
@@ -149,7 +149,7 @@ vars:
 workflow:
 
   # 0. TECHNICAL rule files → sticky standards (configuration, not hardcoded).
-  #    tech-select reads guardrails/projects/<project>/tech-rule-bindings.md under
+  #    tech-select reads guardrails/<project>/tech-rule-bindings.md under
   #    "## /aw-spec-analyze-slice" and loads that set (testing + coding-standards) into
   #    the sticky standards the conformance query reads (include_standards: true). The
   #    DOMAIN gate overlays are loaded separately below. No blocking gate: an unconfigured
@@ -559,7 +559,7 @@ workflow:
         mock: { ok: true, unbound: [], notes: [] }
         task: |
           WOULD THIS SLICE RUN? Check the service lane's composition against its code.
-          The lane is `{{be_lane_id}}` and its source path is `{{be_source_path}}`; the
+          The lane is `{{be_lane_id}}` and its lane root folder is `{{be_source_path}}`; the
           backend plan is in context, and its §2.1 Ports, §4.1 Persistence and §4.3 Wiring
           say what has to be bound.
 

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

@@ -26,7 +26,7 @@
 # compiled by its own build command, so what this stage needs is a declaration to compile
 # from, not a particular kind of one; requiring the service lane blocked a frontend-only
 # project that `plan` and `implement` both accept. The rest of the gate is unchanged: no
-# lane declared, a lane with no source path, a source path that is not on disk, and two
+# lane declared, a lane with no lane root folder, a lane root folder that is not on disk, and two
 # lanes claiming overlapping subtrees all still stop the run.
 #
 # Launch:  /appweaver build [strategy]
@@ -48,7 +48,7 @@ scripts:
 
 # Sticky standards seed = the UNIVERSAL always-on rule only (ai-rules). The technical
 # rule files (the compile/fix reference set) are CONFIGURATION, loaded per-command from
-# guardrails/projects/<project>/tech-rule-bindings.md by the tech-select module (see the
+# guardrails/<project>/tech-rule-bindings.md by the tech-select module (see the
 # tech_select step below). Technical rules ONLY — build loads no domain rules and does
 # not reference constitution.technical.md. A required file that is missing is reported
 # at assembly time (`[system] MISSING (required)`), an `optional:` one is skipped.
@@ -61,7 +61,7 @@ vars:
 workflow:
 
   # Rule files → sticky standards: TECHNICAL only, via tech-select, read from
-  # guardrails/projects/<project>/tech-rule-bindings.md under "## /aw-spec-build".
+  # guardrails/<project>/tech-rule-bindings.md under "## /aw-spec-build".
   # NO domain-select here — see the header: build repairs compile errors, a purely
   # technical job, and the domain never reaches this stage anyway (specify is its sole
   # carrier; build reads code and design intent, not spec).
@@ -90,7 +90,7 @@ workflow:
   # project compiles the one it has, whichever kind that is. A frontend-only project is a
   # legal project: `plan` and `implement` both accept one, so refusing it here stopped it
   # at the first stage that had no reason to care. Passing no required kind leaves every
-  # other check armed — no lane declared at all, a lane with no source path, a source path
+  # other check armed — no lane declared at all, a lane with no lane root folder, a lane root folder
   # that is not on disk, and two lanes claiming overlapping subtrees.
   - id: lane_gate
     action: include

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

@@ -58,7 +58,7 @@ scripts:
 # Sticky standards seed = the UNIVERSAL always-on rule only (ai-rules). The FRAMEWORK /
 # test-generation set (same as implement/analyze-slice — HOW to write + place tests) is no
 # longer hardcoded here — it is now CONFIGURATION, loaded per-command from
-# guardrails/projects/<project>/tech-rule-bindings.md under "## /aw-spec-characterize" by the
+# guardrails/<project>/tech-rule-bindings.md under "## /aw-spec-characterize" by the
 # tech-select module (see the tech_select step below). No domain files: the behaviour to
 # fence comes from the CODE + the adopted spec/design/source-map (constitution.technical.md
 # is referred to directly as context), not from domain rules — the tech map lists only
@@ -79,7 +79,7 @@ vars:
 workflow:
 
   # 0. TECHNICAL rule files → sticky standards (configuration, not hardcoded). tech-select
-  #    reads guardrails/projects/<project>/tech-rule-bindings.md under "## /aw-spec-characterize"
+  #    reads guardrails/<project>/tech-rule-bindings.md under "## /aw-spec-characterize"
   #    and loads that test-generation set into the sticky standards the agent_generate steps
   #    ALWAYS prepend. No domain rule file is loaded here — the tech map lists only technical
   #    files. No blocking gate: an unconfigured project soft-continues (the golden-master is