Council Review: Untracked Architecture Gaps Versus Active MCP Follow-up

Decision

Prioritize ChatToolCatalog modularization as the enabling architecture task for the active MCP backlog, then run a dedicated route-and-core simplification sequence for Chat.razor, Admin.razor, and MemoryApplicationService rather than continuing to add work to those hotspots opportunistically.

Evidence Reviewed

Findings

Seat Recommendation Confidence Blocking concern
Source-Grounded Archivist Add new tasks only where the backlog truly has no owner: route decomposition, memory-core decomposition, and tool-catalog modularization. Update TSK-0053 instead of cloning a duplicate hygiene task. 92% Avoid re-auditing already-tracked 2026-05-26 MCP follow-up work.
Data Model Architect Treat MemoryApplicationService as a first-class architecture hotspot because it now owns read, write, diagnostic, and telemetry flows. Split by stable domain boundary, not by method count alone. 87% Do not start extraction without characterization tests around context-pack, search envelopes, CRUD, and stats.
Retrieval Specialist Make TSK-0192 an enabler for TSK-0185 and TSK-0186; search-contract expansion will otherwise keep hard-coding more MCP/search behavior into one already oversized registry file. 90% Modularization must preserve tool names, risk tiers, and current output formats exactly.
Human Learning Advocate Decompose Chat.razor and Admin.razor, but do it after the MCP follow-up sprint so users see stable behavior while the architecture work is prepared and explained. 79% If decomposition starts without stable route smoke coverage, the user-facing risk is higher than the maintainability gain.
Skeptical Reviewer Resist adding Tasks.razor and Pages.razor decomposition tasks today; evidence is strongest for Chat/Admin only. Also keep TSK-0053 medium priority unless tooling or task imports actively break. 84% Do not let architecture cleanup sprawl into a many-surface refactor program with no clear demo.
Synthesizer Sequence work into three sprints: MCP contract/tooling, then route decomposition, then memory-core plus task-contract cleanup. Keep each sprint small enough that validation remains focused and reversible. 88% Each sprint needs explicit exit gates so the cleanup does not become open-ended.

Synthesis

Change Now

Defer

Dissent

The Human Learning Advocate would prefer deferring all route decomposition until additional route-smoke or browser characterization exists for Chat/Admin, while the Retrieval Specialist argues TSK-0192 should happen immediately because more MCP feature work is already queued. The council resolves this by sequencing TSK-0192 first and placing route decomposition in the following sprint rather than the same sprint.

Acceptance Criteria

Open Questions