aw-spec-cli 0.1.1 → 0.1.2

package/assets/.agents/skills/aw-spec-foundation/SKILL.md

@@ -2,7 +2,7 @@
 name: "aw-spec-foundation"
 description: "Scaffold a complete, compiling project by unpacking a verified foundation bundle (docs/<FoundationName>/<FoundationName>.pack.txt) and renaming its sentinel app name to your app name."
 argument-hint: "FoundationName AppName [OutputDirectory]  —  e.g. VerticalSlice AppWeaver.Health"
-compatibility: "Requires docs/<FoundationName>/<FoundationName>.pack.txt and unpack-foundation.ps1 to exist"
+compatibility: "Requires docs/<FoundationName>/<FoundationName>.pack.txt and an unpacker (unpack-foundation.ps1 preferred via pwsh; unpack-foundation.sh fallback when pwsh is absent)"
 metadata:
   author: "github-aw-spec"
 user-invocable: true
@@ -30,20 +30,17 @@ Example: /aw-spec-foundation VerticalSlice AppWeaver.Health
 
 ---
 
-## How this works (read before acting)
+## How this works
 
-This skill does **not** reconstruct files from prose rule docs anymore — that
-caused broken skeletons. Instead it unpacks a **byte-for-byte bundle of a real,
-verified solution** and renames the sentinel app name to `APP_NAME`.
+Unpack a **byte-for-byte bundle of a verified solution**
+(`docs/<FOUNDATION_NAME>/<FOUNDATION_NAME>.pack.txt`) via its unpack script, which rewrites the
+pack's **sentinel** app name to `APP_NAME` (in dotted / underscored / lower-hyphen / lower-dot
+forms) across file contents and names. The sample domain folder `Projects` and `AppWeaver.*`
+framework packages are **left unchanged**.
 
-- The bundle: `docs/<FOUNDATION_NAME>/<FOUNDATION_NAME>.pack.txt`
-- The renamer: `docs/<FOUNDATION_NAME>/unpack-foundation.ps1`
-- The rules for building/refreshing the bundle: `docs/<FOUNDATION_NAME>/PACKAGING.md`
-
-The unpack script reads the **sentinel** from the pack header and rewrites it (in
-dotted / underscored / lower-hyphen / lower-dot forms) across file contents and
-file/folder names. The sample domain folder `Projects` and the `AppWeaver.*`
-framework package references are intentionally **left unchanged**.
+> ⚠️ **Never open a `.pack.txt` with Read/`cat`/`head`/`tail`** — it is ~700 KB (≈180K tokens).
+> The script parses and writes everything to disk; the only thing you read from the pack is its
+> `#` header, via a bounded `grep` (Step 1).
 
 ---
 
@@ -72,9 +69,15 @@ Check both exist.
   ```
   Then stop.
 
-Read the **header lines** (those starting with `#`) at the top of `PACK_FILE` to obtain
-`SENTINEL` and the declared file count. Do not parse the whole bundle yourself — the
-script does the unpacking.
+Read **only** the `#` header lines of `PACK_FILE` to obtain `SENTINEL` and the declared
+file count. Use a bounded command — **do not** open the pack with the Read tool, `cat`,
+`head`, or `tail` (it would load ~20K tokens of pack body into context):
+
+```bash
+grep -m 30 '^#' "docs/<FOUNDATION_NAME>/<FOUNDATION_NAME>.pack.txt"
+```
+
+This returns just the sentinel, file count, and replacement contract.
 
 ---
 
@@ -103,44 +106,215 @@ Proceed? (yes/no)
 
 ## Step 3 — Dry run, then unpack
 
-First do a **dry run** to surface any path collisions without writing anything, using
-the PowerShell tool:
+### Choosing the runner (do this first)
 
-```powershell
-& "docs/<FOUNDATION_NAME>/unpack-foundation.ps1" `
-    -PackFile "docs/<FOUNDATION_NAME>/<FOUNDATION_NAME>.pack.txt" `
-    -TargetAppName "<APP_NAME>" `
-    -OutDir "<OUTPUT_DIR>" `
+Each foundation ships two equivalent unpackers. **Prefer PowerShell** (`unpack-foundation.ps1`,
+~50× faster); fall back to bash (`unpack-foundation.sh`) only when `pwsh` is absent. Detect once
+and reuse the choice for every unpack call (Steps 3 and 4c):
+
+```bash
+command -v pwsh >/dev/null 2>&1 && echo "pwsh" || echo "sh"
+```
+
+The bash port takes the same flags in kebab-case (`--pack-file`, `--target-app-name`,
+`--out-dir`, `--dry-run`, `--force`); positional args also work.
+
+### Dry run
+
+First do a **dry run** to surface any path collisions without writing anything.
+
+PowerShell (preferred):
+```bash
+pwsh -NoProfile -File "docs/<FOUNDATION_NAME>/unpack-foundation.ps1" \
+    -PackFile "docs/<FOUNDATION_NAME>/<FOUNDATION_NAME>.pack.txt" \
+    -TargetAppName "<APP_NAME>" \
+    -OutDir "<OUTPUT_DIR>" \
     -DryRun
 ```
 
-- If it reports files that **already exist** (the script throws on conflict unless `-Force`),
-  show the conflict list and ask whether to overwrite. Only add `-Force` if the user agrees.
-- Otherwise run it for real (drop `-DryRun`; add `-Force` only if the user approved overwrite):
+bash fallback (only if `pwsh` is missing):
+```bash
+bash "docs/<FOUNDATION_NAME>/unpack-foundation.sh" \
+    --pack-file "docs/<FOUNDATION_NAME>/<FOUNDATION_NAME>.pack.txt" \
+    --target-app-name "<APP_NAME>" \
+    --out-dir "<OUTPUT_DIR>" \
+    --dry-run
+```
+
+- If it reports files that **already exist** (the script throws on conflict unless `-Force`
+  / `--force`), show the conflict list and ask whether to overwrite. Only add the force flag
+  if the user agrees.
+- Otherwise run it for real (drop `-DryRun`/`--dry-run`; add the force flag only if the user
+  approved overwrite). PowerShell (preferred):
 
-```powershell
-& "docs/<FOUNDATION_NAME>/unpack-foundation.ps1" `
-    -PackFile "docs/<FOUNDATION_NAME>/<FOUNDATION_NAME>.pack.txt" `
-    -TargetAppName "<APP_NAME>" `
+```bash
+pwsh -NoProfile -File "docs/<FOUNDATION_NAME>/unpack-foundation.ps1" \
+    -PackFile "docs/<FOUNDATION_NAME>/<FOUNDATION_NAME>.pack.txt" \
+    -TargetAppName "<APP_NAME>" \
     -OutDir "<OUTPUT_DIR>"
 ```
 
+bash fallback:
+```bash
+bash "docs/<FOUNDATION_NAME>/unpack-foundation.sh" \
+    --pack-file "docs/<FOUNDATION_NAME>/<FOUNDATION_NAME>.pack.txt" \
+    --target-app-name "<APP_NAME>" \
+    --out-dir "<OUTPUT_DIR>"
+```
+
 Capture the script's stdout (it reports the number of files written). Do **not**
 hand-edit or regenerate any unpacked file.
 
 ---
 
-## Step 4 — Verify
+## Step 4 — Offer reference project
+
+After the foundation unpack succeeds, ask the user whether to also unpack the bundled
+reference sample:
+
+```
+AskUserQuestion — single-select:
+  "Would you like to include the reference sample project?"
+  • "Yes — include reference sample"  (description: "Unpacks sample domain slices — Projects, Users, Reports — and merges them into the scaffolded project")
+  • "No — skip reference sample"      (description: "Leave the project as a clean, empty foundation")
+```
+
+- If the user chooses **No**, proceed directly to Step 5 (Verify).
+- If the user chooses **Yes**, continue with the steps below **before** verifying.
 
-After unpacking:
+### Step 4a — Locate the reference pack
 
-1. **File count** — confirm the written count matches the bundle's declared file count.
+`REFERENCE_PACK_FILE` = `docs/<FOUNDATION_NAME>/<FOUNDATION_NAME>.Reference.pack.txt`
+`UNPACK_REF`          = `docs/<FOUNDATION_NAME>/unpack-reference-foundation.ps1` (preferred)
+                        or `…/unpack-reference-foundation.sh` (fallback when `pwsh` is absent)
+
+If the pack or the matching unpacker for your chosen runner is missing:
+```
+Reference pack not found: <REFERENCE_PACK_FILE>
+Run pack-reference-foundation.ps1 first (see docs/<FOUNDATION_NAME>/).
+Skipping reference sample.
+```
+Then proceed to Step 5 without unpacking reference files.
+
+Read the header of `REFERENCE_PACK_FILE` to obtain `REF_SENTINEL` and `REF_FILE_COUNT` —
+again with a bounded `grep -m 30 '^#' "<REFERENCE_PACK_FILE>"`, **never** a full Read/`cat`
+of the reference pack (it is just as large as the foundation pack).
+
+### Step 4b — Save the foundation DbContext before overwrite
+
+The reference unpack will conflict with (and overwrite) `ApplicationDbContext.cs` because
+both packs rename their sentinel's project structure to the same output path. Before running
+the reference unpack, **read and save** the full content of the existing foundation DbContext:
+
+```powershell
+# Locate it — do NOT assume a fixed path; search the output tree:
+$dbCtxPath = Get-ChildItem -Path "<OUTPUT_DIR>/src" -Recurse -Filter "ApplicationDbContext.cs" |
+             Select-Object -First 1 -ExpandProperty FullName
+$foundationDbCtx = [System.IO.File]::ReadAllText($dbCtxPath)
+```
+
+Store `$foundationDbCtx` in memory; you will need it in Step 4d.
+
+### Step 4c — Unpack the reference pack
+
+Run with `-Force` / `--force` (the DbContext and any other overlapping files will be
+overwritten — the DbContext will be restored via merge in Step 4d). Use the **same runner**
+you selected in Step 3 (`pwsh` preferred, `.sh` only if `pwsh` is missing).
+
+PowerShell (preferred):
+```bash
+pwsh -NoProfile -File "docs/<FOUNDATION_NAME>/unpack-reference-foundation.ps1" \
+    -PackFile      "docs/<FOUNDATION_NAME>/<FOUNDATION_NAME>.Reference.pack.txt" \
+    -TargetAppName "<APP_NAME>" \
+    -OutDir        "<OUTPUT_DIR>" \
+    -Force
+```
+
+bash fallback:
+```bash
+bash "docs/<FOUNDATION_NAME>/unpack-reference-foundation.sh" \
+    --pack-file      "docs/<FOUNDATION_NAME>/<FOUNDATION_NAME>.Reference.pack.txt" \
+    --target-app-name "<APP_NAME>" \
+    --out-dir        "<OUTPUT_DIR>" \
+    --force
+```
+
+Capture the count of files written.
+
+### Step 4d — Merge ApplicationDbContext.cs
+
+After the reference unpack the DbContext file now contains the **reference version**
+(sample DbSet<> properties only, no `OnModelCreating`). Merge it with the saved
+**foundation version** (full `OnModelCreating`, no DbSet<>) to produce a single
+complete DbContext.
+
+**Merge rules — apply in order:**
+
+1. **Base = foundation file.** Start with `$foundationDbCtx` as the text to edit.
+
+2. **Add missing `using` directives.** Read the reference DbContext's `using` lines.
+   For each one not already present in the foundation file, insert it at the top of the
+   using block (before the namespace declaration or the class declaration).
+
+3. **Add `DbSet<>` properties.** Extract every `public DbSet<…>` property line from the
+   reference DbContext. Insert them as a block inside the foundation class body, directly
+   after the opening brace `{` of the class and before `OnModelCreating` (or before the
+   closing `}` if there is no `OnModelCreating`). Preserve the comment above the DbSets
+   (e.g. `// TaskContext`) if present.
+
+4. **Preserve everything else in the foundation file unchanged.** Do not touch the class
+   header, constructor, interface list, `OnModelCreating`, or any existing using statements.
+
+5. **Write the merged result** back to `$dbCtxPath` (overwrite the reference version that
+   the unpack left there).
+
+**Example — VerticalSlice result after merge:**
+```csharp
+using Microsoft.EntityFrameworkCore;
+using AppWeaver.Repository.EfCore;
+using AppWeaver.Contexts;
+using AppWeaver.DomainAbstraction.Entities;
+// ← reference usings inserted here, e.g.:
+using AppWeaver.Pharma.Service.Projects.Domain;
+using AppWeaver.Pharma.Service.Users.Domain;
+using AppWeaver.Pharma.Service.Reports.Domain;
+
+namespace AppWeaver.Pharma.Service.Infrastructure;
+
+public class ApplicationDbContext(
+    DbContextOptions<ApplicationDbContext> options,
+    ICurrentTenant? tenant = null
+) : ContextAwareDbContext<ApplicationDbContext>(options, tenant)
+{
+    // TaskContext  ← DbSet block from reference, inserted here
+    public DbSet<Project> Projects => Set<Project>();
+    public DbSet<ProjectTask> ProjectTasks => Set<ProjectTask>();
+    public DbSet<TaskUser> TaskUsers => Set<TaskUser>();
+    public DbSet<ReportRequest> ReportRequests => Set<ReportRequest>();
+
+    protected override void OnModelCreating(ModelBuilder modelBuilder)
+    {
+        // ... full foundation OnModelCreating preserved unchanged ...
+    }
+}
+```
+
+---
+
+## Step 5 — Verify
+
+After unpacking (and merging, if reference was included):
+
+1. **File count** — confirm the written count(s) match the bundle's declared file count(s).
 2. **Sentinel residue** — search the output tree for any leftover sentinel token
    (dotted/underscored/lower forms). There should be **none**. If any remain, report the
    files (it indicates a case form the bundle used that the rename list missed).
 3. **Framework packages intact** — confirm `AppWeaver.*` package references in the
    generated `.csproj`/`Directory.Packages.props` are unchanged.
-4. **Build (optional, recommended)** — if the .NET SDK is available, offer to build.
+4. **DbContext integrity (if reference included)** — confirm the merged `ApplicationDbContext.cs`
+   contains both `DbSet<>` properties (from reference) **and** `OnModelCreating` (from foundation).
+   If either section is missing, report it as a warning.
+5. **Build (optional, recommended)** — if the .NET SDK is available, offer to build.
    The solution file is whatever the bundle shipped (e.g. `api.sln`) and is **not**
    renamed unless its name contains the sentinel — so discover it rather than assuming
    `<APP_NAME>.sln`:
@@ -155,18 +329,19 @@ Report check failures as warnings; do not silently continue past a sentinel-resi
 
 ---
 
-## Step 5 — Completion report
+## Step 6 — Completion report
 
 ```
 ✅ Foundation scaffold complete
 
-Foundation : <FOUNDATION_NAME>
-App Name   : <APP_NAME>
-Output     : <OUTPUT_DIR or repo root>
-Files      : <N> written
+Foundation  : <FOUNDATION_NAME>
+App Name    : <APP_NAME>
+Output      : <OUTPUT_DIR or repo root>
+Files       : <N> written  [+ <M> reference files]  (omit reference line if skipped)
+Reference   : included / skipped
 
 Next steps:
-  1. Rename the sample 'Projects' domain to your bounded context.
+  1. [If reference skipped] Rename the sample 'Projects' domain to your bounded context.
   2. Ensure your NuGet feed for AppWeaver.* packages is configured.
   3. Run the AppHost:  dotnet run --project <OUTPUT_DIR>/src/<APP_NAME>.AppHost
   4. Use /aw-spec-specify to create your first feature spec.
@@ -176,13 +351,8 @@ Next steps:
 
 ## Notes
 
-- **The bundle is the source of truth.** If scaffolds come out wrong, fix the foundation
-  solution and re-pack (`docs/<FOUNDATION_NAME>/PACKAGING.md`) — never patch generated
-  output as a workaround.
-- The engineering **standards** the foundation must satisfy live in the project
-  constitution and the domain-specs rule files (used by `/aw-spec-plan`, `/aw-spec-specify`,
-  etc.) — not in this foundation folder.
-- To add a new foundation (e.g. `ModularMonolith`), create `docs/ModularMonolith/` with its
-  own `pack-foundation.ps1`, `unpack-foundation.ps1`, `PACKAGING.md`, and built
-  `ModularMonolith.pack.txt`, then call `/aw-spec-foundation ModularMonolith <AppName>`.
+- **The bundle is the source of truth** — if a scaffold comes out wrong, fix the foundation
+  solution and re-pack (`PACKAGING.md`); never patch generated output as a workaround.
+- To add a new foundation, create `docs/<Name>/` with its own `pack-foundation.ps1`,
+  `unpack-foundation.ps1`, `PACKAGING.md`, and built `<Name>.pack.txt`.
 ```

package/assets/.agents/skills/aw-spec-implement/SKILL.md

@@ -19,6 +19,17 @@ $ARGUMENTS
 
 You **MUST** consider the user input before proceeding (if not empty).
 
+## Context Reuse (cross-command dedup)
+
+**Skip Read-ing any file already in this conversation.** Before loading a standards/domain/template/spec file this command names, check whether it is already in context (loaded earlier here or by a prior `/aw-spec-*` command). If present and unchanged, reuse it and **skip the Read** — only Read files not yet loaded. A file already in context still counts as loaded; this just avoids the redundant re-read.
+
+## Project Structure Gate (run before loading standards)
+
+**Before loading standards or writing code, confirm a scaffolded app exists** — the output of `/aw-spec-foundation`, not just `.aw-spec/`/`docs/`/`specs/` framework files. Check the repo root (Glob/Bash) for a real build entrypoint, ignoring matches only inside `.aw-spec/`/`docs/`/`specs/`: `*.sln` or `*.csproj` under `src/` (.NET/AppWeaver), else `package.json`/`pom.xml`/`build.gradle`/`go.mod`/`Cargo.toml`/`pyproject.toml` etc.
+
+- **None found → STOP, no side effects** (don't load standards, run hooks, or write anything): tell the developer *"No scaffolded project found — run `/aw-spec-foundation ModularMonolith <AppName>` (or `VerticalSlice <AppName>`) first, then re-run."*
+- **Found →** use its solution/host-project path as the implementation target and continue.
+
 ## Auto-Loaded Engineering Standards (Required Context)
 
 **Before doing anything else in this command, load the project engineering-standards files listed below into context using the Read tool.** These were previously supplied manually as `@docs/...` mentions; they are now loaded automatically so the user does not need to pass them. Rules:

package/assets/.agents/skills/aw-spec-minimal-implementation/SKILL.md

@@ -0,0 +1,209 @@
+---
+name: "aw-spec-minimal-implementation"
+description: "Single-step implementation tier: takes a requirement DIRECTLY as the argument (an `Aggregate/Feature` token + free-text requirement) and implements it in one load-and-execute pass — no /aw-spec-specify, no spec.md, no plan.md/tasks.md, no analysis report. Loads a curated technical + domain rule set once, builds a structurally complete vertical slice (implementing what the loaded rules support, stubbing only genuinely-external runtime services), emits a final execution note, then offers an opt-in breakdown of unclear areas. For audited/traceable work use /aw-spec-fast-implement or the full plan→tasks→analyze→implement flow instead."
+argument-hint: "<Aggregate>/<Feature> then the requirement text — e.g. MedicinalProduct/RegisterMedicinalProduct  Allow an authorized user to register a new medicinal product..."
+compatibility: "Requires a scaffolded application project (output of /aw-spec-foundation) and the .aw-spec/ directory. Does NOT require a spec.md or /aw-spec-specify."
+metadata:
+  author: "github-aw-spec"
+  source: "templates/commands/minimal-implementation.md"
+user-invocable: true
+disable-model-invocation: false
+---
+
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+**The argument IS the requirement — this is a single-step command.** `$ARGUMENTS` contains an `Aggregate/Feature` token (two PascalCase segments separated by `/`, e.g. `MedicinalProduct/RegisterMedicinalProduct`) followed by the free-text requirement (the feature description + acceptance criteria). There is **no** `/aw-spec-specify` step and **no** `spec.md`: parse the requirement straight from this argument and implement it in one pass. If `$ARGUMENTS` is empty, or carries an `Aggregate/Feature` token but no requirement text, STOP and show usage: `/aw-spec-minimal-implementation <Aggregate>/<Feature> <requirement text>`.
+
+## Context Reuse (cross-command dedup)
+
+**Skip Read-ing any file already in this conversation.** Before loading a standards/domain/template/spec file this command names, check whether it is already in context (loaded earlier here or by a prior `/aw-spec-*` command). If present and unchanged, reuse it and **skip the Read** — only Read files not yet loaded. A file already in context still counts as loaded; this just avoids the redundant re-read.
+
+## When to use this command
+
+**Single-step tier.** Takes the requirement directly from the argument and implements it in one pass — **no** `/aw-spec-specify`, **no** `spec.md`/`plan.md`/`tasks.md`/research/contracts/analysis — loading a curated rule set (technical standards + the domain's single-step set) once, ending with a final note + an opt-in unclear-areas breakdown. It implements what the loaded rules support; only a **genuinely-external runtime service** (live terminology server, external FHIR endpoint) is left as an injectable fixture port, recorded as a deferral.
+
+**Non-negotiable:** scaffolded project present (gate below), requirement supplied, constitution MUST principles honored, architecture patterns (vertical slices, CQRS, folder structure) + the aggregate's in-aggregate invariants (NDC format, ≥1 ingredient, ≥1 packaging, Draft guard) implemented, and an in-memory coverage check before writing code. **Escalate to `/aw-spec-fast-implement`** (or the full flow) if you need the heavy integrations actually built, traceable artifacts, or the work is audited/complex.
+
+## Project Structure Gate (run before loading standards)
+
+**Before loading standards or writing code, confirm a scaffolded app exists** — the output of `/aw-spec-foundation`, not just `.aw-spec/`/`docs/`/`specs/` framework files. Check the repo root (Glob/Bash) for a real build entrypoint, ignoring matches only inside `.aw-spec/`/`docs/`/`specs/`: `*.sln` or `*.csproj` under `src/` (.NET/AppWeaver), else `package.json`/`pom.xml`/`build.gradle`/`go.mod`/`Cargo.toml`/`pyproject.toml` etc.
+
+- **None found → STOP, no side effects** (don't load standards, run hooks, or write anything): tell the developer *"No scaffolded project found — run `/aw-spec-foundation ModularMonolith <AppName>` (or `VerticalSlice <AppName>`) first, then re-run."*
+- **Found →** use its solution/host-project path as the implementation target and continue.
+
+## Auto-Loaded Engineering Standards (Required Context)
+
+**Load these files once with the Read tool, before the Pre-Execution Checks.** Treat them as authoritative (second only to `.aw-spec/memory/constitution.md`); skip any that don't exist. This list is the domain-agnostic **technical knob** (the domain knob is the `## /aw-spec-minimal-implementation` heading in `comandrulemap.md`); edit it to tune richness, or add a file with an `@` mention.
+
+Technical standards for `/aw-spec-minimal-implementation`:
+- docs/architecture/folder-structure.md
+- docs/architecture/vertical-slices.md
+- docs/architecture/cqrs.md
+- docs/architecture/persistence.md
+- docs/architecture/eventing.md
+- docs/domain/domain-driven-design.md
+- docs/security/authorization.md
+- docs/security/auditing.md
+- docs/security/data-classification.md
+- docs/governance/coding-standards.md
+- docs/governance/dependency-policy.md
+- docs/glossary/ai-rules.md
+
+## Domain Rule-File Selection (once)
+
+After the technical standards are loaded, resolve the active domain and load the domain's curated rule set — once.
+
+1. **Resolve the active domain.** Read `.aw-spec/domain.json`'s `domain`. Load **exactly the files listed** under the **`## /aw-spec-minimal-implementation`** heading in `docs/domainspecs/<domain>/comandrulemap.md` (the per-domain knob; the set varies by domain).
+   - **Fallback:** if that heading is absent, load `domain-driven-design.domain.md` + the domain's terms file (`pharma-terms.md`/`clinical-terms.md`) + lifecycle file (`product-lifecycle.domain.md`) if present. A missing heading is **not** an error.
+2. **Domain gate (missing domain or rules).** If `.aw-spec/domain.json` is absent or its `domain` is empty, **or** `docs/domainspecs/<domain>/comandrulemap.md` does not exist:
+   - If no domain is set, do **not** hard-block. Note "no domain set / domain rules unavailable — running technical-only" and continue with just the technical standards (plus any `@`-mentioned files).
+   - Exception: if the user explicitly asked to enforce a domain and none is set, tell them to run `/aw-spec-select-domain` and stop.
+3. **Load the minimal set.** Because the set is already small, default to loading **all** of it (no selection prompt needed). Read each file once; skip missing files silently. In an interactive session you MAY offer a one-line confirm, but the default is "load all of the minimal set".
+4. **Final context set** = technical standards ＋ the domain's rule set ＋ any `@`-mentioned files (always loaded in addition).
+5. Proceed to the Pre-Execution Checks only after these are loaded.
+
+## Pre-Execution Checks
+
+**Check for collapsed pre-hooks**:
+- Check if `.aw-spec/extensions.yml` exists. If not, skip silently.
+- If it exists, read it and collect enabled hook entries under `hooks.before_implement` (the only pre-point relevant to an implementation-only tier). Treat hooks without `enabled` as enabled; skip `enabled: false`.
+- Do **not** evaluate `condition` expressions: run a hook only if it has no non-empty `condition`; otherwise leave it to the HookExecutor.
+- When building slash commands from hook command names, replace dots with hyphens (`aw-spec.git.commit` → `/aw-spec-git-commit`).
+- For each executable hook, emit:
+  - **Optional** (`optional: true`):
+    ```
+    ## Extension Hooks
+
+    **Optional Pre-Hook**: {extension}
+    Command: `/{command}`
+    Description: {description}
+
+    Prompt: {prompt}
+    To execute: `/{command}`
+    ```
+  - **Mandatory** (`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.
+    ```
+
+## Outline
+
+This is a **single-step** flow: parse the requirement from the argument, derive the design in your
+head, and implement — all in one pass. No scripts seed artifacts; nothing is read from or written to
+`specs/`.
+
+### 1. Parse the requirement (from the argument — no spec.md)
+
+- From `$ARGUMENTS`, take the leading **`Aggregate/Feature`** token (two PascalCase segments split by `/`, e.g. `MedicinalProduct/RegisterMedicinalProduct`) and treat the remaining text as the **requirement** (description + acceptance criteria). If no `Aggregate/Feature` token is given, derive `<Feature>` from the requirement and `<Aggregate>` from its primary domain entity.
+- If the argument is empty, or carries an `Aggregate/Feature` token but no requirement text, **STOP** with usage (see the User Input section). Do **not** invent a requirement.
+- The **implementation target** is the scaffolded application source tree located by the Project Structure Gate above (its solution/host project). You will place the slice under that app for `<Aggregate>/<Feature>`.
+
+### 2. Build the internal model (in your head — collapses specify+plan+tasks)
+
+Derive, **without writing any files**:
+- **User story + acceptance criteria** from the requirement (what success looks like).
+- **Functional requirements** — give them working `FR-###` keys for the coverage check and the note.
+- **Key entities / aggregate shape**: the aggregate root, its value objects and child entities, and the **in-aggregate invariants** the acceptance criteria imply (e.g. NDC format + uniqueness, ≥1 ingredient, ≥1 packaging, Draft on create).
+- **Constitution**: IF `.aw-spec/memory/constitution.md` exists, load it; its MUST principles are authoritative even here.
+- Track every **ambiguity / missing detail / assumption** as you go — these feed the opt-in part of the Final Execution Note.
+- Do **not** create `spec.md`, `plan.md`, `tasks.md`, `research.md`, `data-model.md`, `contracts/`, or `quickstart.md`.
+
+### 3. Resolve unclear areas without blocking
+
+For each ambiguity or missing detail in the requirement, choose a **documented reasonable assumption** and proceed — this is single-step, so do **not** stop to ask mid-way. Keep a running list of (a) assumptions made and (b) genuinely unclear/under-specified items; both surface in the opt-in section of the Final Execution Note.
+
+### 4. Implement directly from the requirement
+
+Implement straight into the scaffolded app's source tree (no design files):
+- **Structure**: follow `docs/architecture/folder-structure.md` and `vertical-slices.md` — place the feature as a vertical slice under `<Aggregate>/<Feature>` inside the app located by the Project Structure Gate.
+- **Behavior**: apply CQRS command/query separation per `cqrs.md`; model the entities derived in step 2; implement each Functional Requirement and the primary user-story/acceptance flow.
+- **Conventions**: follow `coding-standards.md` and `ai-rules.md` (loaded in the technical set), the loaded domain rules, and the domain's ubiquitous-language/terms glossary for correct vocabulary in names/labels.
+- **Implement what the loaded rules support; stub only genuinely-external services**: implement the aggregate, value objects, entities, and **in-aggregate invariants** for real, and honor whatever domain rules are in this domain's set (e.g. NDC format/structure, ATC/identifier shape, FHIR mapping shape where those files are loaded). Stub **only** a genuinely-external runtime dependency that can't exist in a self-contained build — e.g. a live terminology server or external FHIR endpoint — behind an **injectable port** with a fixture implementation (e.g. an `INdcValidator` / `ITerminologyValidator`). Never invent real coded values; use a clearly-named sentinel. Record each stub/port as a deferral in the Final Execution Note.
+- **Coverage (in-memory)**: before finishing, confirm every Functional Requirement and the acceptance flow is addressed, the aggregate's structural invariants hold, and nothing violates a constitution MUST. **STOP** and recommend `/aw-spec-fast-implement` only if the *structure itself* can't be expressed simply or a constitution MUST is at stake — not merely because an integration is stubbed.
+- **Tests**: only if the requirement explicitly requests them (this tier defaults to no tests).
+- **Ignore files**: ensure `.gitignore` covers the stack (this is a .NET/C# project by default: `bin/`, `obj/`, `*.user`); append only missing critical patterns.
+
+### 5. Build check
+
+Build/compile the affected project. Report the result in the final note. If it fails, fix obvious issues; if the failure indicates the task is more complex than "minimal," say so and recommend escalating to `/aw-spec-fast-implement`.
+
+## Mandatory Post-Execution Hooks
+
+**Complete this before the Final Execution Note.**
+
+- Check if `.aw-spec/extensions.yml` exists; if not, skip to the Final Execution Note.
+- Read enabled hook entries under `hooks.after_implement` (the only post-point relevant to an implementation-only tier — this tier produces no plan, so plan/agent-context hooks do not apply). Treat missing `enabled` as enabled; skip `enabled: false`; do not evaluate `condition` expressions.
+- Convert command names dots→hyphens. For each executable hook, emit:
+  - **Mandatory** (`optional: false`) — **emit `EXECUTE_COMMAND:`**:
+    ```
+    ## Extension Hooks
+
+    **Automatic Hook**: {extension}
+    Executing: `/{command}`
+    EXECUTE_COMMAND: {command}
+    ```
+  - **Optional** (`optional: true`):
+    ```
+    ## Extension Hooks
+
+    **Optional Hook**: {extension}
+    Command: `/{command}`
+    Description: {description}
+
+    Prompt: {prompt}
+    To execute: `/{command}`
+    ```
+
+## Final Execution Note
+
+This is the **only** output record for this tier — there are no spec.md/plan.md/tasks.md files. After the build check, emit a concise note in chat:
+
+- **Feature**: `<Aggregate>/<Feature>` (parsed from the argument).
+- **Files created/changed**: each path with a one-line purpose.
+- **Requirement coverage**: a short `FR-### → file(s)` map and the user-story/acceptance flow implemented.
+- **Stubbed / deferred integrations (option "B")**: each heavy integration stubbed behind a port (terminology/NDC/ATC validation, FHIR projection, audit/lifecycle depth, etc.) with its fixture/sentinel name — so the reader knows what is NOT production-grade and must be built (e.g. via `/aw-spec-fast-implement`) before release.
+- **Standards applied**: "technical standards + <domain> single-step rule set" (or "technical-only").
+- **Build status**: pass/fail (and what was fixed).
+
+### Then offer the unclear-areas breakdown (opt-in)
+
+After the note above, **ask the developer one question** (single-select, e.g. via AskUserQuestion):
+
+> *"Want a breakdown of the unclear/ambiguous areas and the assumptions I made, so you can refine them one by one?"* — options **"Yes — list them"** / **"No — leave it"**.
+
+- **If the developer says yes** (and in a non-interactive run, default to yes): append an **"⚠️ Unclear Areas & Assumptions to Refine"** section — an **itemized, numbered** list where each entry states: *what was unclear or missing in the requirement*, *the assumption / default chosen*, *where it shows up in the code* (file/symbol), and *how to firm it up*. Order them so the developer can fix them one at a time, and include the stubbed integrations here too (each is a thing to finish).
+- **If the developer says no**: end with just the concise note plus the reminder below.
+
+End with: *no design artifacts were persisted — re-run with `/aw-spec-fast-implement` if you need a traceable `plan.md`/`tasks.md` or the heavy integrations fully built.*
+
+## Key rules
+
+- **Single step**: the requirement comes from the argument — never call `/aw-spec-specify` and never read or create a `spec.md`.
+- Load each rule file **once**; never re-read context you already hold.
+- **Never** create `spec.md`, `plan.md`, `tasks.md`, or Phase-1 design files in this tier — the whole point is no persisted artifacts, just the final note.
+- The constitution and the loaded standards are authoritative. **STOP** on an unjustified constitution MUST violation or a requirement that cannot be met simply — escalate to `/aw-spec-fast-implement` rather than shipping partial/incorrect code.
+- Do **not** block mid-way to clarify: make documented assumptions, finish, then offer the unclear-areas breakdown at the end.
+- This is the tier for **simple, non-domain-rich** tasks. If the work turns out domain-rich or complex, stop and recommend `/aw-spec-fast-implement`.
+
+## Done When
+
+- [ ] Project Structure Gate passed (scaffolded app present); requirement parsed from the argument
+- [ ] Technical standards and the domain rule set loaded **once** (or technical-only); constitution MUST principles honored
+- [ ] Internal model derived in-head (no spec.md/plan.md/tasks.md/design files created)
+- [ ] Feature implemented as a vertical slice (CQRS, correct folder structure, domain vocabulary) into the scaffolded app
+- [ ] In-memory coverage check passed (every FR + the acceptance flow addressed)
+- [ ] Build checked; extension hooks dispatched or skipped per the rules above
+- [ ] **Final Execution Note** emitted, and the developer asked whether to include the itemized unclear-areas / assumptions breakdown

package/assets/.agents/skills/aw-spec-plan/SKILL.md

@@ -19,6 +19,10 @@ $ARGUMENTS
 
 You **MUST** consider the user input before proceeding (if not empty).
 
+## Context Reuse (cross-command dedup)
+
+**Skip Read-ing any file already in this conversation.** Before loading a standards/domain/template/spec file this command names, check whether it is already in context (loaded earlier here or by a prior `/aw-spec-*` command). If present and unchanged, reuse it and **skip the Read** — only Read files not yet loaded. A file already in context still counts as loaded; this just avoids the redundant re-read.
+
 ## Auto-Loaded Engineering Standards (Required Context)
 
 **Before doing anything else in this command, load the project engineering-standards files listed below into context using the Read tool.** These were previously supplied manually as `@docs/...` mentions; they are now loaded automatically so the user does not need to pass them. Rules:

package/assets/.agents/skills/aw-spec-specify/SKILL.md

@@ -19,6 +19,10 @@ $ARGUMENTS
 
 You **MUST** consider the user input before proceeding (if not empty).
 
+## Context Reuse (cross-command dedup)
+
+**Skip Read-ing any file already in this conversation.** Before loading a standards/domain/template/spec file this command names, check whether it is already in context (loaded earlier here or by a prior `/aw-spec-*` command). If present and unchanged, reuse it and **skip the Read** — only Read files not yet loaded. A file already in context still counts as loaded; this just avoids the redundant re-read.
+
 ## Auto-Loaded Engineering Standards (Required Context)
 
 **Before doing anything else in this command, load the project engineering-standards files listed below into context using the Read tool.** These were previously supplied manually as `@docs/...` mentions; they are now loaded automatically so the user does not need to pass them. Rules:

package/assets/.agents/skills/aw-spec-tasks/SKILL.md

@@ -19,6 +19,10 @@ $ARGUMENTS
 
 You **MUST** consider the user input before proceeding (if not empty).
 
+## Context Reuse (cross-command dedup)
+
+**Skip Read-ing any file already in this conversation.** Before loading a standards/domain/template/spec file this command names, check whether it is already in context (loaded earlier here or by a prior `/aw-spec-*` command). If present and unchanged, reuse it and **skip the Read** — only Read files not yet loaded. A file already in context still counts as loaded; this just avoids the redundant re-read.
+
 ## Auto-Loaded Engineering Standards (Required Context)
 
 **Before doing anything else in this command, load the project engineering-standards files listed below into context using the Read tool.** These were previously supplied manually as `@docs/...` mentions; they are now loaded automatically so the user does not need to pass them. Rules:

package/assets/.claude/skills/aw-spec-addcomponent/SKILL.md

@@ -86,17 +86,30 @@ registration scaffold, and verification steps — do not invent integration step
 
 7. **Add the code (one or more selected).** Execute the chosen component's `integration.md` runbook
    **in order** for the selected implementation(s):
-   - Locate the target projects the runbook names (typically `…Application`, `…Infrastructure`,
-     `…Service`; map the roles if the layout differs).
+   - Resolve the **host/startup project** the runbook targets — the single project that owns
+     `Program.cs` + the ASP.NET Core web SDK (`<App>.Service` for the Vertical Slice foundation,
+     `<App>.API` for the Modular Monolith foundation, or another name in a future template). **Find it
+     by locating `Program.cs`, not by assuming a fixed name.** These foundations have **no** separate
+     `…Application` / `…Infrastructure` project — package references, registration, and
+     `appsettings.json` all target this one project.
    - Apply the runbook's **"Common steps"** once.
    - Apply each selected implementation's **block** (package version in
      `Directory.Packages.props`, `PackageReference` without `Version=`, registration line, config).
    - Set `options.Provider` per the runbook (when multiple implementations are selected, follow the
      runbook's rule for choosing the default/active provider — ask a single-select follow-up if it
      requires one).
-   - Honor the cross-cutting rules in `docs/components/README.md` (R0.1–R0.5): versions only in
-     `Directory.Packages.props`; register in Infrastructure; inject the abstraction; always set
-     `options.Provider`; never commit secrets.
+   - Honor the cross-cutting rules in `docs/components/README.md` (R0.1–R0.5, incl. R0.2a): versions
+     only in `Directory.Packages.props`; register in the host/startup project resolved via `Program.cs`
+     (R0.2 — its `Extensions/InfrastructureServiceRegistration.cs`/`AddInfrastructure` if present,
+     else `Program.cs`); inject the abstraction; always set `options.Provider`; never commit secrets.
+   - **Register in both startup paths when they exist (R0.2a).** If the host project splits
+     registration into `AddInfrastructure` (`Extensions/InfrastructureServiceRegistration.cs`) **and**
+     `AddAspireInfrastructure` (`Extensions/AspireInfrastructureExtensions.cs`) — the
+     `if (isAspire) AddAspireInfrastructure(...) else AddInfrastructure(...)` switch in `Program.cs` —
+     add the component's registration to **both** methods, not just `AddInfrastructure`. The block is
+     the same in each, differing only in provider-specific calls (connection strings, `UseSqlite` vs
+     `UseNpgsql`) that must match that method's existing provider. Registering in only one leaves the
+     component missing whenever the app runs in the other mode.
    - Run any optional usage/feature-slice and schema steps only if the runbook calls for them or the
      user asks.