aw-spec-cli 0.1.5 → 0.1.6

package/assets/docs/domainspecs/pharma/atc.md

@@ -1,22 +0,0 @@
-# ATC — WHO Anatomical Therapeutic Chemical Classification
-
-> NON-NEGOTIABLE. Commands: `/aw-spec-constitution`, `/aw-spec-specify`.
-
-## Value Object
-- ATC is the **`AtcCode` value object** — immutable, equality by value (see [[domain-driven-design.domain]]); carries code, ATC system URI, **ATC edition/version** (WHO updates annually), display.
-- Free-text storage of a therapeutic class is a Forbidden Pattern.
-
-## Multiplicity
-- **Multiple ATC codes MAY attach to one `MedicinalProduct`** (a collection of `AtcCode` VOs).
-- The 7-character hierarchy (anatomical → therapeutic → pharmacological → chemical subgroup → substance) SHALL be representable; level is derivable from code length.
-
-## Validation
-- **ATC codes SHALL be validated against configured code sets** — the bound edition is value-set data via the Terminology module (see [[terminology]]).
-- An ATC code absent from the configured set is rejected; the Domain MUST NOT persist an unvalidated ATC code; never invent ATC codes (see [[ai-rules.domain]]).
-- Changing a product's ATC is a **classification change** — audit-mandatory (see [[auditing.domain]]).
-
-## FHIR mapping
-- ATC → FHIR `Medication.code` / `MedicationKnowledge` classification codings (`CodeableConcept`, ATC system URI) (see [[fhir]]).
-
-## Related
-- [[terminology]] · [[domain-driven-design.domain]] · [[fhir]] · [[auditing.domain]] · [[ai-rules.domain]]

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

@@ -1,90 +0,0 @@
-# Auditing — Pharma Domain Addenda
-
-> Technology base: [[auditing]]. NON-NEGOTIABLE. Consumed by `/aw-spec-specify` (LIFTS the
-> auditing requirement into the spec) and `/aw-spec-gate` (VALIDATES the spec/design realise it).
-> `/aw-spec-design` and `/aw-spec-implement` never load this file — auditing reaches them through
-> the spec's **declared audit level per aggregate**, and the enablement mechanics live in the
-> technical base [[auditing]]. Keep this file technology-agnostic (levels + rules, **no code**).
-
-## Two auditing levels (framework-supported)
-
-AppWeaver auditing has exactly **two levels**; the framework's audit interceptor populates every
-audit field automatically (handlers NEVER assign audit fields):
-
-| Level | Captures | Depth |
-|---|---|---|
-| **Basic** | who/when lifecycle — created / modified / (soft-)deleted, by whom and when; one audit entry per aggregate root per save (who · action · resource type · resource id · timestamp · correlation) | entity-level (Created/Updated/Deleted) — **no** before/after values |
-| **Advanced** | everything Basic captures **plus field-level before/after** — each changed property's previous → new value | entity-level **+ property-level previous/new value** |
-
-- **Advanced is REQUIRED whenever the spec asks for "previous value / new value"** — before/after
-  values exist ONLY at the Advanced tier.
-- Child entities fold their changes into the owning aggregate root's audit entry.
-
-> Code realisation — marker interfaces (Basic = `IAuditedObject` / `IFullAuditedObject`; Advanced =
-> `+ IFieldAudited`), the one-time composition, and the audit query API — lives in the technical
-> base. See [[auditing]]; `/aw-spec-design` and `/aw-spec-implement` get the HOW from there.
-
-## Aggregate assignment rule (how specify decides the level)
-
-`/aw-spec-specify` MUST assign an audit level to every aggregate it models and LIFT it into the
-spec as an explicit, developer-editable declaration:
-
-- The **main aggregate** of the requirement (the aggregate root the story is about) → **Advanced**.
-- **Supporting aggregates** (collaborating/referenced roots) → **Basic** by default.
-- A developer MAY raise or lower a level afterwards by editing the spec declaration — the level is
-  a **spec** decision, never a design or implementation one. `/aw-spec-design` then follows the
-  declared level.
-
-Lift it as one line the gate can check, e.g. under Constraints:
-
-> **CN-0xx**: Auditing level — `<MainAggregate>` uses **Advanced** (field-level before/after)
-> auditing; `<SupportingAggregate…>` use **Basic** (lifecycle) auditing; creation is
-> audit-mandatory and append-only. — lifted from auditing.domain.
-
-Declare the **level** — do NOT enumerate the audit record's field shape in the spec (next section).
-
-## Spec-required vs framework-emitted (what the gate checks)
-
-The audit record's field shape is **framework-emitted** — the interceptor populates it; it is NOT
-spec-authored content. Fields the platform always supplies:
-
-- `resourceType`, `resourceId`, `correlationId`, `tenantId`, and the physical record layout.
-
-Split for the gate:
-
-- **Spec-required** (specify lifts it; the gate checks the spec + design carry it): the **audit
-  level per aggregate**; that creation is **audit-mandatory** and **append-only**; and the
-  business-meaningful capture — **User, Timestamp, Action, Previous Value, New Value** (the last
-  two imply Advanced).
-- **Framework-emitted** (NEVER a spec/design gap — always populated by the platform): the fields
-  listed above. The gate MUST NOT raise a LIFT-FAILURE for them; they are guaranteed by the
-  framework, not authored in the spec.
-
-## Queryable audit (framework-provided)
-
-The audit store is queryable out of the box (by resource identity, by user, by tenant, and by
-action/time with paging — see [[auditing]]). A spec "queryable creation audit record for
-compliance" success criterion is therefore satisfied by the framework's audit query API; design
-references it and does **NOT** need a bespoke audit read port/model.
-
-## Setup (pharma)
-
-- Auditing is **MANDATORY** for `MedicinalProduct` (**Advanced**) and its child entities
-  (`ActiveIngredient`, `PackagingConfiguration`, `MarketingAuthorization` — folded into the
-  product's audit entry).
-- Audit-mandatory operations: product **creation**, **modification**, **retirement**
-  (Discontinued/Withdrawn), **identifier changes** (NDC / Package NDC), **classification changes**
-  (ATC) — plus every lifecycle transition and authorized admin action (see
-  [[product-lifecycle.domain]], [[ndc]], [[atc]]).
-
-## Immutability & retention
-
-- Audit records (log · entity change · property change) are **append-only** — no update, no delete
-  (see [[domain-driven-design.domain]], [[persistence.domain]]).
-- Retained per regulatory policy, queryable for the full window; exportable, MAY project to FHIR
-  `AuditEvent` / `Provenance` (see [[fhir]], [[data-provenance]]).
-- Audit + domain events + version snapshots give end-to-end traceability (see
-  [[regulatory-compliance]], [[eventing.domain]]).
-
-## Related
-- [[auditing]] · [[regulatory-compliance]] · [[data-provenance]] · [[persistence.domain]] · [[product-lifecycle.domain]] · [[ndc]] · [[atc]] · [[cqrs.domain]] · [[eventing.domain]] · [[fhir]] · [[domain-driven-design.domain]]

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

@@ -1,25 +0,0 @@
-# Authorization — Pharma Domain Addenda
-
-> Technology base: [[authorization]]. Commands: `/aw-spec-constitution`, `/aw-spec-specify`, `/aw-spec-gate`.
-
-## Roles
-`SystemAdmin`, `RegulatoryOfficer`, `ProductSteward`, `TerminologyManager`, `DataManager`, `ReadOnlyConsumer`, `ExternalSystem`. Per-route matrix: `docs/security/authorization-matrix.md`.
-
-## Change authority
-- **Only `RegulatoryOfficer`** performs guarded lifecycle transitions — approve / activate / discontinue / withdraw (see [[product-lifecycle.domain]]).
-- `ProductSteward` creates/edits a `Draft` and submits for review; MUST NOT approve/activate/retire.
-- **NDC and ATC changes require `RegulatoryOfficer`** authority (or `ProductSteward` + documented `RegulatoryOfficer` sign-off) (see [[ndc]], [[atc]], [[auditing.domain]]).
-- `TerminologyManager` owns `CodeSystem`/`ValueSet`/`ConceptMap` + version changes (see [[terminology]]).
-- `DataManager` runs external imports; each attaches a `ProvenanceRecord` (see [[data-provenance]]).
-
-## Scope enforcement
-- FHIR endpoints scope-enforced (`system/Medication.read`, `system/Substance.read`, `system/*.write` for authorized backends). **No patient-context (SMART) scope** — product master data, not patient data (see [[fhir]], [[zero-trust.domain]]).
-
-## Audit-mandatory
-Every product create/modify/retire, identifier change, classification change, lifecycle transition, terminology change, external import, privileged admin/role change (see [[auditing.domain]]).
-
-## Anonymous allowlist
-- `/fhir/metadata` (CapabilityStatement) and `/health`; no write or product-data endpoint is anonymous (see [[fhir]]).
-
-## Related
-- [[authorization]] · [[product-lifecycle.domain]] · [[ndc]] · [[atc]] · [[terminology]] · [[data-provenance]] · [[auditing.domain]] · [[data-classification.domain]] · [[fhir]] · [[zero-trust.domain]]

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

@@ -1,28 +0,0 @@
-# Coding Standards — Pharma Domain Addenda
-
-> Technology base: [[coding-standards]]. Commands: `/aw-spec-gate`.
-
-## Coded value objects
-- Follow the FHIR pattern: `Codeable`, `Coding`, `Quantity`, `Ratio`, `Identifier` (see [[terminology]], [[fhir]]).
-- Spec-mandated names: `NdcCode`, `ProductName`, `GenericName`, `Strength`, `DosageForm`, `RouteOfAdministration`, `AtcCode`, `MarketingStatus`, `PackageIdentifier` (see [[domain-driven-design.domain]]).
-- Domain may throw `InvalidNdcException`, `InvalidLifecycleTransitionException`, `UnvalidatedCodeException` (see [[ndc]], [[product-lifecycle.domain]], [[terminology]]).
-
-## Forbidden patterns — extend [[coding-standards]]
-- **P1.** Hard delete of a `MedicinalProduct`, version history, or `AuditRecord` — use lifecycle retirement / logical delete (see [[persistence.domain]], [[product-lifecycle.domain]]).
-- **P2.** Hard-coded NDC/Labeler/ATC/UNII/RxNorm/SNOMED literals outside the Terminology seed (see [[terminology]], [[ndc]], [[atc]]).
-- **P3.** Storing NDC, dosage form, route, ATC, or strength as **free text** when a value object/code applies (see [[terminology]]).
-- **P4.** A second FHIR write path bypassing the aggregate (see [[fhir]]).
-- **P5.** Persisting a product with an invalid NDC, dosage form, route, or unvalidated ATC code (see [[ndc]], [[atc]], [[terminology]]).
-- **P6.** Mutating a contained entity (`ActiveIngredient`/`PackagingConfiguration`/`MarketingAuthorization`) outside the aggregate root (see [[domain-driven-design.domain]]).
-- **P7.** Allowing an invalid lifecycle transition or removing a transition guard (see [[product-lifecycle.domain]]).
-- **P8.** Exposing `Draft`/pre-market product data on the public surface (see [[data-classification.domain]]).
-
-## Quality gates — extend [[coding-standards]]
-- **PG1.** FHIR CapabilityStatement regenerates cleanly; FHIR validator passes for every modified Medication/MedicationKnowledge/Substance/Organization resource (see [[fhir]]).
-- **PG2.** No invented NDC/ATC/UNII/RxNorm/SNOMED codes — codes resolve against value sets (grep + tests; see [[terminology]]).
-- **PG3.** NDC uniqueness + format + duplicate-detection tests pass (see [[ndc]]).
-- **PG4.** Lifecycle state-machine tests pass — every allowed + every rejected transition (see [[product-lifecycle.domain]], [[testing.domain]]).
-- **PG5.** Audit-emission tests cover create/modify/retire/identifier/classification with required fields (see [[auditing.domain]]).
-
-## Related
-- [[coding-standards]] · [[terminology]] · [[ndc]] · [[atc]] · [[fhir]] · [[domain-driven-design.domain]] · [[product-lifecycle.domain]] · [[persistence.domain]] · [[data-classification.domain]] · [[auditing.domain]] · [[testing.domain]]

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

@@ -1,108 +0,0 @@
-# Pharma Domain — Command → Rule-File Map
-
-Per-command list of the **pharma domain** rule files loaded (via `resolve-domain` +
-the `domain-select` module, into the sticky standards set) for the spec-anchored
-orchestrator pipeline.
-
-**The model (see `.aw-spec/RULE-PARTITION.md`):** domain files feed
-only three consumers — **specify** (authors them into the spec as FR/BR/CN-/DC-/IC-),
-**constitution** (the domain principles), and the **gates** (conformance checklist).
-**design** and **implement** load **NO** domain file — the domain reaches them solely
-through the spec/design (as CN-/DC-/IC- ids). This is what keeps design authoring from
-the spec + technical standards and the tech base swappable.
-
-- All paths are workspace-relative and live in `docs/domainspecs/pharma/`.
-- `resolve-domain --command <name>` collects the `- ` bullets under `## /<name>`.
-- This file is the **canonical source** for the pharma domain mapping; `/aw-spec-orch
-  select-domain` selects this folder as active.
-
----
-
-## /aw-spec-constitution
-<!-- Domain identity/regulatory/interop sources that become domain principles XVI+ in
-     constitution.domain.md (authored from docs/pharma-constitution.my-ref.md + these). -->
-- docs/domainspecs/pharma/domain-requirements.md
-- docs/domainspecs/pharma/ndc.md
-- docs/domainspecs/pharma/idmp.md
-- docs/domainspecs/pharma/atc.md
-- docs/domainspecs/pharma/terminology.md
-- docs/domainspecs/pharma/pharma-terms.md
-- docs/domainspecs/pharma/product-lifecycle.domain.md
-- docs/domainspecs/pharma/regulatory-compliance.md
-- docs/domainspecs/pharma/data-provenance.md
-- docs/domainspecs/pharma/fhir.md
-- docs/domainspecs/pharma/hl7.md
-- docs/domainspecs/pharma/data-classification.domain.md
-- docs/domainspecs/pharma/auditing.domain.md
-- docs/domainspecs/pharma/authorization.domain.md
-- docs/domainspecs/pharma/zero-trust.domain.md
-- docs/domainspecs/pharma/ai-rules.domain.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). -->
-- docs/domainspecs/pharma/domain-requirements.md
-- docs/domainspecs/pharma/domain-driven-design.domain.md
-- docs/domainspecs/pharma/product-lifecycle.domain.md
-- docs/domainspecs/pharma/ndc.md
-- docs/domainspecs/pharma/idmp.md
-- docs/domainspecs/pharma/atc.md
-- docs/domainspecs/pharma/pharma-terms.md
-- docs/domainspecs/pharma/terminology.md
-- docs/domainspecs/pharma/integration-terms.md
-- docs/domainspecs/pharma/regulatory-compliance.md
-- docs/domainspecs/pharma/data-provenance.md
-- docs/domainspecs/pharma/fhir.md
-- docs/domainspecs/pharma/hl7.md
-- docs/domainspecs/pharma/data-classification.domain.md
-- docs/domainspecs/pharma/persistence.domain.md
-- docs/domainspecs/pharma/cqrs.domain.md
-- docs/domainspecs/pharma/eventing.domain.md
-- docs/domainspecs/pharma/auditing.domain.md
-- docs/domainspecs/pharma/authorization.domain.md
-- docs/domainspecs/pharma/zero-trust.domain.md
-- docs/domainspecs/pharma/api-versioning.domain.md
-- docs/domainspecs/pharma/vertical-slices.domain.md
-
-## /aw-spec-design
-_None — design loads no domain file. Domain reaches design only through the spec (BR-/CN-/DC-/IC-)._
-
-## /aw-spec-implement
-_None — implement loads no domain file. Domain reaches implement only through design.md. Framework
-components are added separately via `/aw-spec-orch add-component`._
-
-## /aw-spec-gate
-<!-- Conformance checklist for the gates (analyze-design · analyze-slice): the domain-derived
-     constraints design/implement were NOT given as authoring input, VALIDATED against the
-     output. Domain re-enters here as a check, never as authoring input. -->
-- docs/domainspecs/pharma/persistence.domain.md
-- docs/domainspecs/pharma/cqrs.domain.md
-- docs/domainspecs/pharma/eventing.domain.md
-- docs/domainspecs/pharma/auditing.domain.md
-- docs/domainspecs/pharma/authorization.domain.md
-- docs/domainspecs/pharma/zero-trust.domain.md
-- docs/domainspecs/pharma/data-classification.domain.md
-- docs/domainspecs/pharma/api-versioning.domain.md
-- docs/domainspecs/pharma/vertical-slices.domain.md
-- docs/domainspecs/pharma/folder-structure.domain.md
-- docs/domainspecs/pharma/coding-standards.domain.md
-- docs/domainspecs/pharma/dependency-policy.domain.md
-- docs/domainspecs/pharma/testing.domain.md
-- docs/domainspecs/pharma/ai-rules.domain.md
-
----
-
-## Quick reference (command → domain file count)
-
-| Command | Domain rule files | Role |
-|---|---|---|
-| /aw-spec-constitution | 16 | domain principles (XVI+) |
-| /aw-spec-specify | 22 | author into spec (lift → CN-/DC-/IC-) |
-| /aw-spec-design | 0 | none — spec is the only domain input |
-| /aw-spec-implement | 0 | none — design is the only domain input |
-| /aw-spec-gate | 14 | conformance checklist (validate, don't author) |
-
-> Retired in the orchestrator pipeline: `/aw-spec-plan`, `/aw-spec-tasks`, `/aw-spec-taskplan`,
-> `/aw-spec-clarify`, `/aw-spec-analyze` (clarify folds into specify; plan/tasks into design). The
-> collapsed tiers `/aw-spec-fast-implement` and `/aw-spec-minimal-implementation` are pending a ruling
-> (they fold design+implement into one pass, which needs internal context staging to keep the partition).

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

@@ -1,119 +0,0 @@
-# Pharma Domain — Command → Technical-Rule-File Map
-
-Per-command list of the **technical** rule files loaded (via `resolve-tech` + the
-`tech-select` module, into the sticky standards set) for the spec-anchored
-orchestrator pipeline. This is the technical counterpart of `comandrulemap.md`
-(which maps the DOMAIN rule files).
-
-**The model:** the technical rule files (the `docs/architecture` · `docs/security` ·
-`docs/interop` · `docs/governance` set that used to be HARDCODED in each workflow's
-`standards:` block) are now CONFIGURATION — tune this map, not the workflows. The
-technology base itself (`constitution.technical.md`) is NOT listed here — every
-consumer still refers to it directly, as-is.
-
-- All paths are workspace-relative technical rule files (domain-agnostic docs/…).
-- `resolve-tech --command <name>` collects the `- ` bullets under `## /<name>`.
-- This file is the **canonical technical mapping** for the pharma domain; it is
-  selected whenever pharma is the active domain (`.aw-spec/domain.json`).
-- A command with no heading here loads no mapped technical file (only the workflow's
-  universal `ai-rules.md` seed + `constitution.technical.md`, referred to directly).
-- `## /aw-spec-specify` is the one **modelling-methodology** slot (see the rule partition):
-  a domain-agnostic way of *modelling*, never a technology choice. Everything below it is a
-  HOW-phase technical set.
-
----
-
-## /aw-spec-specify
-<!-- MODELLING METHODOLOGY ONLY. Specify is the domain phase: the single technical input it
-     may take is a domain-agnostic way of MODELLING (DDD tactical patterns), never a
-     technology choice. Do NOT add an architecture / persistence / codegen file here — that
-     would break specify's domain purity (design/implement own those). The domain's own DDD
-     overlay (domain-driven-design.domain.md) arrives separately via comandrulemap. -->
-- docs/domain/domain-driven-design.md
-
-## /aw-spec-design
-<!-- The technical/architecture rule files the design author works from (alongside the
-     spec and constitution.technical.md). NO domain file here — domain reaches design
-     only as spec ids (BR-/CN-/DC-/IC-). -->
-- docs/architecture/clean-architecture.md
-- docs/architecture/cqrs.md
-- docs/architecture/eventing.md
-- docs/architecture/modular-monolith.md
-- docs/architecture/vertical-slices.md
-- docs/architecture/persistence.md
-- docs/architecture/folder-structure.md
-- docs/architecture/testing.md
-- docs/governance/api-versioning.md
-- docs/security/zero-trust.md
-- docs/security/authorization.md
-- docs/security/authorization-matrix.md
-- docs/security/auditing.md
-- docs/security/data-classification.md
-- docs/interop/ihe-conformance.md
-
-## /aw-spec-implement
-<!-- The FRAMEWORK / code-generation rule files the code generator builds against
-     (alongside design.md and constitution.technical.md). NO domain file — domain
-     reaches implement only through design.md. clean-architecture/cqrs are design
-     concerns; component wiring is a separate /aw-spec-orch add-component step. -->
-- docs/governance/coding-standards.md
-- docs/governance/dependency-policy.md
-- docs/architecture/folder-structure.md
-- docs/architecture/testing.md
-- docs/VerticalSlice/PACKAGING.md
-
-## /aw-spec-implement-delta
-<!-- The CR analog of implement — same FRAMEWORK / code-generation set (HOW to build).
-     The delta's code is generated against the master design.md + delta-design.md; no
-     domain file (domain reached the delta via delta-spec → delta-design). -->
-- docs/governance/coding-standards.md
-- docs/governance/dependency-policy.md
-- docs/architecture/folder-structure.md
-- docs/architecture/testing.md
-- docs/VerticalSlice/PACKAGING.md
-
-## /aw-spec-build
-<!-- The compile/fix reference set: the layering + coding rules the fixer respects when
-     repairing compile errors against the design intent. NO domain file (build loads
-     domain rules separately via domain-select) and no constitution.technical here. -->
-- docs/architecture/clean-architecture.md
-- docs/governance/coding-standards.md
-
-## /aw-spec-analyze-slice
-<!-- The design↔code conformance gate's TECHNICAL checklist: the code + tests are
-     validated against these (alongside the DOMAIN gate overlays, loaded separately via
-     resolve-domain `## /aw-spec-gate`). Validation input only — never authoring. -->
-- docs/architecture/testing.md
-- docs/governance/coding-standards.md
-
-## /aw-spec-constitution
-<!-- The technology-constitution base the TECHNICAL half of the split constitution
-     ratifies into constitution.technical.md. Loaded BEFORE the technical half and before
-     domain-select, so the technical author stays domain-free (the seam). NO domain file
-     here — the domain half's sources are the domain map's ## /aw-spec-constitution. -->
-- docs/technology-constitution.md
-
-## /aw-spec-run
-<!-- Execution / data migration: the persistence rules the migration step generates against.
-     NO domain file; run does not reference constitution.technical.md. -->
-- docs/architecture/persistence.md
-
----
-
-## Quick reference (command → technical file count)
-
-| Command | Technical rule files | Role |
-|---|---|---|
-| /aw-spec-specify | 1 | the modelling methodology (DDD) the domain model is expressed in — no technology |
-| /aw-spec-design | 15 | architecture/security/interop the design author mediates the spec against |
-| /aw-spec-implement | 5 | governance/architecture the code generator builds against (from design.md) |
-| /aw-spec-implement-delta | 5 | same code-generation set, scoped to the open change's delta-design |
-| /aw-spec-build | 2 | layering + coding rules the compile-fixer respects |
-| /aw-spec-analyze-slice | 2 | testing + coding rules the design↔code gate validates against |
-| /aw-spec-constitution | 1 | the technology-constitution base the technical half ratifies |
-| /aw-spec-run | 1 | persistence rules the execution / data-migration step generates against |
-
-> All migrated workflows are on this map. The conformance-gate workflows **analyze-design**
-> and **analyze-delta-design** are intentionally NOT here — they validate design/delta
-> against the spec + DOMAIN gate overlays only (comandrulemap `## /aw-spec-gate`), with no
-> technical gate checklist.

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

@@ -1,16 +0,0 @@
-# CQRS — Pharma Domain Addenda
-
-> Technology base: [[cqrs]]. Commands: `/aw-spec-specify`, `/aw-spec-gate`.
-
-## Pipeline
-- Append a **product-audit behavior** to the mediator pipeline: every create/modify/retire/re-identify/reclassify command on `MedicinalProduct` MUST emit an immutable audit record (User, Timestamp, Action, Previous Value, New Value). See [[auditing.domain]], [[regulatory-compliance]].
-
-## Commands & queries
-- Registration, lifecycle transitions, ingredient/packaging edits, identifier & classification changes = **commands**; each publishes its domain event (see [[eventing.domain]], [[product-lifecycle.domain]]).
-- Product lookup, version history, FHIR projections = **queries** via `IReadRepository<MedicinalProduct>` + a `Specification` (see [[persistence.domain]]).
-
-## Error codes
-`medicinal-product.not_found` · `ndc.duplicate` · `ndc.invalid_format` · `dosage-form.invalid` · `route.invalid` · `atc.invalid_code` · `lifecycle.invalid_transition` · `concurrency.conflict`.
-
-## Related
-- [[cqrs]] · [[auditing.domain]] · [[eventing.domain]] · [[product-lifecycle.domain]] · [[persistence.domain]] · [[domain-driven-design.domain]] · [[regulatory-compliance]]

package/assets/docs/domainspecs/pharma/data-classification.domain.md

@@ -1,24 +0,0 @@
-# Data Classification — Pharma Domain Addenda
-
-> Technology base: [[data-classification]]. Commands: `/aw-spec-constitution`, `/aw-spec-specify`, `/aw-spec-gate`.
-
-> No PHI — the model is commercial confidentiality, regulatory integrity, and source trust.
-
-## Categories
-| Class | Extra rules |
-|---|---|
-| **Public / Published** (NDC-directory disclosure level) | Projectable via the public FHIR surface once `MarketingStatus` is active |
-| **Commercially-Sensitive** (pre-market formulations, proprietary strengths, unpublished products) | Access-restricted; **MUST NOT** be on the public FHIR surface until marketing status permits |
-| **Regulatory-Submission** (MA dossier refs, regulator keys) | Restricted; audited access (see [[auditing.domain]]) |
-| **Externally-Sourced** (FDA NDC / RxNorm / WHO ATC / partner feeds) | Carries a `ProvenanceRecord`; still validated (see [[data-provenance]]) |
-
-## Data integrity (GxP / ALCOA+)
-- GxP records satisfy **ALCOA+** (Attributable, Legible, Contemporaneous, Original, Accurate + Complete, Consistent, Enduring, Available), enforced via immutable audit, provenance, version history (see [[auditing.domain]], [[data-provenance]], [[persistence.domain]], [[regulatory-compliance]]).
-
-## Exposure & logging
-- `Draft`/`Under Review` or non-public `MarketingStatus` products MUST NOT be published on the public FHIR/REST surface (see [[product-lifecycle.domain]], [[fhir]]).
-- Externally-sourced values are never published without passing validation (see [[ndc]], [[atc]], [[terminology]]).
-- Commercially-sensitive pre-market details MUST NOT appear in logs/metrics/traces — log the product ID only (see [[coding-standards.domain]]).
-
-## Related
-- [[data-classification]] · [[data-provenance]] · [[auditing.domain]] · [[persistence.domain]] · [[regulatory-compliance]] · [[product-lifecycle.domain]] · [[authorization.domain]] · [[coding-standards.domain]] · [[ndc]] · [[atc]] · [[fhir]]

package/assets/docs/domainspecs/pharma/data-provenance.md

@@ -1,21 +0,0 @@
-# Data Provenance Standards — Pharma
-
-> NON-NEGOTIABLE. Commands: `/aw-spec-constitution`, `/aw-spec-specify`.
-
-## First-class concern
-- Any product attribute imported from an external source (FDA NDC directory, RxNorm, WHO ATC, an MAH submission, a partner feed) SHALL carry a **`ProvenanceRecord`** (Provenance module).
-- Provenance is captured at ingestion through the Interop adapters — never back-filled by guessing (see [[hl7]], [[fhir]], [[ai-rules.domain]]).
-
-## Record (minimum)
-```
-{ source, sourceSystem, sourceVersion, method, agent, timestamp, importedFields[], correlationId }
-```
-- **sourceVersion** = originating authority's release/version (e.g. terminology edition; see [[terminology]], [[atc]]); **method** = automated import / manual entry / API sync; **agent** = responsible principal.
-
-## Integrity
-- Complements audit (who/when/what; see [[auditing.domain]]) and version history (see [[persistence.domain]]).
-- Provenance does **not** exempt an NDC/ATC/UNII value from validation (see [[ndc]], [[atc]], [[terminology]]).
-- MAY project to the FHIR `Provenance` resource (see [[fhir]]).
-
-## Related
-- [[auditing.domain]] · [[persistence.domain]] · [[terminology]] · [[ndc]] · [[atc]] · [[fhir]] · [[regulatory-compliance]] · [[ai-rules.domain]]

package/assets/docs/domainspecs/pharma/dependency-policy.domain.md

@@ -1,11 +0,0 @@
-# Dependency Policy — Pharma Domain Addenda
-
-> Technology base: [[dependency-policy]]. Commands: `/aw-spec-gate`.
-
-## Reviews & libraries
-- Every new dependency gets a **regulatory-suitability** review beyond the generic license/supply-chain check — reject packages that phone home or ship analytics by default (leak risk for commercially-sensitive pre-market data) (see [[data-classification.domain]]).
-- FHIR: the **official FHIR .NET SDK**, version-matched to the endpoint (R4/R5; see [[fhir]]).
-- Terminology integrations (RxNorm/SNOMED/UNII/ATC/NDC) go through the Terminology module; client libraries added **only** on explicit developer request — no AI-introduced terminology/interop dependencies (see [[terminology]], [[hl7]], [[ai-rules.domain]]).
-
-## Related
-- [[dependency-policy]] · [[fhir]] · [[hl7]] · [[terminology]] · [[data-classification.domain]] · [[ai-rules.domain]]

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

@@ -1,36 +0,0 @@
-# Domain-Driven Design — Medicinal Product Domain Model
-
-> Technology base: [[domain-driven-design]]. NON-NEGOTIABLE. Commands: `/aw-spec-specify`.
-
-## Modeling
-- Use the pharma/regulatory ubiquitous language (see [[pharma-terms]]), aligned to ISO IDMP concepts (see [[idmp]]).
-- FHIR- and IDMP-aligned, but **FHIR resources are projections, not the system of record** (see [[fhir]]); the aggregate is authoritative.
-- Coded concepts use industry terminologies, never free text (see [[terminology]]); coded VOs follow the FHIR pattern (`Codeable`, `Coding`, `Quantity`, `Ratio`, `Identifier`).
-
-## Aggregate Root
-- **`MedicinalProduct` is the Aggregate Root.** All product data (ingredients, packaging, marketing authorization, identifiers, classification, lifecycle state) is reached/modified **through** it; no external code mutates a contained entity directly. Invariants are enforced atomically; state changes raise domain events (see [[eventing.domain]]).
-
-## Value Objects (immutable, equality by value)
-`NdcCode` · `ProductName` · `GenericName` · `Strength` · `DosageForm` · `RouteOfAdministration` · `AtcCode` · `MarketingStatus` · `PackageIdentifier`
-- `NdcCode`/`PackageIdentifier` — segmented, format-validated, unique (see [[ndc]]).
-- `Strength` — numerator/denominator `Quantity` with UCUM units; `DosageForm`/`RouteOfAdministration`/`AtcCode` — coded against configured value sets (see [[terminology]], [[atc]]).
-
-## Entities (identity within the aggregate)
-- **`ActiveIngredient`** — Name, UNII, Strength, Strength Unit. **>= 1 required.**
-- **`PackagingConfiguration`** — Package NDC, Description, Quantity, Unit of Measure. **>= 1 required.**
-- **`MarketingAuthorization`** — authorization granted to the MAH by a regulator (see [[idmp]]).
-
-## Invariants
-- **MedicinalProduct** — NDC unique + format-valid (invalid blocks persistence); >= 1 ActiveIngredient + >= 1 PackagingConfiguration; all required attributes enforced at registration; dosage form/route must be valid coded values; lifecycle transitions must be valid (see [[product-lifecycle.domain]]); identifier/classification changes are audit-mandatory + emit events (see [[auditing.domain]], [[eventing.domain]]).
-- **PackagingConfiguration** — Package NDC unique within and across products (see [[ndc]]).
-- **ActiveIngredient** — Strength + Strength Unit required; UNII validated where supplied (see [[terminology]]).
-- **AuditRecord** — append-only; no update/delete (see [[auditing.domain]]).
-
-## Validation summary
-NDC format; required attributes; duplicate identifiers; invalid dosage forms; invalid routes; invalid lifecycle transitions (see [[ndc]], [[terminology]], [[product-lifecycle.domain]]).
-
-## AI guidance
-See [[ai-rules.domain]] — confirm signatures, use the official FHIR SDK, never invent NDC/UNII/RxNorm/SNOMED/ATC codes, keep FHIR as projections.
-
-## Related
-- [[domain-driven-design]] · [[product-lifecycle.domain]] · [[ndc]] · [[idmp]] · [[atc]] · [[terminology]] · [[fhir]] · [[eventing.domain]] · [[auditing.domain]] · [[persistence.domain]] · [[pharma-terms]] · [[ai-rules.domain]]

package/assets/docs/domainspecs/pharma/domain-requirements.md

@@ -1,99 +0,0 @@
-# DOMAIN REQUIREMENTS (project-specific)
-
-> Project-specific input, **updated independently per project**. The engineering constitution
-> stays domain-agnostic and supreme; this file holds the per-project enumeration and headline
-> profiles for the **Medicinal Product Registration** domain. 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]
-=====================================================================
-- ProductRegistry — aggregate root: **MedicinalProduct**; owns ActiveIngredient,
-  PackagingConfiguration, MarketingAuthorization entities and the product value objects
-  (NdcCode, ProductName, GenericName, Strength, DosageForm, RouteOfAdministration, AtcCode,
-  MarketingStatus, PackageIdentifier). See [[domain-driven-design.domain]].
-- Substances — aggregates: Substance, ActiveMoiety; UNII-keyed ingredient identity
-  (see [[terminology]]).
-- Organizations — aggregates: Organization, MarketingAuthorizationHolder, Manufacturer,
-  Labeler. Maps to FHIR `Organization` (see [[fhir]]).
-- Classification — aggregates: AtcClassification, ProductClassification; ATC code sets and
-  SNOMED CT classification references (see [[atc]], [[terminology]]).
-- Terminology — aggregates: CodeSystem, ValueSet, ConceptMap (project-managed subsets;
-  expansions cached from external terminology services). Backs NDC/ATC/UNII/SNOMED/RxNorm
-  validation (see [[terminology]]).
-- Lifecycle — the MedicinalProduct state machine (Draft → Under Review → Approved → Active →
-  Discontinued → Withdrawn) and its transition guards (see [[product-lifecycle.domain]]).
-- Interoperability — aggregates: FhirProjection, IntegrationEndpoint; FHIR Medication /
-  MedicationKnowledge / Substance / Organization projections and HL7 readiness
-  (see [[fhir]], [[hl7]]).
-- Provenance — aggregate: ProvenanceRecord for externally sourced product data
-  (see [[data-provenance]]).
-- Auditing — aggregate: AuditRecord (append-only). Captures creation, modification,
-  retirement, identifier and classification changes (see [[auditing.domain]]).
-
-=====================================================================
-[DOMAIN: subsection pointers]
-=====================================================================
-[DOMAIN: Standards — NDC]                      -> docs/domainspecs/pharma/ndc.md
-[DOMAIN: Standards — ISO IDMP]                 -> docs/domainspecs/pharma/idmp.md
-[DOMAIN: Standards — ATC]                      -> docs/domainspecs/pharma/atc.md
-[DOMAIN: Standards — Terminology]              -> docs/domainspecs/pharma/terminology.md
-[DOMAIN: Interop — FHIR]                       -> docs/domainspecs/pharma/fhir.md
-[DOMAIN: Interop — HL7]                        -> docs/domainspecs/pharma/hl7.md
-[DOMAIN: Aggregates and Business Invariants]   -> docs/domainspecs/pharma/domain-driven-design.domain.md
-[DOMAIN: Product Lifecycle]                    -> docs/domainspecs/pharma/product-lifecycle.domain.md
-[DOMAIN: Regulatory / Compliance]              -> docs/domainspecs/pharma/regulatory-compliance.md
-[DOMAIN: Data Provenance]                      -> docs/domainspecs/pharma/data-provenance.md
-[DOMAIN: Audit Profile]                        -> docs/domainspecs/pharma/auditing.domain.md
-[DOMAIN: Persistence / Versioning Profile]     -> docs/domainspecs/pharma/persistence.domain.md
-[DOMAIN: Eventing Profile]                     -> docs/domainspecs/pharma/eventing.domain.md
-[DOMAIN: Testing Profile]                      -> docs/domainspecs/pharma/testing.domain.md
-[DOMAIN: Security Profile]                     -> docs/domainspecs/pharma/authorization.domain.md, docs/domainspecs/pharma/data-classification.domain.md, docs/domainspecs/pharma/zero-trust.domain.md
-[DOMAIN: Coding Standards Profile]             -> docs/domainspecs/pharma/coding-standards.domain.md
-[DOMAIN: CQRS / Vertical Slices Profile]       -> docs/domainspecs/pharma/cqrs.domain.md, docs/domainspecs/pharma/vertical-slices.domain.md
-[DOMAIN: Folder Structure Profile]             -> docs/domainspecs/pharma/folder-structure.domain.md
-[DOMAIN: API Versioning Profile]               -> docs/domainspecs/pharma/api-versioning.domain.md
-[DOMAIN: Dependency Policy Profile]            -> docs/domainspecs/pharma/dependency-policy.domain.md
-[DOMAIN: Integration Terms]                    -> docs/domainspecs/pharma/integration-terms.md
-[DOMAIN: AI Policy Addenda]                    -> docs/domainspecs/pharma/ai-rules.domain.md
-[DOMAIN: Ubiquitous Language]                  -> docs/domainspecs/pharma/pharma-terms.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 product registry), Redis
-  (cache for terminology expansions + read models), a message broker (Azure Service Bus,
-  AWS SQS/SNS, or RabbitMQ) for CloudEvents, an OTel collector, the configured IdP, an external
-  Terminology Service (NDC/RxNorm/SNOMED/UNII/ATC value-set expansion, optional), a FHIR
-  validator container, and an object store (S3/Blob) for imported source documents / labels.
-- Scale targets: P95 read latency < 200 ms at 200 RPS per module; FHIR search P95 < 500 ms.
-- Disaster recovery: RPO <= 15 minutes, RTO <= 4 hours; daily encrypted backups with 35-day
-  retention plus monthly archive. Product registry and audit history are retention-protected
-  (see [[persistence.domain]], [[auditing.domain]]).
-
-=====================================================================
-[DOMAIN: Governance Overrides]
-=====================================================================
-- Principal Engineers (approvers): TBD — fill at ratification.
-- Regulatory / Compliance Officer (mandatory approver for any identifier, classification, or
-  lifecycle-rule change): TBD.
-- Domain Owners (per module): TBD — assign one regulatory and one technical owner per bounded
-  context.
-- Quarterly review cadence: first business week of each quarter; an additional review after
-  every relevant regulatory or terminology-release update (e.g. WHO ATC annual update, FDA NDC
-  directory changes).
-- 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.
-
-## Related
-
-- [[domain-driven-design.domain]] · [[product-lifecycle.domain]] · [[ndc]] · [[idmp]] ·
-  [[atc]] · [[terminology]] · [[fhir]] · [[hl7]] · [[regulatory-compliance]] ·
-  [[data-provenance]] · [[auditing.domain]] · [[persistence.domain]] · [[ai-rules.domain]] ·
-  [[pharma-terms]]

package/assets/docs/domainspecs/pharma/eventing.domain.md

@@ -1,18 +0,0 @@
-# Eventing — Pharma Domain Addenda
-
-> Technology base: [[eventing]]. Commands: `/aw-spec-specify`, `/aw-spec-gate`.
-
-## Domain events
-- `MedicinalProduct` raises domain events on every significant state change — the integration seam to downstream consumers (prescribing, dispensing, manufacturing, pharmacovigilance, clinical).
-- Events publish from the aggregate boundary, never by an external feed writing aggregates directly (see [[hl7]], [[domain-driven-design.domain]]).
-
-## Canonical events
-`MedicinalProductRegistered` (Draft) · `…SubmittedForReview`/`Approved`/`Activated`/`Discontinued`/`Withdrawn` (lifecycle, see [[product-lifecycle.domain]]) · `ProductIdentifierChanged` (NDC, see [[ndc]]) · `ProductClassificationChanged` (ATC, see [[atc]]) · `ActiveIngredientChanged`/`PackagingConfigurationChanged` · `MarketingStatusChanged`. Each = an audit-mandatory operation (see [[auditing.domain]]).
-
-## Delivery
-- Outbox pattern: events persisted transactionally with the aggregate change, published to CloudEvents. Consumers integrate via FHIR / REST / event stream — **direct DB access FORBIDDEN** (see [[fhir]]).
-- Payloads carry coded values via standard terminologies, never free text (see [[terminology]], [[ndc]], [[atc]]).
-- Each event carries a `correlationId` tying command → audit record → version snapshot (see [[auditing.domain]], [[persistence.domain]], [[regulatory-compliance]]).
-
-## Related
-- [[eventing]] · [[domain-driven-design.domain]] · [[product-lifecycle.domain]] · [[auditing.domain]] · [[persistence.domain]] · [[fhir]] · [[hl7]] · [[ndc]] · [[atc]] · [[terminology]]