aw-spec-cli 0.1.26 → 0.1.28

package/assets/.kilocode/workflows/appweaver-demo.md

@@ -1,59 +0,0 @@
----
-name: "appweaver-demo"
-description: "Prototype launcher (Kilo Code): run the aw-orchestrator using the specified strategy (spawn, agent, sdk, sdk-apply)."
-argument-hint: "Optional strategy ('agent', 'spawn', 'sdk', 'sdk-apply') and/or k=value vars (e.g. 'agent out_dir=...')"
-compatibility: "Requires .appweaver/orchestrator/ and the claude CLI on PATH"
-user-invocable: true
-disable-model-invocation: false
----
-
-# Orchestrator Launcher
-
-All orchestration lives in the workflow YAML and is executed by `.appweaver/orchestrator/orchestrator.py` (the general, agent-agnostic engine). The interpreter assembles the COMPLETE payload (system + user) for every request; you never author generation context yourself.
-
-- **Engine + workflow (general):** `.appweaver/orchestrator/orchestrator.py`, `*.orch.yaml`
-- **This agent's transport profile:** `.kilocode/agent.json`
-
-  > Kilo Code has no native headless CLI, so it reuses `claude -p` for `spawn`
-  > (native `--system-prompt`, `--tools`, `--bare` isolation). Its `sdk` block
-  > declares the SDK the `sdk`/`sdk-apply` strategies import (`claude-agent-sdk`)
-  > and the adapter (`.appweaver/orchestrator/adapters/claude_agent_sdk.py`,
-  > shared per-SDK) that owns its calling convention.
-
-## Execution Steps
-
-1. **Parse Arguments**:
-   - Identify the requested strategy (one of: `agent`, `spawn`, `sdk`, `sdk-apply`). If the user specifies a strategy as the first argument, use it. Otherwise, default to `spawn`.
-   - Always pass the strategy explicitly: `--strategy <strategy>`.
-   - `--agent-profile .kilocode/agent.json` is required for `spawn`, `sdk`, and `sdk-apply`:
-     `spawn` reads the CLI to launch from it; `sdk`/`sdk-apply` read the SDK
-     package/module (and its `adapter` file) to import from its `sdk` block.
-     If the SDK package isn't installed, add `--sdk-install` so the engine
-     pip-installs the declared package first. (`agent` needs no profile.)
-   - `--checkpoint .appweaver/orchestrator/.demo-out/demo.state.json` is required for
-     `sdk-apply` and `agent` (suspend/resume — follow the loop in step 3).
-   - `spawn` may also add `--isolation bare|fresh` and `--model <name>` (bare is
-     strongest; use it when `ANTHROPIC_API_KEY` is set). `sdk`/`sdk-apply` accept
-     `--model <name>`; isolation is intrinsic (fresh SDK session, no settings).
-
-2. **Run the Interpreter**:
-   Run the command (include only the bracketed flags that apply to the chosen strategy):
-   ```bash
-   python3 .appweaver/orchestrator/orchestrator.py \
-     .appweaver/orchestrator/workflows/aw-spec-demo.orch.yaml \
-     --strategy <strategy> \
-     [--agent-profile .kilocode/agent.json]   # spawn, sdk, sdk-apply \
-     [--checkpoint .appweaver/orchestrator/.demo-out/demo.state.json]  # sdk-apply, agent \
-     --json
-   ```
-
-3. **Handle Suspend/Resume Loop (for `agent` or `sdk-apply` strategies)**:
-   - If the command exits with code `2` (suspend):
-     - Read the prompt from the sidecar file `<checkpoint-path>.user.md` (and system instructions from `<checkpoint-path>.system.md`).
-     - Fulfill the request directly using your own tools (e.g., implementing the handler or reviewing files in the workspace).
-     - Write the final generation or review output to `<checkpoint-path>.response.md`.
-     - Re-run the exact same command.
-     - Repeat until the orchestrator exits with code `0`.
-
-4. **Report**:
-   Report the final JSON outputs (`status`, `outputs`, `review_pass`, generated file paths, etc.) to the user.

package/assets/.kilocode/workflows/appweaver.md

@@ -1,55 +0,0 @@
----
-name: "appweaver"
-description: "Parametric launcher (Kilo Code): run ANY converted aw-spec skill on the aw-orchestrator under one of the 4 strategies (agent [default], spawn, sdk, sdk-apply)."
-argument-hint: "<skill> [strategy] [input…] — e.g. 'select-domain', 'specify spawn Build an order API', 'analyze-slice'"
-compatibility: "Requires .appweaver/orchestrator/ and the claude CLI on PATH"
-user-invocable: true
-disable-model-invocation: false
----
-
-# Orchestrator Skill Launcher
-
-Runs one converted `aw-spec-*` workflow on the shared, agent-agnostic engine. All orchestration and **all context management live in the workflow YAML + engine** (`.appweaver/orchestrator/orchestrator.py`): the interpreter assembles the COMPLETE payload (system + user) for every request; you never author generation context yourself. Execution follows the chosen strategy; the checkpoint channel carries every human-facing interaction regardless of strategy.
-
-- **Engine + workflows (common, shared by all agents):** `.appweaver/orchestrator/orchestrator.py`, `.appweaver/orchestrator/workflows/aw-spec-<skill>.orch.yaml`, shared modules in `.appweaver/orchestrator/modules/`, shared scripts in `.appweaver/scripts/`
-- **This agent's transport profile:** `.kilocode/agent.json`
-
-  > Kilo Code has no native headless CLI, so it reuses `claude -p` for `spawn`
-  > (native `--system-prompt`, `--tools`, `--bare` isolation). Its `sdk` block
-  > declares the SDK the `sdk`/`sdk-apply` strategies import (`claude-agent-sdk`)
-  > and the adapter (`.appweaver/orchestrator/adapters/claude_agent_sdk.py`,
-  > shared per-SDK) that owns its calling convention.
-
-## Execution Steps
-
-1. **Parse Arguments** (`<skill> [strategy] [input…]`):
-   - `skill` (required): the aw-spec skill name, e.g. `demo`, `select-domain`, `foundation`, `specify`, `design`, `implement`, `build`. Resolve the workflow file `.appweaver/orchestrator/workflows/aw-spec-<skill>.orch.yaml`. If it does not exist, list the available `aw-spec-*.orch.yaml` files in that folder and stop.
-   - `strategy` (optional, one of `agent`, `spawn`, `sdk`, `sdk-apply`; default `agent` — YOU fulfill each generation through the checkpoint channel, no profile needed): who executes each generation. Always pass `--strategy <strategy>`.
-   - Everything after the strategy is the user input: pass it as `--input "<text>"` (omit when empty).
-   - `--agent-profile .kilocode/agent.json` is required for `spawn`, `sdk`, and `sdk-apply` (`agent` needs no profile). If the SDK package isn't installed, add `--sdk-install`.
-   - **Always** pass `--checkpoint .appweaver/orchestrator/.state/<skill>.state.json` — for EVERY strategy. Converted skills contain interactive steps (questions, selections, hooks); the checkpoint is how they reach you and the user. Strategies only govern who generates.
-   - `spawn` may also add `--isolation bare|fresh` and `--model <name>`; `sdk`/`sdk-apply` accept `--model <name>`.
-
-2. **Run the Interpreter**:
-   ```bash
-   python3 .appweaver/orchestrator/orchestrator.py \
-     .appweaver/orchestrator/workflows/aw-spec-<skill>.orch.yaml \
-     --strategy <strategy> \
-     --checkpoint .appweaver/orchestrator/.state/<skill>.state.json \
-     [--agent-profile .kilocode/agent.json]   # spawn, sdk, sdk-apply \
-     [--input "<user input>"] \
-     --json
-   ```
-
-3. **Handle the Suspend/Resume Loop** — whenever the command exits with code `2`, read the printed `pending` JSON and dispatch on `pending.kind`; fulfill it, write the response to `pending.response_path`, then re-run the SAME command. Repeat until exit `0` (done) or `1` (stopped by a gate).
-   - **`ask`** — ask the USER the `prompt` with the listed `options` (use your question tool). Write the chosen answer as PLAIN TEXT to `response_path` (comma-separated values when `multi` is true).
-   - **`select`** — ask the USER to pick ONE of `options`; write the chosen value as plain text to `response_path`.
-   - **`hook`** — run each MANDATORY hook in `hooks` (each is a slash command of THIS agent) in this conversation; optional hooks at your discretion. Then write `done` to `response_path`.
-   - **`author`** — read `system_path` + `user_path` and treat them as your ONLY standards and context. Author the COMPLETE content of the file named in `target` and write it — content ONLY, no commentary, no code fence — to `response_path`. Do NOT write the target file yourself; the interpreter does that.
-   - **`agent_generate`** — read `system_path` + `user_path`; perform the task YOURSELF with the listed `tools` within `permission_mode`; write your full final reply — ending with the required ```json fence — to `response_path`.
-   - **`agent_query` / `agent_review`** — same as above but READ-ONLY (do not modify files); the reply must end with the required ```json fence.
-   - **`apply`** — an isolated generation already decided the changes: read `artifact_path` and write its file contents EXACTLY to the paths it names, then write the confirmation ```json fence to `response_path`.
-   - If `pending.note` is present, your previous response was rejected — follow the note and rewrite `response_path`.
-
-4. **Report**:
-   Report the final JSON (`status`, `outputs`, and any `reason`) to the user. On `stopped`, relay the gate message verbatim — it tells the user what to fix or run first.

package/assets/guardrails/projects/dotnet-default-project/tech-rule-bindings.md

@@ -1,271 +0,0 @@
-# dotnet-default-project — 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
-orchestrator pipeline. This is the technical counterpart of `domain-rule-bindings.md`
-(which maps the DOMAIN rule files).
-
-**The model:** the technical rule files are CONFIGURATION — tune this map, not the
-workflows. They live in the **shared technology corpora**, one folder per stack, and this
-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.
-- 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
-  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`).
-- 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):
-  a domain-agnostic way of *modelling*, never a technology choice. Everything below it is a
-  HOW-phase technical set.
-
----
-
-## /aw-spec-specify
-<!-- MODELLING METHODOLOGY ONLY, in two halves. Specify is the domain phase: the single kind
-     of technical input it may take is a domain-agnostic way of MODELLING, never a technology
-     choice. Do NOT add an architecture / persistence / codegen file here — that would break
-     specify's domain purity (design/implement own those). The domain's own DDD overlay
-     (domain-driven-design.domain.md) arrives separately via domain-rule-bindings.
-
-     1. THE DOMAIN MODEL — DDD tactical patterns, plus the same methodology worked through
-        in code as the example beside it.
-     2. THE EXPERIENCE MODEL — the ux/ rules that govern how specify states the experience:
-        Experience Scope, and the project-wide Experience Standards it lifts as UX- ids for
-        prototype / design-ui / implement-ui to author and verify against. These are
-        methodology, not visual design; each file's own "What must NOT appear" section is
-        what keeps screens out of the spec.
-
-     ⚠ The ux/ files sit in a DOMAIN corpus folder but are TECHNICAL-tier inputs: a file's
-     tier is the map that lists it, not the folder it lives in. guardrails/domain/healthcare/
-     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/domain/healthcare/ux/journey-mapping.md
-- guardrails/domain/healthcare/ux/interaction-states.md
-- guardrails/domain/healthcare/ux/accessibility-standards.md
-- guardrails/domain/healthcare/ux/content-design.md
-
-## /aw-spec-plan
-<!-- 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/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
-
-## /aw-spec-plan-ui
-<!-- The FRONTEND LANE's design phase. Its own heading, not a branch of ## /aw-spec-plan:
-     the two lanes are governed by different constitution halves and own disjoint source
-     paths, so keying the map on this command name gives the lane its own rule set for zero
-     mechanism change. NO domain file here — the domain reaches design.ui.md as spec ids,
-     exactly as it reaches design.md. The lane's ratified base (constitution.ui.md) is
-     referred to directly and is NOT mapped.
-
-     THE SERVICE LANE ENTERS THROUGH ONE FILE. api-integration.{{backend_stack}}.md is the
-     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
-     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
-
-## /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
-
-## /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.
-
-     EIGHT FILES ARE MAPPED FOR BOTH LANE PHASES on purpose. error-handling,
-     forms-and-validation, auth-session, design-system, accessibility-implementation, i18n,
-     performance-budgets and the api-integration pairing each carry a DESIGN half and an
-     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
-
-## /aw-spec-implement-delta
-<!-- The SERVICE lane's set on the DELTA path — same FRAMEWORK / code-generation rules (HOW
-     to build). `implement` is one command for both paths and both lanes: it keys this
-     heading while generating a change's delta-backend-plan.md and `## /aw-spec-implement`
-     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
-
-## /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
-
-## /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
-
-## /aw-spec-constitution
-<!-- What the TECHNICAL half of the split constitution ratifies into
-     constitution.technical.md: the technology base, then the STANDARD technical rules for
-     this industry — the same corpus design and implement build against, so a ratified
-     principle can cite the rule it governs — and last the PROJECT-SUPPLIED file the project
-     team authors. Loaded BEFORE the technical half and before domain-select, so the
-     technical author stays domain-free (the seam). NO domain file here: the domain half's
-     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
-
-## /aw-spec-ui-constitution
-<!-- What the UI half ratifies into constitution.ui.md as a UX-* principle series: the
-     standard frontend rules for this industry, then the PROJECT-SUPPLIED file. This heading
-     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
-
-## /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
-
----
-
-## Quick reference (command → technical file count)
-
-| Command | Technical rule files | Role |
-|---|---|---|
-| /aw-spec-specify | 6 | the modelling methodology the spec is expressed in: DDD for the domain model (+ its example), and the four ux/ rules for the experience model it lifts as UX- ids — no technology |
-| /aw-spec-plan | 24 | architecture/security/interop the design author mediates the spec against, each with its example |
-| /aw-spec-plan-ui | 11 | the frontend lane's design set — composition, routing, client state, interaction states, forms, auth surface, design system, accessibility, i18n, performance, and the cross-lane API pairing the UI design author works from (from spec.md) |
-| /aw-spec-implement | 5 | governance/architecture the SERVICE lane builds against (from backend-plan.md), master path |
-| /aw-spec-implement-ui | 13 | the FRONTEND lane's code-generation set (from frontend-plan.md), both paths — conventions, the generated client + its service pairing, auth, client security, states, forms, design system, accessibility, i18n, performance, observability and testing |
-| /aw-spec-implement-delta | 5 | the same set as /aw-spec-implement, for the service lane when implement is generating a change's delta plan |
-| /aw-spec-build | 3 | layering + coding rules the compile-fixer respects, + the layering example |
-| /aw-spec-analyze-slice | 2 | testing + coding rules the design↔code gate validates against |
-| /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 |
-
-> 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
-> against the spec + DOMAIN gate overlays only (domain-rule-bindings `## /aw-spec-gate`), with no
-> technical gate checklist.