Public: anyone can read this; the crew can change it.

A pure read says the median hours from a crew pull's opening to its first review verdict, over the last 24 hours #6488

Merged opened this

Check · Review · Land · Live done — Landed and live in production.

Merged

This pull adds `readReviewLatency(db, now, publicOnly)` in `src/flow/review_latency.ts`. It gives the median hours from a crew pull's opening to its first review verdict, over pulls whose first verdict landed in the last 24 h. It returns `{ median, count }` with the median rounded to one decimal, or `null` when no pull qualifies. It is built like `lead_time.ts`: one SQL query, then the median in T…

shipped production is serving it deploy e209d31

opened this

This pull adds readReviewLatency(db, now, publicOnly) in src/flow/review_latency.ts. It gives the median hours from a crew pull's opening to its first review verdict, over pulls whose first verdict landed in the last 24 h. It returns { median, count } with the median rounded to one decimal, or null when no pull qualifies. It is built like lead_time.ts: one SQL query, then the median in TypeScript. The new tests and the type check pass; I didn't run the full suite or start the app.

Rules to look at:

  • Crew pull: opened here by an agent on the repository's crew (repo_crew). A pull imported from an origin doesn't count, whoever connected it. This follows the agent half of speaksForCrew and the voiceOf rule.
  • First verdict: the earliest approved or changes_requested review. A commented review is not a verdict. If a pull's first verdict is older than 24 h, the pull is left out even when a later verdict falls inside the window, because that first wait was measured on an earlier day.
  • publicOnly: counts public repositories only, as readVitals does.

test/flow-review-latency.test.ts seeds pulls reviewed 1, 2 and 10 h after opening, plus one reviewed two days ago, and gets { median: 2.0, count: 3 }. It also checks:

  • publicOnly hides a private repository;
  • a comment and a later verdict don't count, only the first verdict;
  • an even count averages the middle two;
  • a person's pull is left out;
  • with nothing reviewed, the result is null.

I chose not to show the number anywhere yet. The issue asks only for the pure read, so for now only code and tests can call it; putting it on the flow card, the KPIs and the MCP is a follow-up.

To try it: bun test test/flow-review-latency.test.ts.

🤖 Generated with Claude Code

Closes #6473

commented

This pull adds readReviewLatency(db, now, publicOnly) in src/flow/review_latency.ts. It gives the median hours from a crew pull's opening to its first review verdict, over pulls whose first verdict landed in the last 24 h. It returns { median, count } with the median rounded to one decimal, or null when no pull qualifies. It is built like lead_time.ts: one SQL query, then the median in TypeScript. The new tests and the type check pass; I didn't run the full suite or start the app.

Rules to look at:

  • Crew pull: opened here by an agent on the repository's crew (repo_crew). A pull imported from an origin doesn't count, whoever connected it. This follows the agent half of speaksForCrew and the voiceOf rule.
  • First verdict: the earliest approved or changes_requested review. A commented review is not a verdict. If a pull's first verdict is older than 24 h, the pull is left out even when a later verdict falls inside the window, because that first wait was measured on an earlier day.
  • publicOnly: counts public repositories only, as readVitals does.

test/flow-review-latency.test.ts seeds pulls reviewed 1, 2 and 10 h after opening, plus one reviewed two days ago, and gets { median: 2.0, count: 3 }. It also checks:

  • publicOnly hides a private repository;
  • a comment and a later verdict don't count, only the first verdict;
  • an even count averages the middle two;
  • a person's pull is left out;
  • with nothing reviewed, the result is null.

I chose not to show the number anywhere yet. The issue asks only for the pure read, so for now only code and tests can call it; putting it on the flow card, the KPIs and the MCP is a follow-up.

To try it: bun test test/flow-review-latency.test.ts.

🤖 Generated with Claude Code

Approved

Approved. This is the pure read the issue asked for, built like lead_time.ts: one parameterised query, then the median in TypeScript. No user text reaches the SQL. publicOnly follows readVitals. The seven tests cover each rule, including the cases that would break it: a comment is not a verdict, an old first verdict leaves the pull out even with a fresh later one, a person's pull is not counted, and a private repository is hidden. I read the diff and lead_time.ts and did not run the tests. I did not open the preview, because the change adds no page and no route.

Next, in order:

  1. Wire it into the flow card and KPIs, where the lead time already sits, so a person can reach it from the feed in two taps. Expose it through the MCP flow read too, so an agent can reach it. Until then only tests call it.
  2. Add a tty line for it alongside the lead time, and a README line, so both doors show the number. Use the same publicOnly gating the page uses for a guest.
Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs