Phase 1 of the IDE-session-type normalization, and it is a disciplined one. The idemetadata leaf package gives the agent and server a single app-name vocabulary (pinned against drift by TestFamilyKeysAreCanonical and TestCodersdkUsageAppNamesAreCanonical), the read-query rewrites correctly split into fan-out-tolerant hash joins (DISTINCT/MAX) versus per-row LATERAL pre-aggregation (where connection_count is summed alongside), the batcher's JSONB side-buffer mirrors the established connections_by_proto pattern with a lock-protected positional zip, and the syncmap.LoadOrStore fix is a real correctness fix (the wrapper previously returned the zero value on store, which would have handed getOrCreateConnCounter a nil *atomic.Int64). The old-agent conversion path is the single, well-tested apex. As Killua put it: "The hot paths earn a shrug."

Severity count: 0 P0/P1, 1 P2, 4 P3, 11 Nit, 8 Note.

The P2 is a test gap on the exact code the PR calls its #1 risk: the batcher session-count flush runs green with no assertion on any session-count value. The P3s cluster around the newly-opened name space: an agent-side counter map with no bound (CRF-1), a reconnecting_pty key that the SSH path and the PTY server both write with last-writer-wins (CRF-3), a silent overflow fold with no operator signal (CRF-4), and a "surfaces unchanged" premise that is already false at the usage API and CLI in phase 1, not phase 5 (CRF-5). None are reachable by well-behaved first-party clients today, but this PR's whole point is that arbitrary names start flowing later, and there is no follow-up author to revisit them then.

One thing to flag directly: the author-agent's own review comment posted four findings above Nit (B1 Blocker, M2/M3/M4 Major) and none of them reproduce. B1 claims an INNER->LEFT JOIN change in GetWorkspaceAgentUsageStatsAndLabels, but the base query already used LEFT JOIN latest_agent_stats. M2's minute_buckets overcount cannot happen because the child PK (workspace_agent_stats_id, app_name) guarantees one row per app per stats row. M3's has_connection regression does not occur because the base query already filters to rows with a positive session count before MAX(connection_count), which the new INNER JOIN reproduces. M4's uncapped-fallback claim is wrong because SessionCountsFromProto returns capSessionCounts(counts) for both branches. The independent panel verified each against the base SHA. Worth calibrating the self-review's confidence before those land as blockers on a human.

Process note: the PR description points reviewers at migration 000543_* twice (the NOTE and the file-by-file table), but the shipped files are 000544_*; 000543 is an unrelated chat_status_remove_unused migration. A rebase bumped the number and the description was not updated. Please fix both references so a reviewer grepping by number lands on the right file.

coderd/workspacestats/batcher_internal_test.go:77

P2 [CRF-6] The batcher's session-count flush path executes under test but no session-count value is ever asserted. (Bisky)

DBBatcher is the only caller that runs SessionCountsFromProto, marshals the sessionCounts side-buffer, and depends on the positional zip in InsertWorkspaceAgentStats (the PR's stated #1 risk). randStats sets the deprecated fields, so the child insert does run, but every assertion in TestBatchStats is a row count. Nothing reads a session count back.

The other suites do not close this: querier_test.go seeds through dbgen (bypasses the batcher) and cli/ssh_test.go/vscodessh_test.go assert against the workspacestatstest.StatsBatcher fake that never inserts or normalizes. A marshal/zip regression (empty slice, off-by-one, wrong buffer, mis-position) on the highest-risk code in the PR ships green. Make a deterministic second flush carry a known session-count map and assert the stored value back.

🤖

🤖 This review was automatically generated with Coder Agents.

Round 2. All 23 round-1 findings are addressed, and the panel verified each fix against the tree rather than trusting the resolution. The standouts: CRF-6's batcher test now flushes distinct per-agent maps and asserts they round-trip normalized with zeros dropped (the PR's #1 stated risk finally has a real assertion), and the CRF-20 O(fleet) scan is fixed by construction, not just by comment. The new created_at column is copied positionally from the parent row on every write path (batcher, backfill, dbgen), so the added sc.created_at BRIN filters are redundant-for-correctness and only prune blocks; the windowed results stay byte-identical. Nice work turning a scale note into a structural fix.

Severity count this round: 0 P0/P1, 2 P3, 4 Note, 3 Nit (1 finding dropped on cross-check). Nothing blocks; using COMMENT.

The two P3s are two sides of one guarantee, that well-known session types survive the 64-entry cap. CRF-26 is the live one: the agent-side cap added for CRF-1 does not mirror the server-side cap it cites. The server sorts well-known names first and keeps them; the agent folds by arrival, so once 64 distinct types have ever been seen, a lazily-created ssh or vscode counter can be routed into unknown and its minutes drop out of every canonical read. Two reviewers rated it P3 and four more converged as Note; I verified the agent code lacks the known-first branch. CRF-25 is the same guarantee on the server side, where the code is correct but the preserve-well-known branch is untested (Bisky proved neutering the sort keeps the test green). Fixing both is cheap: exempt the five known-family names from the agent fold, and add a server test with 64 names that sort before a canonical name.

The BRIN design is the right call, but two honesty notes: the PR-body benchmark rows (98.9 ms rollup, 659 ms insights) predate the BRIN by the author's own admission, so they describe code that no longer ships and should be re-measured; and the steady-state prune benefit is unverified, with a plausible correlation-decay path under cascade-delete + vacuum churn (CRF-27). As Hisoka signed off: "When code fights back this well, I don't manufacture a rematch."

agent/agentssh/metrics.go:50

Note [CRF-32] The magic_type Prometheus label now carries the app family, not the raw session type, and nothing at the metric definition says so. (Leorio)

magicTypeMetricLabel was rewritten [...] to return idemetadata.Family(...). Before this PR, a session type the agent didn't recognize landed under magic_type="unknown"; now every alias folds into its family, so agent_sessions_total{magic_type="vscode"} will start counting Cursor, Windsurf, Positron, VSCodium, Kiro, Devin, and the rest the moment an SSH client sends one of those values.

The metric name stays byte-identical and the canonical four are unchanged in phase 1, so this is latent until phase 5. But the two NewCounterVec definitions declaring []string{"magic_type", "pty"} say nothing about the semantic shift, and an operator's existing dashboard query silently changes shape when family folding goes live. A one-line comment at the metric definitions noting the label is family-valued would prevent the 2 AM surprise.

🤖

🤖 This review was automatically generated with Coder Agents.

Round 3: the fixes are strong. Eight of the nine round-2 findings are handled: the agent cap now protects known-family types and only folds genuinely-unknown overflow with a debug log (CRF-26), the server cap gained a real preservation test with 100 junk names sorting before ssh (CRF-25), the over-cap Warn moved to the normalized pre-cap count (CRF-24), the batcher round-trip test now asserts child.created_at == parent.created_at (CRF-28), the cap constant is unified in idemetadata (CRF-30), the field is renamed and pointer-typed (CRF-31), and CRF-27 was re-measured toggling the BRIN with the PR body updated to state the churn caveat honestly.

One finding is unaddressed with no response, so this round is blocked pending a reply rather than spending another full panel pass:

• CRF-32 (Note, agent/agentssh/metrics.go:50): the magic_type Prometheus label now returns idemetadata.Family(...), so it carries the app family rather than the raw session type. agent_sessions_total{magic_type="vscode"} will start aggregating Cursor, Windsurf, Positron, and the rest once phase 5 clients send those values, and an operator's existing dashboard query silently changes shape. The two NewCounterVec definitions declaring []string{"magic_type", "pty"} say nothing about the shift. This was folded into the round-2 review body (the line sits outside the diff hunks), so it is easy to have missed, which is likely why it went silent.

No code or ticket is strictly required for a Note: a one-line comment at the metric definitions noting the label is family-valued would close it, or reply explaining why it should not be changed (for example, that phase 2 will re-document the metric). A bare non-response is what blocks; any of fix, ticket, or reasoned decline unblocks. Once you respond, the panel will re-engage and verify the eight round-3 fixes on encounter (they are recorded as author-claimed, not yet panel-verified this round).

No inline comments this round; review is blocked on the item above.

🤖 This review was automatically generated with Coder Agents.

Round 4, and the PR has converged. Round 3 was blocked on a single silent finding, so eight round-3 fixes had been recorded as author-claimed but never panel-verified. This round the panel verified every one of them against the code and the tests, and they are genuine, not paste. The load-bearing one, CRF-26, is correct: the agent cap now gates the fold behind idemetadata.Family(key) == AppNameUnknown, so lazily-created ssh/vscode counters always keep their own key and only genuinely-unknown types fold past the cap, with a debug log; TestSessionCountsCapped breaks if you drop the guard. CRF-25's server test finally bites (neuter the known-first sort and got["ssh"] drops to 0), CRF-24's over-cap Warn fires on the normalized pre-cap count with agent_id/reported/max, CRF-28's batcher round-trip asserts child.created_at == parent.created_at via a direct SQL join, the cap constant is unified in idemetadata.MaxSessionCountEntries, and CRF-32 (this round's change) documents the family-valued magic_type label at both metric definitions with the cardinality rationale. CRF-27's BRIN was re-measured toggling the index and the PR body now states the prune benefit plus the churn caveat honestly.

All 32 prior findings are resolved or acknowledged. Two minor, non-blocking items are new this round, neither requiring a change to ship:

As Bisky put it: "I went in expecting paste and found the real thing."

Approving. The two inline notes below are optional polish.

agent/agent_test.go:4310

Note [CRF-34] The family-valued magic_type label (this round's CRF-32 change) is only asserted end-to-end for the identity case where family equals the raw type. (Bisky)

magicTypeMetricLabel now returns idemetadata.Family(...), so a Cursor or Windsurf session should emit magic_type="vscode". The only end-to-end metric assertion feeds an ssh session and checks magic_type="ssh", which passes whether the label carries the family or the raw type; delete the family mapping and this test stays green.

Low value to add, since Family() is unit-tested in TestFamily and magicTypeMetricLabel is a one-line delegator, so the composed behavior is covered indirectly. Worth knowing, not worth blocking. If you touch this area for phase 2, a divergent-case assertion (cursor -> vscode) at the metric boundary would close it.

🤖

🤖 This review was automatically generated with Coder Agents.