[Birfy]

The decision log (<home>/decisions.jsonl) was capped to 2000 lines only when read: record() appended forever and list() parsed the whole file before discarding all but the newest 2000 lines. This bounds it on disk as well, and bounds the read.

复现

On main at abaf938b, with config.decisions: true, record 2001 decisions: the file keeps all 2001 lines and every read parses all of them. The new test reproduces that:

git checkout abaf938b -- core/src/host/decisions.js   # main source, new tests
node --test core/test/decisions.test.js
# not ok 4 - #603: record trims the log on disk, keeping the newest entries
# not ok 5 - #603: a byte cap bounds an oversized log left by an older build
# tests 5 / pass 3 / fail 2

改了谁

• core/src/host/decisions.js: record() trims the log after each append to the newest 2000 lines and at most 1 MB, through a temp file + rename (the Bot side stays append-only); list() reads at most the last 1 MB instead of the whole file.
• core/test/decisions.test.js: two tests — append 2001 entries and assert the on-disk file keeps exactly the newest 2000; an oversized log left by an older build is bounded by the 1 MB cap and the newest entry survives.
• patches/ds-bot/files/src/host/decisions.js and patches/ds-bot/files/test/decisions.test.js: mirrors (decisions.js is a FlyBot-added file, so files/ is its generated form).
• docs/subsystems/core-host.md: states the on-disk caps and the bounded read.
• changelog.d/603-decisions-log-bounded.fixed.md.

跑了什么

• node --test core/test/decisions.test.js → 5/5 pass (1.3 s), on the abaf938b tree.
• node scripts/ds-bot-patches.mjs check → ok (pin v0.1.5, 10 patches, core/ equals ds-bot/ + patches).
• node .github/scripts/changelog.mjs check → 19 fragments well formed.
• node core/scripts/check-arch-docs.mjs with ARCH_DOCS_BASE = a base commit holding main's tree → arch-docs: OK (6 changed file(s)).
• TZ=UTC DSH_HARNESS=… node core/scripts/lint.mjs → oxlint 0 errors, 43 warnings (pre-existing).

撤掉源码改动后变红

git checkout abaf938b -- core/src/host/decisions.js   # keep the new tests
node --test core/test/decisions.test.js
# not ok 4 - #603: record trims the log on disk, keeping the newest entries
# not ok 5 - #603: a byte cap bounds an oversized log left by an older build
# tests 5 / pass 3 / fail 2

With the fix restored: # tests 5 / pass 5 / fail 0.

没跑什么

core 全量一次性（本容器 pid 上限 256）、插件套件、smoke、真机、完整 npm run verify；由 CI 在 tip 上跑 tests-ok。

风险

Only core/src/host/decisions.js behaviour changed; no secrets, network, sharing or permission surface. (risk:T* is set by the controller.)

Fixes #603

[Birfy]

Verdict: PASS at 2a161c7 — tier from the diff: T2

Tip SHA: 2a161c7d411262a4a5c64009641000ce270a21a4
CI at this tip (run 39584454603): all 8 checks success —
  tests-ok, package, plugins (social|timeline|tree),
  ubuntu-latest Node 24, reviewed tip, risk tier
mergeable_state: clean
Revert-the-source evidence (from the body, checked against the new tests):
  git checkout abaf938b -- core/src/host/decisions.js; node --test core/test/decisions.test.js
  → not ok 4 (#603: record trims the log on disk) / not ok 5 (#603: a byte cap bounds …); 5 tests, 2 fail
  With the fix: 5/5 pass.

Tier: T2, not T1 — it is host code (core/src/host/) that deletes stored lines by design, so a bug in the trim path loses a Bot's recorded decisions rather than only misreporting them. It does not touch secrets, network, sharing or permission surfaces, so not T3.

I re-derived the trim logic from the patch instead of trusting the body, and it holds:

• trim() walks from the newest line backwards, stopping at KEPT lines or when adding another line would pass MAX_BYTES; the newest line is always kept even if it alone is oversized (kept.length > 0 guard), so the log can never be emptied by the cap.
• record() appends first, then trims only when linesOnDisk > KEPT || size > MAX_BYTES; linesOnDisk is counted once and then incremented, so the common path does not re-read the file on every write.
• The rewrite goes through ${path}.tmp + rename, so a reader never sees a half-trimmed log, and record() serializes every step through its own promise chain — two appends cannot interleave a trim.
• list() now reads at most the last MAX_BYTES from an oversized file and drops the partial first line, so a file left huge by an older build no longer costs a full parse.
• Both tests pin the on-disk state (2001 appends → exactly 2000 lines with the oldest gone; oversized file → ≤ 1 MB with the newest entry alive), which is the right assertion — my earlier review of the sibling PR asked for exactly this.

Nothing blocking. Two non-blocking notes for later, neither for this PR: a hand-edited single line larger than 1 MB would be kept forever and re-trimmed on each append, and writeFile(tmp) gives the rewritten log the default mode instead of preserving the old file's permissions.

This is a reproducible defect fix on the admission line, so per the gate (PASS at tip + CI green + revert-red) I am queueing it.