Architecture Quality Loop - Analyze, Assess, Improve (Deliberate)

You drive a deliberate loop that improves a project's architecture: analyze it, produce a reasoned assessment, work the fixable weaknesses by tier, reconcile the docs, and loop until the fixable ones are resolved or the loop plateaus. This is the heavy, on-purpose counterpart to the code-focused project-quality-loop - it runs only when a user invokes it (/project-architecture-quality-loop), never automatically, because architecture analysis is expensive and architecture changes are consequential.

Best run in Claude Code, where you can dispatch the analysis and build seats and edit files across rounds. On a large codebase, scope it - point it at one bounded context or module subtree per run. The frontmatter pins the invoking turn to opus (the architecture judgment runs in-session, per the capture) - but the pin lasts one turn and this loop pauses for approvals, so a long run wants the session itself on Opus rather than the pin alone.

Execution modes

DELEGATED vs INLINE - and why detection keys on dispatch capability, not file presence - is the shared policy project-task-flow owns. Pick the mode once, before ANALYZE, hold it for the run, and apply it to the loop:

• DELEGATED (dispatch available) - the main session dispatches every seat - code-analyzer for the capture's gathering, then the domain designer / implementers / verifier for a substantial fix, or an implementer for a small one - never doing their work itself (the architecture reasoning itself runs in the main session, per the capture). This skill and project-task-flow are manual (disable-model-invocation), so a substantial fix runs the stack vertical by dispatching that stack's seats directly - the loop discipline is project-task-flow's references/domain-trio-protocol.md.
• INLINE (no dispatch: Cursor, a non-stack project, or a scope too small to fan out) - do the same steps in-session: map and assess the architecture yourself against the house architecture skills, then apply the fixable cons directly, smallest blast radius first.

The loop

1. ANALYZE + ASSESS

Run the project-architecture-analyzer capture over the target: dispatch code-analyzer per module, reason over the digests in-session, and write docs/architecture/ARCHITECTURE.md (the structure map) and docs/architecture/ASSESSMENT.md (10 reasoned strengths + 10 reasoned weaknesses, each weakness carrying a remediation and a tier: small / substantial / structural). Read docs/architecture/ASSESSMENT.md: the weaknesses are this loop's work list, the tier on each is its routing key, and any weakness the summary marks a deliberate tradeoff is left alone - do not 'fix' a conscious choice.

2. TRIAGE + FIX by tier

Take the open weaknesses in leverage order (the assessment's top-few first). Route each by its tier - and confirm the green baseline (build + tests) before you start, so a regression is visible. Hold every fix against the assessment's Strengths list: a remediation whose entry names a strength tension is applied the way the entry preserves the strength, and a fix that turns out mid-round to erode a listed strength stops - resolving a weakness by breaking a strength is a net loss, and a genuine strength-vs-weakness tradeoff is a structural-tier user decision, never an auto-fix: