The web repo's role glossary (components/RoleGlossary.tsx in agentcount-web) still tells readers the minter is "not stored" and that "capturing it is on the sweeper backlog". That is now only half true: migration 0013_minter_capture.sql (schema 6, 2026-07-30) added minter, registration_tx_hash and registration_block to agent_snapshots, and new sweeps populate them. But the population is inconsistent in two ways: the registration scan is best-effort per run, so one failed scan silently leaves the entire run's minters NULL (crates/sweeper/src/main.rs, "registration scan failed … minter will be null for this run"), and the backfill the migration explicitly deferred ("Backfill is a separate job; new sweeps populate it") does not exist — crates/sweeper/src/bin/ has delta, export-run, heartbeat and liveness, and no backfill.
Scope: populate the minter consistently from the registration transaction. A backfill binary that fills the three columns for existing snapshot rows (evidence-first, per 0013's column comments: store the tx hash and block so the claim is re-derivable), and make a per-run scan failure recoverable rather than all-or-nothing.
Where to look
migrations/0013_minter_capture.sql — the columns, their semantics (NULL = "not captured", never "no minter"), and the deferred-backfill notecrates/sweeper/src/main.rs — the registration scan and minter resolution (the minters map and its failure path)crates/chain/src/registry.rs — the registration-transaction read that resolves the fromcrates/sweeper/src/bin/ — where the backfill binary belongs, alongside delta.rs and liveness.rs- agentcount-web
components/RoleGlossary.tsx — the glossary row that gets to change once the data is actually there
Done when
The web repo's role glossary (
components/RoleGlossary.tsxin agentcount-web) still tells readers the minter is "not stored" and that "capturing it is on the sweeper backlog". That is now only half true: migration0013_minter_capture.sql(schema 6, 2026-07-30) addedminter,registration_tx_hashandregistration_blocktoagent_snapshots, and new sweeps populate them. But the population is inconsistent in two ways: the registration scan is best-effort per run, so one failed scan silently leaves the entire run's minters NULL (crates/sweeper/src/main.rs, "registration scan failed … minter will be null for this run"), and the backfill the migration explicitly deferred ("Backfill is a separate job; new sweeps populate it") does not exist —crates/sweeper/src/bin/hasdelta,export-run,heartbeatandliveness, and no backfill.Scope: populate the minter consistently from the registration transaction. A backfill binary that fills the three columns for existing snapshot rows (evidence-first, per 0013's column comments: store the tx hash and block so the claim is re-derivable), and make a per-run scan failure recoverable rather than all-or-nothing.
Where to look
migrations/0013_minter_capture.sql— the columns, their semantics (NULL = "not captured", never "no minter"), and the deferred-backfill notecrates/sweeper/src/main.rs— the registration scan and minter resolution (themintersmap and its failure path)crates/chain/src/registry.rs— the registration-transaction read that resolves thefromcrates/sweeper/src/bin/— where the backfill binary belongs, alongsidedelta.rsandliveness.rscomponents/RoleGlossary.tsx— the glossary row that gets to change once the data is actually thereDone when
minter,registration_tx_hashandregistration_blockfor existing snapshot rows from the registration transaction, leaving NULL only where the chain genuinely has nothing