Stale Work Radar — Spec & Lo-fi Wireframe DEMO — synthetic stream

v1 spec, function over polish. Canonical deliverable: Step 3 narrative + full kickoff transcript coverage (the Dev Lead + the CEO, 7/15) layered in at Step 4; iterated at the Step 5 persona review (technical panel + UX, 7/17 — TR-15…TR-28, Open Calls 8–10). Hover any tag for the verbatim source quote. [Red brackets] = genuinely undecided data or decision pending — every bracket traces to the numbered Open Calls list at the bottom. Nothing fabricated.

Feedback sources — hover any tag for the quote

DL-n the Dev Lead (dev lead), kickoff 7/15 — asks in his priority order

CEO-n the CEO, kickoff 7/15

Decisions & status

TR-n Our design decision — rationale in tooltip (the decision log)

V2 Explicitly deferred at the kickoff

FLAG Open question or data gap (G-n from 02)

Review annotations — internal only, not product UI

✦ lead takeaway what the dev lead should leave with

⚠ weak takeaway fails the test: would the lead care?

Built for the dev lead SINGLE PRIMARY USER

the Dev Lead is the reference user — the kickoff was explicit: this is a dev-lead triage tool first, not an exec report. CEO-2 Every panel serves the lead deciding what to do about at-risk work this week: what's stalling (including work that never got pushed), whether to believe the flag, what it has cost so far, whether one person is carrying it, and whether last week's nudge worked. The tool informs the lead's judgment — it never renders verdicts. DL-6

Lives inside the portal as a Work Area tab — repo scope, membership, visibility, and the individual-vs-anonymized granularity policy are all inherited from the Work Area; no new permission machinery. DL-8 CEO-5

External framing: in any outside telling this surface reads as part of "control your AI token costs" — internally it stays the Dev Lead's triage tool, and the cost story never crowds out the list. CEO-7 DL-10

Narrative spine — internal note, carried from Step 3

The sections below hang on the lead's questions in order: 1 what's going stale right now (the list is the product) → 2 why is this flagged, can I believe it → 3 what is it costing us → 4 item problem or person problem → 5 did my nudge work. Per dashboard conventions the question-style headers from Step 3 are now plain subheads; the spine survives only as this note. TR-12 TR-1

1 · Radar — stale & at-risk workDL-1

✦ Lead takeaway · internalIn one scan I know which in-flight work has stopped moving — including the branch nobody ever pushed — and where to start.

Interaction rules everywhere TR-2: owner names link (↗) to the Developer Profile; PR numbers link to the pull request in the SCM; every KPI carries a trend vs last period; any row expands to its full signal breakdown (Sec 2). See something → investigate it; progressive disclosure is the context — no embedded prose in the final surface.

Stale candidates

12 provisional

in Work Area atlas Core · vs 9 last week (5 new · 2 cleared)

Measured — fact_work_item / work-branch summary (02). Native branches + GitHub PRs only. "Provisional" per TR-15: the count is real but its inclusion rule is interim (Open Call 1) — a count cannot be more resolved than its own definition. Gross churn shown per TR-25: a net delta hides whether interventions drain the pool. TR-15 TR-25

Never pushed

local commits only · via the git observer — unobserved machines not counted · vs 1 last week

Measured — commit-to-push lag from the git observer (02). The radar's differentiator: the SCM can't see this work. DL-7 Coverage caveat stated in the clean state per TR-23 — the count only sees observed machines, same honesty rule as the Jira caption (TR-5). TR-23

High review risk

4 Change AI proxy

of the 12 candidates · vs 3 last week · high = [band cutoff — Open Call 8]

Proxy — Change AI review-risk score; measured provider review facts are thin/unpopulated (02). Always labeled proxy. DL-3 TR-13 Scale and band cutoffs are unstated platform facts — escalated as Open Call 8, never invented here. FLAG

AI cost sunk in stale work

[$— · — tokens]

pending cost-grain verification

Red-bracketed until G5 resolves whether branch is in the cost grain — Open Call 3. See Sec 3. FLAG

Owners affected

of 8 active in this Work Area · vs 4 last week

Derivable — owner attribution via dim_subject join (02). See Sec 4 for clustering. DL-4

Candidate counts and their trends are provisional — counted by an interim inclusion rule (days since last activity; threshold [N days — Open Call 1]) until the staleness definition is decided. TR-15 Time windows, stated once: radar counts trend week-over-week · spend figures are trailing 30 days · capacity signals are calendar-month. TR-19

Ordered by days since last activity (measured) — composite staleness rank deferred until the threshold definition is decided; a hidden formula would violate "the tool never decides" TR-3 FLAG Flag work inactive for [N days — Open Call 1] DL-6

Work item (branch / PR) DL-1	Owner	Last activity	Push status & unpushed DL-7	Review risk proxy DL-3	AI cost sunk DL-2 CEO-1
feature/token-budget-alerts · PR #482 ↗ atlas · open 16 days	Priya ↗	9 days	Pushed · last push 9d · PR open 16d	78 · high	[$— · — tokens]
fix/ws-reconnect-loop atlas · no PR	Elena ↗	8 days	Never pushed · 3 local commits · oldest unpushed 15d	— no pushed diff	[$— · — tokens]
feature/spend-rollup-cache · PR #479 ↗ atlas · draft 12 days	Marcus ↗	7 days	Pushed · last push 7d · PR draft 12d	71 · high	[$— · — tokens]
chore/otel-span-batching atlas · no PR	the Dev Lead ↗	6 days	Pushed · last push 6d · no PR	43 · medium	[$— · — tokens]
feature/work-area-invites · PR #488 ↗ atlas · open 9 days	Priya ↗	5 days	Pushed · last push 5d · PR open 9d	66 · high	[$— · — tokens]
fix/session-replay-flake atlas · no PR	Jonah ↗	4 days	Pushed · last push 4d · no PR	35 · low	[$— · — tokens]
… 6 more candidates (Priya ×2 — one high review risk, Marcus ×2 — one never pushed, the Dev Lead ×1, Elena ×1) — expand to full list

Covers native branches + GitHub PRs in this Work Area. Jira-linked items are not included. — scope stated honestly in the UI caption, never silently missing (02: fact_work_item covers native branches + GitHub PRs only). TR-5

Recency copy is day-grained only ("9 days", never "since 2pm Tuesday") — all Gold facts collapse to UTC day (G7, 02). TR-4 Branch names are demo placeholders pending the Dev Lead's real names from the sprint incident (kickoff action item) — Open Call 7. FLAG

Footing: visible rows Priya ×2, Elena ×1, Marcus ×1, the Dev Lead ×1, Jonah ×1 + hidden Priya ×2, Marcus ×2, the Dev Lead ×1, Elena ×1 = Priya 4, Marcus 3, the Dev Lead 2, Elena 2, Jonah 1 = 12 (matches KPI and Sec 4). Never pushed: Elena + 1 hidden Marcus = 2. High risk: 78/71/66 visible + 1 hidden Priya = 4. Owners: 5. Churn: 9 last week + 5 new − 2 cleared = 12. Truncation-row owner breakdown moved into this review layer per TR-28 — footing scaffolding, not product copy. TR-28

2 · Row detail — signals & provenanceDL-3 DL-6

✦ Lead takeaway · internalI can see exactly why the radar flagged this branch — and every number tells me where it came from, so I decide, not the tool.

This is the expanded state of any radar row (progressive disclosure — drawn once, applies to every row). Signals are shown raw and separately; there is no hidden composite verdict. TR-3

Expanded row — feature/token-budget-alerts · Priya · PR #482

Recency

9 days

since last activity on this branch (any session or commit — event rule [what resets the clock — Open Call 1])

activity

7 days

then

9-day gap

axis: the PR’s 16 days — widths proportional (7d with activity, then the 9-day gap)

Measured — fact_session_day per subject×repo×tool×day; UTC-day grain only (G7, 02). Bars given a real axis per TR-24 — they were decorative widths, the one dishonest geometry on the page. Which events reset the clock (rebases, merges-from-main, reviewer comments, session→branch attribution) is escalated into Open Call 1. TR-24

Push status

Pushed · PR open 16 days

last push 9 days ago · 0 unpushed commits

Measured — push observations + commit-to-push lag, an explicitly listed delivery metric (02). For never-pushed rows this panel is the whole story. DL-7 Verdict adjective removed per TR-21 (was "commit-to-push lag normal") — lag ships as a number beside a Work Area comparator; "normal" is the lead's conclusion, never the tool's. TR-21

Review risk

78 Change AI proxy

large surface area, low test confidence · scale & bands [range and high/med/low cutoffs — Open Call 8]

Proxy, labeled as such and display-only — it never enters the flagging rule. the Dev Lead's trust is calibrated, not absolute: "more than I trusted our old linter, less than I trust Priya." DL-3 TR-13 The score's range and band cutoffs are platform facts not yet stated anywhere on the surface — Open Call 8; disclosed at first use once the data team supplies them. FLAG

AI cost on this branch

[$— · — tokens]

tokens and dollars, branch lifetime

Red-bracketed pending G5 (Open Call 3). Tokens + dollars is the ask verbatim. DL-2

Provenance — "what is this data?"

Every figure in this expansion carries its source and quality band: measured recency (fact_session_day) · measured push status (git observer) · proxy review risk (Change AI) · partial abandonment evidence (lives in Sec 3’s abandoned-work disclosure, not per-row in v1). Quality-by-absence: if a signal has no data, the panel says so instead of showing zero.

Per 02's trust row: surface qualityBand on cost and staleness figures. Pointer added per TR-26 — the provenance line previously cited a per-row abandonment panel that doesn’t exist in the expansion. TR-26

Cycle time context

Not shown

Deliberately absent: averageCycleTime / delivery.cycleTime are Unavailable at the live endpoint — 02: do not design on it. Recency + push lag carry this beat instead. TR-6

The staleness threshold is lead-configurable, never hardcoded — the Dev Lead named three candidate definitions (untouched N days / unpushed N days / open with failing review-risk signal) and refused a silent pick. No tenant-configurable threshold exists in the platform today (only cost policies/budgets are admin-entered) — Open Call 1. DL-6 FLAG

3 · AI spend & sunk costCEO-1 CEO-4

✦ Lead takeaway · internalI know the real AI spend in this Work Area — and the tool refuses to guess what the stale share costs until it can prove it. TR-20

Deliberately one section, not the lead. the Dev Lead's parting line: the cost story must not crowd out the list. Cost appears as one column in the radar + this one context section — the CEO's "dollar number next to a dying branch" lives in the radar column, not above it. TR-7 DL-10 CEO-1

Section leads with the one fully-measured set of numbers (Work Area anchor + per-tool components, which sum); per-item and abandoned figures stay subordinate and red-bracketed until G5/G6 resolve. This resolves Step 3's weak-takeaway finding. TR-14

Context — Work Area AI spend (all work, last 30 days)

$18,400

all work in atlas Core, not just stale items · +12% vs prior 30 days

Claude Code

$9,700

Copilot

$6,150

Codex

$2,550

components sum to the total: 9,700 + 6,150 + 2,550 = 18,400

Measured — spendAllocation: tokens + session cost, per-tool splits (02). Safe at Work Area level regardless of G5. Context anchor for the figures beside it. TR-14 Retitled context-first per TR-17 (was "Work Area AI spend" under a "Sunk cost" header) — the page’s largest real dollar must not be misreadable as money sunk in stale work. TR-17

Sunk in the 12 stale items

[$— · — tokens]

share of Work Area spend · basis [branch lifetime vs 30-day window — Open Call 3] · per-item attribution unverified

Red-bracketed on G5 (Open Call 3): if branch is truly in the fact_session_day grain this is a read-time roll-up; if cost only attaches at repo level it needs a new allocation path. Never shown as real until verified. FLAG DL-2 "Of the $18,400" subset claim removed per TR-18 — per-item cost is branch-lifetime while the anchor is a 30-day window; the label must not promise arithmetic the bases can’t guarantee. TR-18

Sunk in abandoned work estimated — expand for the partial figure

[~$— estimated] estimated as: AI cost on the item × the share of its work that was abandoned, derived from git hard-reset signals and file-retention data. Shown only behind this disclosure, with its quality band, never as a headline.

the CEO's "money we actually lit on fire" — realized waste, wanted prominent. Held at partial: mart components exist (hard-reset abandonment signal, fact_file_retention), but served retention/abandonment rates are Unavailable and contributionMix is estimated (G6, Open Call 5). Promoted to a headline only when the served rates land. CEO-4 FLAG TR-14 Formula restated in plain language per TR-27 — "hard-reset + retention components" was platform-internal vocabulary that wouldn’t survive cross-examination. TR-27

What this section will never show

No counterfactuals. the CEO asked for "cost of abandonment avoided" — how much waste rescuing a branch prevented. Declined at the kickoff (Trent): counterfactuals are non-capturable by policy (G1) and we've been through this on the exec report; the CEO conceded. Permanent design constraint, not a roadmap gap — only realized sunk cost appears here, so nobody re-adds it later. CEO-3 TR-11

4 · Owner loadDL-4

✦ Lead takeaway · internalI can see when stale work is piling up on one person — that's an overload conversation, not four separate branch problems.

Stale items by owner (of 12)

Priya ↗

4spread-thin

Marcus ↗

the Dev Lead ↗

Elena ↗

Jonah ↗

Derivable — owner attribution (measured) × stale candidates (measured); the join is read-time (02). Counts sum to the Sec 1 total: 4+3+2+2+1 = 12. the Dev Lead's framing verbatim: four stale branches on one person is "a person problem, not four branch problems." DL-4

Overload signal

1 estimated

team member spread thin: Priya ↗ — 4 of the 12 stale items + capacity-health spread-thin signal this month · signal definition [mechanism disclosure — Open Call 8]

operatingHealth: capacity health + spread-thin subjects — served domains that directly back this ask; qualityBand shown. Clicking opens session/branch drill-down rows (operationsDiagnostics). Whether an estimated label may render against a named person at all is part of the exposure policy — Open Call 2; the signal’s mechanism disclosure is Open Call 8. FLAG

Exposure policy is undecided: who sees this tab, whether owners see their own rows, and the names-vs-anonymized default are all [Open Call 2].

Names vs anonymized rollups is an open call, not a design assumption. the Dev Lead noted his Work Area policy already resolves granularity, but nobody wrote down a decision on anonymized rollups (Open Call 2). Drawn with names because the existing granularity policy (individual → anonymized) covers both renderings at query time; this section must read correctly in anonymized mode too ("Owner A — 4 items"). FLAG DL-8 TR-8 Extended at the 7/17 persona review: Open Call 2 now also covers disclosure to the measured (do owners see their own rows first?), never-pushed detail granularity, Sec 5 watch-list visibility, and the Developer’s note that with 8 active members "Owner A — 4 items" is cosmetic anonymity.

5 · Follow-throughDL-5 FLAG

✦ Lead takeaway · internalOnce an intervention anchor exists, the radar will close the loop on my nudges — until then this section stays bracketed rather than pretending it can. TR-20

the Dev Lead verbatim: "when he pokes someone about a stale branch, did it move afterwards. 'Otherwise I'm just a nag with a dashboard.'" DL-5

⚠ Data gap — this panel is designed but has no anchor event.
G4 (02): nothing in the platform records "I nudged this person/item on date X." Post-intervention movement is derivable from existing activity facts once an intervention timestamp exists — the delta logic is cheap; the anchor is the gap. Nearest neighbors (fact_insight_feedback, insight-feed completion tracking) are partial or return unavailable. Open Call 4.

Watching — items I acted on

Item	Owner	Marked [anchor event — none exists in the platform yet · Open Call 4]	Since then	Verdict (lead's, not the tool's)
feature/spend-rollup-cache	Marcus ↗	[Jul 10?]	[activity delta — computable once anchor exists]	lead marks: resumed / still stuck / let go
fix/ws-reconnect-loop	Elena ↗	[Jul 12?]	[activity delta]	lead marks outcome

Verdict stays with the lead by design — the tool reports movement, the lead judges the outcome; keeps "no verdicts" intact inside the loop. Candidate v1 anchor: a manual "mark as raised" action on a radar row, which would itself create the missing timestamp — carried as Open Call 4, not assumed. TR-10 DL-6 Clean-state brackets made self-explaining per TR-22 — a reader without the review layer must learn from the section itself that it is deliberately blocked (no anchor event), not broken. TR-22

Not in scope — deferred or excludedV2

Notifications V2

Slack pings on threshold crossings — agreed v2 at the kickoff; the Dev Lead himself: "v2, don't let it eat the core list." The radar is a pull surface in v1. DL-9

Defect correlation FLAG

Visibly parked, per the CEO — must not be forgotten. "Do stale branches ship more bugs?" needs defect/CI ingestion, which doesn't exist today (G2). Parked here so it survives into the roadmap conversation. CEO-6

Counterfactual savings FLAG

"Spend avoided" — permanently excluded, not deferred (G1). the CEO asked, Trent declined, the CEO conceded; restated here so nobody re-adds it. CEO-3 TR-11

Jira-linked work items

Not ingested — fact_work_item covers native branches + GitHub PRs only (02). Stated honestly in the radar's caption (Sec 1), not silently missing. TR-5

Coverage cross-check — every transcript ask, where it's answered

Ask (kickoff 7/15)	Answered by	Status
DL-1 — ranked list: branch/PR, owner, repo, days since last activity, days unpushed. "The list is the product."	Sec 1: ranked table (all five fields) + KPI strip; list leads the page (TR-1)	Covered — all fields measured; ordering interim (days inactive) until threshold call (Open Call 1/6)
DL-2 — AI cost per agent-heavy branch, tokens and dollars	Sec 1 cost column + Sec 2 branch-cost panel + Sec 3	Partially blocked — per-item figures red-bracketed on G5 (Open Call 3); tokens + dollars format specced
DL-3 — review-risk signal per item	Sec 1 risk column + Sec 2 risk panel	Covered as labeled Change AI proxy, display-only (TR-13)
DL-4 — "who is spread thin": staleness clustering on a person	Sec 4: by-owner bars + operatingHealth spread-thin signal	Covered — join derivable from measured facts; spread-thin estimated with qualityBand
DL-5 — follow-through: did the poke move it	Sec 5: watching list + post-nudge movement	Designed but blocked on G4 — no anchor event (Open Call 4)
DL-6 — don't pick a stale definition silently; "just don't hardcode seven"	Sec 1 threshold control (bracketed) + Sec 2 raw signals, no composite; verdicts stay with the lead (Sec 5)	Covered in design — configurability needs G3 to be real (Open Call 1)
DL-7 — commit-to-push lag; never-pushed work is "the worst offenders"	Sec 1: Never-pushed KPI + first-class rows with unpushed days; Sec 2 push panel	Covered — push observations + lag are measured
DL-8 — lives in the portal, scoped to his Work Area; granularity via existing policy	Audience head + Sec 4 anonymization note	Covered — inherited policy, no new machinery; default mode Open Call 2
DL-9 — Slack notifications: "v2, don't let it eat the core list"	Not-in-scope strip	Deferred to v2 by agreement
DL-10 — "as long as the cost stuff doesn't crowd out the list"	Layout: cost = one column + one section, never the lead (TR-7)	Covered
CEO-1 — "a dollar number next to a dying branch, that's the headline"	Sec 1 cost column + Sec 3	Partially blocked — column specced, values pend G5; Work Area anchor real ($18,400)
CEO-2 — dev-lead tool first: "the Dev Lead is the user, not me"	Audience head; every takeaway voiced as the lead	Covered
CEO-3 — show "cost of abandonment avoided"	Sec 3 "never show" panel + not-in-scope strip	Declined at kickoff — permanent exclusion, logged TR-11
CEO-4 — realized waste prominent: "the money we actually lit on fire"	Sec 3 abandoned-work disclosure	Partially blocked — held at estimated-behind-disclosure on G6 (Open Call 5); promoted when served rates land
CEO-5 — "inherits whatever the Work Area lets you see, no new permission system"	Audience head	Covered
CEO-6 — defect correlation: "park it, but note it somewhere visible"	Not-in-scope strip, flagged G2	Parked visibly per the ask
CEO-7 — external framing: "control your AI token costs"	Audience head framing note	Covered — framing only; list stays primary internally
Action item — the Dev Lead to send real branch names from the sprint incident	Sec 1 note; demo placeholders in use	Pending — Open Call 7

Cross-checked against 01-Objectives.md: the Dev Lead's asks 1–5 map 1:1 to Objectives 1–5; framing decisions and exclusions match. No divergence found — 01 stands unrevised. Step 3 carry-over decisions TR-1…TR-8 and TR-10 retained; TR-9 (question headers as Step 3 scaffolding) is executed and superseded by TR-12. Step 4 adds TR-11…TR-14. Step 5 persona review (7/17, technical panel + UX Designer) adds TR-15…TR-28 and Open Calls 8–10 — synthesis and triage in Persona-Review-Audit-Stale-Work-Radar-2026-07-17.md.

Red [bracketed] values on this page trace to 10 numbered open decisions, tracked in this file’s review layer — “Show review layer”, top right. TR-16

Open callsFLAG

Staleness threshold definition (G3; DL-6). "Stale" has no single definition and must not be hardcoded silently — the Dev Lead named three candidates (untouched N days / unpushed N days / failing review-risk signal). What does the lead configure, per Work Area? Does push status or review risk enter the flagging rule or only the display? No tenant-configurable threshold exists in the platform today (only cost policies/budgets) — platform ask or per-surface setting? Extended 7/17 (persona review): the definition must also enumerate the activity-event rule — which events reset the recency clock (rebases? merges-from-main? reviewer comments?), how a session attributes to a branch across mid-session branch switches, whether draft PRs share open-PR staleness semantics, and resistance to trivial-touch resets (an empty commit every N−1 days). Panel note: a 4-day row currently sits on the list — the chosen rule must defend or exclude it. Until resolved, the radar states its interim rule inline and all candidate counts are labeled provisional (TR-15).
Anonymized rollups vs individual names. Undecided at the kickoff ("nobody wrote down a decision"); carried as an open call, not a design assumption. The Work Area granularity policy supports both — the decision is which default this surface gets, and whether Sec 4 reads usefully in anonymized mode. Extended 7/17 (persona review) into the full exposure policy: who can open this tab; whether owners see their own rows, and see them first (Developer's candidate rule: "the lead sees nothing about a person that the person can't see" — recorded, not adopted); never-pushed detail granularity (local commit counts/ages) shown to non-owners; whether Sec 5 marks are visible to the person marked; whether estimated labels ("spread-thin") may render against named individuals at all; and that with 8 active members, "Owner A — 4 items" is cosmetic anonymity below some n.
G5 — per-branch cost grain. The inventory's two grain statements disagree (subject×repo×tool×day vs …×branch×…). Must be resolved against the repo before the per-row cost column, the Sec 2 branch-cost panel, and the "sunk in stale items" figure are designed as real. Until then, every per-item cost is red-bracketed. Extended 7/17 (persona review): also decide (a) whether v1 ships the cost column at all before the grain resolves — an all-bracket column reads as breakage rather than integrity (Dev Manager, Dev Lead), though cost-next-to-the-dying-branch is a kickoff commitment (CEO-1, TR-7); and (b) the declared window for "sunk in the stale items" (branch lifetime vs 30 days) so it reconciles with the Work Area anchor (TR-18).
Intervention tracking anchor (G4; DL-5). Nothing records that the lead acted. Candidate: a manual "mark as raised" action on a radar row (which would create the timestamp). Is a manual mark acceptable for v1, or does close-the-loop wait for real instrumentation? Panel note 7/17: Dev Manager urges shipping the manual mark in v1 — it is the only action verb on the surface and the anchor Sec 5 needs; without it, v1 triage leaves no trace.
G6 — abandoned-share quality (CEO-4). Served retention/abandonment rates are Unavailable; components exist in the mart. v1 treatment decided (TR-14): estimated, behind a disclosure, with qualityBand. Open: when the served rates land, does the figure get promoted to the headline the CEO wants?
Radar ordering once Call 1 resolves. v1 orders by days inactive (measured). Should a composite rank (recency + push lag + review risk — all served or proxy today) replace it, and if so how is the formula disclosed to the lead so it never becomes a silent verdict? Extended 7/17 (persona review): also decide never-pushed ordering weight — the design calls never-pushed the worst offender class while the sort buries it below the fold; pin to top, or a persistent filter chip (Dev Manager), vs plain measured ordering (TR-3).
Real branch names (kickoff action item, the Dev Lead). Example rows use demo placeholder branch names until the Dev Lead sends the real ones from the sprint incident.
Signal definitions & banding disclosure (added 7/17, persona review). The review-risk score's scale and band cutoffs (what makes 78 "high" and 43 "medium" — out of what range, set by whom?) and the spread-thin signal's mechanism are platform facts stated nowhere on the surface. Both must be disclosed at first use, in the clean state; the affected labels carry red brackets until the data team supplies the values. Flagged by CTO, Dev Manager, and UX Designer — never invented here.
Row-level parked / blocked status (added 7/17, persona review). No way to mark an item deliberately paused — blocked upstream, waiting on a decision, a throwaway spike, superseded. Dev Lead calls it the single biggest determinant of week-three retention ("~a third of in-flight branches are intentionally paused at any moment"); Developer proposes an owner-set status (spike / parked / blocked on X / superseded) that would also distinguish deliberate abandonment from rot in Sec 3's waste figure, give owners a voice on their own rows, and absorb intentional local spikes flagged never-pushed. Who sets it (lead / owner / both) and its KPI treatment (excluded vs separate band) are the call.
Owner attribution rule (added 7/17, persona review). "Owner" is drawn but undefined — branch creator vs last committer, and what happens on handoff when someone rescues a stalled branch (does the rescue transfer the blame?). Sec 4's overload framing is only as fair as this join; the rule surfaces in Sec 2's provenance panel once decided.