full-module-qa-loop

Start with a Party Mode multi-agent discussion to converge on the test tree, then verify business rules against code, and run the 7-step detection cycle per module. The user tests manually while the orchestrator collects Chrome MCP evidence and sub-agents analyze root causes with file:line proof.

The orchestrator acts only as an observer using seven tools: list_pages, navigate_page, take_snapshot, take_screenshot, list_console_messages, list_network_requests, and evaluate_script. It never clicks, types, or fills forms, since those actions belong to the human tester.

Use it when you need human acceptance combined with systematic repair, such as MVP confidence rebuilds or plan-matrix compliance checks. For fully automated E2E coverage use a Playwright-based skill, and for a single bug use a bug-fix-verification workflow instead.

CMRD scores relevance across five dimensions: shared files, shared business rules, same root-cause category, similar symptoms, and similar fix patterns. Scores of 50 or above auto-merge, 25-49 suggest a merge for review, and below 25 creates a new Story.

Stories with an SDS above 50 fail in the dev-story pipeline at high rates because large acceptance-criteria counts overwhelm the repair agent. The Refinement Gate computes SDS from AC count, affected files, cross-module reach, and other factors, then splits oversized Stories using the strategy with the largest SDS reduction.

It requires a Product Owner willing to perform manual testing across accounts, so it is unsuitable under extreme time pressure. It also depends on Chrome MCP connectivity and constitutional rules requiring code evidence rather than inference from documentation.