aw-spec-cli 0.1.5 → 0.1.7

package/assets/.aw-spec/DESIGN-FORMAT.md

@@ -1,151 +0,0 @@
-# aw-spec design-doc format — the single high-level design (HLD)
-
-The format the spec-anchored pipeline uses for the **Design** phase. Sibling of
-`ORCH-DIALECT.md` (the orchestrator dialect) and `RULE-PARTITION.md` (which rules each
-command loads): this one governs the *artifact* those workflows read and write — the
-design document — not the engine. The authoring template is
-`.aw-spec/templates/design-template.md`.
-
-## The contract
-
-A feature's design is **one document**, living beside its spec:
-
-```
-specs/<Aggregate>/
-  spec.md      # behaviour (tech-agnostic) — WHAT / WHY — the source of truth
-  design.md    # structure & decisions (tech-agnostic HLD) — the MEDIATOR
-  changes/     # open + archived change records (delta-spec + delta-design)
-```
-
-`design.md` is the **mediator** between the spec and the generated code:
-
-```
-spec.md  ──▶  design.md  ──▶  code (+ tests)
-behaviour     structure &       generated by `implement`
-FR/BR/US/SC   decisions (HLD)    (stack bound at generation time)
-```
-
-- **One design per aggregate.** The four clean-architecture layers (Domain,
-  Application, API, Infrastructure) are **sections** of this one document, each at
-  design level. Feature = aggregate; commands are user stories inside it. *(This is
-  the **greenfield** layout, authored from `design-template.md`. See the Brownfield
-  variant below for reverse-engineered / existing-codebase designs.)*
-- **High-level, not code.** It carries entities/value-objects/events, behaviour as
-  **signatures + pre/post/invariant/raises**, use-cases, endpoint contracts, ports,
-  and the significant technical decisions with rationale — but **no complete method
-  bodies**. See `design-template.md` for the section structure (§0–§9). The domain
-  layer (§1) follows spec.md exactly — its entities/value-objects are the spec's Key
-  Entities and its invariants are the spec's Business Rules.
-- **Technology-agnostic.** Behaviour and contracts use conceptual types, never a
-  language. The SAME design.md must be generatable on a different stack. The target
-  language/framework/persistence is bound only at `implement` time from the
-  constitution's technology base + the active stack profile.
-- **Physical schema is out of scope.** PKs/FKs, columns, indexes, JSON shapes, and
-  migration SQL belong to a separate technical-data-model — design.md states WHAT is
-  stored and WHICH port persists it, not the schema.
-- **Two deferral ledgers are first-class:** §7 Assumptions (`DA-n`, clarify later)
-  and §8 Workarounds (`WA-n`, clear later). They keep the HLD honest about what it
-  defers; `implement` tags generated code that leans on them.
-- **Solution-wide rules live elsewhere, not per feature:** the layering/dependency
-  rule is the constitution's; the code-generation mechanics (folder mapping,
-  file-per-element, test pairing, stack binding) are a technology-specific rule
-  applied in the `implement` phase. `design.md` stays feature-specific and
-  technology-agnostic.
-
-## Brownfield variant (existing codebases)
-
-A design reverse-engineered from — or added forward to — an **existing** codebase is
-authored from the repo's **code-derived `design-template` override**, which
-`/aw-spec-orch onboard` reverse-engineers from the repo's own structure and installs at
-`.aw-spec/templates/overrides/design-template.md`. Both `adopt` (reverse design) and the
-forward `design` phase scaffold from it via the default template name. It is the **same
-contract** as above — one living HLD per aggregate, tech-agnostic, spec-anchored, with the
-same traceability spine and the two deferral ledgers — with **one difference that matters**:
-
-- **Structure follows the code, not a fixed layering.** The **code is the source of
-  truth**, so the design describes the system **as-built**. Its structural sections
-  are **derived from the code's own organisation** (its folders / projects / modules)
-  rather than the fixed Domain/Application/API/Infrastructure four. A component the
-  code has that fits no textbook layer (a UI tier, a worker, a host project) gets its
-  own section; a layer the code lacks does not appear. Two neutral anchors are kept
-  because every system has them and the tooling keys on them: **§1 is the domain/data
-  model** (the cross-reference tool reads it for `<Other>Id` reference edges) and one
-  **§2 subsection is the External Integrations table** (matched by heading keyword, so
-  `aw-xref` extracts contract edges from either layout). The `debt` ledger records
-  only debt the **code itself** evidences (stubs, dead code, torn seams) — being
-  organised unlike a reference architecture is **not** debt, it is the as-built shape;
-  migrating toward a target is a separate modernization decision.
-
-This keeps a brownfield design free of greenfield architectural bias while remaining a
-normal feature the CR delta loop and forward pipeline consume unchanged.
-
-## Generate forward, reconcile only the high-level back
-
-The design document and the code are **not** a byte-for-byte copy of each other.
-
-| Direction | Phase | What happens |
-|---|---|---|
-| **Generate** (forward) | Implement | The model reads spec + design.md and **generates** the code and tests — a reasoning step the design guides and constrains, not a transcription. |
-| **Reconcile** (high-level back) | Build / Run fixes | Compile/typecheck/runtime fixes happen on the **code**. Only when a fix is a **high-level technical variation** — a changed pattern, a new component, an altered contract/dependency — is that decision written back into design.md. Low-level churn stays in the code. |
-
-> **Invariant:** design.md remains a faithful **high-level** account of the built
-> system — every significant technical decision is recorded — but it is a durable
-> design reference, **not** a line-by-line mirror of the code. (This retires the old
-> `docs == files` extract/reconcile invariant.)
-
-## The traceability spine
-
-```
-FR/BR/US/SC ↔ design section (element / decision) ↔ code (+ tests) ↔ commit
-```
-
-Every design element traces **up** to a spec id, and the whole spec traces **down**
-into a design section (§6 Traceability). This is what makes the analyze gate and the
-review able to check coverage, and what keeps CR impact analysis exact.
-
-## Feature granularity (why a command is a delta, not a new feature)
-
-A **feature is the largest slice whose code no other feature owns.** Because
-`implement` regenerates the whole feature's code coherently, a shared file
-(`src/Domain/Order.cs`) must have exactly **one** owning design. So for an aggregate
-with a shared entity, **feature = the aggregate** (`Order`), and individual commands
-(`CreateOrder`, `UpdateOrder`, …) are **user stories / deltas** on the same design.md:
-
-- `CreateOrder` = US-1; `UpdateOrder` = US-2.
-- Adding `UpdateOrder` is an additive CR: a Delta Spec (`+US-2`) and a Delta Design
-  (`ADDED` new use-case/endpoint sections, `MODIFIED` the shared Order/root and
-  repository sections — see `delta-design-template.md`). The design phase amends
-  design.md doc-first, bumps the feature version (`v1.0 → v1.1`), and archives the CR;
-  `implement` regenerates the touched slice; regression re-tests the shared-file
-  dependents.
-
-Two command-level features would both claim `src/Domain/Order.cs` and collide —
-which is exactly why the aggregate is the boundary.
-
-## Migration status
-
-**Complete.** Every phase now runs this HLD model, including the executable chain.
-
-The legacy path-tagged helpers (`design-extract` / `design-reconcile` / `design-paths`)
-are **retired and deleted** from both shells. They belonged to the four-document,
-full-code model in which `design.{domain,application,api,infra}.md` carried the source
-inside ` ```lang path=… ` fences. That convention is gone — no template emits `path=`,
-and `design-scaffold` writes a single `design.md` — so all three had been finding
-nothing and no-op'ing at exit 0. (Their glob, `design.*.md`, could not have matched a
-single `design.md` even if the fences had survived: the second dot required a middle
-segment. The one legitimate remaining user of that glob, `list-features`'s informational
-`design_docs` count, is fixed to `design*.md`.)
-
-The question those helpers answered — *which files is this slice made of* — is now an
-**OKF query**, because the knowledge bundle is where that answer is actually maintained:
-
-| Need | Now |
-| --- | --- |
-| read the slice's files | `aw-xref concept-paths --feature-dir <dir>` → the concept's `source_files` |
-| record files a fix loop touched | `aw-xref concept-upsert --source-files … --merge` |
-
-`build`, `run`, and `analyze-slice` all read through `concept-paths` (feeding their fix
-loops and, in `analyze-slice`, the conformance pass) and write back through
-`concept-upsert --merge`. Both directions are advisory: `concept-paths` is strictly
-read-only and returns an empty list rather than an error when no concept exists yet, so
-a greenfield slice before its first `implement` behaves exactly as it did before.

package/assets/.aw-spec/ORCH-DIALECT.md

@@ -1,156 +0,0 @@
-# aw-spec.orchestrator/v1 — orchestrator workflow dialect
-
-The workflow dialect executed by `.aw-spec/orchestrator/orchestrator.py`, and the
-**only** workflow dialect that ships. It grew out of the earlier declarative
-`skill.yaml` dialect (`aw-spec.declarative/v1`, the `aw-spec-decl-*` skills), which
-was **retired 2026-08-03** along with its reference doc: same YAML subset, same
-step/`outputs:`/`condition:` conventions, but built for
-the **orchestrator model**: the interpreter assembles 100% of every model
-payload (system = standards/rules, user = artifacts + task) and a **fresh
-agent** executes it under one of the 4 strategies. Everything here is common
-across agent roots — `.claude`, `.agents`, `.kilocode` differ only in their
-transport profile (`agent.json`) and their thin `/aw-spec-orch` launcher.
-
-## Layout (the common folder)
-
-```
-.aw-spec/orchestrator/
-  orchestrator.py            the engine (stdlib-only; reuses run-skill's YAML loader)
-  ORCH-DIALECT.md            → this doc lives at .aw-spec/ORCH-DIALECT.md
-  README.md                  strategies, transports, checkpoint machinery
-  AGENT-PROFILE.md           profile (agent.json) reference
-  adapters/                  shared per-SDK adapters (claude_agent_sdk, google_antigravity)
-  modules/                   shared includable modules (*.orch.yaml): delta-design,
-                             delta-spec, domain-select, tech-select
-  rev-templates/             neutral (shape-only) skeletons the brownfield govern-backward
-                             authors follow — see aw-spec-onboard.orch.yaml
-  workflows/                 one aw-spec-<skill>.orch.yaml per converted skill (+ _smoke)
-.aw-spec/scripts/            53 deterministic subcommands — 36 in aw-spec-actions (a true
-                             bash+powershell pair) + 17 across aw-xref, aw-inventory,
-                             aw-parity, aw-rev-constitution (thin sh/ps1 wrappers over one
-                             python core each) — reused as-is
-```
-
-## Execution model (strictly held)
-
-1. **Context management is the orchestrator's** — as in `workflows/aw-spec-demo.orch.yaml`.
-   `build_context` REPLACES the per-request envelope; `load_standards`
-   maintains the sticky system prefix. No agent ever assembles its own context.
-2. **Execution follows any of the 4 strategies** (`--strategy`, per-step
-   `strategy:` override): `sdk`, `sdk-apply`, `spawn`, `agent` — they only
-   govern WHO fulfills a generation, never what goes into it.
-3. **The checkpoint channel is strategy-independent** (D1): `ask`,
-   `user_select` and `dispatch_hooks` suspend via `--checkpoint` under EVERY
-   strategy, so the launching agent can relay to the human. Converted-skill
-   launchers therefore always pass `--checkpoint`.
-
-## Workflow file anatomy
-
-```yaml
-name: aw-spec-<skill>
-dialect: aw-spec.orchestrator/v1     # checked by --validate
-
-inputs:                              # F10 — bound from --input
-  user_input: { description: …, required: false, bind: USER_INPUT }
-
-scripts:                             # F1 — ref map for execute_script
-  actions:
-    sh:  .aw-spec/scripts/bash/aw-spec-actions.sh
-    ps1: .aw-spec/scripts/powershell/aw-spec-actions.ps1
-
-standards:                           # F4 — optional seed of the sticky set
-  - { path: docs/architecture/clean-architecture.md, optional: true }
-
-vars: { k: v }                       # seed variables (--var k=v overrides)
-workflow: [ …steps… ]
-outputs: { k: "{{v}}" }              # resolved and printed at the end
-```
-
-Every step: `id:` (required, unique), `action:`, optional `condition:`
-(`==`/`!=`/truthy), optional `strategy:`/`model:` (generating actions),
-optional `outputs: [{name, from: "$.field"}]` (JSONPath into the step's
-structured result). `{{var}}` substitutes with dotted/index access
-(`{{q.text}}`, `{{items.0}}`); a value that is EXACTLY one `{{ref}}` yields
-the raw object, not its JSON string.
-
-## Actions
-
-| action | who runs | what it does |
-|---|---|---|
-| `set` | engine | assign vars (`vars:` or decl-style `parameters:`); raw-object aware |
-| `build_context` | engine | REPLACE the per-request envelope: `system:`/`context:` file lists (+ `context_from: <var>` holding paths a prior generation reported, + `vars:`) |
-| `load_standards` | engine | F4 — append to the **sticky standards set** prepended to every system block (dedup, `optional:`, `files:`/`files_from_variable`). This is the byte-stable, prompt-cacheable prefix |
-| `execute_script` | engine | F1 — run a `scripts:` ref (`subcommand:` + `args:`; sh/ps1 via `--os`); stdout's last line = JSON, bound via `outputs[]`; `on_error: continue` tolerated; cached across resumes; runs for real even in mock transport |
-| `verify_context` | engine | F2 — gates: `required_files` (+`allow_missing`), `require_non_empty` (+`on_empty[_message]`), `require_true` (+`on_false[_message]`), `require_value`+`equals` (+`on_mismatch[_message]`). `stop` raises a terminal stop |
-| `agent_generate` | fresh agent | demo contract (code work): agent DECIDES file paths per the loaded standards, writes with its tools, reports `files[]` in the trailing ```json fence. `sdk-apply` = read-only generation + invoking agent applies |
-| `agent_review` | fresh agent | read-only review of `review_of_var`/`review_of` files → `{pass, issues}` |
-| `agent_author` | fresh agent | F5 — **authored artifact** (decl `llm_generate`): the INTERPRETER owns `output_target: {type: file, path}`. Generation is READ-ONLY under every strategy; the ENGINE writes the returned content (sdk-apply degrades to sdk). Optional `context:` (per-request extras), `include_standards: false` (narrow payload) |
-| `agent_query` | fresh agent | F6 — generic read-only structured JSON (decl `llm_query`): `schema:` shapes the required fence, `outputs[]` binds it, `mock:` supplies the mock-transport result; one malformed-JSON retry on fresh strategies |
-| `ask` | human (via launcher) | F7 — question: `prompt`, `options`/`options_from`/`options_from_variable`, `multi`, `answer_key`, `answer_var` (default `answer`). Sources in order: cache → `--answer k=v` → `--non-interactive` (first option; all when multi) → checkpoint suspend `ask` → stdin |
-| `user_select` | human (via launcher) | F7 — pick ONE from `options_from_variable`; `preselect_from` (direct-argument fast path), `single_option_confirm`; `--select stepid=v`; binds `selection` + `outputs[]` |
-| `dispatch_hooks` | invoking agent | F8 — suspend kind `hook` with the `hooks_from_variable` list (slash commands of the LAUNCHING agent); logged-only without a checkpoint; never re-fires across resumes |
-| `include` | engine | F9 — run a module `.orch.yaml` inline: shares vars/envelope/standards/scripts/replay-cache; `with:` seeds inputs; cache keys namespaced `inc:<id>/…`; module `Stop` stops the caller |
-| `loop` | engine | `while: <cond>` + `max_iterations` (default 5), or F3 foreach `over: "{{list}}"` + `as: item` (binds `item`, `item_index`, `iteration`); `break` (+`condition:`) exits the innermost loop |
-
-Decl steps may keep their `parameters:` wrapper — every ported action reads
-`parameters:` or flat step keys interchangeably, so conversion is mechanical.
-
-## The suspend-kind protocol (checkpoint transport)
-
-At each handoff the engine writes sidecars next to the state file, prints the
-`pending` request (exit 2), and the launcher fulfills it, writes
-`response_path`, and re-runs the same command. Kinds:
-
-| kind | sidecars | launcher writes to response_path | resume ingests as |
-|---|---|---|---|
-| `agent_generate` | system/user | full reply ending in ```json fence | parsed fence → replay cache |
-| `agent_review`, `agent_query` | system/user | read-only reply ending in ```json fence | parsed fence |
-| `apply` | artifact | confirmation ```json fence after writing the named files | parsed fence |
-| `author` | system/user (+`target`) | the COMPLETE file content — no fence, no commentary (the ENGINE writes `target`) | raw content |
-| `ask` | none (`prompt`/`options`/`multi` inline) | the answer as plain text (comma-separated when multi) | string / list |
-| `select` | none (`prompt`/`options` inline) | the chosen option's value | string |
-| `hook` | none (`hooks` inline) | `done` after running the mandatory slash commands | `true` |
-
-A rejected response re-suspends with a `note` explaining what to fix. The
-state file persists vars, strategy, model, profile path, `--input`, answers,
-selects, `--os` and the replay cache — a bare
-`… <workflow> --checkpoint <state>` resumes with everything restored.
-Completed steps (generations, scripts, answers, hooks) replay from the cache
-and never re-fire; loop iterations get their own keys (`loopid#i`).
-
-## CLI
-
-```
-orchestrator.py <workflow.orch.yaml>
-  --strategy sdk|sdk-apply|spawn|agent   (per-step `strategy:` overrides)
-  --agent-profile <agent.json>           spawn/sdk/sdk-apply
-  --checkpoint <statefile>               the interaction channel (always, for converted skills)
-  --input "<text>"                       bound via inputs: (F10)
-  --answer k=v … / --select stepid=v …   HITL prefills
-  --non-interactive                      CI: first option everywhere
-  --os posix|windows                     script variant (F1 / D7)
-  --model <name> / --budget / --isolation bare|fresh / --sdk-install
-  --var k=v … / --show-full / --json / --dry-run
-  --validate                             F11 — static lint, never executes
-```
-
-## decl → orch conversion map
-
-| declarative (run-skill) | orchestrator |
-|---|---|
-| `load_context` (standards, domain rules, constitution) | `load_standards` (sticky system set — D3) |
-| `load_context` (feature artifacts, templates) | `build_context` `context:` before the consuming step |
-| `llm_generate` + `output_target` | `agent_author` (same `output_target`) |
-| `llm_query` | `agent_query` (+ `schema:`, `mock:`) |
-| `include_loaded_context: false` | narrow `build_context` + `include_standards: false` |
-| `execute_script` / `verify_context` / `ask` / `user_select` / `dispatch_hooks` / `set` / `loop` / `break` / `include` | same action, `parameters:` wrapper optional |
-| implement-style code tasks | `agent_generate` (+ `agent_review`), `context_from` chaining between iterations |
-
-## Validation & smoke
-
-- `--validate` every workflow/module (unknown actions/strategies, duplicate
-  ids, script refs + files on disk, `output_target.path`, module paths,
-  unproduced `{{vars}}`, dialect header).
-- `workflows/_smoke.orch.yaml` exercises every construct with no model and no
-  writes outside `.smoke-out`: run it `--non-interactive` (CI) and with
-  `--checkpoint` (protocol walk-through).

package/assets/.aw-spec/RULE-PARTITION.md

@@ -1,126 +0,0 @@
-# Rule Partition — which command reads which rules
-
-*AppWeaver · aw-spec · companion to [Spec-Anchored-Pipeline.md](Spec-Anchored-Pipeline.md) and
-[DESIGN-FORMAT.md](DESIGN-FORMAT.md)*
-
-The authority on how rule files are partitioned across the pipeline, so each phase gets a
-focused, non-overlapping context. Domain-agnostic and technology-agnostic: it describes the
-**contract**, never a particular project's files. The concrete file lists are configuration —
-they live in the two rule maps, not here.
-
----
-
-## The principle — the spec is the pivot
-
-Domain knowledge enters the pipeline **once**, at `specify`, and is written into the spec as
-identified requirements (`BR-` / `CN-` / `DC-` / `IC-` / `FR-`). From that point on the **spec is
-the only domain input**. Later phases mediate against the spec, not against the domain files.
-
-This is what makes a spec re-platformable: swap the technical rule set and the same spec still
-governs. It also stops domain detail leaking straight into code authoring without ever being
-pinned in a reviewable requirement.
-
-> **Lift, then gate.** If a domain constraint is needed downstream, it must first be *lifted*
-> into the spec as an id. A gate that finds a constraint in neither the spec nor the design
-> reports `LIFT-FAILURE:` and routes back to `specify` — it must never invent the rule into a
-> design or into code.
-
----
-
-## The three classes of rule input
-
-| Class | What it is | Carried by |
-|---|---|---|
-| **Domain rule files** | Business/domain rules of the active domain | `comandrulemap.md`, read by `resolve-domain` |
-| **Technical rule files** | Architecture, conventions, code-generation rules | `commandtechrulemap.md`, read by `resolve-tech` |
-| **Constitution halves** | Ratified standing principles | Referred to **directly, as-is** — never mapped |
-
-Both maps are **configuration**: to change what a phase loads, edit the map, not the workflow.
-A command with **no heading** in a map loads nothing mapped for that class and
-**soft-continues** — an absent heading is a valid state, never a failure.
-
-### The constitution halves are not mapped
-
-- `.aw-spec/memory/constitution.technical.md` — the technology base. Standing input to
-  **design + implement**. Domain-agnostic.
-- `.aw-spec/memory/constitution.domain.md` — the active domain's addenda. Standing input to
-  **specify** (and the gate checklist). Deliberately **not** loaded by design or implement.
-- `.aw-spec/memory/constitution.md` — the composed human/compatibility view. The pipeline loads
-  the halves, not this file.
-
----
-
-## The map
-
-### `specify` — *domain modelling*
-- **Domain rule files: yes** — the domain authority. Authored INTO the spec as ids.
-- **Technical rule files: no**, with one exception: a **modelling methodology** (e.g. DDD
-  tactical patterns) may seed it. That is a domain-agnostic way of *modelling*, not a
-  technology choice. Like every other class, that exception is **configuration** — it is
-  wired under `## /aw-spec-specify` in `commandtechrulemap.md`, not hardcoded in the
-  workflow. Nothing else may go under that heading: an architecture, persistence, or
-  code-generation file there would break specify's domain purity. Greenfield wires
-  `docs/domain/domain-driven-design.md`; a code-derived (brownfield) pack wires
-  `tech/domain-modelling.md`, which `onboard` reverse-engineers from the code — the
-  as-built answer to *how does this codebase express a domain model*. Either way it is
-  **HOW to model**; **WHAT** the model is stays in the domain tier.
-- Constitution: the **domain** half.
-
-### `design` — *architecture; domain input = the spec only*
-- **Domain rule files: NEVER.** Domain reaches design solely as spec ids.
-- **Technical rule files: yes** — architecture and cross-cutting rules the design mediates the
-  spec against.
-- Constitution: the **technical** half.
-
-### `implement` / `implement-delta` — *code generation*
-- **Domain rule files: NEVER.** The design is the only input describing what to build.
-- **Technical rule files: yes** — the code-generation and convention set.
-- Constitution: the **technical** half.
-
-### `build` — *compile + repair*
-- **Technical rule files: yes** — the layering and convention rules the compile-fixer respects.
-- No domain files: build repairs against design intent, which the domain never reaches.
-
-### `run` — *runtime*
-- **Technical rule files:** only if the project evidences a runtime/hosting concern.
-
-### Gates — `analyze-design`, `analyze-delta-design`, `analyze-slice`, and the `/aw-spec-gate` overlay set
-- Load the domain **gate overlays** as a **conformance checklist**.
-- **Validation input ONLY — never authoring.** A gate may fail a document or a slice; it may
-  never write a rule into one.
-
-### `constitution`
-- Loads both classes to author the two halves from their own sources.
-
-### `adopt` (brownfield)
-- Same partition, reversed: the reversed **spec** is authored with domain rules in context; the
-  reversed **design** is authored with the technical set only, so design stays domain-free.
-- Technical files here are **reference, not authority — the CODE wins.**
-
----
-
-## Invariants
-
-1. **No domain rule file is ever loaded by `design`, `implement`, `implement-delta` or `build`.**
-2. **Domain reaches design and code only as spec ids.**
-3. **Gate overlays validate; they never author.**
-4. **A constraint not in the spec cannot be honoured downstream** — lift it first
-   (`LIFT-FAILURE:` → back to `specify`).
-5. **An absent map heading loads nothing and soft-continues** — it is never a blocking error.
-6. **The constitution halves are referred to directly** and never listed in either map.
-
----
-
-## Where the concrete lists live
-
-| Map | Reader | Class |
-|---|---|---|
-| `docs/domainspecs/<domain>/comandrulemap.md` | `resolve-domain` | domain rule files |
-| `docs/domainspecs/<domain>/commandtechrulemap.md` | `resolve-tech` | technical rule files |
-
-Each map keys on `## /aw-spec-<command>` headings whose `- ` bullets are workspace-relative
-file paths. Shape references for authoring a new pack live in
-`.aw-spec/orchestrator/rev-templates/`.
-
-Rule files may carry a `Commands:` header naming their consumers. That header is **derived from
-these maps** — the maps are authoritative; a header that disagrees is a bug in the header.

package/assets/.aw-spec/domain.json

@@ -1,3 +0,0 @@
-{
-  "domain": ""
-}

package/assets/.aw-spec/extensions/.registry

@@ -1,19 +0,0 @@
-{
-  "schema_version": "1.0",
-  "extensions": {
-    "agent-context": {
-      "version": "1.0.0",
-      "source": "local",
-      "manifest_hash": "sha256:9a1dc02d2d0139bb03860392ecacef79183be2c442feda2f9ccaa4e5907b1e47",
-      "enabled": true,
-      "priority": 10,
-      "registered_commands": {
-        "claude": [
-          "aw-spec.agent-context.update"
-        ]
-      },
-      "registered_skills": [],
-      "installed_at": "2026-06-10T07:39:02.078494+00:00"
-    }
-  }
-}

package/assets/.aw-spec/extensions/agent-context/README.md

@@ -1,57 +0,0 @@
-# Coding Agent Context Extension
-
-This bundled extension manages the **coding agent context/instruction file** (e.g. `CLAUDE.md`, `.github/copilot-instructions.md`, `AGENTS.md`, `GEMINI.md`, …) for the active integration.
-
-It owns the lifecycle of the managed section delimited by the configurable start/end markers (defaults: `<!-- AW-SPEC START -->` / `<!-- AW-SPEC END -->`).
-
-## Why an extension?
-
-Not every AW-Spec user wants AW-Spec to write into the coding agent's context file. Extracting this behavior into a dedicated extension lets users:
-
-- **Opt out** entirely with `specify extension disable agent-context` — AW-Spec will then never create or modify the agent context file.
-- **Customize the markers** by editing `.aw-spec/extensions/agent-context/agent-context-config.yml` — both the Python layer and the bundled scripts honor the same `context_markers` value.
-- **Refresh on demand** with `/aw-spec.agent-context.update`, or automatically through the hooks declared in `extension.yml` (`after_specify`, `after_plan`).
-
-## Commands
-
-| Command | Description |
-|---------|-------------|
-| `aw-spec.agent-context.update` | Refresh the managed section in the agent context file with the current plan path. |
-
-## Configuration
-
-All configuration flows through the extension's own config file at
-`.aw-spec/extensions/agent-context/agent-context-config.yml`:
-
-```yaml
-# Path to the coding agent context file managed by this extension
-context_file: CLAUDE.md
-
-# Delimiters for the managed AW-Spec section
-context_markers:
-  start: "<!-- AW-SPEC START -->"
-  end: "<!-- AW-SPEC END -->"
-```
-
-- `context_file` — the project-relative path to the coding agent context file, written by `specify init` and `specify integration install`.
-- `context_markers.start` / `.end` — the delimiters around the managed section. Edit these to use custom markers.
-
-## Requirements
-
-The bundled update scripts require **Python 3** with **PyYAML** for YAML/upsert processing (PowerShell can also use `ConvertFrom-Yaml` when available).
-
-PyYAML ships with the `specify` CLI and is normally available via the same `python3` interpreter. If a hook reports *"PyYAML is required … not available in the current Python environment"*, it means the system `python3` differs from the one used to install AW-Spec. To resolve, run:
-
-```bash
-pip install pyyaml
-# or target the specific interpreter AW-Spec uses:
-/path/to/aw-spec-python -m pip install pyyaml
-```
-
-## Disable
-
-```bash
-specify extension disable agent-context
-```
-
-When disabled, AW-Spec skips context file creation, updates, and removal (the gates are inside `upsert_context_section()` and `remove_context_section()`).

package/assets/.aw-spec/extensions/agent-context/agent-context-config.yml

@@ -1,4 +0,0 @@
-context_file: CLAUDE.md
-context_markers:
-  start: <!-- AW-SPEC START -->
-  end: <!-- AW-SPEC END -->

package/assets/.aw-spec/extensions/agent-context/commands/aw-spec.agent-context.update.md

@@ -1,26 +0,0 @@
----
-description: "Refresh the managed AW-Spec section in the coding agent context file"
----
-
-# Update Coding Agent Context
-
-Refresh the managed AW-Spec section inside the active coding agent's context/instruction file (e.g. `CLAUDE.md`, `.github/copilot-instructions.md`, `AGENTS.md`).
-
-## Behavior
-
-The script reads the agent-context extension config at
-`.aw-spec/extensions/agent-context/agent-context-config.yml` to discover:
-
-- `context_file` — the path of the coding agent context file to manage.
-- `context_markers.start` / `.end` — the delimiters surrounding the managed section. Defaults to `<!-- AW-SPEC START -->` and `<!-- AW-SPEC END -->` when the field is missing.
-
-It then creates, replaces, or appends the managed block so that the section points at the most recent plan path when one can be discovered (`specs/<feature>/plan.md`).
-
-If `context_file` is empty or the file cannot be located, the command reports nothing to do and exits successfully.
-
-## Execution
-
-- **Bash**: `.aw-spec/extensions/agent-context/scripts/bash/update-agent-context.sh [plan_path]`
-- **PowerShell**: `.aw-spec/extensions/agent-context/scripts/powershell/update-agent-context.ps1 [plan_path]`
-
-When `plan_path` is omitted, the script auto-detects the most recently modified `specs/*/plan.md`.

package/assets/.aw-spec/extensions/agent-context/extension.yml

@@ -1,37 +0,0 @@
-schema_version: "1.0"
-
-extension:
-  id: agent-context
-  name: "Coding Agent Context"
-  version: "1.0.0"
-  description: "Manages coding agent context/instruction files (e.g., CLAUDE.md, copilot-instructions.md) with project-specific plan references and configurable markers"
-  author: aw-spec-core
-  repository: https://github.com/github/aw-spec
-  license: MIT
-
-requires:
-  aw-spec_version: ">=0.2.0"
-
-provides:
-  commands:
-    - name: aw-spec.agent-context.update
-      file: commands/aw-spec.agent-context.update.md
-      description: "Refresh the managed AW-Spec section in the coding agent context file"
-
-# NO auto-wired hooks — this extension is ON-DEMAND only
-# (/aw-spec.agent-context.update). It previously declared after_specify + after_plan,
-# and installing it re-wrote both into .aw-spec/extensions.yml. Both were stale:
-#   • after_plan   — no workflow dispatches that phase; the plan/tasks tier was
-#                    retired by the spec-anchored redesign.
-#   • after_specify — the updater targets `specs/*/plan.md`, which nothing produces,
-#                    so every specify (greenfield forward loop AND brownfield CR
-#                    loop, which both enter at specify) offered a hook that could
-#                    not do its job.
-# Restore a hook here once the updater is retargeted at spec.md / design.md — that
-# retarget is the open work, not the hook wiring.
-hooks: {}
-
-tags:
-  - "agent"
-  - "context"
-  - "core"