diff --git a/src/bmm-skills/3-solutioning/bmad-architecture/SKILL.md b/src/bmm-skills/3-solutioning/bmad-architecture/SKILL.md
index 551f98602..8a94630c9 100644
--- a/src/bmm-skills/3-solutioning/bmad-architecture/SKILL.md
+++ b/src/bmm-skills/3-solutioning/bmad-architecture/SKILL.md
@@ -1,12 +1,13 @@
 ---
 name: bmad-architecture
-description: 'Produce the architecture: a lean spine of invariants that keeps everything built from it consistent, projected into whatever format the work needs. Use when the user says "create the architecture", "create technical architecture", "architecture spine", or "create a solution design".'
+description: 'Produce, update, validate, or refine architecture as a lean spine of invariants that keeps independently built work consistent. Use when the user asks for architecture, solution design, an architecture spine, or brownfield refinement of seams, interfaces, and module boundaries.'
 ---
+
 # BMad Architecture
 
 ## Overview
 
-You produce an **architecture spine**: a consistency contract that fixes only the **invariants** keeping independently-built units from diverging — the design paradigm, the boundary and dependency rules, how state is mutated, who owns shared data. Everything structural (stack, tree, full data shape) is **seed**: true at cold-start, owned by the code once it exists. A spine is not a design document; its worth is the durable calls a future builder *can't* read off compliant code. Lead with a named paradigm — it carries a whole model for free — and keep the seed minimal.
+You produce an **architecture spine**: a consistency contract that fixes only the **invariants** keeping independently-built units from diverging — the design paradigm, the boundary and dependency rules, how state is mutated, who owns shared data. Everything structural (stack, tree, full data shape) is **seed**: true at cold-start, owned by the code once it exists. A spine is not a design document; its worth is the durable calls a future builder _can't_ read off compliant code. Lead with a named paradigm — it carries a whole model for free — and keep the seed minimal.
 
 One test decides what belongs:
 
@@ -18,17 +19,17 @@ Record decisions, not rationale (rationale lives in the memlog). Carry shape in
 
 ## How you work
 
-You're a coach, and the **Coaching path is the default** — this runs against the model's instinct to just produce an architecture, so hold the line on it. The choice (offered as an Activation step, in the user's language, before any drafting): **Coaching path** (we work it together — open-ended questions, I pull the decisions out of you and push back where one is thin) or **Fast path** (I draft the whole spine fast with `[ASSUMPTION]` tags you correct in review). Unless the user clearly wants speed, **coach; don't silently draft.** A finished architecture produced from two quick questions is the failure mode, not the win — the elicitation is the value. On the Coaching path, the load-bearing calls — paradigm, stack or starter, the major boundaries — are *shown, not silently made*: lay out the realistic alternatives you weighed and why you lean one way, then let the user choose. That rationale lives in the conversation and the memlog, never in the terse spine.
+You're a coach, and the **Coaching path is the default** — this runs against the model's instinct to just produce an architecture, so hold the line on it. The choice (offered as an Activation step, in the user's language, before any drafting): **Coaching path** (we work it together — open-ended questions, I pull the decisions out of you and push back where one is thin) or **Fast path** (I draft the whole spine fast with `[ASSUMPTION]` tags you correct in review). Unless the user clearly wants speed, **coach; don't silently draft.** A finished architecture produced from two quick questions is the failure mode, not the win — the elicitation is the value. On the Coaching path, the load-bearing calls — paradigm, stack or starter, the major boundaries — are _shown, not silently made_: lay out the realistic alternatives you weighed and why you lean one way, then let the user choose. That rationale lives in the conversation and the memlog, never in the terse spine.
 
-Elicit, don't quiz: open-ended "how are you thinking about X?" beats a multiple-choice menu; reserve a crisp either/or for a genuinely binary fork. When you catch yourself picking the boundaries, the stack, or the phases for the user, hand the pen back — unless you're on the Fast path, where inferring and tagging *is* the job.
+Elicit, don't quiz: open-ended "how are you thinking about X?" beats a multiple-choice menu; reserve a crisp either/or for a genuinely binary fork. When you catch yourself picking the boundaries, the stack, or the phases for the user, hand the pen back — unless you're on the Fast path, where inferring and tagging _is_ the job.
 
 When the stack is open — greenfield, or a small/beginner project that could sit on a paved path — **recommend a well-known current starter** (verify the going choice on the web first): a good one pre-decides a coherent slab of the architecture for free and beats hand-rolling for a less-experienced user. For brownfield, **investigate before you decide** — read enough of the real code (and `project-context.md`; if there is none, offer to invoke the `bmad-document-project` skill) to ratify the conventions already there rather than invent new ones.
 
 ## Read the input to know the job
 
-The input itself tells you what kind of job this is — read it rather than quizzing the user about it. A spec package (`SPEC.md` + its memlog) is the richest start and the spine's home, so fold the spine back into it. But you'll also get a raw idea, a sprawling architecture document to distill down, an existing codebase to derive a spine *from* (ratify the conventions the code already shows — don't re-document them), the slice of one a new feature touches, or an existing spine to extend or pressure-test. Prefer a `.memlog.md` over re-reading the source it came from. Distill whatever you're given; mark real gaps as open questions instead of inventing answers. The spine's **altitude** mirrors what it augments and keeps the level below coherent — initiative→features, feature→epics, epic→stories.
+The input itself tells you what kind of job this is — read it rather than quizzing the user about it. A spec package (`SPEC.md` + its memlog) is the richest start and the spine's home, so fold the spine back into it. But you'll also get a raw idea, a sprawling architecture document to distill down, an existing codebase to derive a spine _from_ (ratify the conventions the code already shows — don't re-document them), the slice of one a new feature touches, an existing spine to extend or pressure-test, or a brownfield seam/interface/module-boundary to refine. Prefer a `.memlog.md` over re-reading the source it came from. Distill whatever you're given; mark real gaps as open questions instead of inventing answers. The spine's **altitude** mirrors what it augments and keeps the level below coherent — initiative→features, feature→epics, epic→stories.
 
-**Inheriting a parent spine** (e.g. pointed at one epic of a spec whose feature/initiative spine already exists): load the parent `ARCHITECTURE-SPINE.md` first and treat its `AD`s, conventions, and paradigm as **binding, read-only** constraints — log each as a `constraint` entry, list them under the spine's *Inherited Invariants* (parent `AD` IDs, never renumbered), and don't re-derive them. Your job is only what the parent **left open**: its `Deferred` items plus the divergences this epic's stories could hit. A new `AD` that contradicts or weakens an inherited one is a **conflict to surface**, not a local override. An epic spine fixes the invariants the epic's stories must share — it does **not** expand per-story detail; that's deferred to story time, when you invoke the `bmad-create-story` skill.
+**Inheriting a parent spine** (e.g. pointed at one epic of a spec whose feature/initiative spine already exists): load the parent `ARCHITECTURE-SPINE.md` first and treat its `AD`s, conventions, and paradigm as **binding, read-only** constraints — log each as a `constraint` entry, list them under the spine's _Inherited Invariants_ (parent `AD` IDs, never renumbered), and don't re-derive them. Your job is only what the parent **left open**: its `Deferred` items plus the divergences this epic's stories could hit. A new `AD` that contradicts or weakens an inherited one is a **conflict to surface**, not a local override. An epic spine fixes the invariants the epic's stories must share — it does **not** expand per-story detail; that's deferred to story time, when you invoke the `bmad-create-story` skill.
 
 ## How a run works
 
@@ -53,10 +54,10 @@ Writes go through the shared script (don't read the file back except on resume):
 
 1. Resolve customization: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow` (on failure read `{skill-root}/customize.toml`, use defaults). Run `{workflow.activation_steps_prepend}`, then `{workflow.activation_steps_append}`. Hold `{workflow.persistent_facts}` as standing context — the default loads `project-context.md`, load-bearing for brownfield — and consult `{workflow.external_sources}` on demand.
 2. Load `{project-root}/_bmad/bmm/config.yaml` (+ `config.user.yaml`) for `{user_name}`, `{communication_language}`, `{document_output_language}`, `{planning_artifacts}`, `{project_name}`, `{date}`; missing keys take neutral defaults, never block.
-3. Headless (no interactive user) → follow `references/headless.md` for the whole run. Otherwise greet `{user_name}` in `{communication_language}`. Detect the intent from the conversation and input — **create** (the default), **update** an existing spine, or **validate** one (see those sections). If the real ask is requirements / UX / a capability contract / epic breakdown / an agent, invoke the `bmad-prd`, `bmad-ux`, `bmad-spec`, `bmad-create-epics-and-stories`, or `bmad-workflow-builder` (if the BMad Builder module is installed) skill instead.
+3. Headless (no interactive user) → follow `references/headless.md` for the whole run. Otherwise greet `{user_name}` in `{communication_language}`. Detect the intent from the conversation and input — **create** (the default, including deriving a general spine from a brownfield codebase), **update** when an accepted spine amendment is already known, **validate** a spine without changing it, or **refine** when a specific seam/interface/module boundary/hotspot or tentative amendment must be investigated before acceptance (see those sections). If the real ask is requirements / UX / a capability contract / epic breakdown / an agent, invoke the `bmad-prd`, `bmad-ux`, `bmad-spec`, `bmad-create-epics-and-stories`, or `bmad-workflow-builder` (if the BMad Builder module is installed) skill instead.
 4. If a run folder for this target already exists under `{workflow.spine_output_path}`, offer to resume from its memlog rather than restart.
-5. Interactive create: offer the working mode in `{communication_language}` — **Coaching path** (default) or **Fast path** (see *How you work*) — before any drafting; default to Coaching unless the user asks for speed.
-6. **Mandatory, both paths, before drafting:** ask whether the spine is the only deliverable — and if not, draw out the *purpose and audience* rather than a document type. "An architecture doc" balloons into bloat; what they actually need might be a one-detail explainer for a single team or a non-technical vision piece for a board. Purpose right-sizes the artifact and may call for extra elicitation up front, not just a finale add-on.
+5. Interactive create or refine: offer the working mode in `{communication_language}` — **Coaching path** (default) or **Fast path** (see _How you work_) — before drafting or comparing options; default to Coaching unless the user asks for speed.
+6. **Mandatory, both paths, before drafting:** ask whether the spine is the only deliverable — and if not, draw out the _purpose and audience_ rather than a document type. "An architecture doc" balloons into bloat; what they actually need might be a one-detail explainer for a single team or a non-technical vision piece for a board. Purpose right-sizes the artifact and may call for extra elicitation up front, not just a finale add-on.
 
 For a new spine, bind `{doc_workspace}` to `{workflow.spine_output_path}/{workflow.run_folder_pattern}/`, seed `ARCHITECTURE-SPINE.md` from `{workflow.spine_template}`, run `memlog.py init`, and tell the user the path. **At epic altitude, scope the folder to the epic** (set `run_folder_pattern` per `customize.toml`) so per-epic runs don't collide.
 
@@ -72,11 +73,21 @@ Walk the sequence; reviewer fixes land before polish.
 2. **Reconcile inputs.** A subagent per load-bearing input checks it against the spine and returns what didn't land — especially a quiet requirement (a tone, a constraint) the `AD` structure dropped. Before the gate.
 3. **Reviewer pass.** Run the Reviewer Gate (`references/reviewer-gate.md`). Resolve before polish.
 4. **Triage.** Open questions and `[ASSUMPTION]` tags: blockers (unsafe for what's next) resolved one at a time; the rest deferred with a revisit condition in the memlog.
-5. **Renderings & polish.** The spine is the build deliverable; with it and the memlog now in place, produce any *additional* human-facing artifact the user needs, scoped to the purpose and audience drawn out up front. The up-front question already flagged whether one's needed; if it wasn't, still offer one here, seeding concrete options: an interactive HTML+SVG deck to walk a team through the architecture and drive discussion, a fuller HTML/md solution design, a C4 set, or a view of how the work splits across teams/epics. Build only what they pick, right-sized to that purpose; apply `{workflow.doc_standards}` polish to that prose only, never to the spine.
+5. **Renderings & polish.** The spine is the build deliverable; with it and the memlog now in place, produce any _additional_ human-facing artifact the user needs, scoped to the purpose and audience drawn out up front. The up-front question already flagged whether one's needed; if it wasn't, still offer one here, seeding concrete options: an interactive HTML+SVG deck to walk a team through the architecture and drive discussion, a fuller HTML/md solution design, a C4 set, or a view of how the work splits across teams/epics. Build only what they pick, right-sized to that purpose; apply `{workflow.doc_standards}` polish to that prose only, never to the spine.
 6. **External handoffs.** Run `{workflow.external_handoffs}`; surface returned URLs/IDs. Offer to invoke the `bmad-spec` skill to adopt the spine as a companion, keeping `AD` IDs stable so downstream can cite them.
 7. **Close.** Set the spine's own frontmatter `status: final`, `updated: {date}`; log a `memlog.py append --type event --text "spine finalized"` (the memlog has no status field). Share paths. Next, **lead with `bmad-spec`** — recommend adopting/refreshing the spine as a spec companion (always the top recommendation when a spec was an input, and a useful next step even when it wasn't), then `bmad-create-epics-and-stories` or — epic altitude — `bmad-create-story`; or invoke `bmad-help` to route.
 8. Run `{workflow.on_complete}`.
 
+## Refine
+
+Investigate a brownfield hotspot or pressure-test a seam, interface, or module boundary when the desired amendment is not yet known. Load `references/architecture-refinement.md`; when interface shape is at issue, also load `references/interface-design.md`.
+
+Use the normal run workspace and memlog. Select the nearest governing spine at the target altitude and inherit any parent spine above it. If that spine exists, resume from its `.memlog.md`; when its memlog is missing, reconstruct only demonstrable constraints from the spine and code, mark the reconstruction as an assumption, and halt blocked if stable decision history cannot be preserved. If no spine applies, perform the normal new-spine initialization (`doc_workspace`, spine template, and `memlog.py init`) at the smallest scope needed for the refinement. Candidate lists, interface comparisons, and recommendations are optional **companions** in `{doc_workspace}` — useful working evidence, never a second architecture authority.
+
+Explore and compare before committing. Existing reality may ratify a constraint or already-adopted decision; a new amendment requires explicit user acceptance in interactive runs. Append the durable outcome to the memlog as a decision, constraint, or deferred item, keeping inherited and existing `AD` IDs stable, then re-distill and run Finalize without changing intent or workspace mid-run. If investigation finds no architecture decision worth binding, record that result as an event; when this run initialized a new spine solely for refinement, remove the unfinalized seed spine and return the companions as non-authoritative evidence rather than manufacturing an `AD`.
+
+Story slices and test strategy are lower-altitude follow-ons: offer them only at epic altitude or when the user explicitly needs implementation planning. They must cite the governing `AD` IDs and remain subordinate to the spine.
+
 ## Update
 
 Amend an existing spine. Resume from its `.memlog.md` (the authority on what was decided), not the rendered spine. Capture the change as new memlog entries; **keep `AD` IDs stable** — amend a Rule in place, add the next `AD-n` for a new decision, never renumber or reuse a retired ID. Then re-distill (Finalize step 1), run the Reviewer Gate (`references/reviewer-gate.md`), and close as in Finalize. An update that overrides something from a source input: offer to update that source too, so upstream and the spine don't silently diverge.
diff --git a/src/bmm-skills/3-solutioning/bmad-architecture/references/architecture-refinement.md b/src/bmm-skills/3-solutioning/bmad-architecture/references/architecture-refinement.md
new file mode 100644
index 000000000..c99aea117
--- /dev/null
+++ b/src/bmm-skills/3-solutioning/bmad-architecture/references/architecture-refinement.md
@@ -0,0 +1,63 @@
+# Architecture Refinement
+
+Use this reference for brownfield architecture work where the problematic seam is visible but the durable decision is not yet known.
+
+## Build the working map
+
+Read the applicable spine and memlog first, then inspect the code, tests, project context, and ADRs needed to establish:
+
+- binding inherited and existing `AD` decisions
+- current ownership and dependency direction
+- repeated orchestration or knowledge spread across callers
+- tests coupled to internals instead of observable behavior
+- high-friction seams, interfaces, and module boundaries
+
+Ratify existing reality where it is coherent. Do not create an architecture decision merely to document code that already communicates the rule.
+
+## Find candidates
+
+Look for:
+
+- callers duplicating orchestration or policy
+- modules whose removal deletes indirection but no capability
+- helpers that moved code without concentrating change or knowledge
+- interfaces exposing nearly as much complexity as they hide
+- tests that must mock or inspect internals
+- seams justified by only one hypothetical implementation
+
+Before proposing interfaces, present a short ranked candidate list. For each candidate include files, divergence risk, likely direction, expected test-surface improvement, governing or conflicting `AD` IDs, migration size, and risk. In an interactive run, stop for the user's choice unless the request already names the target.
+
+## Resolve the chosen candidate
+
+Ask only what removes decision risk:
+
+- What behavior and callers must remain stable?
+- Which failures or changes repeatedly cross this area?
+- Which inherited decisions and ADRs are binding?
+- Is the work behavior-preserving or behavior-changing?
+- What observable tests must survive?
+
+Compare realistic options before committing. Use `./interface-design.md` when interface shape is material.
+
+## Dependency and seam rules
+
+- Merge in-process dependencies freely when a smaller interface can hide them.
+- A locally substitutable dependency can stay behind the interface when its stand-in supports behavior-level tests.
+- Put an owned remote dependency behind a seam only when production and test/local implementations are real.
+- Inject a true external dependency at the seam and isolate its adapter.
+- One implementation is not evidence of required variation; do not manufacture a port.
+- Keep internal seams private when callers do not need to know they exist.
+
+The interface is the preferred test surface. Assert observable behavior, invariants, errors, and performance obligations rather than internal state.
+
+## Translate the result
+
+Accepted durable outcomes must become memlog entries and then stable spine decisions or explicit Deferred items. Optional companions may include:
+
+- `refinement-candidates.md`
+- `interface-options-{slug}.md`
+- `refinement-recommendation-{slug}.md`
+
+Companions explain evidence and alternatives; they do not override the spine. Cite applicable `AD` IDs and flag conflicts rather than weakening inherited decisions.
+
+At initiative or feature altitude, stop at architecture decisions and Deferred items. Offer story slices or test strategy only at epic altitude or on explicit request; each must cite the governing `AD` IDs.
diff --git a/src/bmm-skills/3-solutioning/bmad-architecture/references/headless.md b/src/bmm-skills/3-solutioning/bmad-architecture/references/headless.md
index bd4d20be1..f9fef6136 100644
--- a/src/bmm-skills/3-solutioning/bmad-architecture/references/headless.md
+++ b/src/bmm-skills/3-solutioning/bmad-architecture/references/headless.md
@@ -2,14 +2,16 @@
 
 No interactive user: infer everything, ask nothing, but never invent — record inferences as `assumptions[]` and gaps that need a human as `open_questions[]`. Detect headless from a `headless: true` flag, a non-interactive / no-TTY invocation, an activation hook that declares it, or a first message that pre-supplies all inputs and asks for an artifact path back; when ambiguous, default to interactive.
 
-Drive the run from the payload in the first message — `intent`, `altitude`, `purpose`, the driving input (spec package / PRD / raw intent / brownfield path), a parent spine path at lower altitude, and `doc_workspace` if a specific folder is required. Infer anything absent from the inputs or workspace; don't invent stack, constraints, or scope to fill a gap. You still verify named tech on the web (you can't ask, but you can check) and still drive every write through the shared `{project-root}/_bmad/scripts/memlog.py`. Run the full Reviewer Gate (`references/reviewer-gate.md`) non-interactively: `scripts/lint_spine.py` plus **every `{workflow.finalize_reviewers}` lens as a parallel subagent** (and any ad-hoc lens the spine's criticality warrants). Headless skips only the human picking from the menu — never the reviewers themselves; apply the clear fixes and record anything unresolved in `open_questions[]`. For a true authority collision, list it in `conflicts_with_prior_decisions[]`. For the Validate intent, always write the report to `{doc_workspace}` and add `"offer_to_update": true`. If intent stays ambiguous after inference, halt blocked.
+Drive the run from the payload in the first message — `intent`, `altitude`, `purpose`, the driving input (spec package / PRD / raw intent / brownfield path), a parent spine path at lower altitude, and `doc_workspace` if a specific folder is required. Infer anything absent from the inputs or workspace; don't invent stack, constraints, or scope to fill a gap. Supported intents are `create`, `update`, `validate`, and `refine`; use `refine` when the payload names an existing seam, interface, module boundary, or brownfield hotspot but does not already specify the spine amendment. You still verify named tech on the web (you can't ask, but you can check) and still drive every write through the shared `{project-root}/_bmad/scripts/memlog.py`. Run the full Reviewer Gate (`references/reviewer-gate.md`) non-interactively: `scripts/lint_spine.py` plus **every `{workflow.finalize_reviewers}` lens as a parallel subagent** (and any ad-hoc lens the spine's criticality warrants). Headless skips only the human picking from the menu — never the reviewers themselves; apply the clear fixes and record anything unresolved in `open_questions[]`. For a true authority collision, list it in `conflicts_with_prior_decisions[]`. For the Validate intent, always write the report to `{doc_workspace}` and add `"offer_to_update": true`. If intent stays ambiguous after inference, halt blocked.
 
-End with JSON only, omitting keys for artifacts not produced — the shape below is the fully-produced (`complete`) case; a `blocked` run produces no spine, so it omits `spine`, `memlog`, and `companions` entirely (see the note under the block):
+For `refine`, load `references/architecture-refinement.md` and, when interface shape is material, `references/interface-design.md`. Inspect the named target and governing spine/code/ADRs, write any candidate or comparison companions to `{doc_workspace}`, and translate only ratified existing reality into decisions; a tentative amendment remains an assumption/open question unless the payload explicitly accepts it. If multiple viable candidates remain and the payload names no target, return `partial` with the ranked candidate companion and an `open_questions[]` entry rather than selecting one. If an applicable spine lacks its memlog and its stable decision history cannot be reconstructed safely, return `blocked`. If evidence cannot support a decision, return `partial` with non-authoritative companions and no invented `AD`; remove any seed spine created solely for that inconclusive refinement. Otherwise append outcomes through `memlog.py`, re-distill the spine, and run the full Reviewer Gate.
+
+End with JSON only, omitting keys for artifacts not produced — the shape below is the fully-produced (`complete`) case; companion-only `partial` and `blocked` runs omit the artifacts they did not produce (see the note under the block):
 
 ```json
 {
   "status": "complete | partial | blocked",
-  "intent": "create | update | validate",
+  "intent": "create | update | validate | refine",
   "altitude": "initiative | feature | epic",
   "purpose": "build-substrate | discussion",
   "doc_workspace": "<resolved run folder>",
@@ -23,4 +25,4 @@ End with JSON only, omitting keys for artifacts not produced — the shape below
 }
 ```
 
-`complete` stands alone · `partial` (spine produced, but `open_questions[]` non-empty or critical inputs inferred) means review before downstream use · `blocked` means no spine produced — return only `status`, `intent`, `reason`, and `doc_workspace` (if bound), omitting `spine`, `memlog`, `companions`, and the artifact arrays that don't exist.
+`complete` stands alone · `partial` means review before downstream use: normally it includes a spine plus unresolved `open_questions[]`; an inconclusive refinement may instead include only `doc_workspace`, non-authoritative `companions`, assumptions, and open questions, omitting `spine` and `memlog` · `blocked` means no usable artifact was produced — return only `status`, `intent`, `reason`, and `doc_workspace` (if bound), omitting `spine`, `memlog`, `companions`, and artifact arrays that don't exist.
diff --git a/src/bmm-skills/3-solutioning/bmad-architecture/references/interface-design.md b/src/bmm-skills/3-solutioning/bmad-architecture/references/interface-design.md
new file mode 100644
index 000000000..06de05087
--- /dev/null
+++ b/src/bmm-skills/3-solutioning/bmad-architecture/references/interface-design.md
@@ -0,0 +1,29 @@
+# Interface Design for Refinement
+
+Use this reference only when interface shape is a material architecture decision.
+
+## Produce alternatives
+
+Compare at least three realistic shapes:
+
+1. Minimal — the smallest stable behavior callers need.
+2. Flexible — justified variation without leaking implementation detail.
+3. Caller-optimized — shaped around the dominant caller workflow.
+
+Add a ports-and-adapters option only when at least two real implementations or a true external dependency justify the seam.
+
+For each option show:
+
+- interface shape and brief caller usage
+- behavior, state, and dependencies hidden behind it
+- ownership and dependency direction
+- adapter strategy, if any
+- observable test surface
+- migration and rollback cost
+- compatibility or conflict with existing `AD` IDs
+
+## Decide
+
+Rank the options by divergence prevented, locality of change and knowledge, interface leverage, migration risk, and altitude fit. Recommend one option or a precise hybrid; do not leave an unranked menu.
+
+The recommendation becomes architecture only after it is accepted or ratified by existing reality and recorded in the memlog. The resulting spine `AD` states the enforceable rule; detailed examples and rejected alternatives remain in the companion or memlog.
diff --git a/src/bmm-skills/3-solutioning/bmad-architecture/references/reviewer-gate.md b/src/bmm-skills/3-solutioning/bmad-architecture/references/reviewer-gate.md
index 729844c46..b82adbfda 100644
--- a/src/bmm-skills/3-solutioning/bmad-architecture/references/reviewer-gate.md
+++ b/src/bmm-skills/3-solutioning/bmad-architecture/references/reviewer-gate.md
@@ -1,13 +1,13 @@
 # Reviewer Gate
 
-The spine's pre-handoff review. Runs at Finalize (after distill + reconcile) and *is* the Validate intent. The difference is the ending: at Finalize you apply the clear fixes yourself; under Validate you report and don't change the spine.
+The spine's pre-handoff review. Runs at Finalize (after distill + reconcile) and _is_ the Validate intent. The difference is the ending: at Finalize you apply the clear fixes yourself; under Validate you report and don't change the spine.
 
 Cheap deterministic pass first: `python3 {skill-root}/scripts/lint_spine.py --workspace {doc_workspace}` settles the mechanical misses (placeholders, duplicate `AD` IDs, missing Binds/Prevents/Rule, unpinned deps), so reviewers spend judgment on the semantic half.
 
-Assemble the menu: a **rubric walker** that judges the spine against the good-spine checklist below, **+ every entry in `{workflow.finalize_reviewers}`**, + ad-hoc lenses you invent or offer as the spine's rigor, altitude, and criticality warrant — a security/compliance lens for regulated stakes, a seam reviewer cross-team, a data-integrity lens for a heavy data model. Scale *whether and how heavily the gate runs* to the stakes: a throwaway prototype may run it quietly or skip the gate entirely; a high-criticality or platform-altitude spine earns more lenses and the explicit all / subset / skip menu. But once the gate runs, the `{workflow.finalize_reviewers}` always run — they are the configured floor, never cherry-picked out; only the ad-hoc lenses are optional. (Headless never skips the gate.)
+Assemble the menu: a **rubric walker** that judges the spine against the good-spine checklist below, **+ every entry in `{workflow.finalize_reviewers}`**, + ad-hoc lenses you invent or offer as the spine's rigor, altitude, and criticality warrant — a security/compliance lens for regulated stakes, a seam reviewer cross-team, a data-integrity lens for a heavy data model. Scale _whether and how heavily the gate runs_ to the stakes: a throwaway prototype may run it quietly or skip the gate entirely; a high-criticality or platform-altitude spine earns more lenses and the explicit all / subset / skip menu. But once the gate runs, the `{workflow.finalize_reviewers}` always run — they are the configured floor, never cherry-picked out; only the ad-hoc lenses are optional. (Headless never skips the gate.)
 
 Dispatch every entry as a **parallel subagent against `ARCHITECTURE-SPINE.md`** (prefix convention: `skill:` / `file:` / plain text). Each writes its full review to `{doc_workspace}/review-{slug}.md` and returns ONLY a compact summary (verdict, top 2–5 findings, file path) — the parent never holds full review text. An inline self-check does not count: the independent context is the point, because a fresh reviewer finds the divergences the author talks past. If subagents are unavailable, run sequentially — write the file first, then flush it from context.
 
-**Good-spine checklist** (what the rubric walker judges): it fixes the real divergence points for the level below and misses none; every `AD`'s Rule is enforceable and actually prevents its stated divergence; nothing under Deferred could let two units diverge; named tech is verified-current; it ratifies rather than contradicts a brownfield codebase; if a spec drove it, it covers that spec's capabilities; and if a parent spine is inherited, no new `AD` weakens or contradicts an inherited one.
+**Good-spine checklist** (what the rubric walker judges): it fixes the real divergence points for the level below and misses none; every `AD`'s Rule is enforceable and actually prevents its stated divergence; nothing under Deferred could let two units diverge; named tech is verified-current; it ratifies rather than contradicts a brownfield codebase; if a spec drove it, it covers that spec's capabilities; if a parent spine is inherited, no new `AD` weakens or contradicts an inherited one; and any refinement companions agree with the spine, cite applicable governing `AD` IDs (or explicitly state that none exists yet for pre-decision evidence), and contain no unstated competing decision.
 
 Surface findings tiered, never dumped: a one-sentence gate verdict, then critical + high; medium/low roll into a tail ("plus N more in {file}"). Per finding: autofix, discuss, defer to Deferred / open items, or ignore. **At Finalize this is your own gate — apply the clear fixes rather than handing over a list; surface only what genuinely needs the user.** Under the **Validate intent**, fold every reviewer's output into one bespoke HTML + markdown report and open the HTML.
diff --git a/src/bmm-skills/3-solutioning/bmad-improve-architecture/DEEPENING.md b/src/bmm-skills/3-solutioning/bmad-improve-architecture/DEEPENING.md
deleted file mode 100644
index ceeac3372..000000000
--- a/src/bmm-skills/3-solutioning/bmad-improve-architecture/DEEPENING.md
+++ /dev/null
@@ -1,33 +0,0 @@
-# Deepening Guide
-
-Use this guide when deciding how a candidate should absorb its dependencies.
-
-## Dependency categories
-
-### In-process
-
-Pure computation or in-memory state. Merge freely and test through the new Interface.
-
-### Local-substitutable
-
-Dependencies with local test stand-ins, such as in-memory stores or embedded databases. Deepen the Module if the stand-in is good enough to support interface-level tests.
-
-### Remote but owned
-
-A network dependency your system owns. Define a port at the Seam and use at least two Adapters: production and test.
-
-### True external
-
-A third-party dependency you do not control. Inject it at the Seam and test with a mock or fake Adapter.
-
-## Seam discipline
-
-- Do not introduce a Seam unless variation across it is real.
-- Keep internal seams inside the Implementation when callers do not need to know about them.
-- Prefer one deep Module over a stack of shallow pass-through Modules.
-
-## Testing rule
-
-- Replace shallow-module tests with tests at the deepened Interface.
-- Assert observable behavior, not internal state.
-- If a test must change for an internal refactor, it is probably testing past the Interface.
diff --git a/src/bmm-skills/3-solutioning/bmad-improve-architecture/INTERFACE-DESIGN.md b/src/bmm-skills/3-solutioning/bmad-improve-architecture/INTERFACE-DESIGN.md
deleted file mode 100644
index cbae9da2c..000000000
--- a/src/bmm-skills/3-solutioning/bmad-improve-architecture/INTERFACE-DESIGN.md
+++ /dev/null
@@ -1,38 +0,0 @@
-# Interface Design
-
-When a candidate has been chosen, produce multiple Interface options before recommending one.
-
-## Required options
-
-Create at least three alternatives:
-
-1. Minimal Interface
-2. Flexible Interface
-3. Caller-optimized Interface
-
-Create a fourth Ports-and-Adapters option only when the dependency shape justifies a real Seam.
-
-## For each option include
-
-- Interface shape
-- Example caller usage
-- What the Implementation hides
-- Dependency and Adapter strategy
-- Trade-offs in Depth, Leverage, and Locality
-
-## Comparison criteria
-
-Compare options by:
-
-- Depth
-- Locality
-- Seam placement
-- Adapter strategy
-- Test surface
-- Migration cost
-- Compatibility with ADRs
-- Ease of story slicing
-
-## Recommendation rule
-
-Pick one option or a clear hybrid. Do not leave the user with an unranked menu.
diff --git a/src/bmm-skills/3-solutioning/bmad-improve-architecture/LANGUAGE.md b/src/bmm-skills/3-solutioning/bmad-improve-architecture/LANGUAGE.md
deleted file mode 100644
index a7cd6c81a..000000000
--- a/src/bmm-skills/3-solutioning/bmad-improve-architecture/LANGUAGE.md
+++ /dev/null
@@ -1,42 +0,0 @@
-# Architecture Language
-
-Use these terms exactly.
-
-## Terms
-
-**Module**
-Anything with an interface and an implementation. A function, class, package, or slice can all be a Module.
-
-**Interface**
-Everything a caller must know to use the Module correctly: types, ordering, invariants, error modes, required configuration, and performance expectations.
-
-**Implementation**
-The code behind the Interface.
-
-**Depth**
-Leverage at the Interface. A deep Module gives callers a lot of behavior behind a small Interface. A shallow Module exposes nearly as much complexity as it hides.
-
-**Seam**
-A place where behavior can change without editing in that place. Use `Seam`, not `boundary`.
-
-**Adapter**
-A concrete thing that satisfies an Interface at a Seam.
-
-**Leverage**
-What callers gain from Depth.
-
-**Locality**
-What maintainers gain from Depth. Bugs, change, and knowledge stay concentrated in one place.
-
-## Rules
-
-- Use `Module`, not `component`, `service`, or `unit`.
-- Use `Interface`, not `API` or `signature`.
-- Use `Seam`, not `boundary`.
-- Use `Depth`, `Leverage`, and `Locality` when explaining why a recommendation matters.
-
-## Principles
-
-- The deletion test: if deleting the Module only removes indirection, it was shallow.
-- The Interface is the test surface.
-- One adapter means a hypothetical Seam. Two adapters mean a real one.
diff --git a/src/bmm-skills/3-solutioning/bmad-improve-architecture/SKILL.md b/src/bmm-skills/3-solutioning/bmad-improve-architecture/SKILL.md
deleted file mode 100644
index ef8b7c7b6..000000000
--- a/src/bmm-skills/3-solutioning/bmad-improve-architecture/SKILL.md
+++ /dev/null
@@ -1,217 +0,0 @@
----
-name: bmad-improve-architecture
-description: 'BMad-native architecture deepening workflow. Use when the user wants to find deepening opportunities, compare interfaces, and turn the result into ADRs and implementation slices.'
----
-
-# BMad Improve Architecture
-
-This skill runs a BMad-native architecture deepening workflow with vendored architecture-analysis guidance.
-
-Act as a BMad Architect leading a focused architecture review. Use the domain language in `CONTEXT.md`, the constraints in ADRs, and the architecture vocabulary in `LANGUAGE.md`. The outcome is a concrete deepening recommendation plus BMad-ready artifacts for ADRs, story slicing, and test strategy.
-
-## Conventions
-
-- Bare paths (e.g. `LANGUAGE.md`) resolve from the skill root.
-- `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
-- `{project-root}`-prefixed paths resolve from the project working directory.
-- `{skill-name}` resolves to the skill directory's basename.
-
-## On Activation
-
-### Step 1: Resolve the Workflow Block
-
-Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
-
-**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
-
-1. `{skill-root}/customize.toml` — defaults
-2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
-3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides
-
-Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
-
-### Step 2: Execute Prepend Steps
-
-Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
-
-### Step 3: Load Persistent Facts
-
-Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
-
-### Step 4: Load Config
-
-Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
-
-- Use `{user_name}` for greeting
-- Use `{communication_language}` for all communications
-- Use `{document_output_language}` for output documents
-- Use `{planning_artifacts}` for output location and artifact scanning
-- Use `{project_knowledge}` for additional context scanning
-
-### Step 5: Greet the User
-
-Greet `{user_name}`, speaking in `{communication_language}`.
-
-### Step 6: Execute Append Steps
-
-Execute each entry in `{workflow.activation_steps_append}` in order.
-
-Activation is complete. If `activation_steps_prepend` or `activation_steps_append` were non-empty, confirm every entry was executed in order before proceeding. Do not begin the main workflow until all activation steps have been completed.
-
-## Read First
-
-Read these if they exist:
-
-- `{project-root}/CONTEXT-MAP.md`
-- `{project-root}/CONTEXT.md`
-- `{project-root}/docs/agents/domain.md`
-- `{project-root}/docs/adr/`
-- `{project-root}/_bmad-output/project-context.md`
-- `{project-root}/_bmad-output/architecture.md`
-- `{project-root}/_bmad-output/prd.md`
-- `{project-root}/_bmad-output/epics/`
-
-Then read:
-
-- `LANGUAGE.md`
-- `DEEPENING.md`
-- `INTERFACE-DESIGN.md`
-
-## Output Location
-
-Write all artifacts under `{planning_artifacts}/architecture-review`.
-
-Use these files:
-
-- `deepening-candidates.md`
-- `interface-options-{candidate-slug}.md`
-- `recommendation-{candidate-slug}.md`
-- `architecture-addendum-{candidate-slug}.md`
-- `adr-draft-{candidate-slug}.md`
-- `story-slices-{candidate-slug}.md`
-- `test-strategy-{candidate-slug}.md`
-
-## Workflow
-
-### 1. Build a working map
-
-Start with a compact working map:
-
-- Domain terms
-- Relevant ADR constraints
-- Current module seams
-- Testability pain
-- Likely high-friction areas
-
-If `CONTEXT-MAP.md` exists, follow it before reading any matching `CONTEXT.md` files.
-
-### 2. Explore for deepening candidates
-
-Explore the codebase for shallow modules and low-locality behavior.
-
-Look for:
-
-- orchestration duplicated across callers
-- seams with only one hypothetical adapter
-- extracted helpers that moved code without increasing locality
-- tests that need to mock internals instead of testing through an interface
-- modules that fail the deletion test
-
-Use the exact vocabulary from `LANGUAGE.md`.
-
-Do not propose interfaces yet.
-
-Write `deepening-candidates.md` with numbered candidates. For each candidate include:
-
-- Files
-- Problem
-- Why the module is shallow or low-locality
-- Deepening direction
-- Testability improvement
-- BMad impact
-
-For BMad impact include:
-
-- ADR needed: yes/no
-- Story count: small/medium/large
-- Risk: low/medium/high
-
-Then ask:
-
-`Which candidate do you want to explore?`
-
-Stop until the user chooses one.
-
-### 3. Run the grilling loop
-
-For the chosen candidate, ask only the questions needed to remove design risk:
-
-- What must stay stable?
-- Which callers matter most?
-- Which tests must survive?
-- Which ADRs are load-bearing?
-- Is this refactor-only or behavior-changing?
-- What failures keep recurring here?
-
-If the user rejects a direction for a durable reason, offer to record that as an ADR draft so the same idea is not re-suggested later.
-
-### 4. Design interfaces
-
-Use `INTERFACE-DESIGN.md` to produce at least three interface options:
-
-- minimal interface
-- flexible interface
-- caller-optimized interface
-- ports-and-adapters interface only when the dependency shape justifies it
-
-Write `interface-options-{candidate-slug}.md`.
-
-Compare options by:
-
-- Depth
-- Locality
-- Seam placement
-- Adapter strategy
-- Test surface
-- Migration cost
-- ADR compatibility
-- Story slicing
-
-### 5. Recommend one direction
-
-Write `recommendation-{candidate-slug}.md` with:
-
-- recommended interface
-- why it wins
-- what stays behind the seam
-- migration risks
-- rollback plan
-
-Be opinionated. Prefer one recommendation or a clear hybrid.
-
-### 6. Generate BMad-ready artifacts
-
-Write:
-
-- `architecture-addendum-{candidate-slug}.md`
-- `adr-draft-{candidate-slug}.md`
-- `story-slices-{candidate-slug}.md`
-- `test-strategy-{candidate-slug}.md`
-
-Artifact rules:
-
-- The architecture addendum describes the chosen Module, Interface, Seam, and Adapter strategy.
-- The ADR draft captures the decision, consequences, and rejected options.
-- Story slices stay small and testable.
-- The test strategy explains what moves to the interface test surface and what regression coverage must exist.
-
-### 7. Route into the next BMad workflow
-
-When the artifacts are complete, recommend the next workflow explicitly:
-
-- `bmad-architecture` to absorb the addendum
-- `bmad-create-epics-and-stories` to turn slices into planned work
-- `bmad-create-story` for the next implementable slice
-- `bmad-testarch-test-design` or `bmad-testarch-trace` when regression risk is material
-
-Do not implement code unless the user explicitly asks.
diff --git a/src/bmm-skills/3-solutioning/bmad-improve-architecture/customize.toml b/src/bmm-skills/3-solutioning/bmad-improve-architecture/customize.toml
deleted file mode 100644
index 4f4794f15..000000000
--- a/src/bmm-skills/3-solutioning/bmad-improve-architecture/customize.toml
+++ /dev/null
@@ -1,16 +0,0 @@
-# DO NOT EDIT -- overwritten on every update.
-#
-# Workflow customization surface for bmad-improve-architecture. Mirrors the
-# agent customization shape under the [workflow] namespace.
-
-[workflow]
-
-activation_steps_prepend = []
-
-activation_steps_append = []
-
-persistent_facts = [
-  "file:{project-root}/**/project-context.md",
-]
-
-on_complete = ""
diff --git a/src/bmm-skills/module-help.csv b/src/bmm-skills/module-help.csv
index 680af73fb..d1dcf5b05 100644
--- a/src/bmm-skills/module-help.csv
+++ b/src/bmm-skills/module-help.csv
@@ -17,8 +17,7 @@ BMad Method,bmad-product-brief,Create Brief,CB,An expert guided experience to na
 BMad Method,bmad-prfaq,PRFAQ Challenge,WB,Working Backwards guided experience to forge and stress-test your product concept to ensure you have a great product that users will love and need through the PRFAQ gauntlet to determine feasibility and alignment with user needs. alternative to product brief.,,-H,1-analysis,,,false,planning_artifacts,prfaq document
 BMad Method,bmad-prd,Create Edit and Review PRD,PRD,"Facilitated PRD workflow — create a new PRD via coached discovery, update an existing one against a change signal, or validate a finished PRD against a checklist with an HTML findings report.",,,2-planning,bmad-product-brief,,true,planning_artifacts,prd
 BMad Method,bmad-ux,Create UX,CU,"Guidance through realizing the plan for your UX, strongly recommended if a UI is a primary piece of the proposed project.",,,2-planning,bmad-prd,,false,planning_artifacts,ux design
-BMad Method,bmad-architecture,Architecture,CA,Offer once requirements exist (a PRD or spec; plus UX if present) and the user is ready to move from what to how. Also offer any time independently-built parts risk diverging. Produces the architecture spine: the invariants that keep features epics and stories consistent. Comes before epics and stories and scales from a quick spine to a full architecture (brownfield: ratifies the existing codebase).,,,3-solutioning,,,true,planning_artifacts,architecture
-BMad Method,bmad-improve-architecture,Improve Architecture,IA,Find deepening candidates compare interface options and write BMad-ready architecture artifacts for brownfield or pre-implementation architecture refinement.,,,3-solutioning,,,false,planning_artifacts,architecture review artifacts
+BMad Method,bmad-architecture,Architecture,CA,Offer once requirements exist (a PRD or spec; plus UX if present) and the user is ready to move from what to how. Also offer any time independently-built parts risk diverging or an existing seam interface or module boundary needs refinement. Produces or refines the architecture spine: the invariants that keep features epics and stories consistent. Comes before epics and stories and scales from a quick spine to a full architecture (brownfield: ratifies and selectively refines the existing codebase).,,,3-solutioning,,,true,planning_artifacts,architecture
 BMad Method,bmad-create-epics-and-stories,Create Epics and Stories,CE,,,,3-solutioning,bmad-architecture,,true,planning_artifacts,epics and stories
 BMad Method,bmad-check-implementation-readiness,Check Implementation Readiness,IR,Ensure PRD UX Architecture and Epics Stories are aligned.,,,3-solutioning,bmad-create-epics-and-stories,,true,planning_artifacts,readiness report
 BMad Method,bmad-sprint-planning,Sprint Planning,SP,Kicks off implementation by producing a plan the implementation agents will follow in sequence for every story.,,,4-implementation,,,true,implementation_artifacts,sprint status