codebase-snapshot

chore: record weekly search positions

76d9e8e · 11/9/2026

docs: 0.9.16 -- the lock a refused run kept, and a suite that leaves nothing The release commit for the two changes below: version 0.9.16 in package.json, package-lock.json, packages/create/package.json and src/version.ts, the changelog entry, and the documentation spans that state the current version. Fixed since 0.9.15: - a generate run that was refused by the second lock released neither lock, leaving a lock file that named the current, live pid -- so later runs in the same process (MCP

7f1027f · 11/8/2026

test: the leak fixture is ESM on every supported Node The deliberate-leak child test was written as a .js file in a directory with no package.json. Node 18 therefore loaded it as CommonJS, the import statements threw, and the child exited 1 before it could leak anything -- the assertion in the parent failed on Node 18 in CI. Naming it .test.mjs makes the file ESM on every runtime the project supports, so the test exercises the leak it describes instead of passing for the wrong reason on a newer

eb91943 · 11/8/2026

fix: a run refused by the second lock releases the lock it took A generate run locks both the staging root and the output directory, in sorted order. When the second acquisition was refused, the first lock was never released: the release list came from a single map() that threw before the assignment, so the finally had nothing to run. The leftover lock names the current, live pid, so reclaimStaleLock treats it as an active run and every later generate in that process -- an MCP server, watch mod

5ade41a · 11/8/2026

test: the suite stops leaving its scratch directories behind npm test created every fixture in the host temp directory and relied on each test to remove it. Two tests never did: agent-simulation.test.js made two fixtures per run with no cleanup, and one repo() argument in generation-truth.test.js was never assigned, so its directory could not be removed. Five days of runs had left 616 directories and about 600 MB behind. The suite now runs through scripts/test-run.mjs, which points TEMP, TMP a

0678c46 · 11/8/2026

chore: stop secret scanners alerting on the fixtures they exist to test This repository is a secret-redaction engine, so its test suites, its rule definitions and its documentation all contain credential-shaped strings on purpose. They are the vectors the engine detects, they cannot authenticate against any service, and they exist so detection can be proved. A scanner that scans this repository is therefore guaranteed to find them - and GitGuardian scans the whole history, so every occurrence i

e39d4e0 · 11/8/2026

fix: close the three known limitations, and the two an independent pass found Follow-up to 0.9.15 while it is still unreleased. The changelog had listed three known limitations; an independent red-team pass against the built artifact then found two more defects in the redaction work. All five are closed here rather than documented as known, because a release note that documents a leak is still a leak. Closed: - parsePartSections read the line counts from the whole metadata line instead of t

79b0a18 · 11/8/2026

fix: the sixth audit, and the seven promises it found unkept A sixth audit of codebase-snapshot, aimed at the promises rather than the paths the suite already covers. Release 0.9.15. Every defect below lived somewhere `npm run verify` did not look, and each now has a regression test that fails without the fix. - Two credential shapes reached the artifact. A quoted camelCase key in JSON or YAML (`"dbPassword": "hunter2"`, `"discordToken"`, `"jwtSecret"`) was never redacted, because the quo

955ed0f · 11/8/2026

test: the read-only backup needs no second cleanup hook node:test runs after hooks in the order they were registered, so the one makeRepo added removes the tree first and a hook of mine cannot run at all — it failed with ENOENT on a directory that no longer existed. The modes are restored immediately after the second run, which is the only place that knows they were changed, so the hook is gone.

7d596f9 · 11/7/2026

test: the read-only backup is restored before anything can clean up `t.after` hooks are not ordered relative to the one `makeRepo` registered, so the recursive delete reached the 0555 backup directory first and failed with EACCES — reported as a hook failure, which reads as a broken test rather than as the cleanup it was. The modes are put back immediately after the second run now, before any assertion, so the order does not matter. Found by the second release attempt on the Node 18/20/22 matr

d3faee3 · 11/7/2026

fix: what the release matrix found, and the read-only output directory The 0.9.14 release ran the verify gate on Node 18, 20 and 22 — the first time these five behaviours were exercised on Linux at all. It found four failures in the tests and one in the tool. The tool: a read-only output directory no longer fails the run. A directory this generator owns can be renamed whatever its own mode is, so the new snapshot *is* installed; what cannot happen is deleting the old one. 0.9.14's swap fix mad

fdf2609 · 11/7/2026

test: two portability fixes a release would have found `import.meta.dirname` is Node 20.11+; the release workflow verifies on 18, where it is `undefined` and `path.join` throws — so the file would have failed on the matrix and nowhere else. Every other test in this repository uses `fileURLToPath` for the same reason. The read-only-directory reproduction now proves its own trigger. A host that does not enforce directory permissions — root in a container, or a filesystem that ignores the mode —

1fe882e · 11/7/2026