Back to Bmad Method

Aggregate Views

src/bmm-skills/ship/bmad-retrospective/references/aggregate-views.md

6.11.04.2 KB
Original Source

Aggregate Views

Phase 2. An epic is many coding sessions, each validated in isolation; the defects that matter are the ones no single session — and no single diff hunk — could see. Nine sessions each added three hundred lines and none ever saw the 3,000-line class they collectively built. These views are properties of the whole change, derived across the full diff range from Phase 1.

Prefer deterministic derivation: a script that measures the codebase is evidence; a model's impression is not. Where you compute a view inline instead of by script, record the narrowed scope. Every observation that becomes a finding carries a source reference — the file, the symbol, the commits. references/evidence-gathering.md is authoritative for what every git_evidence.py key means, including the commit-level is_merge and stories (every story id a subject names, so a commit spanning two counts for both) — read it there before deriving anything from the numbers.

The catalog

  • Architecture delta — how the dependency structure changed across the epic. Where a language-native dependency tool exists (dependency-cruiser, madge, pydeps, and the like), run it before and after the range and diff the graphs; otherwise derive the module/import graph from the changed files. Look for new cross-cutting dependencies, layering violations, and cycles introduced — structure the code's own conventions would forbid but no single story tripped.
  • Duplication map — the same problem solved more than one way across stories. Two sessions independently writing near-identical logic, or a helper reimplemented because the second session did not know the first existed.
  • God-class / size growth — files that grew past a healthy size over the epic, invisible per-commit because each session added only a little. The git_evidence.py pre-pass (Phase 1) reports added / deleted / net per path in fileschange volume, not a file's absolute size or a per-commit growth rate. Those sums cover the range's non-merge commits only, and they are always integers: an unmeasurable revision is left out of them rather than nulling them. Rank on files, then open the top of the ranking and read each file's real current size and structure before calling anything a god-class — high net churn makes a file a candidate to inspect, not a verdict on its own. Three qualifiers say how far the ranking can be trusted: binary_revisions counts that path's revisions whose churn could not be measured, so its true volume is at least what the sums report; merges_measured short of merge_count means some merges were never measured at all, which caps how complete the ranking can be; and merge_files mostly restates churn files already counted, so summing the two double counts — but it is not redundant, because a merge's first-parent diff also carries whatever the conflict resolution itself added, code that lives in no non-merge commit and therefore appears in files nowhere. So read merge_files separately, for the paths whose churn shows up only there, rather than discarding it as double counting. Whether a flagged file is genuinely a god-class or legitimately large stays your judgment.
  • Pattern divergence — where the epic's code diverges from the conventions the surrounding codebase already established: naming, error handling, test structure, module boundaries. Agents learn conventions by pattern-matching the code, so divergence compounds.
  • Spec-to-implementation reconciliation — where the as-built diverges from what the epic spec and PRD/architecture described. Requirements silently dropped, added behavior nobody specified, intent reinterpreted between stories. Each divergence is either a defect (fix), an accepted deviation (record so later runs stop re-flagging it), or a spec that should be reconciled to reality (propose in Phase 4).

Delegation

When sub-agents are available, delegate the derivation: each returns evidence with source refs and checked scope, never a verdict — the parent consolidates and decides. Give each a narrow view and an explicit return format. When sub-agents are unavailable, compute the highest-value views inline (architecture delta and spec reconciliation first) and record which views were narrowed or skipped.