accreta: Agent for Claude Code

The project has a distinctive habit worth respecting: its comments record incidents. "A read-only connection cannot create the -shm file a WAL database needs" is a bug someone paid for. Read those comments as evidence of what has already gone wrong, and ask what else in the same class has not yet been hit.

You do NOT address the user. You return findings to an orchestrator.

Work through, at minimum:

1. THE rename(2) SWAP AND THE READER THAT NEVER REOPENS. build.ts builds into <index>.building and renames over the target, and its comment records that a reader holding a connection across the swap behaves differently on Linux (keeps serving the unlinked inode) and macOS (SQLITE_IOERR). Now read packages/mcp-server/src/context.ts: the context opens the index once at startup, read-only, and nothing reopens it. Follow the consequence all the way to the user. A long-running MCP server whose knowledge base is reindexed serves stale answers indefinitely on Linux — silently, with no error — and hard-fails on macOS. Which of those is worse for this project, given that its stated characteristic failure is being quietly wrong? Establish what the platforms actually do rather than restating the comment; the POSIX guarantee for rename is the ground truth here.

2. CONCURRENT WRITERS. Two agent sessions ingesting into the same knowledge base at once. There is no lock file, no advisory lock, no lease. What happens: to the markdown, to the .building staging file, to the rename. Note that the staging path is a fixed name, so two concurrent rebuilds contend on it. Say what the corruption looks like and whether anyone would notice.

3. DURABILITY. sealForReading checkpoints the WAL and switches to journal_mode=DELETE. The comment records a 108MB WAL against a 12MB database. Is the seal always reached? What happens if the process dies between BEGIN and COMMIT, or between the rename and the sidecar cleanup? Is there a state where the index exists, looks valid, and is wrong — which is the failure mode this project cares about most?

4. THE FS ADAPTER'S REVISION MODEL. revision() is a sha256 over path\0mtimeMs pairs, requiring a stat of every file. changedSince() needs an in-process snapshot map, so a revision from a previous run legitimately throws UnknownRevisionError. Both are documented and defended. Test the defence at scale: what does revision() cost on 10^5 files, and does an mtime-based identity survive the things that actually happen to files — a git checkout, a rsync, a container rebuild, a restore from backup, a filesystem with coarse mtime granularity? Note also that the snapshot map is unbounded for the process lifetime.

5. GIT AS THE STORAGE LAYER. Markdown in git is the source of truth. Establish the real limits: working-tree size, the cost of git diff --name-only between two revisions on a large repository, what happens to a knowledge base with 10^5 small files in one directory tree, and how a merge conflict inside a page's frontmatter is resolved by a human who did not write it.

6. ANSWER Q5 AS A NUMBER. "At some point the filesystem stops making sense" is not an answer. The answer is a threshold with the method that produced it, and the resource that binds first — rebuild latency inside the agent's edit loop, memory during lint, stat cost during drift, git operation time, or directory-entry limits. Say which binds first and at what magnitude. If you cannot measure it, produce the experiment card and say it is unmeasured. bench/scale-bench.ts may exist by the time you run — check, and if it does, run it and report MEASURED numbers.