git:20260718.7cc9d66 to git:20260718.188cd11

11 added, 26 removed. Audit A to A.

---

name: architecture-refine

- description: Refine product and system architecture through one focused decision at a time. Use when runtime boundaries, ownership, configuration, persistence, deployment, operations, security, or implementation structure remain underdefined.

+ description: Refine underdefined product or system architecture through focused interactive decisions. Use when the user wants architecture sparring before a formal implementation plan or contract update.

---

# Architecture Sparring

- Drive vague architecture toward explicit, implementable decisions.

+ Resolve only the architecture decisions needed for the user's stated next step.

## Interaction Loop

- 1. Inspect relevant repository context before questioning assumptions.

- 2. Identify the highest-leverage unresolved decision.

- 3. Ask exactly one focused question.

- 4. Prefer two or three concrete options with real tradeoffs.

- 5. Evaluate the answer directly: accept it, reject it with a reason, or narrow it.

- 6. State the consequence of the decision.

- 7. Continue with the next unresolved boundary.

- ## Pressure Points

- - Separate source inputs, build artifacts, deployment artifacts, and runtime contracts.

- - Distinguish build-time configuration, runtime configuration, secrets, generated metadata, and persistent state.

- - Test ownership boundaries between services, modules, data, and operators.

- - Challenge flexibility that leaves behavior undefined.

- - Surface hidden support burden, failure modes, migration costs, and rollback constraints.

- - Prefer the smallest viable design that can be built, tested, deployed, and operated.

- - Reject premature abstractions and parallel ownership paths.

+ 1. Inspect the relevant repository evidence and known constraints.

+ 2. Identify the highest-leverage unresolved architecture decision.

+ 3. Ask one focused question, grouping inseparable constraints only when the decision cannot be evaluated honestly otherwise.

+ 4. Offer two or three concrete options with material tradeoffs.

+ 5. Evaluate the answer directly and state its architectural consequence.

+ 6. Continue only while another unresolved boundary changes the requested next deliverable.

- ## Style

+ Pressure-test runtime boundaries, ownership, configuration, persistence, deployment, operations, security, migration, rollback, and support burden. Prefer the smallest viable design and reject flexibility that leaves behavior undefined.

- - Be concise and direct.

- - Do not dump option lists or architecture essays unless asked.

- - Call out vague, contradictory, or overbroad answers plainly.

- - Verify version-sensitive claims with local evidence or current official sources.

- - Do not pretend a decision is settled when required context is missing.

+ Do not create an implementation plan, edit a specification, conduct extended technical research, design a refactor sequence, implement code, or write durable repository context. Use `plan-create`, `spec-update`, `technical-spike`, `refactor-plan`, or `repo-context-document` for those outputs.

- When enough decisions are locked, summarize accepted decisions, rejected alternatives, non-goals, open risks, and remaining loopholes.

+ Finish when the decisions needed for the stated next step are settled, the user ends sparring, or a named blocker requires another workflow. Report accepted decisions, rejected alternatives, non-goals, open risks, and remaining blockers.