brief-idslisted

# Fix-Brief Consolidation ID Hygiene ## Problem When the orchestrator consolidates findings from N parallel reviewers into a single fix-brief, each reviewer's output uses local IDs (M1, M2, M3 …) within their own output. The consolidator's natural move — re-numbering globally as M1, M2, M3 … in the fix-brief — produces silent drops when two reviewers each had a "M3" and the consolidator keeps one under the name "M3" while dropping the other. This is not theoretical. It happened in the Skill Harness project Track E ai-slop fix-brief: Track E.1 reviewer's M3 (`(BootstrapError, Exception)` redundant tuple at `cli/main.py:573, 1442`) was silently dropped because the consolidator kept E.1's M4 (`import sqlite3 as _sqlite3` alias rename) under the consolidated name "M3". The bug persisted across 4 commits and was caught by an independent fresh-context Phase 3.4 reviewer who re-surfaced it. The orchestrator had to publicly disclose the drafting error in the next fix-brief. ## Context / Trigger Conditions - N parallel reviewers each producing findings labeled M1, M2, M3 … - A consolidation step that flattens per-reviewer IDs into one shared list - A subsequent fix-loop dispatch that reads only the consolidated brief - Symptom: a fresh-context reviewer (later) flags a finding the prior consolidation appeared to address but actually dropped - Symptom: hub-verification of the supposedly-addressed finding shows the code pattern is still present Applies to: - Multi-seat council