aw-spec-cli 0.1.3 → 0.1.5

package/assets/.kilocode/workflows/aw-spec-taskstoissues.md

@@ -1,107 +0,0 @@
----
-name: "aw-spec-taskstoissues"
-description: "Convert existing tasks into actionable, dependency-ordered GitHub issues for the feature based on available design artifacts."
-argument-hint: "Optional filter or label for GitHub issues"
-compatibility: "Requires aw-spec project structure with .aw-spec/ directory"
-metadata:
-  author: "github-aw-spec"
-  source: "templates/commands/taskstoissues.md"
-user-invocable: true
-disable-model-invocation: false
----
-
-
-## User Input
-
-```text
-$ARGUMENTS
-```
-
-You **MUST** consider the user input before proceeding (if not empty).
-
-## Pre-Execution Checks
-
-**Check for extension hooks (before tasks-to-issues conversion)**:
-- Check if `.aw-spec/extensions.yml` exists in the project root.
-- If it exists, read it and look for entries under the `hooks.before_taskstoissues` key
-- If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally
-- Filter out hooks where `enabled` is explicitly `false`. Treat hooks without an `enabled` field as enabled by default.
-- For each remaining hook, do **not** attempt to interpret or evaluate hook `condition` expressions:
-  - If the hook has no `condition` field, or it is null/empty, treat the hook as executable
-  - If the hook defines a non-empty `condition`, skip the hook and leave condition evaluation to the HookExecutor implementation
-- When constructing slash commands from hook command names, replace dots (`.`) with hyphens (`-`). For example, `aw-spec.git.commit` → `/aw-spec-git-commit`.
-- For each executable hook, output the following based on its `optional` flag:
-  - **Optional hook** (`optional: true`):
-    ```
-    ## Extension Hooks
-
-    **Optional Pre-Hook**: {extension}
-    Command: `/{command}`
-    Description: {description}
-
-    Prompt: {prompt}
-    To execute: `/{command}`
-    ```
-  - **Mandatory hook** (`optional: false`):
-    ```
-    ## Extension Hooks
-
-    **Automatic Pre-Hook**: {extension}
-    Executing: `/{command}`
-    EXECUTE_COMMAND: {command}
-
-    Wait for the result of the hook command before proceeding to the Outline.
-    ```
-- If no hooks are registered or `.aw-spec/extensions.yml` does not exist, skip silently
-
-## Outline
-
-1. Run `.aw-spec/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
-1. **IF EXISTS**: Load `.aw-spec/memory/constitution.md` for project principles and governance constraints.
-1. From the executed script, extract the path to **tasks**.
-1. Get the Git remote by running:
-
-```bash
-git config --get remote.origin.url
-```
-
-> [!CAUTION]
-> ONLY PROCEED TO NEXT STEPS IF THE REMOTE IS A GITHUB URL
-
-1. For each task in the list, use the GitHub MCP server to create a new issue in the repository that is representative of the Git remote.
-
-> [!CAUTION]
-> UNDER NO CIRCUMSTANCES EVER CREATE ISSUES IN REPOSITORIES THAT DO NOT MATCH THE REMOTE URL
-
-## Post-Execution Checks
-
-**Check for extension hooks (after tasks-to-issues conversion)**:
-Check if `.aw-spec/extensions.yml` exists in the project root.
-- If it exists, read it and look for entries under the `hooks.after_taskstoissues` key
-- If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally
-- Filter out hooks where `enabled` is explicitly `false`. Treat hooks without an `enabled` field as enabled by default.
-- For each remaining hook, do **not** attempt to interpret or evaluate hook `condition` expressions:
-  - If the hook has no `condition` field, or it is null/empty, treat the hook as executable
-  - If the hook defines a non-empty `condition`, skip the hook and leave condition evaluation to the HookExecutor implementation
-- When constructing slash commands from hook command names, replace dots (`.`) with hyphens (`-`). For example, `aw-spec.git.commit` → `/aw-spec-git-commit`.
-- For each executable hook, output the following based on its `optional` flag:
-  - **Optional hook** (`optional: true`):
-    ```
-    ## Extension Hooks
-
-    **Optional Hook**: {extension}
-    Command: `/{command}`
-    Description: {description}
-
-    Prompt: {prompt}
-    To execute: `/{command}`
-    ```
-  - **Mandatory hook** (`optional: false`):
-    ```
-    ## Extension Hooks
-
-    **Automatic Hook**: {extension}
-    Executing: `/{command}`
-    EXECUTE_COMMAND: {command}
-    ```
-- If no hooks are registered or `.aw-spec/extensions.yml` does not exist, skip silently

package/assets/docs/command.txt

@@ -1,295 +0,0 @@
-================================================================================
-AW-SPEC COMMAND SHEET — Feature: Patient Registration  (Patient / RegisterPatient)
-================================================================================
-Run these in order, one per turn, from /aw-spec-specify to /aw-spec-implement.
-All six numbered steps are REQUIRED for this feature — clarify and analyze are
-correctness gates, not optional extras (see their sections for why).
-
-CONVENTIONS USED BELOW
-- @paths are Claude Code file mentions; they are inlined as context. Paths are
-  relative to the workspace root (e:\Work\Company\Project), so they start with `docs/...`.
-- "MANUAL TEXT" = the plain prompt you type as part of the command.
-- The spec folder convention is specs/<Aggregate>/<Feature>; starting the feature
-  description with the token `Patient/RegisterPatient` makes /aw-spec-specify create
-  specs/Patient/RegisterPatient/ and pin it in .aw-spec/feature.json. Every later
-  command (clarify/plan/tasks/analyze/implement) auto-resolves that folder from
-  feature.json — you do NOT pass the aggregate/feature token again.
-- The constitution (.aw-spec/memory/constitution.md) AND the domain-agnostic technical
-  standards are AUTO-LOADED by each command (see each SKILL.md) — you
-  do NOT pass those with @.
-- The DOMAIN-SPECIFIC files shown per step come from the active domain's comandrulemap.md
-  (active domain = .aw-spec/domain.json, set via /aw-spec-select-domain). Each command offers
-  them in a selection box (Select all / Pick a subset / None); the @ mentions below are an
-  equivalent, OPTIONAL shortcut and are always loaded in addition to the auto-loaded set.
-
-INTEROPERABILITY SCOPE FOR THIS FEATURE
-  Patient registration is an interoperability-heavy feature. It MUST support:
-   - Inbound HL7 v2 ADT^A04 (Register a Patient) via an Interop/Hl7v2 adapter that
-     converts the message to the RegisterPatientCommand (never writes to the aggregate
-     directly), over MLLP, with ACK handling.
-   - Outbound ADT emission on PatientRegisteredEvent (egress adapter).
-   - External FHIR R4 Patient projection + PIX/PDQ identity cross-reference.
-  Therefore docs/domainspecs/healthcare/hl7.md and the eventing docs are part of the context from
-  specify through implement.
-
-SETUP (one-time per project) — set the active domain
-  /aw-spec-select-domain              (lists docs/domainspecs/ folders; writes .aw-spec/domain.json)
-  /aw-spec-select-domain healthcare   (or set it directly)
-  -> For this demo the domain is `healthcare` (already set). If the domain is unset or its
-     comandrulemap.md is missing, every command first asks "Continue without domain rules?
-     (Continue / Exit)" before running.
-
-PREREQUISITE (one-time, only if the constitution has not been ratified yet)
-  /aw-spec-constitution @docs/healthcare-constitution.md @docs/domainspecs/healthcare/domain-requirements.md
-  -> docs/technology-constitution.md auto-loads (technology base); pass only the domain addenda.
-  -> Ratifies .aw-spec/memory/constitution.md. Not part of the per-feature loop.
-
-
-================================================================================
-STEP 1 — /aw-spec-specify   (create the feature spec)
-================================================================================
-PURPOSE
-  Create specs/Patient/RegisterPatient/spec.md (WHAT/WHY, no implementation detail)
-  and pin the folder in .aw-spec/feature.json. A git feature branch is created by the
-  before_specify hook.
-
-CONTEXT FILES TO ADD
-  docs/domainspecs/healthcare/domain-requirements.md          (bounded contexts: Patient aggregates)
-  docs/domainspecs/healthcare/clinical-terms.md             (MRN, Encounter, Coverage, ...)
-  docs/domainspecs/healthcare/integration-terms.md          (FHIR, HL7, PIX/PDQ, ATNA, ADT)
-  docs/domainspecs/healthcare/domain-driven-design.domain.md  (Patient invariants)
-  docs/domainspecs/healthcare/fhir.md                          (Patient FHIR projection)
-  docs/domainspecs/healthcare/hl7.md                           (HL7 v2 ADT ingestion/egress)  <-- HL7
-  docs/domainspecs/healthcare/dicom.md                         (imaging identifiers; optional for registration)
-  docs/domainspecs/healthcare/terminology.md                   (coded fields)
-  docs/domainspecs/healthcare/hipaa.md                          (PHI / minimum-necessary)
-  docs/domainspecs/healthcare/consent.md                        (Consent at registration)
-  docs/domainspecs/healthcare/data-classification.domain.md   (PHI/PII categories)
-  docs/domainspecs/healthcare/ai-rules.domain.md              (PHI masking, no invented codes)
-
-COMMAND (copy-paste, single line)
-/aw-spec-specify Patient/RegisterPatient Register a new patient into the master patient index. Capture demographics (legal HumanName, date of birth, administrative sex, contact points, address) and assign a tenant-unique MRN. Invariants: MRN is unique per tenant; date-of-birth must not be in the future; minimum-necessary projection by role/scope. Interoperability: inbound HL7 v2 ADT^A04 (Register a Patient) messages MUST be ingested through an Interop/Hl7v2 adapter that converts to the RegisterPatientCommand (no direct aggregate writes) over MLLP with ACK handling, and an outbound ADT emitter fires on PatientRegisteredEvent; also expose an external FHIR R4 Patient projection and PIX/PDQ identity cross-reference. Surfaces: internal REST POST /patients returning the created Patient, the FHIR R4 Patient endpoint, and the HL7 v2 ADT ingress channel. Every PHI read/write must produce an ATNA audit record. Out of scope: patient merge, portal self-registration. @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/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/ai-rules.domain.md
-
-MANUAL TEXT (the prompt portion, for reference)
-  Patient/RegisterPatient Register a new patient into the master patient index. Capture
-  demographics (legal HumanName, date of birth, administrative sex, contact points,
-  address) and assign a tenant-unique MRN. Optionally link an insurance Coverage and
-  capture initial patient Consent. Invariants: MRN is unique per tenant; date-of-birth
-  must not be in the future; minimum-necessary projection by role/scope.
-  Interoperability: inbound HL7 v2 ADT^A04 (Register a Patient) messages MUST be ingested
-  through an Interop/Hl7v2 adapter that converts to the RegisterPatientCommand (no direct
-  aggregate writes) over MLLP with ACK handling, and an outbound ADT emitter fires on
-  PatientRegisteredEvent; also expose an external FHIR R4 Patient projection and PIX/PDQ
-  identity cross-reference. Surfaces: internal REST POST /patients returning the created
-  PatientDto with an ETag, the FHIR R4 Patient endpoint, and the HL7 v2 ADT ingress
-  channel. Every PHI read/write must produce an ATNA audit record. Out of scope: patient
-  merge, portal self-registration.
-
-NOTES
-  - The leading `Patient/RegisterPatient` token sets the spec folder; keep PascalCase.
-  - Expect output: SPEC_FILE = specs/Patient/RegisterPatient/spec.md.
-
-
-================================================================================
-STEP 2 — /aw-spec-clarify   (REQUIRED — feature-correctness gate)
-================================================================================
-WHY THIS MATTERS (do not skip)
-  Clarify finds underspecified areas and asks up to 5 targeted questions, then writes the
-  answers back into spec.md. Building plan/tasks/code on an ambiguous spec is the most
-  expensive mistake in the pipeline — for a PHI + HL7 feature the ambiguities have real
-  cost. Resolve at least:
-   - HL7 scope: only ADT^A04, or also A28 (add person) / A31 (update) / A08 (update info)?
-     Which MSH sending/receiving apps? MLLP vs file drop? ACK mode (AA/AE/AR) and NAK on
-     duplicate MRN?
-   - Identity: who assigns the MRN (this system vs source)? PIX/PDQ matching rules and
-     duplicate/merge-candidate handling on inbound ADT.
-   - Consent: is Consent mandatory at registration or optional? purpose-of-use default.
-   - Demographics: required vs optional fields; terminology bindings (administrative sex,
-     marital status); multiple-birth/aliases.
-   - Coverage: required at registration or deferred.
-  Re-run until no high-impact (scope/PHI/interop) ambiguity remains.
-
-CONTEXT FILES TO ADD
-  docs/domainspecs/healthcare/domain-driven-design.domain.md
-  docs/domainspecs/healthcare/hl7.md                          (HL7 ADT clarifications)  <-- HL7
-  docs/domainspecs/healthcare/hipaa.md
-  docs/domainspecs/healthcare/consent.md
-  docs/domainspecs/healthcare/clinical-terms.md
-  docs/domainspecs/healthcare/integration-terms.md
-
-COMMAND
-/aw-spec-clarify @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/integration-terms.md
-
-MANUAL TEXT
-  (none — answer the questions it asks; the answers are written back into spec.md)
-
-
-================================================================================
-STEP 3 — /aw-spec-plan   (create the implementation plan / design)
-================================================================================
-PURPOSE
-  Produce plan.md (+ research/data-model/contracts) under specs/Patient/RegisterPatient/.
-  This is where the engineering standards matter most — load the architecture stack,
-  the HL7 adapter rules, and the eventing rules for inbound feeds.
-
-CONTEXT FILES TO ADD
-  Architecture (technology):
-    docs/architecture/folder-structure.md
-    docs/architecture/clean-architecture.md
-    docs/architecture/modular-monolith.md
-    docs/architecture/cqrs.md
-    docs/architecture/vertical-slices.md
-    docs/architecture/persistence.md
-    docs/architecture/eventing.md
-    docs/domainspecs/healthcare/eventing.domain.md       (HL7/FHIR inbound feeds)  <-- HL7
-    docs/architecture/testing.md
-  Domain (healthcare, this slice):
-    docs/domain/domain-driven-design.md
-    docs/domainspecs/healthcare/domain-driven-design.domain.md
-    docs/domainspecs/healthcare/fhir.md
-    docs/domainspecs/healthcare/hl7.md                          (HL7 v2 adapter pattern)  <-- HL7
-    docs/domainspecs/healthcare/dicom.md                        (imaging identifiers; optional for registration)
-    docs/domainspecs/healthcare/terminology.md
-    docs/domainspecs/healthcare/hipaa.md
-    docs/domainspecs/healthcare/consent.md
-  Security:
-    docs/security/authorization.md  + .domain.md
-    docs/security/auditing.md        + .domain.md
-    docs/domainspecs/healthcare/data-classification.domain.md
-  Governance + AI rules:
-    docs/governance/coding-standards.md  + .domain.md
-    docs/glossary/ai-rules.md            + .domain.md
-
-COMMAND (copy-paste, single line)
-/aw-spec-plan Implement RegisterPatient as a complete vertical slice in the Patients module following the loaded standards: Patient aggregate root (Vogen PatientId, MRN value object, HumanName/Address/ContactPoint value objects), RegisterPatientCommand + handler (transaction + PatientRegisteredEvent), SecureFastEndpoint POST /patients with ETag, PatientDto + hand-written ToDto, EF configuration + migration, FHIR R4 Patient projector, and the PHI-access audit behavior. Interop: an Interop/Hl7v2 inbound adapter that parses ADT^A04 and dispatches RegisterPatientCommand via IMediator (no direct aggregate writes), MLLP transport + ACK, and an outbound ADT emitter subscribed to PatientRegisteredEvent; plan PIX/PDQ identity cross-reference. Use AppWeaver.Mediator/Repository/ServiceDefaults per the docs; PostgreSQL prod / SQLite dev; no MediatR/AutoMapper. @docs/architecture/folder-structure.md @docs/architecture/clean-architecture.md @docs/architecture/modular-monolith.md @docs/architecture/cqrs.md @docs/architecture/vertical-slices.md @docs/architecture/persistence.md @docs/architecture/eventing.md @docs/domainspecs/healthcare/eventing.domain.md @docs/architecture/testing.md @docs/domain/domain-driven-design.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/security/authorization.md @docs/domainspecs/healthcare/authorization.domain.md @docs/security/auditing.md @docs/domainspecs/healthcare/auditing.domain.md @docs/domainspecs/healthcare/data-classification.domain.md @docs/governance/coding-standards.md @docs/domainspecs/healthcare/coding-standards.domain.md @docs/glossary/ai-rules.md @docs/domainspecs/healthcare/ai-rules.domain.md
-
-MANUAL TEXT (the prompt portion, for reference)
-  Implement RegisterPatient as a complete vertical slice in the Patients module following
-  the loaded standards: Patient aggregate root (Vogen PatientId, MRN value object,
-  HumanName/Address/ContactPoint value objects), RegisterPatientCommand + handler
-  (transaction + PatientRegisteredEvent), SecureFastEndpoint POST /patients with ETag,
-  PatientDto + hand-written ToDto, EF configuration + migration, FHIR R4 Patient projector,
-  and the PHI-access audit behavior. Interop: an Interop/Hl7v2 inbound adapter that parses
-  ADT^A04 and dispatches RegisterPatientCommand via IMediator (no direct aggregate writes),
-  MLLP transport + ACK, and an outbound ADT emitter subscribed to PatientRegisteredEvent;
-  plan PIX/PDQ identity cross-reference. Use AppWeaver.Mediator/Repository/ServiceDefaults
-  per the docs; PostgreSQL prod / SQLite dev; no MediatR/AutoMapper.
-
-NOTES
-  - No aggregate/feature token here — the folder is resolved from feature.json.
-
-
-================================================================================
-STEP 4 — /aw-spec-tasks   (generate the dependency-ordered task list)
-================================================================================
-PURPOSE
-  Produce tasks.md from plan.md under specs/Patient/RegisterPatient/.
-
-CONTEXT FILES TO ADD
-  docs/architecture/folder-structure.md
-  docs/architecture/vertical-slices.md   (+ .domain.md)
-  docs/architecture/cqrs.md               (+ .domain.md)
-  docs/architecture/persistence.md        (+ .domain.md)
-  docs/architecture/testing.md            (+ .domain.md)
-  docs/architecture/eventing.md           (+ .domain.md)
-  docs/domainspecs/healthcare/domain-driven-design.domain.md
-  docs/domainspecs/healthcare/fhir.md
-  docs/domainspecs/healthcare/hl7.md                       (HL7 adapter tasks)  <-- HL7
-  docs/security/authorization.md          (+ .domain.md)
-  docs/security/auditing.md               (+ .domain.md)
-  docs/governance/coding-standards.md     (+ .domain.md)
-  docs/glossary/ai-rules.md               (+ .domain.md)
-
-COMMAND (copy-paste, single line)
-/aw-spec-tasks Break the plan into ordered, testable tasks for the RegisterPatient slice: value objects + tests, Patient aggregate + invariant tests, EF config + migration, RegisterPatientCommand/Validator/Handler + handler tests (happy/validation/not-found/conflict), SecureFastEndpoint + integration test, FHIR Patient projector + round-trip test, HL7 v2 ADT^A04 inbound parser + outbound emitter with HL7 conformance tests against an internal corpus, PatientRegisteredEvent + publish, PHI-audit wiring. Tests precede implementation. @docs/architecture/folder-structure.md @docs/architecture/vertical-slices.md @docs/domainspecs/healthcare/vertical-slices.domain.md @docs/architecture/cqrs.md @docs/domainspecs/healthcare/cqrs.domain.md @docs/architecture/persistence.md @docs/domainspecs/healthcare/persistence.domain.md @docs/architecture/testing.md @docs/domainspecs/healthcare/testing.domain.md @docs/architecture/eventing.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/security/authorization.md @docs/domainspecs/healthcare/authorization.domain.md @docs/security/auditing.md @docs/domainspecs/healthcare/auditing.domain.md @docs/governance/coding-standards.md @docs/domainspecs/healthcare/coding-standards.domain.md @docs/glossary/ai-rules.md @docs/domainspecs/healthcare/ai-rules.domain.md
-
-MANUAL TEXT (the prompt portion, for reference)
-  Break the plan into ordered, testable tasks for the RegisterPatient slice: value objects
-  + tests, Patient aggregate + invariant tests, EF config + migration,
-  RegisterPatientCommand/Validator/Handler + handler tests
-  (happy/validation/not-found/conflict), SecureFastEndpoint + integration test, FHIR
-  Patient projector + round-trip test, HL7 v2 ADT^A04 inbound parser + outbound emitter
-  with HL7 conformance tests against an internal corpus, PatientRegisteredEvent + publish,
-  PHI-audit wiring. Tests precede implementation.
-
-
-================================================================================
-STEP 5 — /aw-spec-analyze   (REQUIRED — cross-artifact correctness gate)
-================================================================================
-WHY THIS MATTERS (do not skip)
-  Analyze is a non-destructive consistency/quality check across spec.md, plan.md, and
-  tasks.md, run AFTER tasks and BEFORE implement. It is the last gate before code, and for
-  a regulated, interoperable feature it catches exactly the failures that are most costly
-  after implementation:
-   - Requirements in the spec with no covering task (e.g. ADT^A04 ingest, PIX/PDQ, Consent
-     capture, audit on every PHI write).
-   - Tasks with no basis in the spec (scope creep).
-   - Constitution NON-NEGOTIABLE gaps: missing ATNA audit task, hard-delete instead of
-     soft-delete, missing ETag/If-Match concurrency, PHI in logs, free-text where a coded
-     value object is required, a second FHIR write path, banned packages.
-   - Terminology / naming drift between artifacts.
-  Fix everything it flags by amending spec/plan/tasks, then re-run until clean.
-
-CONTEXT FILES TO ADD
-  docs/domainspecs/healthcare/hl7.md                       (verify HL7 coverage)  <-- HL7
-  docs/domainspecs/healthcare/hipaa.md
-  docs/domainspecs/healthcare/auditing.domain.md
-  docs/governance/coding-standards.md     (+ .domain.md)
-  docs/domainspecs/healthcare/ai-rules.domain.md
-
-COMMAND
-/aw-spec-analyze @docs/domainspecs/healthcare/hl7.md @docs/domainspecs/healthcare/hipaa.md @docs/domainspecs/healthcare/auditing.domain.md @docs/governance/coding-standards.md @docs/domainspecs/healthcare/coding-standards.domain.md @docs/domainspecs/healthcare/ai-rules.domain.md
-
-MANUAL TEXT
-  (none — review the report, then amend spec/plan/tasks for any finding and re-run)
-
-
-================================================================================
-STEP 6 — /aw-spec-implement   (execute the tasks / write the code)
-================================================================================
-PURPOSE
-  Execute tasks.md and produce the actual source under src/ following the standards.
-  Add the full implementation context: tasks-set + HL7 + dependency/versioning +
-  FHIR/terminology + data-classification/zero-trust.
-
-CONTEXT FILES TO ADD
-  (everything from STEP 4) PLUS:
-    docs/domainspecs/healthcare/hl7.md                      (already in step 4 — keep)  <-- HL7
-    docs/governance/dependency-policy.md   (+ .domain.md)
-    docs/governance/api-versioning.md      (+ .domain.md)
-    docs/domainspecs/healthcare/terminology.md
-    docs/security/data-classification.md    (+ .domain.md)
-    docs/security/zero-trust.md             (+ .domain.md)
-
-COMMAND (copy-paste, single line)
-/aw-spec-implement Implement the RegisterPatient tasks exactly per the loaded standards. Generate the complete vertical slice (Domain/Persistence/Features/Shared), the Interop/Hl7v2 ADT^A04 inbound adapter + outbound ADT emitter (MLLP + ACK, no direct aggregate writes), the FHIR R4 Patient projector, unit + integration + FHIR-validator + HL7-conformance tests, and the EF migration. Honor every NON-NEGOTIABLE: Result pattern, ETag/If-Match concurrency, soft-delete, ATNA audit, minimum-necessary, no PHI in logs, coded value objects, inbound feeds via adapters only, no banned packages. Do not run migrations against shared environments. @docs/architecture/folder-structure.md @docs/architecture/vertical-slices.md @docs/domainspecs/healthcare/vertical-slices.domain.md @docs/architecture/cqrs.md @docs/domainspecs/healthcare/cqrs.domain.md @docs/architecture/persistence.md @docs/domainspecs/healthcare/persistence.domain.md @docs/architecture/testing.md @docs/domainspecs/healthcare/testing.domain.md @docs/architecture/eventing.md @docs/domainspecs/healthcare/eventing.domain.md @docs/domain/domain-driven-design.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/security/authorization.md @docs/domainspecs/healthcare/authorization.domain.md @docs/security/auditing.md @docs/domainspecs/healthcare/auditing.domain.md @docs/security/data-classification.md @docs/domainspecs/healthcare/data-classification.domain.md @docs/security/zero-trust.md @docs/domainspecs/healthcare/zero-trust.domain.md @docs/governance/coding-standards.md @docs/domainspecs/healthcare/coding-standards.domain.md @docs/governance/dependency-policy.md @docs/domainspecs/healthcare/dependency-policy.domain.md @docs/governance/api-versioning.md @docs/domainspecs/healthcare/api-versioning.domain.md @docs/glossary/ai-rules.md @docs/domainspecs/healthcare/ai-rules.domain.md
-
-MANUAL TEXT (the prompt portion, for reference)
-  Implement the RegisterPatient tasks exactly per the loaded standards. Generate the
-  complete vertical slice (Domain/Persistence/Features/Shared), the Interop/Hl7v2 ADT^A04
-  inbound adapter + outbound ADT emitter (MLLP + ACK, no direct aggregate writes), the
-  FHIR R4 Patient projector, unit + integration + FHIR-validator + HL7-conformance tests,
-  and the EF migration. Honor every NON-NEGOTIABLE: Result pattern, ETag/If-Match
-  concurrency, soft-delete, ATNA audit, minimum-necessary, no PHI in logs, coded value
-  objects, inbound feeds via adapters only, no banned packages. Do not run migrations
-  against shared environments.
-
-
-================================================================================
-QUICK REFERENCE — order of operations (all required for this feature)
-================================================================================
-  (0) /aw-spec-select-domain  ... one-time: set active domain (healthcare) -> .aw-spec/domain.json
- (0b) /aw-spec-constitution   ... one-time, if not yet ratified
-   1. /aw-spec-specify        ... Patient/RegisterPatient + domain/glossary + HL7 context
-   2. /aw-spec-clarify        ... correctness gate: resolve HL7/PHI/identity ambiguities
-   3. /aw-spec-plan           ... architecture + domain + HL7/eventing + security + governance
-   4. /aw-spec-tasks          ... tasks-set + HL7 adapter/conformance tasks
-   5. /aw-spec-analyze        ... correctness gate: spec<->plan<->tasks + NON-NEGOTIABLE coverage
-   6. /aw-spec-implement      ... full build: slice + HL7 adapters + FHIR + tests + migration
-
-All steps after /aw-spec-specify auto-resolve specs/Patient/RegisterPatient/ from
-.aw-spec/feature.json — do not repeat the Patient/RegisterPatient token.
-
-HL7 v2 is threaded through every step (docs/domainspecs/healthcare/hl7.md + docs/domainspecs/healthcare/eventing.domain.md) because inbound
-ADT^A04 ingestion and outbound ADT emission are first-class surfaces of this feature, not an
-afterthought — interoperability is a NON-NEGOTIABLE constitution principle (XIV).

package/assets/docs/pharma-constitution.my-ref.md

@@ -1,86 +0,0 @@
-# Pharma Constitution — Domain Addenda
-
-> **Domain addenda to the technology constitution.** Not ratified on its own — compose it with
-> the technology base.
-
-## How to use (compose-at-ratification)
-
-The technology base (`docs/technology-constitution.md`) **auto-loads** for `/aw-spec-constitution`,
-so you pass only this domain addenda:
-
-```
-/aw-spec-constitution @docs/pharma-constitution.md
-```
-
-This file supplies **only** the pharma deltas: project identity, regulatory posture, the pharma
-domain principles (which **continue** the technology numbering at **XVI**), folder additions,
-governance overrides, and the active-domain pointer. The reusable principles I–XV live in the
-technology base and are not repeated here.
-
-Active domain folder: `docs/domainspecs/pharma/` (set via `/aw-spec-select-domain pharma`).
-
-## Project Identity (fills the technology base)
-
-- **Project name:** `<SampleProjectName>` — Medicinal Product Registry (Headless API).
-- **Mission:** maintain a centralized, authoritative registry of medicinal products in compliance with pharmaceutical industry standards, regulatory requirements, and healthcare interoperability specifications; exposed as a headless HTTP + FHIR API ready for integration with prescribing, dispensing, manufacturing, pharmacovigilance, and clinical systems.
-- **Bounded contexts (modules):** enumerated in `docs/domainspecs/pharma/domain-requirements.md` (project-specific).
-- **Architecture posture:** Modular Monolith with Clean Architecture + DDD; `MedicinalProduct` is the Aggregate Root; each module designed for clean extraction into an independent microservice. **HEADLESS.**
-
-## Regulatory Posture
-
-Built for regulatory compliance **readiness** — auditability, traceability, data integrity, and
-provenance are designed in. Data-integrity expectations follow **ALCOA+** for GxP-relevant
-product records. Identifier standards (NDC), substance identity (UNII), classification (WHO
-ATC), and ISO IDMP concept alignment are first-class. Data residency configurable per deployment.
-
-## Domain Principles
-
-> Extend the technology Core Principles; numbering **continues from XV**.
-
-### XVI — Pharmaceutical Product Identification (NON-NEGOTIABLE)
-NDC modeled as a Value Object with discrete Labeler/Product/Package segments; NDC uniqueness enforced (aggregate + persistence constraint); NDC validation rules configurable; no invented NDC/Labeler codes. The domain model aligns with ISO IDMP concepts (Medicinal Product, Manufactured Item, Pharmaceutical Product, Substance, MAH, Packaging, Strength, Route of Administration).
-→ `docs/domainspecs/pharma/ndc.md`, `idmp.md`
-
-### XVII — Pharma Terminology & Classification (NON-NEGOTIABLE)
-Coded data uses standard terminologies — UNII (substances), RxNorm (clinical drug), SNOMED CT (dose form / route / classification), UCUM (units), and WHO ATC (therapeutic classification). Every coded field is a Codeable value object; lookup/validation via the Terminology module; ATC codes validated against configured code sets (multiple ATC per product allowed); no invented or free-text codes.
-→ `docs/domainspecs/pharma/terminology.md`, `atc.md`
-
-### XVIII — Regulatory Compliance: Audit, Provenance & Versioning (NON-NEGOTIABLE)
-Immutable audit records (User, Timestamp, Action, Previous Value, New Value) for product creation, modification, retirement, identifier changes, and classification changes; `AuditRecord` is append-only. Provenance captured for externally sourced product data (source, method, agent, timestamp). Full version history of product information; historical versions remain queryable. Extends technology **X** and **XIV** with pharma compliance controls.
-→ `docs/domainspecs/pharma/regulatory-compliance.md`, `data-provenance.md`, `auditing.domain.md`, `persistence.domain.md`
-
-### XIX — Medicinal Product Lifecycle Integrity (NON-NEGOTIABLE)
-MedicinalProduct lifecycle (Draft → Under Review → Approved → Active → Discontinued/Withdrawn) is a guarded state machine; only valid transitions are permitted; registration completeness (required attributes, ≥ 1 active ingredient, ≥ 1 packaging, valid NDC/dosage-form/route/ATC) is enforced before leaving Draft; retirement is a logical state change, never a hard delete. Each transition emits a domain event and is audit-mandatory.
-→ `docs/domainspecs/pharma/product-lifecycle.domain.md`, `domain-driven-design.domain.md`, `eventing.domain.md`
-
-### XX — Healthcare Interoperability Readiness
-The model maps to FHIR Medication / MedicationKnowledge / Substance / Organization (projections, not the system of record); product identifiers map to FHIR Identifier; coded fields map to CodeableConcept/Coding; the solution supports future HL7-based integration via Interop adapters. Extends technology **XII** and **XIV** with the FHIR contract.
-→ `docs/domainspecs/pharma/fhir.md`, `hl7.md`
-
-## Folder Structure Additions
-
-- Pharma additions (Interop/Fhir + Hl7v2 adapters, InteropTests, terminology seed fixtures, provenance/version-history stores): `docs/domainspecs/pharma/folder-structure.domain.md`
-
-## Security & Governance Addenda
-
-- **Change authority** (who may register / approve / retire products, and change identifiers or classification): `docs/domainspecs/pharma/authorization.domain.md`
-- **Data classification** (public vs commercially-sensitive / pre-market / externally-sourced; GxP/ALCOA+ integrity): `docs/domainspecs/pharma/data-classification.domain.md`
-- **Zero-trust posture** (transport, scope/trace propagation, change-authority enforcement): `docs/domainspecs/pharma/zero-trust.domain.md`
-- **Coding standards** (forbidden patterns, quality gates): `docs/domainspecs/pharma/coding-standards.domain.md`
-- **API/contract versioning** (FHIR + NDC identifier stability): `docs/domainspecs/pharma/api-versioning.domain.md`
-- **Dependency policy** (FHIR SDK, terminology libraries, regulatory suitability): `docs/domainspecs/pharma/dependency-policy.domain.md`
-
-## AI Rules Addenda
-
-- Identifier/code safety (no invented NDC/UNII/RxNorm/SNOMED/ATC), projection discipline, lifecycle/audit edit limits, pharma refusal conditions: `docs/domainspecs/pharma/ai-rules.domain.md` (extends `docs/glossary/ai-rules.md`)
-
-## Governance Overrides
-
-- Mandatory approver for any identifier (NDC), classification (ATC), or lifecycle-rule change: Regulatory/Compliance Officer (in addition to a Principal Engineer and a Domain Owner). Change-authority roles are defined in `docs/domainspecs/pharma/authorization.domain.md`.
-- Additional review required after every relevant regulatory or terminology-release update (e.g. WHO ATC annual update, FDA NDC directory changes).
-- **Versioning note:** any change to NDC identity rules, the lifecycle state machine, the audit-record shape, or the canonical FHIR interoperability surface is a MAJOR bump.
-
-## Domain Requirements Pointer
-
-→ `docs/domainspecs/pharma/domain-requirements.md`
-(`[DOMAIN: Bounded Contexts / Modules]`, per-subsection pointers, `[DOMAIN: Platform Topology]`, `[DOMAIN: Governance Overrides]`).