Codebase Fragility

A treemap or sunburst of your repo, sized by how many objectives touched each path and colored by how hard those objectives were to land.

Every agent run that calls planwright_record_diff with diff content contributes file paths and an iteration count to this map. Size answers "how much work happened here"; color answers "how much retrying did it take." Click any node, or search a file path directly, to see the objectives behind it — sorted by iteration count, with chronological and cluster views.

The Codebase Fragility tab doesn't appear in the Signals tab bar at all for projects without a linked GitHub repo — no disabled state, no empty placeholder.

Iteration count is only a meaningful complexity signal when it's mapped onto real file paths — agent runs need diffs with file_paths to plot. For non-code workflows (a marketing project, a research board), a high iteration count usually reflects spec ambiguity or stakeholder indecision, not code fragility, so plotting it onto a directory tree that doesn't exist would misrepresent the signal rather than just show it empty. The feature doesn't degrade gracefully — it's absent unless the project has a linked repo.

Churn measures how often a file changes. Fragility measures how hard each change was to land — something churn can't see.

GitHub's most-changed-files view and churn metrics tell you frequency: this file changed 40 times this quarter. They can't tell you whether each of those 40 changes landed clean on the first pass or took six agent runs to get right. Two files can churn identically — same commit count, same author count — while one takes a single objective and one takes six. Planwright's fragility score is iteration count, not change count: the average number of agent runs it took to close objectives touching that path. High churn with low fragility is a healthy, frequently-iterated area. High churn with high fragility is where agents keep struggling, and where GitHub's tooling has nothing to say.

Box or wedge size = objective count. Color = fragility score, green to red. Two view modes, same data.

Color scale: ≤1.5 average iterations is low (green), ≤3 is medium (amber), above 3 is high (red). Paths with fewer objectives than the minimum-objective threshold render gray — unscored, not green — so a single lucky one-pass objective can't paint a whole directory green.

Two controls reshape the map without re-fetching: how many directory levels to collapse into, and how many objectives a path needs before its color counts.

Depth (1, 2, 3, or 5) controls how many directory levels are collapsed into a single node — depth 1 shows top-level folders only, depth 5 goes five levels deep before treating everything beneath as one leaf. Minimum objectives (1, 2, or 5) sets the threshold a path needs to clear before its fragility color is trusted; below it, the node renders as unscored gray regardless of how bad its one or two data points look. Raising the threshold is the fix for a map that reads as noisier or redder than it should — it's almost always a handful of single-objective outliers, not systemic fragility.

Clicking a node, or searching a file path, opens the same panel: every objective that touched that scope, sorted by iteration count, with a cross-cutting-concern flag when it's warranted.

This panel is Intent Archaeology — it isn't a separate view or a separate tab, it's the drill-in behavior of the map itself. Click a treemap box or sunburst wedge and the panel opens scoped to that directory; type a path into the search box in the header and it opens scoped to that search instead, matching any file reference containing the query. Either way you get the same panel: a chronological list (most recent objective first) or a cluster view (grouped by inferred theme), each row showing the objective's title, intent summary, iteration count, and initiative. If the entries span multiple initiatives in a pattern that looks like unplanned cross-cutting work, the panel surfaces a warning banner calling it out — a signal that a directory's fragility may be a coordination problem, not a code-quality one.

Documented on this page rather than split out separately: Intent Archaeology has no independent navigational surface. There's one Codebase Fragility tab, one component, one panel — describing the drill-in and describing Intent Archaeology are the same description twice. A future feature with its own route or entry point would warrant its own page; this one doesn't have one to point at.

Architects prioritize refactors, tech leads scope before scheduling, engineering managers calibrate assignment risk.

billing/ at 4.2 average iterations prompts a split into two narrower objectives — the next run takes 2 iterations instead of the historical average.

A tech lead opens the Codebase Fragility tab before scheduling a new objective and sees billing/ colored red, at 4.2 average iterations across its contributing objectives. Rather than schedule the new objective as originally scoped, they split it into two narrower objectives, each with explicit file-level acceptance criteria instead of one broad description. The resulting runs complete in 2 iterations combined — well under the directory's historical average — because the narrower scope gave the agent a much smaller ambiguity surface to resolve per pass.