aw-spec-cli 0.1.4 → 0.1.5

package/assets/docs/domainspecs/UIVisualization/testing.domain.md

@@ -1,52 +0,0 @@
-# Testing — UI Visualization Domain
-
-> Test profile for the viz front-end. Commands: `/aw-spec-plan`, `/aw-spec-tasks`, `/aw-spec-implement`.
-
-## What to test (priority order)
-
-1. **Adapters** (highest value) — pure mapping functions: domain type → generic props. Assert the
-   produced `series`/`arms`/`curves`/`matrix` and labels match the input. No DOM needed.
-2. **Data layer** — the Excel parser and any workbook→domain mapper: given a fixture workbook (or
-   row array), assert the parsed dataset (counts, fields, null handling, derived curves).
-3. **Store actions** — `loadExcel`, `resetToSample`, `toggleCurve` change state as specified
-   (see [[state-management.domain]]).
-4. **Smoke render** — each selected chart renders without throwing when given representative data
-   (mock `plotly.js-dist-min` so no real canvas is needed).
-
-## How
-
-- **Vitest** (or Jest) + **@testing-library/react** for component smoke tests.
-- **Mock Plotly**: `vi.mock('plotly.js-dist-min', () => ({ react: vi.fn(), purge: vi.fn() }))` —
-  assert the wrapper called `react` with the expected trace count, not pixels.
-- Adapters and parsers are plain functions — unit-test them directly, no mocks.
-- A `build` (type-check + `next build`) is the compile-time gate; keep it green.
-
-## Example (agent reference)
-
-```ts
-import { describe, it, expect } from 'vitest'
-import { compoundsToBubbleSeries } from '@/components/charts/CompoundScatterPlot'
-
-it('groups compounds by target into series with log-scaled y', () => {
-  const series = compoundsToBubbleSeries([
-    { name: 'A', target: 'EGFR', molecularWeight: 393, ic50_nM: 10, selectivityRatio: 40 },
-  ])
-  expect(series).toHaveLength(1)
-  expect(series[0].seriesLabel).toBe('EGFR')
-  expect(series[0].points[0].y).toBeCloseTo(1) // log10(10)
-})
-```
-
-> Tip: export the mapping function from the adapter (e.g. `compoundsToBubbleSeries`) so it is
-> unit-testable without rendering.
-
-## Rules
-
-- Don't assert on Plotly's internal DOM — assert on the **inputs** you hand Plotly.
-- One fixture workbook per project lives beside the parser tests; mirror the shipped
-  `public/sample-data.xlsx` columns.
-- Only test charts that are **selected** for the project (see [[domain-requirements]]).
-
-## Related
-- [[component-contracts.domain]] · [[state-management.domain]] · [[data-source.domain]] ·
-  [[coding-standards.domain]]

package/assets/docs/domainspecs/UIVisualization/ui-viz-terms.md

@@ -1,39 +0,0 @@
-# Ubiquitous Language — UI Visualization Domain
-
-> Shared vocabulary for the visualization front-end. Commands: `/aw-spec-specify`, `/aw-spec-clarify`.
-
-## Core terms
-
-- **Generic chart** — a domain-agnostic, props-driven Plotly component in
-  `components/charts/generic/`. Knows nothing about any project domain. The 10 in the catalog.
-- **Adapter** — a thin component mapping a project/domain type into a generic chart's props; lives
-  in `components/charts/` (not `generic/`). The only place domain vocabulary meets a chart.
-- **Base wrapper** — `PlotlyChart`; the single SSR-safe Plotly mount every chart renders through.
-- **Data source** — origin of chart data: `sample` (hard-coded), `excel` (client upload), or
-  `api` (Phase-2 REST). The store's `sourceMode`.
-- **Dataset** — the project's chart-ready data held in the store; the contract between data source
-  and charts.
-- **Command (action)** — a named store mutation (`loadExcel`, `resetToSample`, `toggleCurve`).
-- **Query (selector)** — a read of store state from a component via `useDataStore`.
-- **Chart selection** — the developer-specified subset of the catalog to scaffold (or "all plots").
-- **Fill-height** — responsive sizing: a chart with no `height` fills its flex parent.
-- **Series / arm / curve / panel / trace** — per-chart data groupings (see each `chart-*` file).
-- **meta / metadata** — open key/value bag for tooltip enrichment; never a typed domain field.
-
-## Chart friendly-name ↔ component
-
-| Friendly name(s) | Component |
-|---|---|
-| Heatmap | `Heatmap` |
-| Bubble / Bubble chart | `BubbleChart` |
-| S-Curve / Sigmoid / Dose-Response | `SCurveChart` |
-| Survival / Kaplan-Meier / KM / Retention | `SurvivalCurveChart` |
-| Volcano | `VolcanoPlot` |
-| Dim. Reduction / PCA / t-SNE / UMAP | `DimRedPlot` |
-| Parallel Coords / parcoords | `ParallelCoordinatesPlot` |
-| Violin / Distribution | `ViolinPlot` |
-| Network / Graph / Node-Edge | `NetworkGraph` |
-| Trellis / Facet / Small-multiples | `TrellisGrid` |
-
-## Related
-- [[domain-requirements]] · [[component-contracts.domain]] · [[charting-standards.domain]]

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]`).