samiandClaude Sonnet 5
d3ab00d67c
DAEMON's rebase audit caught it: TaskDetail.effectiveBufferBytes said "the daemon reduces every live segment's buffer" to fit maxTotalBufferBytes, but ADR 0011's ownership table (line 55) assigns bufferBytes/maxTotalBufferBytes to CORE in bytes-units -- DAEMON counts tasks, CORE counts segments and bytes. "The engine" is correct. Same error, same root cause, in DownloadSpec.segments: "the daemon lowers it to the per-host cap" attributes the per-host *segment* cap to DAEMON, but that's CORE's (ADR 0011 line 54, "CORE enforces per-host segment caps -- it owns the connections and is the only place segments are counted"). DAEMON's own per-host cap is a *task*-level admission cap (line 50), a different thing entirely -- conflating the two in the schema's own prose is exactly how the clamp ends up implemented twice, once in each lane, disagreeing. Description-only, no version bump: the JSON Schema shape is untouched, only which component the prose names as doing the reducing. Regenerated code diffs are comment-only (doc comments in the generated header and TS types). Checked every other buffer/segment-clamp description for the same mistake; the rest either already said "CORE"/"the engine" or used passive voice that doesn't misattribute (Settings.connection.maxTotalBufferBytes, Settings.connection.bufferBytes, docs/04, ADR 0012). Co-Authored-By: Claude Sonnet 5 <[email protected]> Claude-Session: https://claude.ai/code/session_012fgjnqFCS5h5L7gZTZo3rV
Owner: lane EXT. See ../docs/agents/AGENT-EXT.md and ../docs/05-extension-spec.md. Firefox MV3, TypeScript. Zero download logic.