CTO Dashboard — Rebuild

• The page — engineering/reports/page.tsx is one 1,000-line client component: cycle navigator, 3 summary cards, triage inbox, and per-person sections (stacked SP-by-team bars + task list + rollover). refactor into components
• Daily goals are hardcoded in TEAM_MEMBERS (Temir 14, Tima 8, Niyaz 8, Nurakhmet 0). Historical cycles render with today's number, not the goal that was actually in effect. replace with DB model
• State history already reachable — getIssueMilestones() reconstructs status transitions with timestamps; today it's lazy-loaded per issue on click and still references the dead "Sent to QA" state. promote to a real engine
• Cycle model is solid — IELTS drives the navigator, sibling cycles matched per team by startsAt; pg-backed cache (6h active, forever for past cycles). reuse

A1Data model new

Two small tables. Defaults are effective-dated so changing someone's weekly goal never rewrites the past. Overrides handle one-off days and carry a note so "why was Tuesday a 0?" answers itself.

// src/lib/db/schema.ts — keyed by email prefix (same keys as TEAM_MEMBERS)
spGoalDefaults(
  id           serial pk,
  team_member  varchar(100)  // "temirlan.temirbayev"
  daily_goal   integer,
  effective_from date,        // default applies from this date forward
  updated_at   timestamp,
  unique(team_member, effective_from)
)
spGoalOverrides(
  id           serial pk,
  team_member  varchar(100),
  date         date,          // the specific work-day
  daily_goal   integer,       // 0 = sick / off
  note         varchar(200),  // "sick", "half day", "on-call"
  updated_at   timestamp,
  unique(team_member, date)
)

Effective goal for (person, day) resolves in order:

override(person, day)
  ?? (isWorkday(day) ? latestDefault(person, effectiveFrom ≤ day) : 0)
  ?? hardcodedFallback(person)   // migration safety net

isWorkday = not Sunday (keeps the current Mon–Sat default); an override can still force any value on any day, including a Sunday or a 0 on a workday. Cycle target = sum of effective goals over the cycle's days, replacing today's dailyGoal × workDays.

A2API new

• GET /api/analytics/sp-goals?from&to → per-person effective goal per day across the range, plus the raw defaults & overrides so the editor can render exact state.
• POST /api/analytics/sp-goals → upsert one of {type:"default", teamMember, dailyGoal, effectiveFrom} or {type:"override", teamMember, date, dailyGoal, note}.
• DELETE /api/analytics/sp-goals → drop an override (revert that day to its default).

Mutations are admin-gated by the existing dashboard_auth cookie. Writing a goal invalidates the affected cycle's cached payload so the target recomputes.

A3Editing UI new

An "Edit goals" affordance on each person's section opens an inline editor: a default field (with an effective-from date) and a per-day grid for the visible cycle where any day can be overridden, with an optional note. Saving writes through A2 and the per-person target + the daily reference line update in place. Past cycles render read-only against the historical effective goals.

B1Bucket definitions

Two numbers headline each cycle — ① Intake and ② Todo→Done. The rest progressively disclose as ②'s decomposition. Every dwell bucket sums all intervals in that status (rework loops count each visit). Dev time is In Progress dwell specifically — the "actual coding" slice, not the whole span. Population is Done-only: issues ending Canceled / Duplicate are dropped so they don't drag the average.

B2Population & aggregation

• Historical (per cycle) — issues that reached Done inside the cycle window, attributed to the cycle they shipped in. Canceled / Duplicate dropped entirely. Full history reconstructed per issue → the two headliners + decomposition.
• Live WIP aging survivorship-bias antidote — for the active cycle, every still-open issue's time in its current status, surfacing the most-aged items ("RING-42 in Review 6d"). Plus the current Triage queue's age. This catches bottlenecks the Done-only view hides.
• Median + p75 — cycle times are right-skewed; median is the headline, p75 the tail signal. Mean would be dragged by outliers (another reason to drop Canceled/Duplicate).
• Per-cycle delta — each cycle compares against the previous cycle (green/rose), matching the dashboard's inline period-over-period pattern.

B3Visualization new

• Per-cycle overview card — the two headline numbers (Intake, Todo→Done) with median + p75 and a delta vs the previous cycle; a small horizontal bar decomposes Todo→Done into Pickup / Dev / Review / Rework / Merge on expand.
• Trend graph — last 8 cycles; stacked median-decomposition bars (or a Todo→Done line) so a creeping Review or Rework time is visible at a glance.
• WIP aging panel — active cycle only; aged open issues grouped by status, worst first.
• Drill-down — per-issue table (each bucket + the two headliners) behind the card for when a number looks off.

B4How it's computed (performance)

Buckets need each completed issue's full transition history. The SDK's lazy relations (await entry.toState per row) would explode into N+1 calls per cycle, so the engine issues one raw GraphQL query per team-cycle that returns issues with their history and state names inline:

// one round-trip per team-cycle via client.client.rawRequest(...)
issues(filter:{ cycle:{id:{eq:$c}}, state:{type:{eq:"completed"}} }){
  nodes{ id identifier estimate
    history(first:50){ nodes{
      createdAt
      fromState{ name type }
      toState  { name type }
    }}
  }
}

Per-cycle summaries are cached in the existing pg cache — forever for past cycles, 6h for the active one — so the trend graph just stitches cached summaries and stays cheap. A dedicated /api/analytics/linear-cto-cycletime endpoint keeps the main dashboard's first paint off the history fetch. Calendar time (incl. nights/weekends) by design — the clock not stopping at 6pm is the point: it pressures closing issues rather than leaving them open at EOD.

Page flow, top to bottom:

• Header — ← Back + large serif italic title, cache pill, refetch. keep, refine
• Cycle navigator — prev/next, active badge. keep
• Summary cards — triage processed, team SP vs target, issues completed; add the cycle-time headliners (Intake · Todo→Done). extend
• SP throughput — per-person stacked bars + task lists, now reading goals from the new model, with the Edit goals editor. goals editor
• Cycle Time section — overview card · trend graph · WIP aging · drill-down. new

The monolithic page.tsx gets split into composable section components (SummaryCards, PersonSection, GoalsEditor, CycleTimeSection, …) so the page reads top-down and each piece is testable. /impeccable runs live against the running dashboard for the visual pass; that's the last step, after the data is real.