aw-spec-cli 0.1.33 → 0.1.34

package/assets/guardrails/README.md

@@ -1,8 +1,9 @@
 # Guardrails — Index & Rule-Loading Map
 
 Rules live in **shared corpora**, keyed on the one thing that makes them differ: a technical rule
-varies by **stack**, a domain rule varies by **industry**. A **project** owns neither corpus. It
-owns two maps that say which files it loads, plus the handful of files its own team authors.
+varies by **stack**, a domain rule varies by **industry**, and a methodology rule by neither. A
+**project** owns no corpus. It owns two maps that say which files it loads, plus the handful of
+files its own team authors.
 
 ```
 guardrails/
@@ -13,30 +14,40 @@ guardrails/
 ├── domain/<industry>/        domain rules — vary by industry, never by stack
 │   ├── healthcare/
 │   └── pharma/
-├── project-specific/         the project's own rules — what it SELECTS from the corpora
-│   ├── tech-rule-bindings.md      → technology/{{backend_stack}}/ + technology/{{frontend_stack}}/
-│   ├── domain-rule-bindings.md    → domain/healthcare/
+├── methodology/<topic>/      methodology rules — vary by neither stack nor industry
+│   └── ux/                       how specify states the experience
+├── project-specific/         the ACTIVE project as shipped — maps no industry corpus
+│   ├── tech-rule-bindings.md      → technology/{{backend_stack}}/ + technology/{{frontend_stack}}/ + methodology/ux/
+│   ├── domain-rule-bindings.md    → its own domain/domain-requirements.md only
 │   ├── service/technical-requirements.md    PROJECT-SUPPLIED
 │   ├── frontend/ui-requirements.md          PROJECT-SUPPLIED
-│   └── domain/domain-requirements.md        PROJECT-SUPPLIED
+│   └── domain/domain-requirements.md        PROJECT-SUPPLIED (a blank template)
+├── sample-healthcare/        a worked project on the healthcare corpus — same shape, filled in
+│   ├── tech-rule-bindings.md      → as project-specific, with domain/healthcare/ux/ + ihe-conformance.md
+│   └── domain-rule-bindings.md    → domain/healthcare/
 └── brf-<name>/               a project `onboard` reverse-engineers from existing code
 ```
 
 **The active project is the folder `.appweaver/domain.json` names** — `project-specific` as shipped,
 and `brf-<name>` once `onboard` has run, because onboard creates that folder and writes its name
-there. No sequence selects a project. To use another one, copy `project-specific/` to a new folder
-here, change the `guardrails/project-specific/` paths inside its two maps to the new folder, and run
-the optional `/appweaver select-domain <name>` — it lists the folders here that hold a map and
-writes the one picked into `domain.json` (editing `"domain"` by hand does the same). It never
-creates a folder. Re-run `/appweaver constitution` after switching so the constitution follows.
+there. No sequence selects a project. As shipped, `project-specific` maps no industry corpus: a
+team fills in its three files and adds the corpora it uses to its two maps. `sample-healthcare` is
+the same shape filled in for the healthcare corpus — `/appweaver select-domain sample-healthcare`
+switches to it whole, and its maps show which files of an industry corpus go under which heading.
+To start a project of your own from either, copy the folder to a new one here, change the
+`guardrails/<folder>/` paths inside its two maps to the new folder, and run the optional
+`/appweaver select-domain <name>` — it lists the folders here that hold a map and writes the one
+picked into `domain.json` (editing `"domain"` by hand does the same). It never creates a folder.
+Re-run `/appweaver constitution` after switching so the constitution follows.
 `resolve-tech` and `resolve-domain` read the active project's two maps. **To change what a command
-loads, edit the map — never a workflow.** The folder names `technology/` and `domain/` are the only
-vocabulary here: a project's maps may point anywhere, in any combination.
+loads, edit the map — never a workflow.** The folder names `technology/`, `domain/` and
+`methodology/` are the only vocabulary here: a project's maps may point anywhere, in any combination.
 
 **A directory under `guardrails/` is a project only if it carries a rule map.** Both shells'
 `list-domains` enforces that, exactly as `foundations/` requires a `*.pack.txt` or `*.spec.txt` — the
-corpora `technology/` and `domain/` carry no map, so they are never taken for a project. Either map
-qualifies, because `onboard` writes the domain map several steps before the technical one.
+corpora `technology/`, `domain/` and `methodology/` carry no map, so they are never taken for a
+project. Either map qualifies, because `onboard` writes the domain map several steps before the
+technical one.
 
 **The technical map names no stack.** Every path in `project-specific/tech-rule-bindings.md` writes
 its stack directory as `{{backend_stack}}` or `{{frontend_stack}}`, resolved from the lanes in
@@ -92,19 +103,25 @@ pointer per principle, so sample code is weight without a reader.
 
 **A file's tier is set by the map that lists it, not by the folder it lives in.**
 `domain/healthcare/ihe-conformance.md` is the live proof: it sits in the domain corpus because IHE
-is a healthcare standard, and it is on the **technical** tier because `tech-rule-bindings.md`
-is what lists it. Infer the tier from the folder and the fold breaks.
+is a healthcare standard, and it is on the **technical** tier because
+`sample-healthcare/tech-rule-bindings.md` is what lists it. The `methodology/ux/` rules are the
+same: technical tier, because a technical map lists them. Infer the tier from the folder and the
+fold breaks.
 
 ## Adding to the tree
 
 - **A stack** — create `technology/<stack-id>/`, author the rules domain-free, map them from a
   project. See [technology/java-spring/README.md](technology/java-spring/README.md), which is that
   procedure written out. Use the stack id from `.appweaver/stack-profiles/`, so a lane in
-  `stacks.json` and a rule folder are the same word.
+  `stacks.json` and a rule folder are the same word. Give the files the names the project's
+  map lists under `technology/{{backend_stack}}/` or `technology/{{frontend_stack}}/`:
+  `/appweaver select-stack` counts how many of those exist for each stack and reports the
+  stack as complete, partial or without a rule set (`stack-rules`).
 - **An industry** — create `domain/<industry>/`, author the overlays, point a project's
   `domain-rule-bindings.md` at it. The technical map needs no edit.
-- **A project** — fill in `project-specific/`: repoint the bullets and replace the three
-  project-supplied files. Nothing outside that folder changes.
+- **A project** — fill in `project-specific/`: add the corpora it uses as bullets in its two maps
+  and replace the three project-supplied files. `sample-healthcare/` is that done for one
+  industry. Nothing outside the project's folder changes.
 
 ## Files — technical (`technology/dotnet-webapi/`)
 
@@ -147,8 +164,25 @@ same name.
 Mapping `## /aw-spec-ui-*` in a project's `tech-rule-bindings.md` is what declares that the project
 *has* a frontend lane. With no such heading, `constitution` skips the UI half and creates no file.
 
+## Files — methodology (`methodology/ux/`)
+
+**Experience** — mapped under `## /aw-spec-specify` on the **technical** tier by the shipped
+`project-specific/` map: they govern how `specify` states the experience, and the spec's Experience
+Scope + Experience Standards (`UX-`) are what `prototype`, `ui-design` and `ui-implement` author
+and verify against. Each carries a "What must NOT appear" section — that is what keeps screens,
+pages and components out of the spec. They hold for every stack and every industry; an industry
+corpus may carry its own variant, as `domain/healthcare/ux/` does.
+- [journey-mapping.md](methodology/ux/journey-mapping.md) — a journey is a `US-n`; outcome not click-path; interruption and hand-off
+- [interaction-states.md](methodology/ux/interaction-states.md) — which states must be handled; the `UX-` standard vs the EARS `FR-` behaviour
+- [accessibility-standards.md](methodology/ux/accessibility-standards.md) — conformance target, AT floor, keyboard-completable `US-n`, waiver discipline
+- [content-design.md](methodology/ux/content-design.md) — ubiquitous language, actionable errors, verbatim regulated wording, units and provenance
+
 ## Files — healthcare domain (`domain/healthcare/`)
 
+Mapped by [sample-healthcare/](sample-healthcare/), not by the shipped `project-specific/`.
+[sample-healthcare/domain/domain-requirements.md](sample-healthcare/domain/domain-requirements.md)
+is the hospital enumeration (Patients, EMR, Radiology…) a healthcare project starts from.
+
 **Constitution**
 - [domain-constitution.md](domain/healthcare/domain-constitution.md) — the ratified industry base, principles XVI+
 
@@ -181,11 +215,11 @@ Mapping `## /aw-spec-ui-*` in a project's `tech-rule-bindings.md` is what declar
 - [dependency-policy.domain.md](domain/healthcare/dependency-policy.domain.md) — HIPAA suitability, healthcare libs
 - [api-versioning.domain.md](domain/healthcare/api-versioning.domain.md) — FHIR versioning, CapabilityStatement
 
-**Experience (`ux/`)** — mapped under `## /aw-spec-specify` on the **technical** tier, like
-`ihe-conformance.md`: they govern how `specify` states the experience, and the spec's Experience
-Scope + Experience Standards (`UX-`) are what `prototype`, `ui-design` and `ui-implement` author
-and verify against. Each carries a "What must NOT appear" section — that is what keeps screens,
-pages and components out of the spec.
+**Experience (`ux/`)** — the healthcare variant of [methodology/ux/](methodology/ux/): the same
+rules, with the clinical cases (interrupted clinical work, staleness as a clinical fact, units on
+clinical values, clinical-safety accessibility) stated outright. `sample-healthcare/` maps them under
+`## /aw-spec-specify` in place of the industry-free set, on the **technical** tier like
+`ihe-conformance.md`.
 - [ux/journey-mapping.md](domain/healthcare/ux/journey-mapping.md) — a journey is a `US-n`; outcome not click-path; interruption and hand-off
 - [ux/interaction-states.md](domain/healthcare/ux/interaction-states.md) — which states must be handled; the `UX-` standard vs the EARS `FR-` behaviour
 - [ux/accessibility-standards.md](domain/healthcare/ux/accessibility-standards.md) — conformance target, AT floor, keyboard-completable `US-n`, waiver discipline
@@ -213,6 +247,8 @@ Medicinal-Product-Registration enumeration a pharma project would copy into its
 - **`domain/<industry>/<name>.domain.md`** — a domain overlay extending the `technology/` file of
   the same name.
 - **`domain/<industry>/<name>.md`** — inherently domain (FHIR, HIPAA, NDC, terminology…).
+- **`methodology/<topic>/<name>.md`** — a way of working that holds for every stack and every
+  industry (the `ux/` rules `specify` states the experience by); its tier is the map that lists it.
 
 ## What is not here
 

package/assets/guardrails/methodology/ux/accessibility-standards.md

@@ -0,0 +1,38 @@
+# UX Rule — Accessibility Standards
+
+> Loaded under `## /aw-spec-specify` in a project's `tech-rule-bindings.md`. A methodology
+> rule: it governs how the conformance obligation is stated in the spec so that `ui-design`
+> and the UI code gate can verify it. It holds for every stack and every industry; an industry
+> corpus may carry its own variant (`guardrails/domain/healthcare/ux/` is one).
+
+## Why this is a spec concern at all
+
+`ui-design` and `ui-implement` author from the **spec**, never from the rule corpus. An
+accessibility obligation that lives only here reaches no UI phase and is gated by nothing. The
+lift into a `UX-n` is what makes it binding.
+
+## Rules
+
+1. **Name the target, the level, and the surface it covers.** "Meets WCAG 2.2 Level AA on
+   every user-facing surface" is checkable. "Is accessible" is not, and fails the gate as an
+   unverifiable standard.
+2. **State the assistive-technology floor in Experience Scope**, not in the standard. The
+   standard says conformance; the scope says which readers and input modes define it. The two
+   are separated so a floor change does not rewrite the standard.
+3. **Keyboard operability is stated against the User Stories.** The obligation is that every
+   task the spec lists as a `US-n` is completable keyboard-only. That binds the standard to
+   this aggregate's actual work rather than to a generic surface.
+4. **A status the user acts on is not decoration.** Colour is never the sole carrier of a
+   status that affects a decision the user makes, alerts are announced to assistive
+   technology, and a dismissible warning is re-reachable. State these as `UX-n` standards.
+5. **A waiver is an id, a reason and an expiry.** An accessibility exception is recorded against
+   the `UX-n` id it relaxes, time-boxed, and expires. An unrecorded exception is a defect.
+6. **Regulatory accessibility obligations lift as themselves.** Where a jurisdiction imposes a
+   conformance regime on the software or on the users it serves, that obligation is a `UX-n`
+   citing the regime. Where the same regime also imposes a records or retention duty, that half
+   stays a `CN-n`.
+
+## What must NOT appear
+
+ARIA attributes, roles, landmark structure, tab order, contrast values for a specific palette,
+component libraries, or linter configuration. Those are how the standard is met.

package/assets/guardrails/methodology/ux/content-design.md

@@ -0,0 +1,34 @@
+# UX Rule — Content Design
+
+> Loaded under `## /aw-spec-specify` in a project's `tech-rule-bindings.md`. A methodology
+> rule: it governs the language obligations the spec carries into the UI lane. It holds for
+> every stack and every industry; an industry corpus may carry its own variant
+> (`guardrails/domain/healthcare/ux/` is one).
+
+## Rules
+
+1. **The UI speaks the ubiquitous language.** User-facing terms are the terms in Key Entities.
+   Where the interface must show a term the domain does not use, the spec says which term and
+   why; an unmapped synonym invented in a component is a defect against the domain model.
+2. **Every error names what happened and what to do next.** State this once as a `UX-n`. A
+   message that reports a failure without an action is not a message, it is a dead end — see
+   `interaction-states.md`.
+3. **Regulated wording is reproduced verbatim.** Consent text, legal notices, safety warnings,
+   and any wording a regulator or another authority fixes are quoted exactly and never
+   paraphrased, truncated or localised without the approved translation. Lift the obligation as
+   a `UX-n` and the retention or audit duty attached to it as a `CN-n`.
+4. **Measured values carry their units and their provenance.** A displayed quantity without its
+   unit is ambiguous; a value drawn from an external feed is attributable. State the obligation
+   here, state the classification of the field itself in `DC-n`.
+5. **Identity display is a classification decision, not a wording one.** What may appear on a
+   surface — and what must not appear in logs, metrics or traces — is `DC-n`. This section
+   governs only how the permitted content reads.
+6. **Localisation is structural where it applies.** Where the product ships more than one
+   locale, state as a `UX-n` that user-visible strings come from a catalogue and that dates,
+   numbers and units format locale-aware at the boundary. Where it ships one, say so in
+   Experience Scope and omit the standard.
+
+## What must NOT appear
+
+Final copy, message strings, tone-of-voice guides, or per-screen wording. The spec states the
+obligation the wording must satisfy; the prototype and the design system settle the words.

package/assets/guardrails/methodology/ux/interaction-states.md

@@ -0,0 +1,45 @@
+# UX Rule — Interaction States
+
+> Loaded under `## /aw-spec-specify` in a project's `tech-rule-bindings.md`. A methodology
+> rule: it governs how the spec expresses what the user meets while the system works, never
+> how any of it is rendered. It holds for every stack and every industry; an industry corpus
+> may carry its own variant (`guardrails/domain/healthcare/ux/` is one).
+
+## The split this rule exists to hold
+
+Two things look alike and belong in different sections:
+
+| Statement | Home | Why |
+|---|---|---|
+| "Every asynchronous operation presents its loading, empty, partial-failure, recovery and success states" | **`UX-n`** | project-wide standard, true of every surface |
+| "IF the order history cannot be retrieved THEN THE SYSTEM SHALL present the last known list marked stale and offer retry" | **`FR-n`** | this aggregate's behaviour, in EARS |
+
+The standard is lifted once. The behaviour is specified per aggregate, in EARS, using the
+unwanted-behaviour patterns the spec template already defines.
+
+## Rules
+
+1. **Enumerate the states, do not draw them.** The states are loading, empty, partial,
+   failure, recovery, success and — where the domain requires it — stale and degraded. The
+   spec says which must be handled; the prototype says what they look like.
+2. **No dead end.** A `UX-n` states that no reachable state leaves the user without a next
+   action. A state the UI can reach and the spec does not describe is a spec defect routed
+   back to `specify`, never invented in a component.
+3. **Partial failure is stated, not implied.** Where a surface composes several sources, the
+   spec states whether a partial result is presentable and how it is marked. Where a partial
+   result could mislead the user, it is presentable ONLY when its incompleteness is explicit;
+   silence here is a defect, not a default.
+4. **Staleness is stated where it matters.** Where cached or last-known data may be shown, say
+   so as an `FR-n` and carry the project-wide marking obligation as a `UX-n`. Data whose
+   currency affects a decision the user makes is never presented as current when it is not.
+5. **Destructive and irreversible actions state their confirmation obligation** as a `UX-n`,
+   and their specific consequence as an `FR-n` or `BR-n`.
+6. **Responsiveness is a bound, not a behaviour.** Acknowledgement and progress thresholds are
+   `UX-n` limits. Where the bound depends on a server-side budget, that budget stays a `CN-n`
+   and the two cross-reference — the service-side gates read `CN-` and never read the
+   Experience Standards.
+
+## What must NOT appear
+
+Spinners, skeletons, toasts, banners, placement, animation, timing curves, or any component
+name. Those realise the state; they are not the state.

package/assets/guardrails/methodology/ux/journey-mapping.md

@@ -0,0 +1,41 @@
+# UX Rule — Journey Mapping
+
+> Loaded under `## /aw-spec-specify` in a project's `tech-rule-bindings.md`. It is a
+> **methodology** rule: it governs how `specify` expresses the experience in the spec, not
+> what any screen looks like. It holds for every stack and every industry; an industry corpus
+> may carry its own variant (`guardrails/domain/healthcare/ux/` is one). Tier is set by the map
+> that lists it, not by the folder it sits in — it is loaded as a technical input.
+
+## What this rule governs
+
+The spec states the user's **path through a task** as a `US-n` user story and the standards
+that path must hold to as `UX-n` entries. It never states the route the user takes through a
+UI. One story may become one screen or five; that is the prototype's and `design.ui.md`'s
+decision, and a spec that pre-empts it has specified the solution.
+
+## Rules
+
+1. **A journey is a `US-n`, not a new id class.** A user story is already defined as a
+   prioritized, independently testable journey. An experience journey uses that definition
+   unchanged — the actor, the goal, the acceptance criteria in Given/When/Then.
+2. **State the outcome, never the mechanism.** "A buyer can compare two saved quotes and
+   accept one in a single sitting" is a journey. "A buyer opens the Quotes tab, ticks two rows,
+   clicks Compare, then Accept" is a click-path and belongs in the prototype.
+3. **Every journey names the actor from Experience Scope.** A story whose actor is not listed
+   there is either an unlisted actor or a story that does not belong to this aggregate.
+4. **Interruption is a first-class case.** Real work is interrupted; a long or shared task
+   whose journey cannot survive being abandoned mid-task and resumed is under-specified. Where
+   resumability is required, state it as an acceptance criterion on the `US-n`, and state the
+   project-wide expectation once as a `UX-n`.
+5. **Journey integrity is a `UX-n` standard.** Completability without leaving the aggregate's
+   surface, confirmation and reversibility of destructive actions, and preservation of entered
+   work across a failure are standards that hold for every journey — lift them once, do not
+   repeat them per story.
+6. **Hand-offs between actors are journeys too.** Where a task passes from one role to another
+   (request → approval → fulfilment), the hand-off is part of the journey and its state at the
+   boundary is stated in the acceptance criteria.
+
+## What must NOT appear
+
+Screens, pages, tabs, wizards, step counts, navigation structure, button labels, modal-vs-inline
+choices, or any statement whose only realisation is one layout.

package/assets/guardrails/project-specific/domain/domain-requirements.md

@@ -1,58 +1,45 @@
 # 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.
+> project. It is mapped under `## /aw-spec-constitution` and `## /aw-spec-specify` in
+> `domain-rule-bindings.md`, so `constitution` ratifies it into `constitution.domain.md` and
+> `specify` lifts its constraints into the spec. Where the project maps an industry corpus, it
+> is the last file in that set and the only one expected to differ between two projects on the
+> same corpus. Its mapping is optional — a project that has not authored it yet still runs.
 >
-> 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.
+> This file holds the per-project enumeration and headline profiles. Replace every comment
+> below with this project's content; a section that does not apply says so in one line rather
+> than being deleted. `guardrails/sample-healthcare/domain/domain-requirements.md` is a filled
+> example.
 
 =====================================================================
 [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).
+<!-- One bullet per bounded context: its name, then the aggregates it owns, e.g.
+     - Ordering — aggregates: Order, Cart, Quote.
+     Name the aggregates in the business's own language; specify and the domain model reuse
+     these names. -->
 
 =====================================================================
 [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
+<!-- Where the detailed rules for each profile live — a file in this folder, a file of an
+     industry corpus this project maps, or "below". One line per profile, e.g.
+     [DOMAIN: Aggregates and Business Invariants]  -> below
+     [DOMAIN: Persistence Profile]                 -> below
+     [DOMAIN: Security Profile]                    -> below
+     [DOMAIN: Testing Profile]                     -> below
+     [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.
+<!-- Target runtime and regions, the external systems the product depends on, scale targets,
+     and recovery objectives (RPO / RTO, backup retention). State targets as numbers. -->
 
 =====================================================================
 [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.
+<!-- The approvers (principal engineers, the security or compliance owner, a domain owner per
+     bounded context), the review cadence, and the exception process: who approves a waiver,
+     its maximum duration, and where it is recorded. -->

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

@@ -2,7 +2,8 @@
 
 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.
+orchestrator pipeline. As shipped it maps **no industry corpus**: the only domain file it
+loads is the one the project team authors, `domain/domain-requirements.md`, beside this map.
 
 **The model:** domain files feed
 only three consumers — **specify** (authors them into the spec as FR/BR/CN-/DC-/IC-),
@@ -10,69 +11,43 @@ only three consumers — **specify** (authors them into the spec as FR/BR/CN-/DC
 **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.
+- All paths are workspace-relative. **Standard industry rules** live in shared corpora under
+  `guardrails/domain/<industry>/` — `healthcare/` and `pharma/` ship — reusable by every
+  project that maps them. To govern this project by one, add its files as `- ` bullets under
+  the headings below. Nothing else changes: the technical map, the workflows and the engine
+  are untouched.
+- `guardrails/sample-healthcare/` is a complete project on the healthcare corpus: its
+  `domain-rule-bindings.md` shows which files of an industry corpus go under which heading.
+  `/appweaver select-domain sample-healthcare` switches to it whole.
+- A heading with no bullets loads nothing. With this map as shipped, `specify` lifts only the
+  constraints `domain-requirements.md` states, and the gates check the plans and the code
+  against the spec and the bounded context's domain model, with no industry checklist. Keep
+  every heading, even with nothing under it: a command whose heading is absent or misspelled
+  loads the same nothing, and its run ends with a warning saying so.
 - 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.
+  that has not authored its `domain-requirements.md` yet still runs; the run ends with a
+  warning naming the file.
 - `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 `project-specific`, which it does by default.
 
 ---
 
 ## /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
+<!-- What the DOMAIN half ratifies into constitution.domain.md as domain principles. With an
+     industry corpus mapped, its constitution comes first, then its STANDARD 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 — and LAST the PROJECT-SUPPLIED domain-requirements.md the project team authors.
+     As shipped only that last file is mapped. Its mapping is OPTIONAL: the project owner
+     supplies the file, and where it is absent the set loads without it rather than failing. -->
 - guardrails/project-specific/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). -->
+     overlays into the spec's CN-/DC-/IC- sections (design/implement never see these files).
+     An industry corpus adds its terminology, its standards and its *.domain.md overlays here. -->
 - guardrails/project-specific/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
@@ -94,21 +69,10 @@ 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
+     output. Domain re-enters here as a check, never as authoring input. An industry corpus
+     maps its *.domain.md overlays here. -->
+_None — this project maps no industry corpus, so the gates have no domain checklist. They still
+check the plans and the code against the spec and the bounded context's domain-model.md._
 
 ---
 
@@ -116,13 +80,13 @@ frontend-plan.md and the context's domain-model.md._
 
 | 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-constitution | 1 | domain principles — the project's own requirements; an industry corpus adds its constitution and standard rules |
+| /aw-spec-specify | 1 | 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) |
+| /aw-spec-gate | 0 | conformance checklist (validate, don't author) — an industry corpus's overlays |
 
 > 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

package/assets/guardrails/project-specific/frontend/ui-requirements.md

@@ -1,8 +1,8 @@
 # UI Requirements — project-supplied
 
 > **This file is authored by the project team, not by the corpus.**
-> `guardrails/technology/nextjs/ui-constitution.md` 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
+> `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

package/assets/guardrails/project-specific/service/technical-requirements.md

@@ -1,8 +1,8 @@
 # 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 `guardrails/technology/dotnet-webapi/` — the standard set for that
-> stack, reusable by every project that maps it. This file is where one project's own technology
+> 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