aw-spec-cli 0.1.32 → 0.1.34

package/assets/guardrails/project-specific/tech-rule-bindings.md

@@ -36,7 +36,8 @@ NOT listed here — every consumer refers to it directly, as-is.
   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
+  on disk loads nothing in its place, and the run ends with a warning naming it; so does a
+  placeholder the kit does not know. 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
@@ -45,7 +46,8 @@ NOT listed here — every consumer refers to it directly, as-is.
 - 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).
+  universal `ai-rules.md` seed + `constitution.technical.md`, referred to directly), and its
+  run ends with a warning — a misspelled heading reads the same as a missing one.
 - `## /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.
@@ -67,17 +69,19 @@ NOT listed here — every consumer refers to it directly, as-is.
         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-backend 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. -->
+     ⚠ The ux/ files sit in guardrails/methodology/ — rules that vary by neither stack nor
+     industry — and are TECHNICAL-tier inputs: a file's tier is the map that lists it, not the
+     folder it lives in. An industry corpus may carry its own variant of them;
+     guardrails/sample-healthcare/ maps guardrails/domain/healthcare/ux/ in their place.
+     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/{{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
-- guardrails/domain/healthcare/ux/content-design.md
+- guardrails/methodology/ux/journey-mapping.md
+- guardrails/methodology/ux/interaction-states.md
+- guardrails/methodology/ux/accessibility-standards.md
+- guardrails/methodology/ux/content-design.md
 
 ## /aw-spec-plan-backend
 <!-- The technical/architecture rule files the design author works from (alongside the
@@ -97,7 +101,6 @@ NOT listed here — every consumer refers to it directly, as-is.
 - 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/{{backend_stack}}/examples/clean-architecture.md
 - guardrails/technology/{{backend_stack}}/examples/cqrs.md
 - guardrails/technology/{{backend_stack}}/examples/eventing.md
@@ -278,7 +281,7 @@ NOT listed here — every consumer refers to it directly, as-is.
 | 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-backend | 24 | architecture/security/interop the design author mediates the spec against, each with its example |
+| /aw-spec-plan-backend | 23 | architecture and security the design author mediates the spec against, each with its example |
 | /aw-spec-plan-frontend | 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-backend | 6 | governance/architecture the SERVICE lane builds against (from backend-plan.md), both paths |
 | /aw-spec-implement-frontend | 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 |

package/assets/guardrails/sample-healthcare/domain/domain-requirements.md

@@ -0,0 +1,58 @@
+# DOMAIN REQUIREMENTS (project-specific)
+
+> Project-specific input, **authored by the project owner** and updated independently per
+> project. It is the last file in the set mapped under `## /aw-spec-constitution` in
+> `domain-rule-bindings.md`, and the only one there expected to differ between two projects on this
+> corpus; the standard industry rules beside it are shared. Its mapping is optional — a project
+> that has not authored it yet ratifies the standard set alone.
+>
+> This file holds the per-project enumeration and headline profiles. Detailed domain *rules*
+> are expanded in the sibling files in this folder.
+>
+> Replace `<SampleProjectName>` and the bounded-context list below for a new project.
+
+=====================================================================
+[DOMAIN: Bounded Contexts / Modules]
+=====================================================================
+- Patients — aggregates: Patient (master patient index), Consent, RelatedPerson; cross-references via PIX/PDQ.
+- Appointments — aggregates: Appointment, Slot, Schedule, Waitlist.
+- Encounters — aggregates: Encounter (inpatient, outpatient, emergency), Admission, Transfer, Discharge.
+- EMR — aggregates: ClinicalNote, ProblemList, AllergyIntolerance, MedicationStatement, Observation (vitals, social history), Immunization, CarePlan, ServiceRequest, Procedure.
+- Radiology — aggregates: ImagingOrder, ImagingStudy (DICOM metadata), DiagnosticReport (radiology); pixel data lives in PACS/VNA.
+- Lab — aggregates: LabOrder, Specimen, Observation (lab result), DiagnosticReport (lab).
+- Pharmacy — aggregates: MedicationRequest, MedicationDispense, MedicationAdministration, Formulary, ControlledSubstanceLedger.
+- Billing — aggregates: ChargeItem, Invoice, Claim, ClaimResponse, PaymentReconciliation, Account, AdjustmentEntry.
+- Insurance — aggregates: Coverage, Payer, Plan, EligibilityRequest, EligibilityResponse, PriorAuth.
+- Inventory — aggregates: InventoryItem, Lot, StockMovement, Reservation, ExpiryAlert.
+- Interoperability — aggregates: IntegrationEndpoint, MessageEnvelope (HL7v2), FhirSubscription, BulkExportJob.
+- PatientPortal — aggregates: PortalAccount (identity-bound), MessageThread, AppointmentRequest, RecordAccessRequest.
+- Identity — aggregates: Practitioner, PractitionerRole, Organization, Location, HealthcareService.
+- Auditing — aggregates: AuditRecord (append-only, ATNA + FHIR AuditEvent shape).
+- Terminology — aggregates: CodeSystem, ValueSet, ConceptMap (project-managed subsets; expansions cached from external TS).
+
+=====================================================================
+[DOMAIN: subsection pointers]
+=====================================================================
+[DOMAIN: Aggregates and Business Invariants]  -> guardrails/domain/healthcare/domain-driven-design.domain.md
+[DOMAIN: Persistence Profile]                 -> guardrails/domain/healthcare/persistence.domain.md
+[DOMAIN: Security Profile]                     -> guardrails/domain/healthcare/authorization.domain.md, guardrails/domain/healthcare/data-classification.domain.md
+[DOMAIN: Testing Profile]                      -> guardrails/domain/healthcare/testing.domain.md
+[DOMAIN: AI Policy Addenda]                    -> guardrails/domain/healthcare/ai-rules.domain.md
+[DOMAIN: Platform Topology]                    -> below
+
+=====================================================================
+[DOMAIN: Platform Topology]
+=====================================================================
+- Target runtime: Kubernetes (AKS, EKS, or on-prem). Single-region by default; multi-region active/passive for DR.
+- External dependencies (Aspire resources): PostgreSQL (primary), Redis (cache + portal session), a message broker (Azure Service Bus, AWS SQS/SNS, or RabbitMQ) for CloudEvents, an OTel collector, the configured IdP, an external Terminology Service (optional), a FHIR validator container, a PACS/VNA endpoint (DICOMweb), an HL7v2 broker (MLLP), an SMTP/SMS gateway, an object store (S3/Blob) for binaries.
+- Scale targets: P95 read latency < 200 ms at 200 RPS per module; FHIR search P95 < 500 ms; HL7v2 ingest sustains 50 messages/sec per channel.
+- Disaster recovery: RPO <= 15 minutes, RTO <= 4 hours; daily encrypted backups with 35-day retention plus monthly archive >= 7 years.
+
+=====================================================================
+[DOMAIN: Governance Overrides]
+=====================================================================
+- Principal Engineers (approvers): TBD — fill at ratification.
+- Security/Compliance Officer (mandatory approver for any PHI/security change): TBD.
+- Domain Owners (per module): TBD — assign one clinical and one technical owner per bounded context.
+- Quarterly review cadence: first business week of each quarter; security review additionally after every significant regulatory update.
+- Exception process: a time-boxed waiver via a Waiver Request issue, approved by a Principal Engineer + the Compliance Officer, with a mandatory expiry <= 90 days and a remediation plan recorded in the issue.

package/assets/guardrails/sample-healthcare/domain-rule-bindings.md

@@ -0,0 +1,138 @@
+# sample-healthcare — Command → Domain-Rule-File Map
+
+Per-command list of the **domain** rule files this project loads (via `resolve-domain`
++ the `domain-select` module, into the sticky standards set) for the spec-anchored
+orchestrator pipeline. This project draws its domain from the **healthcare** corpus.
+
+**A worked sample, not the default.** The kit ships `project-specific/` as the active project,
+and it loads no industry rule set. This folder is a complete project on the healthcare corpus:
+switch to it with `/appweaver select-domain sample-healthcare`, or copy it to
+`guardrails/<name>/` and change the `guardrails/sample-healthcare/` paths in its two maps to
+start a healthcare project of your own.
+
+**The model:** 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. The **standard industry rules** live in
+  `guardrails/domain/healthcare/` — shared, reusable by every project that maps them. The
+  one file this project authors, `domain/domain-requirements.md`, lives beside this map.
+- A mapped file that does not exist is skipped rather than failing the run, so a project
+  that has not authored its `domain-requirements.md` yet still gets the standard set; the run
+  ends with a warning naming the file. A command whose heading is absent or misspelled loads
+  nothing from this map, and its run ends with a warning saying so.
+- `resolve-domain --command <name>` collects the `- ` bullets under `## /<name>`.
+- To govern a different industry, repoint these bullets at another
+  `guardrails/domain/<industry>/` corpus — `guardrails/domain/pharma/` also ships. Nothing
+  else changes: the technical map, the workflows and the engine are untouched.
+- This file is the **canonical domain mapping** for this project; it is used whenever
+  `.appweaver/domain.json` names `sample-healthcare`.
+
+---
+
+## /aw-spec-constitution
+<!-- What the DOMAIN half ratifies into constitution.domain.md as domain principles XVI+.
+     The industry constitution first, then the STANDARD industry rules — the modelling
+     overlay the Adopted Modelling Standard section cites, identity, regulatory, interop,
+     security overlays, and the folder overlay the Domain Folder Additions section cites —
+     which every project on this corpus shares, and LAST the PROJECT-SUPPLIED
+     domain-requirements.md the project team authors. Only that last file is expected to
+     differ between two projects on the same corpus, and its mapping is OPTIONAL: the project
+     owner supplies the file, and where it is absent the set loads without it rather than
+     failing. -->
+- guardrails/domain/healthcare/domain-constitution.md
+- guardrails/domain/healthcare/domain-driven-design.domain.md
+- guardrails/domain/healthcare/clinical-terms.md
+- guardrails/domain/healthcare/terminology.md
+- guardrails/domain/healthcare/consent.md
+- guardrails/domain/healthcare/hipaa.md
+- guardrails/domain/healthcare/fhir.md
+- guardrails/domain/healthcare/hl7.md
+- guardrails/domain/healthcare/dicom.md
+- guardrails/domain/healthcare/data-classification.domain.md
+- guardrails/domain/healthcare/auditing.domain.md
+- guardrails/domain/healthcare/authorization.domain.md
+- guardrails/domain/healthcare/zero-trust.domain.md
+- guardrails/domain/healthcare/ai-rules.domain.md
+- guardrails/domain/healthcare/folder-structure.domain.md
+- guardrails/sample-healthcare/domain/domain-requirements.md
+
+## /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). -->
+- guardrails/sample-healthcare/domain/domain-requirements.md
+- guardrails/domain/healthcare/domain-driven-design.domain.md
+- guardrails/domain/healthcare/clinical-terms.md
+- guardrails/domain/healthcare/terminology.md
+- guardrails/domain/healthcare/integration-terms.md
+- guardrails/domain/healthcare/consent.md
+- guardrails/domain/healthcare/hipaa.md
+- guardrails/domain/healthcare/fhir.md
+- guardrails/domain/healthcare/hl7.md
+- guardrails/domain/healthcare/dicom.md
+- guardrails/domain/healthcare/data-classification.domain.md
+- guardrails/domain/healthcare/persistence.domain.md
+- guardrails/domain/healthcare/cqrs.domain.md
+- guardrails/domain/healthcare/eventing.domain.md
+- guardrails/domain/healthcare/auditing.domain.md
+- guardrails/domain/healthcare/authorization.domain.md
+- guardrails/domain/healthcare/zero-trust.domain.md
+- guardrails/domain/healthcare/api-versioning.domain.md
+- guardrails/domain/healthcare/vertical-slices.domain.md
+
+## /aw-spec-plan-backend
+_None — the service lane of plan loads no domain file. Domain reaches it only through the spec
+(BR-/CN-/DC-/IC-) and the context's domain-model.md._
+
+## /aw-spec-plan-frontend
+_None — the frontend lane of plan loads no domain file. Domain reaches it only through the spec
+and the context's domain-model.md._
+
+## /aw-spec-implement-backend
+_None — the service lane of implement loads no domain file. Domain reaches it only through
+backend-plan.md and the context's domain-model.md. Framework components are added separately via
+`/appweaver add-component`._
+
+## /aw-spec-implement-frontend
+_None — the frontend lane of implement loads no domain file. Domain reaches it only through
+frontend-plan.md and the context's domain-model.md._
+
+## /aw-spec-gate
+<!-- Conformance checklist for the gates (analyze-plan · 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. -->
+- guardrails/domain/healthcare/persistence.domain.md
+- guardrails/domain/healthcare/cqrs.domain.md
+- guardrails/domain/healthcare/eventing.domain.md
+- guardrails/domain/healthcare/auditing.domain.md
+- guardrails/domain/healthcare/authorization.domain.md
+- guardrails/domain/healthcare/zero-trust.domain.md
+- guardrails/domain/healthcare/data-classification.domain.md
+- guardrails/domain/healthcare/api-versioning.domain.md
+- guardrails/domain/healthcare/vertical-slices.domain.md
+- guardrails/domain/healthcare/folder-structure.domain.md
+- guardrails/domain/healthcare/coding-standards.domain.md
+- guardrails/domain/healthcare/dependency-policy.domain.md
+- guardrails/domain/healthcare/testing.domain.md
+- guardrails/domain/healthcare/ai-rules.domain.md
+
+---
+
+## Quick reference (command → domain file count)
+
+| Command | Domain rule files | Role |
+|---|---|---|
+| /aw-spec-constitution | 16 | domain principles (XVI+) — the industry constitution + standard industry rules + the project's own requirements |
+| /aw-spec-specify | 19 | author into spec (lift → CN-/DC-/IC-) |
+| /aw-spec-plan-backend | 0 | none — the spec and the domain model carry the domain |
+| /aw-spec-plan-frontend | 0 | none — the spec and the domain model carry the domain |
+| /aw-spec-implement-backend | 0 | none — backend-plan.md and the domain model carry the domain |
+| /aw-spec-implement-frontend | 0 | none — frontend-plan.md and the domain model carry the domain |
+| /aw-spec-gate | 14 | conformance checklist (validate, don't author) |
+
+> Retired in the orchestrator pipeline: the prose `/aw-spec-plan` phase, `/aw-spec-tasks`,
+> `/aw-spec-taskplan`, `/aw-spec-clarify`, `/aw-spec-analyze` (clarify folded into specify; the
+> prose plan/tasks pair into the design phase, which is now itself named `/aw-spec-plan`). The
+> collapsed tiers `/aw-spec-fast-implement` and `/aw-spec-minimal-implementation` are pending a ruling.

package/assets/guardrails/sample-healthcare/frontend/ui-requirements.md

@@ -0,0 +1,43 @@
+# UI Requirements — project-supplied
+
+> **This file is authored by the project team, not by the corpus.**
+> `ui-constitution.md` in the frontend stack's folder under `guardrails/technology/` is the
+> standard frontend rule set for that stack, reusable by every project that maps it. This file is where one project's own experience
+> decisions go.
+
+It is mapped under `## /aw-spec-ui-constitution` in `tech-rule-bindings.md`, so its
+content is ratified into `constitution.ui.md` alongside the standard rules.
+
+Keep it **domain-free**, exactly like the standard set: regulatory and terminology rules
+belong to `domain-constitution.md`, and reach the UI lane through the spec.
+
+## Declared Lane
+
+<!-- The lane id, its stack and the root it owns. Must match .appweaver/stacks.json where that
+     file exists — STACK-MISMATCH: is the failure, not a silent rewrite. -->
+
+## Design System
+
+<!-- Which design system and token set this project adopts, its version, and who may change
+     it. UX-II makes it the only source of visual truth; this says WHICH one. -->
+
+## Conformance Target
+
+<!-- The accessibility conformance level this project commits to, and the waiver authority.
+     UX-I makes it non-negotiable; this names the level. -->
+
+## Performance Budget
+
+<!-- Core Web Vitals thresholds and the per-route JavaScript budget CI enforces. UX-IX makes
+     the budget a gate; this sets the numbers. -->
+
+## Deviations from the Standard Rules
+
+<!-- Each deviation: which UX-* principle, what this project does instead, why, and who
+     approved it. Empty is the expected state for a new project. -->
+
+## Ratification Metadata
+
+- **Version:** 0.1.0
+- **Ratified:** `<YYYY-MM-DD>`
+- **Last Amended:** `<YYYY-MM-DD>`

package/assets/guardrails/sample-healthcare/service/technical-requirements.md

@@ -0,0 +1,40 @@
+# Technical Requirements — project-supplied
+
+> **This file is authored by the project team, not by the corpus.** The rules this project's
+> technical map lists live in the backend stack's folder under `guardrails/technology/` — the
+> standard set for that stack, reusable by every project that maps it. This file is where one project's own technology
+> decisions go, and it is the only technical file a second project on the same stack replaces.
+
+It is mapped under `## /aw-spec-constitution` in `tech-rule-bindings.md`, so its content
+is ratified into `constitution.technical.md` alongside the standard rules — which is what
+lets a project's own constraints become governed principles rather than folklore.
+
+Where this file is silent, the standard rules govern unchanged. Where it adds a constraint,
+say which standard rule it extends, so the ratified principle can cite both.
+
+## Project Identity
+
+<!-- Project name, mission, the bounded contexts it owns, and its deployment posture. -->
+
+## Technology Decisions
+
+<!-- The choices this project has made WITHIN the standard rules: target framework version,
+     database engine and hosting, messaging broker, identity provider, cloud target. State
+     the decision, not the tutorial. -->
+
+## Deviations from the Standard Rules
+
+<!-- Each deviation: which standard rule, what this project does instead, why, and who
+     approved it. A deviation with no approver is a defect, not a decision. Empty is the
+     expected state for a new project. -->
+
+## Project-Specific Constraints
+
+<!-- Performance budgets, availability targets, data residency, integration deadlines, or
+     anything else that must become a governed principle for THIS project. -->
+
+## Ratification Metadata
+
+- **Version:** 0.1.0
+- **Ratified:** `<YYYY-MM-DD>`
+- **Last Amended:** `<YYYY-MM-DD>`