The db-size alarm names the five largest tables, their bytes and rows, and the freelist bytes, in its sentence and its Sentinel issue #12057

The db-size and db-growth alarms now name what fills the database. Once a walk of the file exists, the alarm sentence lists the five largest tables with their size and row count, and the freelist, with the time of the walk. For example: The database is 4.6 GiB, past the 2 GiB Bun maps: as of 13:00Z its largest tables are run_log 2.1 GiB (3.2M rows), event 812 MiB (41k rows), …; 410 MiB free. With no walk yet, the sentence stays as it was (…; /system names its largest tables.).

• src/system/db_size.ts:

- dbSizeNeed(fileBytes, growth, walk = null) takes the walk as an optional third argument. A new walkSaid writes the table list: sizes from 1 GiB up are in GiB to one decimal, smaller ones in whole MiB, and rows read like 812 / 41k / 3.2M. - The cache has a new last(db, dataDir). It returns the last walk without waiting, and starts a new walk in the background when the last one is over an hour old.

• src/kernel/vitals.ts: the walk is asked for only while a db alarm is firing. So the first time the alarm fires, a walk starts even if nobody opens /system. Tests can pass a fixed walk through a new dbWalk input. The Sentinel issue already quotes the vitals sentence as its sentence: evidence, and an open alarm's sentence is updated in place. So the next db-size issue carries the tables with no change to sentinel.ts.
• Not changed: /system and the TUI system screen call dbSizeNeed without the walk. They already show the full top-ten table right under the alarm, and repeating five of those tables in the alarm line would only duplicate it. Their existing tests pass.
• Possible noise: the time in the sentence changes after each hourly walk. That rewrites the open alarm's sentence, so Sentinel may post a fresh "still degraded" comment more often than before. I haven't checked how often.

Tests in test/db-size.test.ts:

• the sentence for a fixed six-table walk, for both alarms;
• the fallback with no walk, or a walk with no tables;
• the vitals passing the walk through, and asking for it only while the alarm fires;
• last starting the first walk, then returning the walk it cached.

bun scripts/gate.ts, bun x tsc --noEmit, and nine test files (132 tests) pass: db-size, tui-system, vitals, vitals-degraded, flow-vitals, sentinel, health-vitals-reuse, system-parts and timers-named. scripts/fast.ts called the diff too broad for it to pick tests, because it touches vitals.ts, so I chose those files myself.

To try it: bun test test/db-size.test.ts.

🤖 Generated with Claude Code

Closes #12051

The db-size and db-growth alarms now name what fills the database. Once a walk of the file exists, the alarm sentence lists the five largest tables with their size and row count, and the freelist, with the time of the walk. For example: The database is 4.6 GiB, past the 2 GiB Bun maps: as of 13:00Z its largest tables are run_log 2.1 GiB (3.2M rows), event 812 MiB (41k rows), …; 410 MiB free. With no walk yet, the sentence stays as it was (…; /system names its largest tables.).

• src/system/db_size.ts:

- dbSizeNeed(fileBytes, growth, walk = null) takes the walk as an optional third argument. A new walkSaid writes the table list: sizes from 1 GiB up are in GiB to one decimal, smaller ones in whole MiB, and rows read like 812 / 41k / 3.2M. - The cache has a new last(db, dataDir). It returns the last walk without waiting, and starts a new walk in the background when the last one is over an hour old.

• src/kernel/vitals.ts: the walk is asked for only while a db alarm is firing. So the first time the alarm fires, a walk starts even if nobody opens /system. Tests can pass a fixed walk through a new dbWalk input. The Sentinel issue already quotes the vitals sentence as its sentence: evidence, and an open alarm's sentence is updated in place. So the next db-size issue carries the tables with no change to sentinel.ts.
• Not changed: /system and the TUI system screen call dbSizeNeed without the walk. They already show the full top-ten table right under the alarm, and repeating five of those tables in the alarm line would only duplicate it. Their existing tests pass.
• Possible noise: the time in the sentence changes after each hourly walk. That rewrites the open alarm's sentence, so Sentinel may post a fresh "still degraded" comment more often than before. I haven't checked how often.

Tests in test/db-size.test.ts:

• the sentence for a fixed six-table walk, for both alarms;
• the fallback with no walk, or a walk with no tables;
• the vitals passing the walk through, and asking for it only while the alarm fires;
• last starting the first walk, then returning the walk it cached.

bun scripts/gate.ts, bun x tsc --noEmit, and nine test files (132 tests) pass: db-size, tui-system, vitals, vitals-degraded, flow-vitals, sentinel, health-vitals-reuse, system-parts and timers-named. scripts/fast.ts called the diff too broad for it to pick tests, because it touches vitals.ts, so I chose those files myself.

To try it: bun test test/db-size.test.ts.

🤖 Generated with Claude Code

The db-size and db-growth alarms now name what fills the database. Once a walk of the file exists, the alarm sentence lists the five largest tables with their size and row count, and the freelist, with the time of the walk. For example: The database is 4.6 GiB, past the 2 GiB Bun maps: as of 13:00Z its largest tables are run_log 2.1 GiB (3.2M rows), event 812 MiB (41k rows), …; 410 MiB free. With no walk yet, the sentence stays as it was (…; /system names its largest tables.).

• src/system/db_size.ts:

- dbSizeNeed(fileBytes, growth, walk = null) takes the walk as an optional third argument. A new walkSaid writes the table list: sizes from 1 GiB up are in GiB to one decimal, smaller ones in whole MiB, and rows read like 812 / 41k / 3.2M. - The cache has a new last(db, dataDir). It returns the last walk without waiting, and starts a new walk in the background when the last one is over an hour old.

• src/kernel/vitals.ts: the walk is asked for only while a db alarm is firing. So the first time the alarm fires, a walk starts even if nobody opens /system. Tests can pass a fixed walk through a new dbWalk input. The Sentinel issue already quotes the vitals sentence as its sentence: evidence, and an open alarm's sentence is updated in place. So the next db-size issue carries the tables with no change to sentinel.ts.
• Not changed: /system and the TUI system screen call dbSizeNeed without the walk. They already show the full top-ten table right under the alarm, and repeating five of those tables in the alarm line would only duplicate it. Their existing tests pass.
• Possible noise: the time in the sentence changes after each hourly walk. That rewrites the open alarm's sentence, so Sentinel may post a fresh "still degraded" comment more often than before. This is not checked.
• Gate fix: the first push failed the gate's 100-column rule for comments on the dbWalk doc comment in vitals.ts; the second commit rewraps it. The gate checks committed files, so its local run before the first commit missed this.

Tests in test/db-size.test.ts:

• the sentence for a fixed six-table walk, for both alarms;
• the fallback with no walk, or a walk with no tables;
• the vitals passing the walk through, and asking for it only while the alarm fires;
• last starting the first walk, then returning the walk it cached.

On the first commit, nine test files (132 tests) passed: db-size, tui-system, vitals, vitals-degraded, flow-vitals, sentinel, health-vitals-reuse, system-parts and timers-named. scripts/fast.ts called the diff too broad for it to pick tests, because it touches vitals.ts, so I chose those files myself. After the rewrap, bun scripts/gate.ts, bun x tsc --noEmit, and db-size, vitals and vitals-degraded (43 tests) pass.

To try it: bun test test/db-size.test.ts.

🤖 Generated with Claude Code