aw-spec-cli 0.1.3 → 0.1.5

package/assets/docs/architecture/cqrs.md

@@ -1,6 +1,6 @@
 # CQRS + Mediator Standards
 
-> Pure technology (domain-agnostic) — domain additions in [[cqrs.domain]]. NON-NEGOTIABLE. Commands: `/aw-spec-plan`, `/aw-spec-tasks`, `/aw-spec-implement`.
+> Pure technology (domain-agnostic) — domain additions in [[cqrs.domain]]. NON-NEGOTIABLE. Commands: `/aw-spec-design`.
 
 ## Command / query patterns
 

package/assets/docs/architecture/eventing.md

@@ -1,6 +1,6 @@
 # Eventing Standards
 
-> Pure technology (domain-agnostic) — domain additions in [[eventing.domain]]. Commands: `/aw-spec-plan`, `/aw-spec-tasks`, `/aw-spec-implement`.
+> Pure technology (domain-agnostic) — domain additions in [[eventing.domain]]. Commands: `/aw-spec-design`.
 
 ## Domain events
 

package/assets/docs/architecture/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-tasks`, `/aw-spec-implement`.
+> Pure technology (domain-agnostic) — domain additions (Interop adapters, conformance tests, fixtures) in [[folder-structure.domain]]. NON-NEGOTIABLE. Commands: `/aw-spec-design`, `/aw-spec-implement`, `/aw-spec-implement-delta`.
 >
 > Replace `<SampleProjectName>` with the project name (e.g. `Acme.Billing`).
 

package/assets/docs/architecture/modular-monolith.md

@@ -1,6 +1,6 @@
 # Modular Monolith Standards
 
-> Pure technology (domain-agnostic). NON-NEGOTIABLE where marked. Commands: `/aw-spec-plan`, `/aw-spec-tasks`, `/aw-spec-implement`.
+> Pure technology (domain-agnostic). NON-NEGOTIABLE where marked. Commands: `/aw-spec-design`.
 
 ## Module boundaries
 

package/assets/docs/architecture/persistence.md

@@ -1,6 +1,6 @@
 # Persistence Standards
 
-> Pure technology (domain-agnostic) — domain additions in [[persistence.domain]]. NON-NEGOTIABLE where marked. Commands: `/aw-spec-plan`, `/aw-spec-tasks`, `/aw-spec-implement`.
+> Pure technology (domain-agnostic) — domain additions in [[persistence.domain]]. NON-NEGOTIABLE where marked. Commands: `/aw-spec-design`, `/aw-spec-run`.
 
 ## EF Core conventions
 

package/assets/docs/architecture/testing.md

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

package/assets/docs/architecture/vertical-slices.md

@@ -1,6 +1,6 @@
 # Vertical Slice Standards
 
-> Pure technology (domain-agnostic) — domain additions in [[vertical-slices.domain]]. Commands: `/aw-spec-plan`, `/aw-spec-tasks`, `/aw-spec-implement`.
+> Pure technology (domain-agnostic) — domain additions in [[vertical-slices.domain]]. Commands: `/aw-spec-design`.
 
 ## Feature organization
 

package/assets/docs/components/Email/README.md

@@ -2,7 +2,7 @@
 
 > Pure technology (domain-agnostic). Reference sheet for the Email messaging component.
 > To wire it into a project, follow the agent runbook in [integration.md](./integration.md).
-> Commands: `/aw-spec-plan`, `/aw-spec-tasks`, `/aw-spec-implement`.
+> Commands: `/aw-spec-add-component`.
 
 ## What it is
 

package/assets/docs/components/Jobs/README.md

@@ -2,7 +2,7 @@
 
 > Pure technology (domain-agnostic). Reference sheet for the background-job component.
 > To wire it into a project, follow the agent runbook in [integration.md](./integration.md).
-> Commands: `/aw-spec-plan`, `/aw-spec-tasks`, `/aw-spec-implement`.
+> Commands: `/aw-spec-add-component`.
 
 ## What it is
 

package/assets/docs/components/QrGenerator/README.md

@@ -2,7 +2,7 @@
 
 > Pure technology (domain-agnostic). Reference sheet for the QR-code generation component.
 > To wire it into a project, follow the agent runbook in [integration.md](./integration.md).
-> Commands: `/aw-spec-plan`, `/aw-spec-tasks`, `/aw-spec-implement`.
+> Commands: `/aw-spec-add-component`.
 
 ## What it is
 

package/assets/docs/components/README.md

@@ -3,7 +3,7 @@
 > Pure technology (domain-agnostic). These docs are the authoritative integration contracts for
 > opt-in AppWeaver framework components. An AI coding agent (or a human) MUST read the relevant
 > component folder **before** wiring the component into a project.
-> Commands: `/aw-spec-plan`, `/aw-spec-tasks`, `/aw-spec-implement`.
+> Commands: `/aw-spec-add-component`.
 
 Each component is an optional NuGet-distributed building block that plugs into the standard
 AppWeaver layout (see [[folder-structure]]) via the same **provider/registry** registration

package/assets/docs/domain/domain-driven-design.md

@@ -1,6 +1,6 @@
 # Domain-Driven Design Standards (Tactical Patterns)
 
-> Pure technology (domain-agnostic) — generic DDD tactical patterns; the business model, canonical aggregates + invariants are in [[domain-driven-design.domain]]. NON-NEGOTIABLE. Commands: `/aw-spec-specify`, `/aw-spec-plan`, `/aw-spec-tasks`, `/aw-spec-implement`.
+> Pure technology (domain-agnostic) — generic DDD tactical patterns; the business model, canonical aggregates + invariants are in [[domain-driven-design.domain]]. NON-NEGOTIABLE. Commands: `/aw-spec-specify`.
 
 > Note: this file lives under `domain/` because DDD is a domain-modeling methodology, but the
 > rules here are domain-agnostic and reusable. The business-specific model is in the companion

package/assets/docs/domainspecs/healthcare/api-versioning.domain.md

@@ -1,6 +1,6 @@
 # API Versioning — Healthcare Domain Addenda (FHIR)
 
-> Technology base: [[api-versioning]]. Commands: `/aw-spec-plan`, `/aw-spec-tasks`, `/aw-spec-implement`.
+> Technology base: [[api-versioning]]. Commands: `/aw-spec-specify`, `/aw-spec-gate`.
 
 ## FHIR versioning
 - R4 default; R5 is **additive** under a versioned path (`/fhir/R5/...`).

package/assets/docs/domainspecs/healthcare/auditing.domain.md

@@ -1,29 +1,97 @@
 # Auditing — Healthcare Domain Addenda (ATNA)
 
-> Technology base: [[auditing]]. NON-NEGOTIABLE. Commands: `/aw-spec-plan`, `/aw-spec-tasks`, `/aw-spec-implement`.
+> Technology base: [[auditing]]. NON-NEGOTIABLE. Consumed by `/aw-spec-specify` (LIFTS the
+> auditing requirement into the spec) and `/aw-spec-gate` (VALIDATES the spec/design realise it).
+> `/aw-spec-design` and `/aw-spec-implement` never load this file — auditing reaches them through
+> the spec's **declared audit level per aggregate**, and the enablement mechanics live in the
+> technical base [[auditing]]. Keep this file technology-agnostic (levels + rules, **no code**).
 
-## Setup
-- Auditing is **MANDATORY** for every PHI-bearing aggregate.
-- Enable via `.EnableAdvancedAuditing()` + `AddAuditing(... UseEfCoreAuditing(...).UseAppWeaverDataStore())`.
-- Audit tables: shared `AppWeaver.DataStore`, schema `Auditing`, prefix `Audit_`.
-- A **PHI-access-audit** pipeline behavior runs on every mediator request (see [[cqrs.domain]]).
+## Two auditing levels (framework-supported)
 
-## Record (immutable)
-Every PHI read/mutation, authentication, consent change, export, and break-the-glass MUST emit:
-```
-{ timestamp, subjectId, subjectRole, patientId, action, resourceType,
-  resourceId, outcome, sourceIp, correlationId, reason }
-```
+AppWeaver auditing has exactly **two levels** for entity state-change auditing; the framework's
+audit interceptor populates every audit field automatically (handlers NEVER assign audit fields):
 
-## Audit-mandatory operations
-Every PHI read/write; every authentication; every consent change; every export (`$export`, bulk/report download); every break-the-glass; every privileged admin action; every IdP/role change. See [[authorization.domain]].
+| Level | Captures | Depth |
+|---|---|---|
+| **Basic** | who/when lifecycle — created / modified / (soft-)deleted, by whom and when; one audit entry per aggregate root per save (who · action · resource type · resource id · timestamp · correlation) | entity-level (Created/Updated/Deleted) — **no** before/after values |
+| **Advanced** | everything Basic captures **plus field-level before/after** — each changed property's previous → new value | entity-level **+ property-level previous/new value** |
+
+- **Advanced is REQUIRED whenever the spec asks for "previous value / new value"** — before/after
+  values exist ONLY at the Advanced tier.
+- Child entities fold their changes into the owning aggregate root's audit entry.
+- Beyond state-change auditing, healthcare additionally requires **PHI access (read) auditing** —
+  a separate mandatory concern (see below), not one of the two write-levels.
+
+> Code realisation — marker interfaces (Basic = `IAuditedObject` / `IFullAuditedObject`; Advanced =
+> `+ IFieldAudited`), the one-time composition, and the audit query API — lives in the technical
+> base. See [[auditing]]; `/aw-spec-design` and `/aw-spec-implement` get the HOW from there.
+
+## Aggregate assignment rule (how specify decides the level)
+
+`/aw-spec-specify` MUST assign an audit level to every aggregate it models and LIFT it into the
+spec as an explicit, developer-editable declaration:
+
+- Every **PHI-bearing main aggregate** of the requirement → **Advanced** (regulated PHI change
+  history requires field-level before/after).
+- **Supporting aggregates** (collaborating/referenced roots, no PHI) → **Basic** by default.
+- A developer MAY raise or lower a level afterwards by editing the spec declaration — the level is
+  a **spec** decision, never a design or implementation one. `/aw-spec-design` then follows the
+  declared level.
+
+Lift it as one line the gate can check, e.g. under Constraints:
+
+> **CN-0xx**: Auditing level — `<PHIAggregate>` uses **Advanced** (field-level before/after)
+> auditing; `<SupportingAggregate…>` use **Basic** (lifecycle) auditing; all PHI access and change
+> is audit-mandatory and append-only. — lifted from auditing.domain.
+
+Declare the **level** — do NOT enumerate the audit record's field shape in the spec (next section).
+
+## PHI access auditing (ATNA — mandatory)
+
+Distinct from state-change auditing: every PHI **read/access**, authentication, consent change,
+export, and break-the-glass MUST emit an audit event (a PHI-access-audit pipeline behavior runs on
+every mediator request). Audit-mandatory triggers:
+
+- Every PHI **read** and **write**; every authentication; every consent change; every export
+  (`$export`, bulk / report download); every **break-the-glass**; every privileged admin action;
+  every IdP / role change. See [[authorization.domain]].
+
+## Spec-required vs framework-emitted (what the gate checks)
+
+The audit record's field shape is **framework-emitted** — the interceptor populates it; it is NOT
+spec-authored content. Fields the platform always supplies:
+
+- `timestamp`, acting `subjectId` (user), `action`, `resourceType`, `resourceId`, `sourceIp`,
+  `correlationId`, `tenantId`, and the physical record layout.
+
+Split for the gate:
+
+- **Spec-required** (specify lifts it; the gate checks the spec + design carry it): the **audit
+  level per aggregate**; that PHI access/change is **audit-mandatory** and **append-only**; and the
+  ATNA business capture — **patientId** (whose PHI), **subjectRole**, **outcome** (grant/deny),
+  **reason** (break-the-glass justification), and **Previous Value / New Value** (Advanced).
+- **Framework-emitted** (NEVER a spec/design gap — always populated by the platform): the fields
+  listed above. The gate MUST NOT raise a LIFT-FAILURE for them; they are guaranteed by the
+  framework, not authored in the spec.
+
+## Queryable audit (framework-provided)
+
+The audit store is queryable out of the box (by resource identity, by user/subject, by tenant, and
+by action/time with paging — see [[auditing]]). A spec "queryable audit trail for compliance /
+ATNA review" success criterion is therefore satisfied by the framework's audit query API; design
+references it and does **NOT** need a bespoke audit read port/model.
 
 ## Retention & format
-- **Append-only**; retained **>= 6 years**; exportable as FHIR `AuditEvent` (see [[domain-driven-design.domain]], [[persistence.domain]]).
+
+- **Append-only**; retained **>= 6 years**; exportable as FHIR `AuditEvent` (see
+  [[domain-driven-design.domain]], [[persistence.domain]]).
 
 ## Telemetry & breach
-- **PHI, full SSN, payment-card numbers, government IDs MUST NEVER** appear in logs, metric labels, exception messages, or traces (see [[data-classification.domain]]).
-- Anomalous PHI access (volume spikes, off-hours mass reads, repeated denials) emits **Critical** alerts (see [[hipaa]]).
+
+- **PHI, full SSN, payment-card numbers, government IDs MUST NEVER** appear in logs, metric labels,
+  exception messages, or traces (see [[data-classification.domain]]).
+- Anomalous PHI access (volume spikes, off-hours mass reads, repeated denials) emits **Critical**
+  alerts (see [[hipaa]]).
 
 ## Related
-- [[auditing]] · [[hipaa]] · [[data-classification.domain]] · [[authorization.domain]] · [[consent]] · [[fhir]] · [[cqrs.domain]] · [[persistence.domain]]
+- [[auditing]] · [[hipaa]] · [[data-classification.domain]] · [[authorization.domain]] · [[consent]] · [[fhir]] · [[cqrs.domain]] · [[persistence.domain]] · [[domain-driven-design.domain]]

package/assets/docs/domainspecs/healthcare/authorization.domain.md

@@ -1,6 +1,6 @@
 # Authorization — Healthcare Domain Addenda
 
-> Technology base: [[authorization]]. Commands: `/aw-spec-plan`, `/aw-spec-tasks`, `/aw-spec-implement`.
+> Technology base: [[authorization]]. Commands: `/aw-spec-constitution`, `/aw-spec-specify`, `/aw-spec-gate`.
 
 ## Roles
 `SystemAdmin`, `ComplianceOfficer`, `Physician`, `Nurse`, `LabTechnician`, `Radiologist`, `Pharmacist`, `BillingClerk`, `FrontDesk`, `Patient`, `ExternalSystem`, `ResearchAnalyst` (de-identified scope only). Per-route matrix: `docs/security/authorization-matrix.md`.

package/assets/docs/domainspecs/healthcare/clinical-terms.md

@@ -1,6 +1,6 @@
 # Glossary — Clinical Terms
 
-> Ubiquitous language for clinical aggregates. Commands: `/aw-spec-specify`, `/aw-spec-clarify`, `/aw-spec-plan`. See [[domain-driven-design.domain]] (modeling) + [[terminology]] (coding).
+> Ubiquitous language for clinical aggregates. Commands: `/aw-spec-constitution`, `/aw-spec-specify`. See [[domain-driven-design.domain]] (modeling) + [[terminology]] (coding).
 
 | Term | Definition |
 |---|---|

package/assets/docs/domainspecs/healthcare/coding-standards.domain.md

@@ -1,6 +1,6 @@
 # Coding Standards — Healthcare Domain Addenda
 
-> Technology base: [[coding-standards]]. Commands: `/aw-spec-plan`, `/aw-spec-tasks`, `/aw-spec-implement`.
+> Technology base: [[coding-standards]]. Commands: `/aw-spec-gate`.
 
 ## Coded value objects
 - Follow the FHIR pattern: `Codeable`, `Coding`, `Quantity`, `Period`, `Range`, `Ratio`, `Identifier`, `HumanName`, `Address`, `ContactPoint` (see [[terminology]]).

package/assets/docs/domainspecs/healthcare/comandrulemap.md

@@ -1,166 +1,100 @@
 # Healthcare Domain — Command → Rule-File Map
 
-Per-AW-Spec-command list of the **healthcare domain** rule files in this folder.
-Technology standards already auto-load inside each command; the files below are the
-domain-specific ones to load **in addition** for a healthcare project.
+Per-command list of the **healthcare domain** rule files loaded (via `resolve-domain`
++ the `domain-select` module, into the sticky standards set) for the spec-anchored
+orchestrator pipeline.
 
-- All paths are workspace-relative and live in this folder: `docs/domainspecs/healthcare/`.
-- A skill can read this file and load every path under the matching command heading.
-- This file is the **canonical source** for the healthcare domain mapping;
-  `/aw-spec-select-domain` selects this folder as active.
+**The model (see `.aw-spec/RULE-PARTITION.md`):** domain files feed
+only three consumers — **specify** (authors them into the spec as FR/BR/CN-/DC-/IC-),
+**constitution** (the domain principles), and the **gates** (conformance checklist).
+**design** and **implement** load **NO** domain file — the domain reaches them solely
+through the spec/design (as CN-/DC-/IC- ids).
+
+- All paths are workspace-relative and live in `docs/domainspecs/healthcare/`.
+- `resolve-domain --command <name>` collects the `- ` bullets under `## /<name>`.
+- This file is the **canonical source** for the healthcare domain mapping; `/aw-spec-orch
+  select-domain` selects this folder as active.
 
 ---
 
 ## /aw-spec-constitution
-- docs/domainspecs/healthcare/domain-requirements.md
-- docs/domainspecs/healthcare/ai-rules.domain.md
-
-## /aw-spec-specify
+<!-- Domain identity/regulatory/interop sources that become domain principles XVI+ in
+     constitution.domain.md (authored from docs/healthcare-constitution.my-ref.md + these). -->
 - docs/domainspecs/healthcare/domain-requirements.md
 - docs/domainspecs/healthcare/clinical-terms.md
-- docs/domainspecs/healthcare/integration-terms.md
-- docs/domainspecs/healthcare/domain-driven-design.domain.md
+- docs/domainspecs/healthcare/terminology.md
+- docs/domainspecs/healthcare/consent.md
+- docs/domainspecs/healthcare/hipaa.md
 - docs/domainspecs/healthcare/fhir.md
 - docs/domainspecs/healthcare/hl7.md
 - docs/domainspecs/healthcare/dicom.md
-- docs/domainspecs/healthcare/terminology.md
-- docs/domainspecs/healthcare/hipaa.md
-- docs/domainspecs/healthcare/consent.md
 - docs/domainspecs/healthcare/data-classification.domain.md
+- docs/domainspecs/healthcare/auditing.domain.md
+- docs/domainspecs/healthcare/authorization.domain.md
+- docs/domainspecs/healthcare/zero-trust.domain.md
 - docs/domainspecs/healthcare/ai-rules.domain.md
 
-## /aw-spec-clarify
+## /aw-spec-specify
+<!-- The FULL domain set. Specify models the domain COMPLETELY and LIFTS the constraint
+     overlays into the spec's CN-/DC-/IC- sections (design/implement never see these files). -->
+- docs/domainspecs/healthcare/domain-requirements.md
 - docs/domainspecs/healthcare/domain-driven-design.domain.md
-- docs/domainspecs/healthcare/hl7.md
-- docs/domainspecs/healthcare/hipaa.md
-- docs/domainspecs/healthcare/consent.md
 - docs/domainspecs/healthcare/clinical-terms.md
+- docs/domainspecs/healthcare/terminology.md
 - docs/domainspecs/healthcare/integration-terms.md
-
-## /aw-spec-plan
-- docs/domainspecs/healthcare/folder-structure.domain.md
-- docs/domainspecs/healthcare/cqrs.domain.md
-- docs/domainspecs/healthcare/vertical-slices.domain.md
-- docs/domainspecs/healthcare/persistence.domain.md
-- docs/domainspecs/healthcare/testing.domain.md
-- docs/domainspecs/healthcare/eventing.domain.md
-- docs/domainspecs/healthcare/domain-driven-design.domain.md
+- docs/domainspecs/healthcare/consent.md
+- docs/domainspecs/healthcare/hipaa.md
 - docs/domainspecs/healthcare/fhir.md
 - docs/domainspecs/healthcare/hl7.md
 - docs/domainspecs/healthcare/dicom.md
-- docs/domainspecs/healthcare/terminology.md
-- docs/domainspecs/healthcare/hipaa.md
-- docs/domainspecs/healthcare/consent.md
-- docs/domainspecs/healthcare/zero-trust.domain.md
-- docs/domainspecs/healthcare/authorization.domain.md
-- docs/domainspecs/healthcare/auditing.domain.md
 - docs/domainspecs/healthcare/data-classification.domain.md
-- docs/domainspecs/healthcare/coding-standards.domain.md
-- docs/domainspecs/healthcare/dependency-policy.domain.md
-- docs/domainspecs/healthcare/api-versioning.domain.md
-- docs/domainspecs/healthcare/ai-rules.domain.md
-
-## /aw-spec-tasks
-- docs/domainspecs/healthcare/folder-structure.domain.md
-- docs/domainspecs/healthcare/vertical-slices.domain.md
-- docs/domainspecs/healthcare/cqrs.domain.md
 - docs/domainspecs/healthcare/persistence.domain.md
-- docs/domainspecs/healthcare/testing.domain.md
-- docs/domainspecs/healthcare/eventing.domain.md
-- docs/domainspecs/healthcare/domain-driven-design.domain.md
-- docs/domainspecs/healthcare/fhir.md
-- docs/domainspecs/healthcare/hl7.md
-- docs/domainspecs/healthcare/authorization.domain.md
-- docs/domainspecs/healthcare/auditing.domain.md
-- docs/domainspecs/healthcare/coding-standards.domain.md
-- docs/domainspecs/healthcare/ai-rules.domain.md
-
-## /aw-spec-analyze
-- docs/domainspecs/healthcare/hl7.md
-- docs/domainspecs/healthcare/hipaa.md
-- docs/domainspecs/healthcare/auditing.domain.md
-- docs/domainspecs/healthcare/coding-standards.domain.md
-- docs/domainspecs/healthcare/ai-rules.domain.md
-
-## /aw-spec-implement
-- docs/domainspecs/healthcare/folder-structure.domain.md
-- docs/domainspecs/healthcare/vertical-slices.domain.md
 - docs/domainspecs/healthcare/cqrs.domain.md
-- docs/domainspecs/healthcare/persistence.domain.md
-- docs/domainspecs/healthcare/testing.domain.md
 - docs/domainspecs/healthcare/eventing.domain.md
-- docs/domainspecs/healthcare/domain-driven-design.domain.md
-- docs/domainspecs/healthcare/fhir.md
-- docs/domainspecs/healthcare/hl7.md
-- docs/domainspecs/healthcare/terminology.md
-- docs/domainspecs/healthcare/hipaa.md
-- docs/domainspecs/healthcare/consent.md
-- docs/domainspecs/healthcare/authorization.domain.md
 - docs/domainspecs/healthcare/auditing.domain.md
-- docs/domainspecs/healthcare/data-classification.domain.md
+- docs/domainspecs/healthcare/authorization.domain.md
 - docs/domainspecs/healthcare/zero-trust.domain.md
-- docs/domainspecs/healthcare/coding-standards.domain.md
-- docs/domainspecs/healthcare/dependency-policy.domain.md
 - docs/domainspecs/healthcare/api-versioning.domain.md
-- docs/domainspecs/healthcare/ai-rules.domain.md
+- docs/domainspecs/healthcare/vertical-slices.domain.md
 
-## /aw-spec-fast-implement
+## /aw-spec-design
+_None — design loads no domain file. Domain reaches design only through the spec (BR-/CN-/DC-/IC-)._
 
-> Fast path that collapses plan + tasks + analyze + implement into one pass. This list is the
-> **deduplicated union** of those four commands' headings above (here, equal to `/aw-spec-plan`).
-> Load it **once** for the whole pass — do not reload per phase.
+## /aw-spec-implement
+_None — implement loads no domain file. Domain reaches implement only through design.md. Framework
+components are added separately via `/aw-spec-orch add-component`._
 
-- docs/domainspecs/healthcare/folder-structure.domain.md
-- docs/domainspecs/healthcare/cqrs.domain.md
-- docs/domainspecs/healthcare/vertical-slices.domain.md
+## /aw-spec-gate
+<!-- Conformance checklist for the gates (analyze-design · analyze-slice): the domain-derived
+     constraints design/implement were NOT given as authoring input, VALIDATED against the
+     output. Domain re-enters here as a check, never as authoring input. -->
 - docs/domainspecs/healthcare/persistence.domain.md
-- docs/domainspecs/healthcare/testing.domain.md
+- docs/domainspecs/healthcare/cqrs.domain.md
 - docs/domainspecs/healthcare/eventing.domain.md
-- docs/domainspecs/healthcare/domain-driven-design.domain.md
-- docs/domainspecs/healthcare/fhir.md
-- docs/domainspecs/healthcare/hl7.md
-- docs/domainspecs/healthcare/dicom.md
-- docs/domainspecs/healthcare/terminology.md
-- docs/domainspecs/healthcare/hipaa.md
-- docs/domainspecs/healthcare/consent.md
-- docs/domainspecs/healthcare/zero-trust.domain.md
-- docs/domainspecs/healthcare/authorization.domain.md
 - docs/domainspecs/healthcare/auditing.domain.md
+- docs/domainspecs/healthcare/authorization.domain.md
+- docs/domainspecs/healthcare/zero-trust.domain.md
 - docs/domainspecs/healthcare/data-classification.domain.md
-- docs/domainspecs/healthcare/coding-standards.domain.md
-- docs/domainspecs/healthcare/dependency-policy.domain.md
 - docs/domainspecs/healthcare/api-versioning.domain.md
-- docs/domainspecs/healthcare/ai-rules.domain.md
-
-## /aw-spec-minimal-implementation
-
-> Single-step set for healthcare — the **per-domain knob** (edit freely). `/aw-spec-minimal-implementation`
-> loads these to interpret and implement the requirement in one pass; genuinely-external runtime
-> services (terminology server, FHIR endpoint) are stubbed behind ports. For an audited build use
-> `## /aw-spec-fast-implement`.
-
-- docs/domainspecs/healthcare/clinical-terms.md
-- docs/domainspecs/healthcare/domain-driven-design.domain.md
-- docs/domainspecs/healthcare/folder-structure.domain.md
 - docs/domainspecs/healthcare/vertical-slices.domain.md
-- docs/domainspecs/healthcare/fhir.md
-- docs/domainspecs/healthcare/hl7.md
-- docs/domainspecs/healthcare/terminology.md
-- docs/domainspecs/healthcare/hipaa.md
+- docs/domainspecs/healthcare/folder-structure.domain.md
+- docs/domainspecs/healthcare/coding-standards.domain.md
+- docs/domainspecs/healthcare/dependency-policy.domain.md
+- docs/domainspecs/healthcare/testing.domain.md
 - docs/domainspecs/healthcare/ai-rules.domain.md
 
 ---
 
-## Quick reference (command → file count)
+## Quick reference (command → domain file count)
+
+| Command | Domain rule files | Role |
+|---|---|---|
+| /aw-spec-constitution | 13 | domain principles (XVI+) |
+| /aw-spec-specify | 19 | author into spec (lift → CN-/DC-/IC-) |
+| /aw-spec-design | 0 | none — spec is the only domain input |
+| /aw-spec-implement | 0 | none — design is the only domain input |
+| /aw-spec-gate | 14 | conformance checklist (validate, don't author) |
 
-| Command | Domain rule files |
-|---|---|
-| /aw-spec-constitution | 2 |
-| /aw-spec-specify | 12 |
-| /aw-spec-clarify | 6 |
-| /aw-spec-plan | 21 |
-| /aw-spec-tasks | 13 |
-| /aw-spec-analyze | 5 |
-| /aw-spec-implement | 20 |
-| /aw-spec-fast-implement | 21 |
-| /aw-spec-minimal-implementation | 9 |
+> Retired in the orchestrator pipeline: `/aw-spec-plan`, `/aw-spec-tasks`, `/aw-spec-taskplan`,
+> `/aw-spec-clarify`, `/aw-spec-analyze` (clarify folds into specify; plan/tasks into design). The
+> collapsed tiers `/aw-spec-fast-implement` and `/aw-spec-minimal-implementation` are pending a ruling.

package/assets/docs/domainspecs/healthcare/commandtechrulemap.md

@@ -0,0 +1,119 @@
+# Healthcare Domain — Command → Technical-Rule-File Map
+
+Per-command list of the **technical** rule files loaded (via `resolve-tech` + the
+`tech-select` module, into the sticky standards set) for the spec-anchored
+orchestrator pipeline. This is the technical counterpart of `comandrulemap.md`
+(which maps the DOMAIN rule files).
+
+**The model:** the technical rule files (the `docs/architecture` · `docs/security` ·
+`docs/interop` · `docs/governance` set that used to be HARDCODED in each workflow's
+`standards:` block) are now 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 technical rule files (domain-agnostic docs/…).
+- `resolve-tech --command <name>` collects the `- ` bullets under `## /<name>`.
+- This file is the **canonical technical mapping** for the healthcare domain; it is
+  selected whenever healthcare is the active domain (`.aw-spec/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. Specify is the domain phase: the single technical input it
+     may take is a domain-agnostic way of MODELLING (DDD tactical patterns), 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 comandrulemap. -->
+- docs/domain/domain-driven-design.md
+
+## /aw-spec-design
+<!-- The technical/architecture rule files the design author works from (alongside the
+     spec and constitution.technical.md). NO domain file here — domain reaches design
+     only as spec ids (BR-/CN-/DC-/IC-). -->
+- docs/architecture/clean-architecture.md
+- docs/architecture/cqrs.md
+- docs/architecture/eventing.md
+- docs/architecture/modular-monolith.md
+- docs/architecture/vertical-slices.md
+- docs/architecture/persistence.md
+- docs/architecture/folder-structure.md
+- docs/architecture/testing.md
+- docs/governance/api-versioning.md
+- docs/security/zero-trust.md
+- docs/security/authorization.md
+- docs/security/authorization-matrix.md
+- docs/security/auditing.md
+- docs/security/data-classification.md
+- docs/interop/ihe-conformance.md
+
+## /aw-spec-implement
+<!-- The FRAMEWORK / code-generation rule files the code generator builds against
+     (alongside design.md and constitution.technical.md). NO domain file — domain
+     reaches implement only through design.md. clean-architecture/cqrs are design
+     concerns; component wiring is a separate /aw-spec-orch add-component step. -->
+- docs/governance/coding-standards.md
+- docs/governance/dependency-policy.md
+- docs/architecture/folder-structure.md
+- docs/architecture/testing.md
+- docs/VerticalSlice/PACKAGING.md
+
+## /aw-spec-implement-delta
+<!-- The CR analog of implement — same FRAMEWORK / code-generation set (HOW to build).
+     The delta's code is generated against the master design.md + delta-design.md; no
+     domain file (domain reached the delta via delta-spec → delta-design). -->
+- docs/governance/coding-standards.md
+- docs/governance/dependency-policy.md
+- docs/architecture/folder-structure.md
+- docs/architecture/testing.md
+- docs/VerticalSlice/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. NO domain file (build loads
+     domain rules separately via domain-select) and no constitution.technical here. -->
+- docs/architecture/clean-architecture.md
+- docs/governance/coding-standards.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. -->
+- docs/architecture/testing.md
+- docs/governance/coding-standards.md
+
+## /aw-spec-constitution
+<!-- The technology-constitution base the TECHNICAL half of the split constitution
+     ratifies into constitution.technical.md. 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. -->
+- docs/technology-constitution.md
+
+## /aw-spec-run
+<!-- Execution / data migration: the persistence rules the migration step generates against.
+     NO domain file; run does not reference constitution.technical.md. -->
+- docs/architecture/persistence.md
+
+---
+
+## Quick reference (command → technical file count)
+
+| Command | Technical rule files | Role |
+|---|---|---|
+| /aw-spec-specify | 1 | the modelling methodology (DDD) the domain model is expressed in — no technology |
+| /aw-spec-design | 15 | architecture/security/interop the design author mediates the spec against |
+| /aw-spec-implement | 5 | governance/architecture the code generator builds against (from design.md) |
+| /aw-spec-implement-delta | 5 | same code-generation set, scoped to the open change's delta-design |
+| /aw-spec-build | 2 | layering + coding rules the compile-fixer respects |
+| /aw-spec-analyze-slice | 2 | testing + coding rules the design↔code gate validates against |
+| /aw-spec-constitution | 1 | the technology-constitution base the technical half ratifies |
+| /aw-spec-run | 1 | persistence rules the execution / data-migration step generates against |
+
+> All migrated workflows are on this map. The conformance-gate workflows **analyze-design**
+> and **analyze-delta-design** are intentionally NOT here — they validate design/delta
+> against the spec + DOMAIN gate overlays only (comandrulemap `## /aw-spec-gate`), with no
+> technical gate checklist.

package/assets/docs/domainspecs/healthcare/consent.md

@@ -1,6 +1,6 @@
 # Consent Standards
 
-> NON-NEGOTIABLE. Commands: `/aw-spec-specify`, `/aw-spec-plan`, `/aw-spec-tasks`, `/aw-spec-implement`.
+> NON-NEGOTIABLE. Commands: `/aw-spec-constitution`, `/aw-spec-specify`.
 
 ## First-class aggregate
 - Consent is a **first-class aggregate** (Patients module). A **withdrawn consent MUST block downstream PHI disclosure** for the purpose-of-use **immediately**; state changes emit `ConsentChangedEvent` (see [[eventing]]).

package/assets/docs/domainspecs/healthcare/cqrs.domain.md

@@ -1,6 +1,6 @@
 # CQRS — Healthcare Domain Addenda
 
-> Technology base: [[cqrs]]. Commands: `/aw-spec-plan`, `/aw-spec-tasks`, `/aw-spec-implement`.
+> Technology base: [[cqrs]]. Commands: `/aw-spec-specify`, `/aw-spec-gate`.
 
 ## Pipeline
 - Append a **PHI-access-audit behavior** to the mediator pipeline (beyond generic logging + FluentValidation): emit an audit record for every command/query touching PHI (see [[auditing.domain]]).