aw-spec-cli 0.1.26 → 0.1.27

package/assets/guardrails/{projects/dotnet-default-project → project-specific}/tech-rule-bindings.md

@@ -1,4 +1,4 @@
-# dotnet-default-project — Command → Technical-Rule-File Map
+# project-specific — Command → Technical-Rule-File Map
 
 Per-command list of the **technical** rule files this project loads (via `resolve-tech` +
 the `tech-select` module, into the sticky standards set) for the spec-anchored
@@ -10,35 +10,39 @@ workflows. They live in the **shared technology corpora**, one folder per stack,
 map is what binds a project to them. The ratified output (`constitution.technical.md`) is
 NOT listed here — every consumer refers to it directly, as-is.
 
-- All paths are workspace-relative. This project maps two stacks:
-  `guardrails/technology/dotnet-webapi/` (the service) and
-  `guardrails/technology/nextjs/` (the frontend lane). Both are **standard rules shared by
-  every project that maps them**, and neither is domain-specific. The frontend corpus is
-  read by three headings — `## /aw-spec-ui-constitution` ratifies the lane's base, and
-  `## /aw-spec-plan-ui` / `## /aw-spec-implement-ui` carry the detail rules under it.
+- All paths are workspace-relative. This project maps two stack corpora:
+  `guardrails/technology/{{backend_stack}}/` (the service) and
+  `guardrails/technology/{{frontend_stack}}/` (the frontend lane). Both are **standard rules
+  shared by every project that maps them**, and neither is domain-specific. The frontend corpus is
+  read by four headings — `## /aw-spec-ui-constitution` ratifies the lane's base,
+  `## /aw-spec-plan-ui` / `## /aw-spec-implement-ui` carry the detail rules under it, and
+  `## /aw-spec-foundation-frontend` is what a spec-built scaffold of the lane follows.
+- `## /aw-spec-foundation-backend` and `## /aw-spec-foundation-frontend` are keyed per lane
+  KIND, not per command: `foundation` scaffolds both lanes in one run and loads one set or
+  the other for each, and only when the lane is built from a spec — a pack is unpacked as-is.
 - The two files this project authors — `service/technical-requirements.md` and
   `frontend/ui-requirements.md` — live beside this map. They are the only mapped technical
   files expected to differ between two projects on the same stacks.
-- `technology/dotnet-webapi/examples/` holds the worked `<SampleProjectName>` sample for the
+- A corpus's `examples/` folder holds the worked `<SampleProjectName>` sample for the
   rule file beside it, split out so a phase can load the rules without the sample code. The
   code-generating phases map both; `## /aw-spec-constitution` maps the rules alone, because a
   thin authority document has no use for sample code.
 - `resolve-tech --command <name>` collects the `- ` bullets under `## /<name>`.
-- Adding a stack is adding a corpus and mapping it — `guardrails/technology/java-spring/`
-  ships unmapped for exactly that. No workflow, script or engine change is involved.
-- **This map is pinned to .NET on purpose** — it is the *default .NET project*, and the stack
-  directories below are spelled out. Read from a repo whose lanes declare another stack,
-  `resolve-tech` returns `stack_mismatch` and `tech-select` asks before loading, because these
-  files become sticky standards the code generator follows. A project on another stack should
-  copy this folder and repoint the bullets, not adopt it as-is.
-- A bullet may name its stack with a **placeholder** instead — `{{stack}}`,
-  `{{backend_stack}}`, `{{frontend_stack}}`, `{{backend_ecosystem}}`, `{{frontend_ecosystem}}`
-  — resolved from `.appweaver/stacks.json`. `guardrails/technology/{{stack}}/persistence.md`
-  reads as `java-spring/` in a Spring repo and `dotnet-webapi/` here, so ONE map serves every
-  stack a project declares. A placeholder for an undeclared lane skips that bullet; a resolved
-  path with no file on disk is reported, not silently dropped. See STACK-PROFILES.md §7a.
-- This file is the **canonical technical mapping** for this project; it is selected whenever
-  `dotnet-default-project` is the active project (`.appweaver/domain.json`).
+- **Every stack directory below is a placeholder**, resolved from the lanes in
+  `.appweaver/stacks.json`: `{{backend_stack}}` is the service lane's stack and
+  `{{frontend_stack}}` the frontend lane's (`{{stack}}`, `{{backend_ecosystem}}` and
+  `{{frontend_ecosystem}}` are also available). `guardrails/technology/{{backend_stack}}/persistence.md`
+  reads as `dotnet-webapi/` in a .NET repo and `java-spring/` in a Spring one, so this one map
+  serves whatever stacks the project declares. A placeholder for an undeclared lane skips
+  that bullet, so a backend-only repo loads no frontend rules. A resolved path with no file
+  on disk is reported as missing and loads nothing in its place. The bullets were written
+  against the `dotnet-webapi` and `nextjs` corpora; another stack's corpus may hold only
+  part of them. See STACK-PROFILES.md §7a.
+- Adding a stack is adding a corpus under `guardrails/technology/<stack>/` with the same file
+  names — the placeholders then reach it with no change to this map, and no workflow, script
+  or engine change is involved.
+- This file is the **canonical technical mapping** for this project; it is used whenever
+  `.appweaver/domain.json` names `project-specific`, which it does by default.
 - A command with no heading here loads no mapped technical file (only the workflow's
   universal `ai-rules.md` seed + `constitution.technical.md`, referred to directly).
 - `## /aw-spec-specify` is the one **modelling-methodology** slot (see the rule partition):
@@ -67,8 +71,8 @@ NOT listed here — every consumer refers to it directly, as-is.
      ihe-conformance.md under ## /aw-spec-plan is the same pattern. Unmapping them does not
      make the spec's Experience Standards section disappear — the section is unconditional and
      resolves to "None" — it removes the methodology specify fills it from. -->
-- guardrails/technology/dotnet-webapi/domain-driven-design.md
-- guardrails/technology/dotnet-webapi/examples/domain-driven-design.md
+- guardrails/technology/{{backend_stack}}/domain-driven-design.md
+- guardrails/technology/{{backend_stack}}/examples/domain-driven-design.md
 - guardrails/domain/healthcare/ux/journey-mapping.md
 - guardrails/domain/healthcare/ux/interaction-states.md
 - guardrails/domain/healthcare/ux/accessibility-standards.md
@@ -78,30 +82,30 @@ NOT listed here — every consumer refers to it directly, as-is.
 <!-- The technical/architecture rule files the design author works from (alongside the
      spec and constitution.technical.md), each followed by its worked example. NO domain file
      here — domain reaches design only as spec ids (BR-/CN-/DC-/IC-). -->
-- guardrails/technology/dotnet-webapi/clean-architecture.md
-- guardrails/technology/dotnet-webapi/cqrs.md
-- guardrails/technology/dotnet-webapi/eventing.md
-- guardrails/technology/dotnet-webapi/modular-monolith.md
-- guardrails/technology/dotnet-webapi/vertical-slices.md
-- guardrails/technology/dotnet-webapi/persistence.md
-- guardrails/technology/dotnet-webapi/folder-structure.md
-- guardrails/technology/dotnet-webapi/testing.md
-- guardrails/technology/dotnet-webapi/api-versioning.md
-- guardrails/technology/dotnet-webapi/zero-trust.md
-- guardrails/technology/dotnet-webapi/authorization.md
-- guardrails/technology/dotnet-webapi/authorization-matrix.md
-- guardrails/technology/dotnet-webapi/auditing.md
-- guardrails/technology/dotnet-webapi/data-classification.md
+- guardrails/technology/{{backend_stack}}/clean-architecture.md
+- guardrails/technology/{{backend_stack}}/cqrs.md
+- guardrails/technology/{{backend_stack}}/eventing.md
+- guardrails/technology/{{backend_stack}}/modular-monolith.md
+- guardrails/technology/{{backend_stack}}/vertical-slices.md
+- guardrails/technology/{{backend_stack}}/persistence.md
+- guardrails/technology/{{backend_stack}}/folder-structure.md
+- guardrails/technology/{{backend_stack}}/testing.md
+- guardrails/technology/{{backend_stack}}/api-versioning.md
+- guardrails/technology/{{backend_stack}}/zero-trust.md
+- guardrails/technology/{{backend_stack}}/authorization.md
+- guardrails/technology/{{backend_stack}}/authorization-matrix.md
+- guardrails/technology/{{backend_stack}}/auditing.md
+- guardrails/technology/{{backend_stack}}/data-classification.md
 - guardrails/domain/healthcare/ihe-conformance.md
-- guardrails/technology/dotnet-webapi/examples/clean-architecture.md
-- guardrails/technology/dotnet-webapi/examples/cqrs.md
-- guardrails/technology/dotnet-webapi/examples/eventing.md
-- guardrails/technology/dotnet-webapi/examples/vertical-slices.md
-- guardrails/technology/dotnet-webapi/examples/persistence.md
-- guardrails/technology/dotnet-webapi/examples/api-versioning.md
-- guardrails/technology/dotnet-webapi/examples/zero-trust.md
-- guardrails/technology/dotnet-webapi/examples/authorization.md
-- guardrails/technology/dotnet-webapi/examples/auditing.md
+- guardrails/technology/{{backend_stack}}/examples/clean-architecture.md
+- guardrails/technology/{{backend_stack}}/examples/cqrs.md
+- guardrails/technology/{{backend_stack}}/examples/eventing.md
+- guardrails/technology/{{backend_stack}}/examples/vertical-slices.md
+- guardrails/technology/{{backend_stack}}/examples/persistence.md
+- guardrails/technology/{{backend_stack}}/examples/api-versioning.md
+- guardrails/technology/{{backend_stack}}/examples/zero-trust.md
+- guardrails/technology/{{backend_stack}}/examples/authorization.md
+- guardrails/technology/{{backend_stack}}/examples/auditing.md
 
 ## /aw-spec-plan-ui
 <!-- The FRONTEND LANE's design phase. Its own heading, not a branch of ## /aw-spec-plan:
@@ -115,42 +119,42 @@ NOT listed here — every consumer refers to it directly, as-is.
      CROSS-LANE pairing rule set — what the service guarantees (paging shape, concurrency
      token, error codes, redaction, caching, CORS) and what the client therefore must do.
      It is named for the service stack and mapped through the placeholder, so ONE bullet
-     serves every backend: it resolves to api-integration.dotnet-webapi.md here and to
+     serves every backend: it resolves to api-integration.dotnet-webapi.md in a .NET repo and to
      api-integration.java-spring.md in a Spring repo — both authored — and to a REPORTED
      missing file for a backend whose pairing nobody has written yet, rather than silently
      loading one stack's assumptions into another. A repo with no backend lane skips the
      bullet entirely. No other service-lane file is mapped here: design.ui.md consumes the
      published surface, never the service's internals. -->
-- guardrails/technology/nextjs/component-architecture.md
-- guardrails/technology/nextjs/routing-navigation.md
-- guardrails/technology/nextjs/state-management.md
-- guardrails/technology/nextjs/error-handling.md
-- guardrails/technology/nextjs/forms-and-validation.md
-- guardrails/technology/nextjs/auth-session.md
-- guardrails/technology/nextjs/design-system.md
-- guardrails/technology/nextjs/accessibility-implementation.md
-- guardrails/technology/nextjs/i18n.md
-- guardrails/technology/nextjs/performance-budgets.md
-- guardrails/technology/nextjs/api-integration.{{backend_stack}}.md
+- guardrails/technology/{{frontend_stack}}/component-architecture.md
+- guardrails/technology/{{frontend_stack}}/routing-navigation.md
+- guardrails/technology/{{frontend_stack}}/state-management.md
+- guardrails/technology/{{frontend_stack}}/error-handling.md
+- guardrails/technology/{{frontend_stack}}/forms-and-validation.md
+- guardrails/technology/{{frontend_stack}}/auth-session.md
+- guardrails/technology/{{frontend_stack}}/design-system.md
+- guardrails/technology/{{frontend_stack}}/accessibility-implementation.md
+- guardrails/technology/{{frontend_stack}}/i18n.md
+- guardrails/technology/{{frontend_stack}}/performance-budgets.md
+- guardrails/technology/{{frontend_stack}}/api-integration.{{backend_stack}}.md
 
 ## /aw-spec-implement
 <!-- The FRAMEWORK / code-generation rule files the SERVICE lane's generator builds against
      (alongside backend-plan.md and constitution.technical.md), on the BOOTSTRAP path.
      NO domain file — domain reaches implement only through the plan. clean-architecture/cqrs
      are planning concerns; component wiring is a separate /appweaver add-component step. -->
-- guardrails/technology/dotnet-webapi/coding-standards.md
-- guardrails/technology/dotnet-webapi/dependency-policy.md
-- guardrails/technology/dotnet-webapi/folder-structure.md
-- guardrails/technology/dotnet-webapi/framework-api-map.md
-- guardrails/technology/dotnet-webapi/testing.md
-- guardrails/technology/dotnet-webapi/PACKAGING.md
+- guardrails/technology/{{backend_stack}}/coding-standards.md
+- guardrails/technology/{{backend_stack}}/dependency-policy.md
+- guardrails/technology/{{backend_stack}}/folder-structure.md
+- guardrails/technology/{{backend_stack}}/framework-api-map.md
+- guardrails/technology/{{backend_stack}}/testing.md
+- guardrails/technology/{{backend_stack}}/PACKAGING.md
 
 ## /aw-spec-implement-ui
 <!-- The FRONTEND LANE's code-generation set — the HOW that lane of `implement` builds
      against, alongside frontend-plan.md and constitution.ui.md. It is loaded on BOTH paths,
      master and delta, because the lane never had a separate delta heading. NO domain file
      (domain reached the lane through spec -> frontend-plan.md), and NO service-lane file
-     beyond the pairing rules below — this lane never writes outside its declared source path.
+     beyond the pairing rules below — this lane never writes outside its declared lane root folder.
 
      EIGHT FILES ARE MAPPED FOR BOTH LANE PHASES on purpose. error-handling,
      forms-and-validation, auth-session, design-system, accessibility-implementation, i18n,
@@ -158,19 +162,19 @@ NOT listed here — every consumer refers to it directly, as-is.
      IMPLEMENT half of one rule: the design decides the states, the affordances and the
      targets; this phase realises them. A rule read by only one of the two loses the
      pairing, and the half that goes unread is always the one that then goes unbuilt. -->
-- guardrails/technology/nextjs/component-conventions.md
-- guardrails/technology/nextjs/api-client.md
-- guardrails/technology/nextjs/api-integration.{{backend_stack}}.md
-- guardrails/technology/nextjs/auth-session.md
-- guardrails/technology/nextjs/client-security.md
-- guardrails/technology/nextjs/error-handling.md
-- guardrails/technology/nextjs/forms-and-validation.md
-- guardrails/technology/nextjs/design-system.md
-- guardrails/technology/nextjs/accessibility-implementation.md
-- guardrails/technology/nextjs/i18n.md
-- guardrails/technology/nextjs/performance-budgets.md
-- guardrails/technology/nextjs/observability.md
-- guardrails/technology/nextjs/frontend-testing.md
+- guardrails/technology/{{frontend_stack}}/component-conventions.md
+- guardrails/technology/{{frontend_stack}}/api-client.md
+- guardrails/technology/{{frontend_stack}}/api-integration.{{backend_stack}}.md
+- guardrails/technology/{{frontend_stack}}/auth-session.md
+- guardrails/technology/{{frontend_stack}}/client-security.md
+- guardrails/technology/{{frontend_stack}}/error-handling.md
+- guardrails/technology/{{frontend_stack}}/forms-and-validation.md
+- guardrails/technology/{{frontend_stack}}/design-system.md
+- guardrails/technology/{{frontend_stack}}/accessibility-implementation.md
+- guardrails/technology/{{frontend_stack}}/i18n.md
+- guardrails/technology/{{frontend_stack}}/performance-budgets.md
+- guardrails/technology/{{frontend_stack}}/observability.md
+- guardrails/technology/{{frontend_stack}}/frontend-testing.md
 
 ## /aw-spec-implement-delta
 <!-- The SERVICE lane's set on the DELTA path — same FRAMEWORK / code-generation rules (HOW
@@ -179,29 +183,29 @@ NOT listed here — every consumer refers to it directly, as-is.
      while generating the master, so keep the two identical unless a change deliberately
      needs different rules. The delta's code is generated against the master backend-plan.md
      + the delta plan; no domain file (domain reached the delta via delta-spec → delta plan). -->
-- guardrails/technology/dotnet-webapi/coding-standards.md
-- guardrails/technology/dotnet-webapi/dependency-policy.md
-- guardrails/technology/dotnet-webapi/folder-structure.md
-- guardrails/technology/dotnet-webapi/framework-api-map.md
-- guardrails/technology/dotnet-webapi/testing.md
-- guardrails/technology/dotnet-webapi/PACKAGING.md
+- guardrails/technology/{{backend_stack}}/coding-standards.md
+- guardrails/technology/{{backend_stack}}/dependency-policy.md
+- guardrails/technology/{{backend_stack}}/folder-structure.md
+- guardrails/technology/{{backend_stack}}/framework-api-map.md
+- guardrails/technology/{{backend_stack}}/testing.md
+- guardrails/technology/{{backend_stack}}/PACKAGING.md
 
 ## /aw-spec-build
 <!-- The compile/fix reference set: the layering + coding rules the fixer respects when
      repairing compile errors against the design intent, plus the layering example it repairs
      towards. NO domain file (build loads domain rules separately via domain-select) and no
      constitution.technical here. -->
-- guardrails/technology/dotnet-webapi/clean-architecture.md
-- guardrails/technology/dotnet-webapi/coding-standards.md
-- guardrails/technology/dotnet-webapi/examples/clean-architecture.md
+- guardrails/technology/{{backend_stack}}/clean-architecture.md
+- guardrails/technology/{{backend_stack}}/coding-standards.md
+- guardrails/technology/{{backend_stack}}/examples/clean-architecture.md
 
 ## /aw-spec-analyze-slice
 <!-- The design↔code conformance gate's TECHNICAL checklist: the code + tests are
      validated against these (alongside the DOMAIN gate overlays, loaded separately via
      resolve-domain `## /aw-spec-gate`). Validation input only — never authoring. -->
-- guardrails/technology/dotnet-webapi/testing.md
-- guardrails/technology/dotnet-webapi/coding-standards.md
-- guardrails/technology/dotnet-webapi/framework-api-map.md
+- guardrails/technology/{{backend_stack}}/testing.md
+- guardrails/technology/{{backend_stack}}/coding-standards.md
+- guardrails/technology/{{backend_stack}}/framework-api-map.md
 
 ## /aw-spec-constitution
 <!-- What the TECHNICAL half of the split constitution ratifies into
@@ -213,24 +217,24 @@ NOT listed here — every consumer refers to it directly, as-is.
      sources are the domain map's ## /aw-spec-constitution. NO examples/ file either — the
      ratified half is one declarative line and a `→` pointer per principle, so sample code is
      weight without a reader. -->
-- guardrails/technology/dotnet-webapi/technology-constitution.md
-- guardrails/technology/dotnet-webapi/clean-architecture.md
-- guardrails/technology/dotnet-webapi/modular-monolith.md
-- guardrails/technology/dotnet-webapi/vertical-slices.md
-- guardrails/technology/dotnet-webapi/domain-driven-design.md
-- guardrails/technology/dotnet-webapi/cqrs.md
-- guardrails/technology/dotnet-webapi/persistence.md
-- guardrails/technology/dotnet-webapi/eventing.md
-- guardrails/technology/dotnet-webapi/folder-structure.md
-- guardrails/technology/dotnet-webapi/testing.md
-- guardrails/technology/dotnet-webapi/zero-trust.md
-- guardrails/technology/dotnet-webapi/authorization.md
-- guardrails/technology/dotnet-webapi/auditing.md
-- guardrails/technology/dotnet-webapi/data-classification.md
-- guardrails/technology/dotnet-webapi/api-versioning.md
-- guardrails/technology/dotnet-webapi/coding-standards.md
-- guardrails/technology/dotnet-webapi/dependency-policy.md
-- guardrails/projects/dotnet-default-project/service/technical-requirements.md
+- guardrails/technology/{{backend_stack}}/technology-constitution.md
+- guardrails/technology/{{backend_stack}}/clean-architecture.md
+- guardrails/technology/{{backend_stack}}/modular-monolith.md
+- guardrails/technology/{{backend_stack}}/vertical-slices.md
+- guardrails/technology/{{backend_stack}}/domain-driven-design.md
+- guardrails/technology/{{backend_stack}}/cqrs.md
+- guardrails/technology/{{backend_stack}}/persistence.md
+- guardrails/technology/{{backend_stack}}/eventing.md
+- guardrails/technology/{{backend_stack}}/folder-structure.md
+- guardrails/technology/{{backend_stack}}/testing.md
+- guardrails/technology/{{backend_stack}}/zero-trust.md
+- guardrails/technology/{{backend_stack}}/authorization.md
+- guardrails/technology/{{backend_stack}}/auditing.md
+- guardrails/technology/{{backend_stack}}/data-classification.md
+- guardrails/technology/{{backend_stack}}/api-versioning.md
+- guardrails/technology/{{backend_stack}}/coding-standards.md
+- guardrails/technology/{{backend_stack}}/dependency-policy.md
+- guardrails/project-specific/service/technical-requirements.md
 
 ## /aw-spec-ui-constitution
 <!-- What the UI half ratifies into constitution.ui.md as a UX-* principle series: the
@@ -238,14 +242,45 @@ NOT listed here — every consumer refers to it directly, as-is.
      is also the AUTHORITATIVE signal that the project HAS a frontend lane — with no heading
      here the constitution command skips the UI half and creates no file at all. Domain-free,
      and loaded before domain-select for the same reason as the set above. -->
-- guardrails/technology/nextjs/ui-constitution.md
-- guardrails/projects/dotnet-default-project/frontend/ui-requirements.md
+- guardrails/technology/{{frontend_stack}}/ui-constitution.md
+- guardrails/project-specific/frontend/ui-requirements.md
 
 ## /aw-spec-run
 <!-- Execution / data migration: the persistence rules the migration step generates against,
      plus their worked example. NO domain file; run does not reference constitution.technical.md. -->
-- guardrails/technology/dotnet-webapi/persistence.md
-- guardrails/technology/dotnet-webapi/examples/persistence.md
+- guardrails/technology/{{backend_stack}}/persistence.md
+- guardrails/technology/{{backend_stack}}/examples/persistence.md
+
+## /aw-spec-foundation-backend
+<!-- What `foundation` builds the SERVICE lane's base project against when the operator picks
+     a spec ([spec] or [manual spec]) instead of a pack. A pack is verified against these rules
+     when it is made; a spec build is not, so the agent gets them as standards and follows them
+     wherever the spec is silent. The set is the SHAPE of a base project — stack base, folder
+     structure, packages, coding and test conventions, the framework's own types, and the
+     project team's technical requirements — not the architecture/persistence detail set plan
+     and implement load for features. NO domain file: a scaffold has no domain yet. -->
+- guardrails/technology/{{backend_stack}}/technology-constitution.md
+- guardrails/technology/{{backend_stack}}/folder-structure.md
+- guardrails/technology/{{backend_stack}}/dependency-policy.md
+- guardrails/technology/{{backend_stack}}/coding-standards.md
+- guardrails/technology/{{backend_stack}}/framework-api-map.md
+- guardrails/technology/{{backend_stack}}/testing.md
+- guardrails/project-specific/service/technical-requirements.md
+
+## /aw-spec-foundation-frontend
+<!-- The same for the FRONTEND lane: the lane base (ui-constitution, which carries the
+     mandatory frontend folder structure), how components are split and named, routing, the
+     design system, the generated API client the lane talks to the service through, the test
+     setup, and the project team's ui-requirements. Loaded INSTEAD of the backend set, never
+     on top of it — foundation swaps the standards between the two lanes. -->
+- guardrails/technology/{{frontend_stack}}/ui-constitution.md
+- guardrails/technology/{{frontend_stack}}/component-architecture.md
+- guardrails/technology/{{frontend_stack}}/component-conventions.md
+- guardrails/technology/{{frontend_stack}}/routing-navigation.md
+- guardrails/technology/{{frontend_stack}}/design-system.md
+- guardrails/technology/{{frontend_stack}}/api-client.md
+- guardrails/technology/{{frontend_stack}}/frontend-testing.md
+- guardrails/project-specific/frontend/ui-requirements.md
 
 ---
 
@@ -264,6 +299,8 @@ NOT listed here — every consumer refers to it directly, as-is.
 | /aw-spec-constitution | 17 | what the technical half ratifies — the technology base, the standard technical rules, and the project team's technical-requirements.md |
 | /aw-spec-ui-constitution | 2 | what the frontend lane's half ratifies — the UI base + the project team's ui-requirements.md — and the signal that the lane exists |
 | /aw-spec-run | 2 | persistence rules the execution / data-migration step generates against, + its example |
+| /aw-spec-foundation-backend | 7 | what `foundation` builds the service lane's base project against when it is built from a spec rather than unpacked from a pack |
+| /aw-spec-foundation-frontend | 8 | the same for the frontend lane — loaded instead of the backend set, never on top of it |
 
 > All migrated workflows are on this map. The conformance-gate workflows **analyze-plan**
 > and **analyze-plan-delta** are intentionally NOT here — they validate the plans / the delta

package/assets/guardrails/technology/dotnet-webapi/PACKAGING.md

@@ -162,12 +162,63 @@ AAABAAE...
 
 ---
 
+## The rule file (`<pack name>.rules.json`)
+
+Every file in a pack is unpacked as packed, and a file that is already there is replaced. A
+pack that needs some files treated otherwise ships a rule file beside it, named after the
+pack: `VerticalSlice.rules.json` for `VerticalSlice.pack.txt`,
+`VerticalSlice.Reference.rules.json` for `VerticalSlice.Reference.pack.txt`. Without one, the
+pack unpacks exactly as described above.
+
+```json
+{
+  "format": "aw-spec-pack-rules/v1",
+  "rules": [
+    {
+      "path": "src/AppWeaver.VerticalSlice.Service/Infrastructure/ApplicationDbContext.cs",
+      "action": "merge",
+      "note": "why this file is merged — for the reader only",
+      "instruction": [
+        "Produce one ApplicationDbContext based on the EXISTING file:",
+        "- insert every INCOMING `public DbSet<...>` property right after the class's opening brace;",
+        "- keep everything else in the EXISTING file unchanged."
+      ]
+    },
+    { "path": "src/AppWeaver.VerticalSlice.Service/Features/", "action": "replace" }
+  ]
+}
+```
+
+- **`path`** is written as the pack holds it, sentinel included, and is renamed the way the
+  pack's files are — one rule file serves every app name. A path ending in `/` covers every
+  pack file under that folder; a rule for a file wins over its folder's rule.
+- **`action`** is `merge` or `replace`. `replace` writes the pack's file over the existing one,
+  which is also what happens to every file no rule names. `merge` applies only when the file is
+  already there (from the base project, or from the lane before a re-unpack); otherwise the
+  pack's file is simply written.
+- **`instruction`** (required for `merge`; a string or a list of lines) tells the merging
+  agent how to combine the two versions. It sees the **EXISTING** file — the one in the lane
+  before this pack was unpacked — and the **INCOMING** file — the pack's own, with the sentinel
+  already renamed — and returns the merged file; the engine writes it.
+- **`note`** is optional and ignored by the kit.
+
+A rule file that does not parse, or a rule with an unknown action or a merge with no
+instruction, stops that pack before anything is written: the base pack reports the lane "not
+scaffolded", and a broken reference rule file leaves the sample out with the reason. A rule
+whose path the pack does not hold is reported in the lane's line — a sign the pack changed
+and the rule file was not updated with it.
+
+---
+
 ## How scaffolding consumes the bundle
 
-`/appweaver foundation VerticalSlice <AppName> [OutputDir]` runs `unpack-foundation.ps1`,
-which reads the sentinel from the pack header, derives the four target case forms, and
-writes the renamed files to the output directory (**repo root by default**). The phase is
-defined in `.appweaver/orchestrator/workflows/aw-spec-foundation.orch.yaml`.
+`/appweaver foundation` unpacks the pack a lane picks into that lane's **lane root folder**
+(`backend/` by default) with `unpack-foundation.ps1` (or `.sh`), which reads the sentinel from
+the pack header, derives the four target case forms, and writes the renamed files. Before it
+runs, the pack's rule file is read and every file to be merged is put aside; after it, each
+merge runs as its rule says. A reference sample, when the pack ships one and the operator
+wants it, goes on top the same way with its own rule file. The steps are in
+`.appweaver/orchestrator/modules/foundation-pack.orch.yaml`.
 
 ```powershell
 ./unpack-foundation.ps1 -PackFile ./VerticalSlice.pack.txt -TargetAppName AppWeaver.Health -OutDir ../../../ 
@@ -182,3 +233,6 @@ defined in `.appweaver/orchestrator/workflows/aw-spec-foundation.orch.yaml`.
 - [ ] No `bin/obj/.vs` or local `.db` files committed into the pack.
 - [ ] `pack-foundation.ps1` reported a non-zero sentinel hit count.
 - [ ] `VerticalSlice.pack.txt` regenerated and committed after any change.
+- [ ] Each pack's rule file names every file that must be merged rather than replaced (for a
+      reference sample: every file it shares with the base pack that is not a straight
+      replacement), and no rule names a path the pack no longer holds.

package/assets/guardrails/technology/dotnet-webapi/coding-standards.md

@@ -1,6 +1,6 @@
 # Coding Standards
 
-> Pure technology (domain-agnostic) — domain forbidden patterns & CI gates in [[coding-standards.domain]]. Commands: `/aw-spec-implement`, `/aw-spec-implement-delta`, `/aw-spec-build`, `/aw-spec-analyze-slice`.
+> Pure technology (domain-agnostic) — domain forbidden patterns & CI gates in [[coding-standards.domain]]. Commands: `/aw-spec-implement`, `/aw-spec-implement-delta`, `/aw-spec-build`, `/aw-spec-analyze-slice`, `/aw-spec-foundation-backend`.
 
 ## Naming conventions
 

package/assets/guardrails/technology/dotnet-webapi/dependency-policy.md

@@ -1,6 +1,6 @@
 # Dependency Policy
 
-> Pure technology (domain-agnostic) — domain package rules in [[dependency-policy.domain]]. Commands: `/aw-spec-implement`, `/aw-spec-implement-delta`.
+> Pure technology (domain-agnostic) — domain package rules in [[dependency-policy.domain]]. Commands: `/aw-spec-implement`, `/aw-spec-implement-delta`, `/aw-spec-foundation-backend`.
 
 ## Package governance
 

package/assets/guardrails/technology/dotnet-webapi/folder-structure.md

@@ -1,6 +1,6 @@
 # Mandatory Folder Structure
 
-> Pure technology (domain-agnostic) — domain additions (Interop adapters, conformance tests, fixtures) in [[folder-structure.domain]]. NON-NEGOTIABLE. Commands: `/aw-spec-plan`, `/aw-spec-implement`, `/aw-spec-implement-delta`.
+> Pure technology (domain-agnostic) — domain additions (Interop adapters, conformance tests, fixtures) in [[folder-structure.domain]]. NON-NEGOTIABLE. Commands: `/aw-spec-plan`, `/aw-spec-implement`, `/aw-spec-implement-delta`, `/aw-spec-foundation-backend`.
 >
 > Replace `<SampleProjectName>` with the project name (e.g. `Acme.Billing`).
 

package/assets/guardrails/technology/dotnet-webapi/framework-api-map.md

@@ -1,7 +1,7 @@
 # Framework API Map — which package and namespace each cited type comes from
 
 > Pure technology (domain-agnostic). NON-NEGOTIABLE where it names a package.
-> Commands: `/aw-spec-implement`, `/aw-spec-implement-delta`, `/aw-spec-analyze-slice`.
+> Commands: `/aw-spec-implement`, `/aw-spec-implement-delta`, `/aw-spec-analyze-slice`, `/aw-spec-foundation-backend`.
 >
 > The rules in this corpus name framework types — `AggregateRootBase<TId>`,
 > `IAggregateChild`, `IUnitOfWork`. This file says where each one LIVES. Without it a

package/assets/guardrails/technology/dotnet-webapi/testing.md

@@ -1,6 +1,6 @@
 # Testing Standards
 
-> Pure technology (domain-agnostic) — domain additions in [[testing.domain]]. Commands: `/aw-spec-plan`, `/aw-spec-implement`, `/aw-spec-implement-delta`, `/aw-spec-analyze-slice`.
+> Pure technology (domain-agnostic) — domain additions in [[testing.domain]]. Commands: `/aw-spec-plan`, `/aw-spec-implement`, `/aw-spec-implement-delta`, `/aw-spec-analyze-slice`, `/aw-spec-foundation-backend`.
 
 ## Test-first engineering
 

package/assets/guardrails/technology/nextjs/api-client.md

@@ -1,7 +1,7 @@
 # API Client Standards — nextjs (frontend lane)
 
 > Pure technology (domain-agnostic). NON-NEGOTIABLE.
-> Commands: `/aw-spec-implement-ui`.
+> Commands: `/aw-spec-implement-ui`, `/aw-spec-foundation-frontend`.
 > Detail layer under `constitution.ui.md` UX-IV (the contract is the only server input)
 > and UX-VII (mutations flow through one path).
 

package/assets/guardrails/technology/nextjs/component-architecture.md

@@ -1,6 +1,6 @@
 # Component Architecture Standards — nextjs (frontend lane)
 
-> Pure technology (domain-agnostic). Commands: `/aw-spec-plan-ui`.
+> Pure technology (domain-agnostic). Commands: `/aw-spec-plan-ui`, `/aw-spec-foundation-frontend`.
 > Detail layer under `constitution.ui.md` UX-II (design system) and UX-III (server components).
 
 The rules the UI design author composes a feature's `§3 Component Structure` from. They

package/assets/guardrails/technology/nextjs/component-conventions.md

@@ -1,6 +1,6 @@
 # Component Conventions — nextjs (frontend lane)
 
-> Pure technology (domain-agnostic). Commands: `/aw-spec-implement-ui`.
+> Pure technology (domain-agnostic). Commands: `/aw-spec-implement-ui`, `/aw-spec-foundation-frontend`.
 > Detail layer under `constitution.ui.md` UX-II (design system) and its Mandatory
 > Frontend Folder Structure.
 
@@ -18,7 +18,7 @@ writing within it.
   states. Business composition does not live in a route file.
 - A component reused by two or more features moves to `components/` — and moving it is a
   decision, recorded in the design, not a refactor made mid-generation.
-- Nothing this lane generates is written outside the lane's declared source path.
+- Nothing this lane generates is written outside the declared lane root folder.
 
 ## Naming
 

package/assets/guardrails/technology/nextjs/design-system.md

@@ -1,7 +1,7 @@
 # Design System Standards — nextjs (frontend lane)
 
 > Pure technology (domain-agnostic). NON-NEGOTIABLE.
-> Commands: `/aw-spec-plan-ui`, `/aw-spec-implement-ui`.
+> Commands: `/aw-spec-plan-ui`, `/aw-spec-implement-ui`, `/aw-spec-foundation-frontend`.
 > Detail layer under `constitution.ui.md` UX-II (the design system is the only source of
 > visual truth).
 

package/assets/guardrails/technology/nextjs/frontend-testing.md

@@ -1,7 +1,7 @@
 # Frontend Testing Standards — nextjs (frontend lane)
 
 > Pure technology (domain-agnostic). NON-NEGOTIABLE.
-> Commands: `/aw-spec-implement-ui`.
+> Commands: `/aw-spec-implement-ui`, `/aw-spec-foundation-frontend`.
 > Detail layer under `constitution.ui.md` UX-XI (frontend test-first).
 
 Every file `implement-ui` generates ships with its test. The design says what to test: each

package/assets/guardrails/technology/nextjs/routing-navigation.md

@@ -1,6 +1,6 @@
 # Routing & Navigation Standards — nextjs (frontend lane)
 
-> Pure technology (domain-agnostic). Commands: `/aw-spec-plan-ui`.
+> Pure technology (domain-agnostic). Commands: `/aw-spec-plan-ui`, `/aw-spec-foundation-frontend`.
 > Detail layer under `constitution.ui.md` UX-III (server components) and UX-V (every
 > interaction state specified).
 

package/assets/guardrails/technology/nextjs/ui-constitution.md

@@ -19,7 +19,7 @@ continue them — the two govern different lanes and version independently.
 
 ## Declared Lane
 
-Stack **nextjs** — Next.js (TypeScript, App Router), lane id `web`, owning `web/`.
+Stack **nextjs** — Next.js (TypeScript, App Router), lane id `web`, owning `frontend/` (the default lane root folder).
 
 Where `.appweaver/stacks.json` declares a frontend lane, that declaration is authoritative for the
 lane id and root; a scaffold that disagrees fails `STACK-MISMATCH:` rather than rewriting it.
@@ -121,11 +121,11 @@ another stack's assumptions. Elsewhere in this corpus the file is referenced as
 
 ## Mandatory Frontend Folder Structure
 
-The whole layout sits under the lane's root (`web/`) and never adds to the service lane's
+The whole layout sits under the lane root folder (`frontend/` by default) and never adds to the service lane's
 structure.
 
 ```
-web/
+frontend/
   app/                  # App Router — route segments, layouts, loading/error/not-found
   components/           # design-system compositions, presentational only
   features/<Feature>/   # one folder per spec feature: its components, hooks, actions

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "aw-spec-cli",
-  "version": "0.1.26",
+  "version": "0.1.27",
   "description": "AppWeaver Spec-Driven Development CLI - scaffolds projects with vertical slices, DDD, CQRS, and agent skills",
   "type": "module",
   "main": "dist/index.js",