id: implement: hot-world signals — write-locality metrics + sustained-threshold detector

Parent: #2059 (hot-world sharding investigation, ID epic #2056). Filed from the #2059 investigation (doc: ~/workspace/id-program-2026-10-28/investigations/hot-world-sharding.md, §2/§5).

Problem

The hot-world sharding triggers in #2059 need two things pkgs/id does not have yet:

Write-locality data. WorldMetrics (pkgs/id/src/world/metrics.rs) records command/journal latency, queue depth, and sessions, but no per-topic/per-region write split — so the rung-1 (topic partition) vs rung-2 (region shard) vs rung-3 (native spill) decision cannot be made from evidence: all three triggers depend on whether writes concentrate in one topic/region.
A signal consumer. Nothing evaluates MetricsSnapshot against sustained thresholds (rate vs ceiling, actor_queue_depth_max growth, latency bands over 10-minute windows). Detection today would be a human reading id world stats.

Scope

Add a bounded write-locality counter to WorldMetrics (per-topic or per-region write counts, fixed-size / top-K so recording never allocates on hot paths, matching the existing metrics design), surfaced in MetricsSnapshot.
Add a threshold evaluation over snapshots (sustained-window, spike-resistant) that reports a world's hotness band (healthy / warning / critical) plus which signal fired, consumable from id world stats.

Acceptance criteria

MetricsSnapshot carries write-locality counts with no allocation/locking on the record path (same discipline as existing fields).
Hotness-band evaluation exists with tests covering: sustained critical, spike-does-not-trigger, and queue-growth detection.
id world stats surfaces the band and the firing signal.
No change to world semantics, journal format, or the serial actor model.

Program: ID wave-1 follow-on from #2059; the design/synthesis consumer is #2046 (serverless edition v1), which stays gated on its named inputs.

CODE-1136

Intake review — fleet monitor, 2026-10-29

Related: parent id: investigate: hot-world sharding — when one world outgrows one Durable Object #2059 (hot-world sharding investigation), epic epic: ID platform expansion — apps, comms, currency, hosting, boards (2026-10-28 directive, LIST 6–15) #2056; investigation doc §2/§5 linked in the body.
Still live: filed today from the id: investigate: hot-world sharding — when one world outgrows one Durable Object #2059 investigation; no metrics/detector implementation exists yet.
Notes: body already carries acceptance criteria; none appended.
Risks: threshold tuning is the open-ended part — a detector that fires constantly is worse than none. Prefer shipping the metrics first with the detector behind a conservative sustained-threshold default.
Suggested approach: write-locality metrics first (observable, no behaviour change), detector second with thresholds from the id: investigate: hot-world sharding — when one world outgrows one Durable Object #2059 doc's numbers.
Labels normalized: kind/enhancement, source/human, priority/normal, effort/m, status/needs-triage, meta/enriched.

Refinement from the #2059 investigation doc review (PR #2820, Codex finding, verified against the code): the hotness detector in this issue must not trigger on actor_queue_depth_max. That metric is a lifetime high-water mark — WorldMetrics::record_queue_depth (pkgs/id/src/world/metrics.rs) uses fetch_max, and MetricsSnapshot never resets it — so after any large burst it can neither show queue growth inside a window nor show recovery. The detector should sample actor_queue_depth per snapshot (trend across 3+ snapshots, per the investigation §2 bands) and/or compute a windowed maximum itself. The landed doc (doc/2026-10-30T19-35-00Z_investigation_hot_world_sharding/, §2 caveat) states this; carrying it here so the implementation spec doesn't have to rediscover it.

🤖 Agent note · done

Agent: queue worker (repo-worker-code), lane code-g
Session / ID: task 7884 (triage); follow-up implementation: task 8498
Found via: queue claim
Task: Triage issue id: implement: hot-world signals — write-locality metrics + sustained-threshold detector #2275 at current main — verdict: still live, confirmed unimplemented, implementation routed.

Evidence (fresh, 2026-11-03):

pkgs/id/src/world/metrics.rs at main: WorldMetrics record methods are record_command, record_journal_append, record_checkpoint, add_frame_bytes, record_queue_depth only. MetricsSnapshot carries latency histograms, totals, frame_bytes_total, actor_queue_depth, actor_queue_depth_max, sessions — no write-locality counts, and no hotness-band evaluation exists anywhere in pkgs/id (code search finds write-locality/hotness only in the investigation/design docs).
PR search for id: implement: hot-world signals — write-locality metrics + sustained-threshold detector #2275: only PR doc: investigation — hot-world sharding (#2059) #2820 (the merged id: investigate: hot-world sharding — when one world outgrows one Durable Object #2059 investigation doc). No implementation PR or branch exists; nobody owns this work.
The 2026-10-30 refinement on this issue (comment 6532029493) is carried into the follow-up packet verbatim: the detector must not trigger on actor_queue_depth_max (lifetime high-water mark, fetch_max, never reset) — it samples the actor_queue_depth gauge trend across 3+ snapshots and/or computes a windowed maximum.

Routing: implementation enqueued as task 8498 (small_fix, priority 30) with the issue's four acceptance criteria as its acceptance list, including the gauge-trend constraint and the sustained-critical / spike-does-not-trigger / queue-growth tests. Issue #2275 stays open; status/needs-triage removed, queue/queued kept for task 8498.

Expectation: done for triage; implementation proceeds under task 8498.
Links: task 8498 · parent id: investigate: hot-world sharding — when one world outgrows one Durable Object #2059 · investigation PR doc: investigation — hot-world sharding (#2059) #2820

agent-note:v1
state: triaged (coverage pass)
Coverage pass 2026-11-03: reviewed in the fleet-wide per-issue pass (drift / overlap / already-handled / stale / blockers / ordering). Verdict: still live; queued in repo-health-code-pilot as triage at priority 40 (priority/normal). If this is already handled at current main, the triage closes it with evidence; if it needs splitting, the triage files the split.
Found via: coverage pass 2026-11-03

Agent note — implementation complete, PR prepared in the action outbox

Task: task 8498 (repo-health-code-pilot, lane I / code-i shift, 2026-11-03).
Implemented on branch queue/8498-2275-hot-world-signals (commit 0e9e83f, pushed): bounded write-locality table in WorldMetrics surfaced in MetricsSnapshot.write_locality (entity-addressed writes record their entity_ref at the journal record path), and the sustained hotness evaluator in world/hotness.rs (queue-gauge trend, sustained latency p95 bands, window-average command rate; never actor_queue_depth_max), retained-window evaluation in every snapshot so id world stats surfaces hotness with the band and firing signals.
PR creation was blocked by GitHub's secondary rate limit; the fully prepared PR is in the action outbox and this note is posted by the outbox processor with the PR link: feat(id): hot-world signals — write-locality metrics + sustained-threshold detector (#2275) #5039
Tests (laptop): world:: suite 220 passed; full pkgs/id lib suite minus the cli:: cluster 1876 passed / 2 failed, both failures pre-existing on a clean baseline (shell-contract drift, fixture hash drift), as are the cli::* stack-overflow aborts on this laptop.

🤖 Agent note · escalated

Agent: fleet monitor (repo-fleet-monitor)
Session / ID: repo-fleet-monitor run 2026-11-05 20:12 CST
Found via: monitor reconciliation (in-progress tracker, Duty 3)
Task: Escalation — this issue still carries + with no live queue claim, and has had no activity since 2026-11-03 (~55 hours, past 2x the deadline for effort classes xs/s/m). The latest agent notes from 2026-11-03 suggest the work was completed/triaged then, but the terminal label cleanup never happened and the issue is still open.
Expectation: reviewer (Muse, per the flow) confirms whether the 2026-11-03 outcome closed the work: if done, remove the stale lifecycle labels and close or re-scope the issue; if not done, requeue — swap labels to + and enqueue a fresh triage packet. The monitor did not auto-requeue because the last notes claim completion.

Correction to the fleet monitor escalation note above (its label names were stripped by a shell substitution error when posting): the stale labels on this issue are queue/claimed + work/assigned; the requeue path, if the reviewer finds the work is not done, is to swap them to queue/queued + status/needs-triage and enqueue a fresh triage packet; user/review was added by that note.

Navigation Menu

Repository navigation

id: implement: hot-world signals — write-locality metrics + sustained-threshold detector #2275

Problem

Scope

Acceptance criteria

5 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

id: implement: hot-world signals — write-locality metrics + sustained-threshold detector #2275

Description

Problem

Scope

Acceptance criteria

Activity

developing-today commented on Oct 29, 2026

dezren39 commented on Oct 29, 2026

dezren39 commented on Oct 30, 2026

dezren39 commented on Nov 3, 2026

5 remaining items

developing-today commented on Nov 3, 2026

developing-today commented on Nov 3, 2026

developing-today commented on Nov 6, 2026

developing-today commented on Nov 6, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions