Anonymized portfolio copy — names and customers replaced; all data illustrative.
Developer Profile — Spec Wireframe CANONICAL · STEP 4
The Individual Developer Profile Page. Lo-fi UI Wireframe — function over polish. Update cycle 6/15: persona-review iteration + new asks (drill-in, tool usage, PR detail) + validated-endpoint data re-grade + V1-focus consolidation (roadmap note for unserved data).
Net-new design
V1 / MVP scope
Primary user: engineering manager
Token-cost framing wins ties
Lo-fi · function over polish
Update cycle · 2026-06-15
Data as of the latest rollup (marts currently flagged freshness-stale — values shown are the most recent available, not live). Scope: this profile reads through the Payments Work Area the manager drilled in from; a Work-Area-scoped read can return an honest empty (no data) for a metric that exists company-wide — the page shows no-data, never tenant-wide numbers in its place. TR-20
Two conventions for non-real content: greyed, dotted-underlined numbers are sample data (layout only); [red brackets] mark data that is undecided or not yet captured (each traces to the Open decisions list). Nothing is fabricated.
Feedback sources
CEO-n the CEO, Jun 1 ask — hover = the source line (verbatim quotes marked)
DATA-READY served by current marts — measured
SECONDARY feasible, flagged caveat (e.g. Work-Area overlap)
BLOCKED needs new pipeline work — design only, no data
Decisions & status
TR-n our design decision (rationale in tooltip) — doubles as the decision log
FLAG open question → Open-decisions box
G1…G9 traces to a gap in the data inventory
1,840 sample data · […] undecided / uncaptured
Review annotations — internal only, not product UI
✦ manager takeaway what the manager should leave with
⚠ weak takeaway the same takeaway, recolored red when it fails the test: would the manager care? why → fix
data-basis lines explain every number’s source
Source basis (read first). The raw Jun 1 the CEO transcript was not present in Sources/ at Step 4. Per Trent’s direction, source tags (CEO-n) trace to 01-Objectives.md — Trent’s synthesis of those notes. Tooltips mark which asks are verbatim quotes carried in 01 versus synthesized from the notes; nothing is presented as a quote that isn’t one. Independent re-verification of the quotes is pending the raw transcript. The the Dev Lead ideation sessions 01/02 anticipated did not happen, so the identity / coaching / layout questions remain genuinely open (see Open decisions), not deferred-and-answered.
Built for the engineering manager SINGLE PRIMARY USER CEO-4
The reader arrives here by drilling into one developer from the team view — "could I… slice that same data?" (the CEO, Jun 1, verbatim). So every panel is voiced as a manager assessing a developer, not the developer self-reviewing. The question the whole page answers: "how engaged is this developer, and where have they been investing their time?" — where engagement means quality of engagement, not raw hours ("not so much busy in terms of hours, but how engaged is the team" — verbatim) CEO-2. Losing a prior enterprise prospect on "very, very underwhelming" metrics dashboards is the cautionary anchor CEO-3: this page has to show value clearly, at a glance.
Token cost control is the company’s top priority, so where two signals compete for space the human/AI & spend read wins the tie TR-1. Example content uses a real-feeling developer ("Sam Okafor") on the atlas team so the page reads like the product, not a placeholder.
Visibility / governance is undecided — this page names an individual in full (not an anonymized band), so who may view it, whether any figure is exported to a performance / HR context, and the minimum cohort size for "vs team" comparisons all need a stakeholder/policy decision before it ships to engineers FLAG (OC-12).
Narrative spine — the reading orderWHY THIS ORDER TR-5
The page is laid out so the manager gets the answer before the evidence, and — refocused 6/15 (TR-22) — it now shows only what V1 can actually serve. Read top to bottom: this developer is engaged (or not), here’s their rhythm, here’s where the effort went, here’s the quality of that effort, here are the tools they use, here’s their PR / work-item detail. The core verdict (1–4) lands first; the drill-in detail (5–6) follows. Everything we can’t serve yet is no longer drawn as empty panels — it’s consolidated in the "Coming when the data lands" note at the bottom TR-17 TR-18 TR-22.
- The verdict — engagement at a glance. Is this developer engaged, and trending up or down vs their own baseline and the team median? Nothing below earns its place if this doesn’t land first. V1 · data-ready
- The rhythm — activity over time. The GitHub-style heatmap: consistent presence, recent ramp or fade. Native day-grain activity. V1 · data-ready
- Where the effort went — work investment. Which projects/repos this developer’s time landed in (repo + Work-Area secondary). V1 · data-ready
- The quality of that effort — engagement, not hours. Human vs AI-assisted mix (estimated) and work flow (stale + completion). AI-survival and cycle time aren’t served — in the roadmap note, not drawn empty here. V1 · partial
- The tools they use. Which AI tools, IDE-vs-agent balance, adoption depth (new ask). Per-dev effectiveness isn’t served — in the roadmap note. V1 · partial
- PR & work-item detail. The developer’s work items / branches with commits-files-lines and proxy risk (new ask). PR-review lifecycle isn’t served — in the roadmap note. V1 · partial
Ship scope — V1 vs roadmapWHAT SHIPS NOW TR-21
Explicit V1 line (Trent, 6/15): which panels ship in V1 (data served, even if Partial/estimated — badged) vs which are roadmap (data not yet served). Refocused 6/15 (TR-22): this spec now renders only the V1 panels inline; roadmap items are consolidated in the "Coming when the data lands" note at the bottom rather than drawn as empty panels — so no ask is dropped, but the page reads as what we can deliver. The clean product cut is Developer-Profile-V1-Ship-View-Wireframe.html.
| Section / panel | V1? | Basis / gap |
|---|
| §1 Engagement at a glance (verdict, baselines, AI-engagement) | V1 | Measured / partial — badged |
| §2 Activity heatmap | V1 | Measured |
| §3 Repo allocation · Work-Area secondary | V1 | Measured / partial (overlap caveat) |
| — Work-type pie | Roadmap | G4 (all unclassified) |
| §4 Human/AI mix · work-moving (stale + completion) | V1 | Partial / estimated — badged |
| — AI survival/retention · cycle time | Roadmap | G7 (rates Unavailable) |
| §5 Tool mix · IDE/agent split · adoption | V1 | Partial / measured — badged |
| — Per-dev tool effectiveness · tool content | Roadmap | G8 (aggregate) / not captured |
| §6 Work-item list · change volume · proxy risk | V1 | Partial / proxy — badged |
| — PR-review lifecycle | Roadmap | G9 (provider review facts) |
| Times-of-day grid | Roadmap | G1 + G2 |
| AI-powered work-area grouping | Roadmap | G3 (aspirational, CEO-8) |
Roadmap = keep in this spec as a documented ask + gap; do not render as an empty box in the shipped product — it moves to the "coming when the data lands" strip in the V1 ship view. TR-21
1 · Engagement at a glanceIs this developer engaged, and which way are they trending? CEO-1 CEO-3
DATA-READY
✦ Manager takeawayIn five seconds: I know whether Sam is engaged, and whether that’s up or down versus how Sam usually works and versus the team.
Identity
SO
Sam Okafor
[role] · atlas team · scoped to Payments Work Area
Name + team read cleanly; role label is undecided — it was one of the questions the the Dev Lead sessions were to settle, and those did not happen FLAG. Scope is now resolved: the profile always inherits the Work Area the manager drilled in from, never tenant-wide TR-8.
Basis: dim_subject (SCD-versioned), resolved through the Work-Area scope the manager arrived from (Inventory §5 — scope-first). Role field is not yet decided. FLAG
Engagement vs baseline CEO-2 FLAG
Active ▲
Active = days with recorded coding-session activity (excludes review / pairing / design time).
active days this period: 18 / 21 (this period = trailing 30 days)
vs Sam’s own 3-mo baseline: ▲ +12%
vs team median: ▲ +6%
✦ TakeawayEngaged and slightly above their own baseline this period. (Was "… not a flight risk this period" — softened per TR-14: attrition can’t be inferred from an activity delta.)
Basis: active-day count & active_minutes_sum from fact_session_day, rolled to the period; baseline = same metric over prior 3 mo; team median from the team view the manager drilled from. Measured. Period = trailing 30 days, baseline = trailing 3 mo TR-8. Plain-language "Active" definition surfaced to the clean state TR-11; verdict state thresholds escalated FLAG (OC-9).
AI engagement TR-1 FLAG
14 / 18
of 18 active days had AI activity (trailing 30 days)
high-AI-usage days: 6 (heuristic: prompts≥10 / tool-calls≥10 / agent-min≥30) — was "power-user days"; relabeled + threshold surfaced per TR-13
⚠ Weak takeawayWhy weak: "Sam is using the AI tooling most days" sits at verdict altitude but reads as a usage tally a manager may not act on — and risks a surveillance read. Fix: keep it as supporting depth behind the verdict, not a headline; pending OC-8 on whether a raw-usage read belongs in §1 at all TR-13.
Basis: ai_active_day + power_user_day proxy per subject-day, fact_session_day (Inventory §4 workActivity, measured). Token-cost tie-break puts AI engagement in the headline by design TR-1; denominator legibility TR-10, label/threshold surfaced TR-13, headline-altitude question escalated FLAG (OC-8).
2 · Activity over timeWhat’s the rhythm — consistent presence, or a recent ramp / fade? CEO-5
DATA-READY · anchor
✦ Manager takeawayI can see at a glance whether Sam shows up steadily or in bursts, and whether the last few weeks are ramping up or trailing off.
Activity heatmap — last 6 months, one cell = one day
Range: 3mo · 6mo · 12mo | Cell metric: active minutes · commits
— selected state now shown by a single bold-underline marker (6mo / active minutes); default active minutes: the engagement signal, not output volume TR-2 TR-15
less
more | outline = AI activity that day
Basis: one cell per UTC day, intensity = active_minutes_sum from fact_session_day sliced to this subject; AI-day outline = ai_active_day. Day grain is the native shape — measured. Reconciles: summed cells = Sam’s active minutes shown in §1 over the same window. Captured-but-unattributable activity is not here (lives in fact_session_unattributed_day) — expected, not a gap.
3 · Where the effort wentWhich projects has this developer been investing time in? CEO-7
DATA-READY · anchor
✦ Manager takeawayI know which projects Sam’s time actually went to this period — and can click into any of them.
By project (= repository) — share of active minutes TR-3
Each repo row links ↗ to the repo. (sample shares sum to 100%)
✦ TakeawayMost of Sam’s time is in the server repo — that’s where to look first if priorities have shifted.
Basis: active_minutes_sum grouped by dim_repository for this one subject, fact_session_day. Measured (02 §1.3 / Inventory §4). TR-3
By Work Area SECONDARY TR-9
Work Areas can overlap — these shares are independent reads of each area and may exceed 100%, not a parts-of-whole split.
Feasible from existing facts, but a Work Area is resolved at query time, and overlapping Work Areas can double-count the same minutes — so shares here need not sum to 100%. Surfaced as a labelled secondary view, not the default. Overlap caveat now promoted to the clean state via the twin pattern TR-9. FLAG
✦ TakeawayA secondary cut for managers who think in Work Areas, not repos — overlapping by design, so read it as separate lenses, not a 100% split.
Basis: subject’s active_minutes_sum run through each Work Area’s repo/subject/branch predicate set (Inventory §5). Overlap caveat is shown, not hidden.
Work-type lens (feature / maintenance / debt) is not rendered here — fact_cost_allocation is all unclassified today, so it would be one slice. Moved to the roadmap note rather than shown as an empty panel G4 TR-22.
4 · Quality of engagement, not hoursIs the effort good effort — how AI-assisted is it, and is it moving? CEO-2
V1 · partial
✦ Manager takeawayBeyond "is Sam here": I can see the directional human/AI mix of their work and whether it’s flowing — the engagement-quality and cost angle.
Human vs AI-assisted mix PARTIAL · estimated TR-16
Composition of retained work — human vs AI-assisted share · illustrative split
Estimated, not measured: the endpoint returns this as a session-attribution estimate, and at current scope the AI side barely registers (company-scope mix reads ~41% human / 0% AI-assisted / 2.9% autonomous). Treat the split as directional until the contribution-mix estimate firms up.
✦ TakeawayDirectionally, how much of Sam’s retained work is AI-assisted — useful for the cost story, but read it as an estimate, not a precise mix.
Basis: contributionLineage.contributionMix.* — Partial / estimated per the validated endpoint (was wrongly graded "measured"; corrected 6/15). Mart components (retained_human_sum/retained_ai_sum) exist but the served share is a session-attribution estimate. TR-16
Is the work moving? PARTIAL TR-16
Stable — 1 item to nudge
stale work items: 1 measured
completion rate: 88% partial
Stale-work is measured; completion is a partial derived ratio. Cycle time isn’t served — it’s in the roadmap note, not shown empty here. Coverage: native branches + GitHub PRs only · not adjusted for task size / mix · no target shown yet.
✦ Takeaway"Is work flowing" beats "hours logged" — stale-work and completion say it’s steady with one item to nudge.
Basis: workItems.summary.staleWork (Available), completionRate (Partial, derived ratio) from fact_work_item (native branches + GitHub PRs). averageCycleTime is Unavailable — moved to roadmap. Issue-tracker items not covered (Inventory §7). Re-graded per endpoint TR-16; targets/trend escalated FLAG (OC-10).
Deliberately left out: averageFocusBlock / contextSwitchRate — they sound like deep-engagement metrics but are proxies (derived from minutes & commit counts, not measured), so they don’t headline the engagement story (02 §2 & G6). TR-7 G6
5 · The tools they useWhich AI tools is this developer using — most, least, and how? TR-17
PARTIAL · estimated mix
✦ Manager takeawayI can see which AI tools Sam actually leans on, how much is hands-on-IDE vs agent-driven, and how deep their adoption runs — the "what are they working with" picture behind the engagement number.
Tool mix — most / least used estimated
Share of this developer’s AI sessions, by tool. Estimated from runtime-session attribution — directional, not exact counts.
✦ TakeawaySam works mostly in Claude Code and Cursor; Copilot and Codex are occasional — useful context, not a target to push.
Basis: workActivity.aiUsage.* tool-mix rows (~10 rows; Partial — estimated from runtime-session attribution per the validated endpoint). Sample shares sum to 100% for this one developer. TR-17
IDE vs agent balance measured
IDE 6% hands-on AGENT 94% agent-driven sessions
✦ TakeawaySam’s work is heavily agent-driven — worth knowing when reading the cost and survival story.
Basis: workActivity.sessions.ideSessions / .agentSessions — Available per the validated endpoint (company-scope reference 128 IDE / 1,942 agent; per-dev sample shown). Diagnostics split is unavailable; the workActivity split is the one to use. TR-17
Adoption depth
78%
of Sam’s active days use AI · prompts this period: [per-dev]
Adoption % is partial/freshness-stale; per-developer prompt count is served (company-scope reference 52,542 prompts).
⚠ Weak takeawayWhy weak: on its own, "AI is a daily habit" isn’t a manager decision, and it duplicates the §1 AI-engagement read. Fix: keep it as supporting depth behind §1, not a second headline (same OC-8 prominence question) TR-17.
Basis: workActivity.aiUsage.adoption (Partial), .promptCount (Available) — validated endpoint. Ties to the §1 AI-engagement card; same OC-8 prominence question. TR-17
Not rendered here: per-developer tool effectiveness (toolEfficiency is bounded/team-aggregate, not per-subject — G8) and tool-call content / steering (sessionSteering Unavailable; transcripts aren’t collected — privacy posture preserved). Both moved to the roadmap note rather than shown as empty panels G8 TR-22.
6 · PR & work-item detailWhat’s in this developer’s PRs and work items? TR-18
V1 · partial
✦ Manager takeawayI can open Sam’s actual work items / PRs — what they are, which repo, how much changed — and click through to the SCM. The review side (who reviewed, how long it waited) isn’t served yet — it’s in the roadmap note, not implied here.
Work items & PRs — most recent, bounded to 5
feat: payment retry queue ↗server · 12 commits · merged
refactor: token ledger ↗portal · 9 commits · in review
fix: webhook signature check ↗server · 4 commits · open
feat: usage export ↗portal · 7 commits · stale
chore: bump deps ↗clients · 2 commits · merged
Each row links ↗ to the work item / PR in the SCM (progressive disclosure). List is bounded to 5 most-recent rows.
✦ TakeawayI can go straight from "Sam" to their actual PRs and see what’s merged, in review, or going stale — the drill-in the CEO asked for, made concrete.
Basis: workItems.edges (Partial, bounded 5) + operationsDiagnostics.workBranches (diagnostic, bounded 5) — native branch lifecycle + GitHub PR mirrors. Status/commits per row from fact_work_item / workFlow. TR-18
Change volume & risk
commits this period: 61
files / lines changed: 230 / 8.4k
review-risk score: 3.7 proxy
test confidence: 3 proxy
Commits / files / lines are measured; risk & test-confidence are proxy scores (estimated from value-score / Change-AI components), not provider review facts.
✦ TakeawayVolume and a rough risk read — enough to know where to look, with risk clearly badged as a proxy, not a verdict.
Basis: workFlow.{commits,filesChanged,linesChanged} (Available); reviewRisk.riskScore 3.7 / .testConfidence 3 (Partial proxy per endpoint). TR-18
Coming when the data lands — not in V1consolidated roadmap TR-22
Asks we can’t serve yet live here as a roadmap note — not drawn as empty panels in the page above. Each traces to a data gap; nothing is fabricated.
- Does the AI output survive? — AI retention / abandonment rate; no served rate yet (no approved generated-work-product denominator) G7.
- Median cycle time — needs cycle observations; stale-work + completion stand in for now G7.
- Most effective tool, per developer — tool efficiency is bounded / team-aggregate, not per-subject G8.
- PR review lifecycle — review wait / depth / comment density / reviewer load / defect rate need provider review facts, all Unavailable G9.
- When in the day they work — times-of-day grid; needs an hour-grained fact + per-developer timezone G1 G2.
- Work-type breakdown (feature / maintenance / debt) —
fact_cost_allocation is all unclassified today G4.
- AI-grouped work areas CEO-8 — auto-clustering doesn’t exist; aspirational G3. And the supervised-vs-autonomous 4-way split G5, collapsed in marts.
- Tool-call content / steering quality — transcripts aren’t collected (privacy posture); counts and mix only.
- Coaching / recommendation panel — unplaced; insight-feed serving is contracted-but-unavailable. See Open decisions FLAG.
Coverage cross-checkevery source ask → where answered
| Source ask / strengthener | Where on the page | Status |
|---|
| CEO-1 — "how engaged, and where investing time?" (core) | Whole page; §1 + §3 carry the two halves | Answered |
| CEO-2 — engagement over hours (verbatim) | §1 baseline deltas + §4 quality framing; hours never headline | Answered |
| CEO-3 — show value at a glance / a prior enterprise prospect anchor (verbatim) | §1 verdict-first + answer-before-evidence order (spine) | Answered (framing) |
| CEO-4 — drill in / "slice that same data" (verbatim) | Audience head + Work-Area scope label + repo/PR links | Answered (framing) |
| CEO-5 — activity heatmap | §2 | Data-ready · anchor |
| CEO-6 — times-of-day grid | Roadmap note | Not served · G1+G2 (not drawn empty) |
| CEO-7 — work-investment allocation | §3 (repo); Work-Area secondary; work-type deferred | Data-ready (repo); G4 deferred |
| CEO-8 — AI grouping into 4–6 areas | Not in V1 strip | Deferred · G3 (aspirational per 01) |
| CEO-9 — ideate with the Dev Lead (process ask) | Did not happen — identity/coaching/layout stay open | Not actioned; see Open decisions |
| New ask (6/15) — drill into a developer from the team view | Breadcrumb chrome + §6 work-item links | Supported (nav + bounded rows) TR-19 |
| New ask (6/15) — what tools, most/least/most-effective | §5 (mix + IDE/agent split + adoption) | Partial · mix estimated; effectiveness team-level only (G8) TR-17 |
| New ask (6/15) — PR detail | §6 (work-item list + change volume + proxy risk) | Partial; PR-review lifecycle BLOCKED · G9 TR-18 |
| Strengthener — human/AI mix | §4 | Re-graded 6/15: PARTIAL · estimated TR-16 |
| Strengthener — AI retention/survival | Roadmap note | Re-graded 6/15: not served (G7) — in roadmap, not drawn empty TR-16 |
| Strengthener — work-item flow | §4 + roadmap | Re-graded 6/15: stale-work measured + completion partial in §4; cycle time in roadmap (G7) TR-16 |
| Strengthener — trend vs baseline/team | §1 | Data-ready |
Every Jun 1 source ask and the three 6/15 asks are accounted for: answered, deferred with a gap reference, or explicitly open/blocked. No ask is silently dropped; metrics the validated endpoint can’t serve are blocked, not faked.
Open decisions — every red bracket traces hereFLAG
- Hour-of-day data basis (Viz #2). Blocked on G1 (hour/interval-grained activity fact) + G2 (per-subject timezone). Decide: wait for the fact, or ship a UTC session-start-hour proxy badged as such. Until then §5 stays designed-but-empty. Drives [times-of-day cells]. OPEN.
- Header / identity fields. Name + team confirmed; role label undecided. This was an the Dev Lead-session question — the the Dev Lead sessions did not happen, so it stays open for the stakeholder. Drives [role]. OPEN.
- Default scope of the profile. RESOLVED — Trent, 6/15: the profile always inherits the Work Area the manager drilled in from; tenant-wide is never the default (Inventory §5 scope-first; audience head). TR-8
- "Project/area" meaning. RESOLVED — Trent, 6/15: = repository for V1 (only fully-populated, non-overlapping grouping). Work-Area allocation kept as a labelled secondary with the overlap caveat. TR-3
- Period & baseline window. RESOLVED — Trent, 6/15: "this period" = trailing 30 days; baseline = the developer’s own trailing 3 months, plus team median over the same window. Needs ~a month of data before month-over-month reads cleanly. TR-8
- Coaching / recommendation panel. the Dev Lead-session question that went unresolved; insight-feed serving is contracted-but-unavailable (Inventory §7). Not placed in V1. Decide whether the profile carries one. OPEN.
- Layout & navigation structure. The full page layout / nav treatment was the third the Dev Lead-session question; those sessions did not happen, so this stays a stakeholder decision (this spec proposes the section order via the narrative spine as a starting point). OPEN.
- AI-engagement headline framing (OC-8, persona review 6/15). Does "days with AI activity" belong at §1 verdict altitude? It risks reading as a usage quota and incentivizes token-burning — against the token-cost narrative; the token-cost goal arguably favors a value/cost read (retained-AI, survival) in the headline over a raw-usage tally. Touches TR-1. OPEN.
- Engagement verdict state thresholds (OC-9, persona review 6/15). What defines "Active" vs at-risk / fading (the cutoffs behind the headline word)? Needed before the verdict can turn amber/red; tied to the unresolved the Dev Lead identity cluster. Drives the Active state label. OPEN.
- KPI targets / bands / trend (OC-10, persona review 6/15). Do the §3–§4 KPIs carry targets or team-bands and prior-period deltas? Trend is feasible from history; target values are a stakeholder call. OPEN.
- Retained / abandoned code definition edge cases (OC-11, persona review 6/15). RESOLVED / SUPERSEDED — Trent, 6/15 (PM): moot for V1 — the validated endpoint returns
aiRetentionRate/aiAbandonmentRate as Unavailable (no approved denominator), so no rate is served to define. The §4 survival panel is blocked (G7); revisit the definition if/when a served rate lands. TR-16 G7
- Profile visibility / data governance (OC-12, persona review 6/15). Who may view an individual profile; whether any figure is exported to performance / HR contexts; the minimum cohort size for any "vs team" comparison. Adoption-critical for the measured engineer. OPEN.
- Per-subject cost / token scoping (OC-13, data re-grade 6/15). The cost dashboard’s spend / value-per-$ / waste are validated at company scope; confirm they resolve per-developer (and through a Work-Area scope) before a per-dev token-cost panel is added to the profile. OPEN.
Resolutions logged per Trent’s direction; the raw Jun 1 transcript was not independently re-checked (see Source basis note). Resolved items are kept, not deleted, per convention. Open calls 8–12 added at the Step 5 persona review (6/15); OC-11 resolved and OC-13 added in the 6/15 PM data re-grade against the validated endpoint inventory. New data gaps from that re-grade (G7 retention rate, G8 per-dev tool effectiveness, G9 PR-review facts) are tracked in "Not in V1" + the gap tooltips, not as decisions.