Changes touching this path

• the shipper gets the entry point a timer will run, and the reviews caught three defects in it that no gate could: an unreadable log read as a CLEAN RUN, because open swallowed every error and the caller skipped the file - so an EACCES on www-data adm 0640, which is the precise hazard the whole runtime-home decision exists to handle, produced scanned zero, failed false, exit zero, indistinguishable from a fresh box. only absence is swallowed now and a permission error is rethrown, with a control asserting a genuinely missing file is still skipped, since every box before its first rotation has no .1. the second was a rotation-sized race in the middle of the file source: stat by name then open by name lets logrotate rename between the two calls, so the read lands on the NEW inode bytes and they are committed under the OLD inode position - a double count and a misattribution at once, and scheduled rather than theoretical since rotation is unconditional and daily. a handle is bound to an inode rather than a name, so the source opens once and measures and reads through that same handle, which makes the race unrepresentable instead of unlikely. the third would have broken every land and every deploy: build:shipper invokes esbuild, which was in overrides and in NEITHER dependency list, resolving only as vite transitive binary - and putting that step inside build made the gate depend on an undeclared one. declared now, matching the override range rather than pinned exact, which npm refuses as a conflict. found by RUNNING the bundle rather than building it: bundled to esm it compiles clean and dies at startup on Dynamic require of pg, which is CommonJS - and external is no escape because the image has no node_modules at all since nitro bundles its own into server libs. it is cjs, pinned four ways including that the step runs AFTER vite build, since vite writes .output and an earlier step would have its artifact deleted silently. two doc claims are narrowed rather than left standing, both mine and both the catalogued class: the entry said what the timer runs in the present tense with no timer anywhere, and credentials.ts said the site has no one entry point this module owns, which was true of the serving process and became false of the deployment the moment a one-shot binary existed. and two of my own assertions are DELETED rather than kept, because they were strict consequences of the set-equality above them and could not fail while it passed - decoration that read like coverage (#1756) 0c0385a8 · dbf3dbe6…
• the failure signal is judged per FILE rather than per run, because one healthy log was answering for a broken one, and both halves of the old condition are shown wrong by reverting them rather than argued: the code that landed an hour ago in #1778 set failed once at the end of the run, bytesConsumed greater than zero and inserted equal to zero, which means the forge log parsing normally while the site log refuses every line reports SUCCESS - inserted is positive because of the forge, the busier surface goes dark, and the one signal built to tell an empty dashboard apart from a quiet site is the thing that hides it. the two logs are written by the same nginx stanza but rewritten per vhost, so diverging one vhost at a time is how this actually arrives rather than a hypothetical. the second half is the opposite error. bytes and no rows also describes a file holding only blank lines, and shipFile skips those with a bare continue without counting them as refusals - so nginx touching a log was a format break. the predicate now requires that something was actually REFUSED, which is the evidence that we read something and failed to read it: understoodNothing is inserted equal to zero AND at least one refusal, evaluated on each ShipReport before its counts are summed away into the run total. blank lines refuse nothing and are not a failure; a format change refuses everything and is. both were verified by mutation rather than by passing. restoring the exact run-wide expression that shipped turns BOTH new tests red at once, which is the demonstration that neither defect was theoretical, and dropping only the refusal term turns only the blank-line control red, which is the demonstration that the two terms are independent rather than one of them decorative. main gets its exit code pinned for the first time, and the mapping is the only teeth any of this has - failed is inert unless something acts on it, and the single thing that does is what systemctl sees. it was untested because main could only run against a live Postgres, so the writer becomes a parameter with the production default beside it, the same shape logDir already had; mutating the return to a constant zero turns exactly one test red. four cases: exit 1 on a log understood not at all, exit 0 on a healthy run, exit 0 on an empty box, and the writer closed even when the run throws mid-batch - that last one written against a writer whose commitBatch rejects, because a first version pointed at a missing directory and never threw at all, which would have asserted the finally clause runs on the path where nothing went wrong. two cleanups from the same review. a duplicated pair of assertions in the bundle-format block, where the earlier copy carried a comment reading build:shipper sits inside , so - the backticked word eaten by an inline edit, and vitest permits two it blocks of the identical name in one describe, so nothing reported either the duplication or the damage. and the FAILED line and three doc comments still described the old run-wide condition in words, which is the scope-drift class this repo keeps catching: a true-sounding sentence that outlived the code under it (#1756) c1629576 · dbf3dbe6…diff
• site/test is type-checked by a project of its own that the site gate already runs, so a test that has drifted against the module it imports refuses a land instead of passing. tsc -b reached src through tsconfig.app.json and vite.config.ts through tsconfig.node.json, and site/test was in neither, so the gate ran those files and never checked them: a type error surfaced there only where it was also a runtime error. site/tsconfig.test.json is referenced from site/tsconfig.json, so npm run typecheck, inside npm run build, inside npm run gate, now reaches them. it is a separate project because vitest runs the tests on node while tsconfig.app.json holds src to an ES2020 browser floor, it includes src because src/routeTree.gen.ts carries the augmentation that types createFileRoute, and it sets allowJs because two tests import tools/budget.mjs; vitest.config.ts joins vite.config.ts in the node project. the first run was a survey and it was not clean: 8 errors over 5 files, every one fixed rather than suppressed, with no ts-expect-error owed and no option loosened. three fake MetricsWriters never learned the saltFor that #1620 added to the interface, private-diff built two outcomes on a LockReason of no-key the union does not contain, private-grants read .reason off a KeyLookup without narrowing to the arm that carries one, and budget-record read an optional reason as a string. proved live: a satisfies number[] on the cli-verbs row list is invisible to the runtime, 7 passed and exit 0 under vitest alone, while npm run gate exits 2 at npm run typecheck before vite build, the suite and the budget ever run. red under mutation: that same error with the new reference dropped is 0 errors and exit 0, saltFor dropped from a fake is 1 error, no-key put back is 2 errors, src dropped from the include is 1 spurious src error, allowJs dropped is 2 errors, the lib put back to ES2020 is 6 errors, and an Array.at added to src is 1 error from the app project, which still decides what src may use. the site gate is green end to end: 643 tests passed and 60 skipped over 52 files, 62 surfaces all under ceiling with nothing recorded. ADR 0071 gains the amendment and a corrected consequence, and CONTEXT.md its site gate line. no migration, no wire or format byte moves and no forge or relay byte moves, so this owes no deploy. the workspace suite is green (3952 passed over 122 binaries, 7 ignored) (#1877) 4290f819 · dbf3dbe6…diff

Renames are not followed. loot's tree maps a path to an address, so a rename is a delete and an add. This list is the history of the name, not of the bytes.