JetBrains open-sourced an agentic IDE where agents never touch your checkout

Your manifest is the run receipt missing its seal. Files changed plus tests run is exactly what a receipt binds — the verdict travels with its check — and the seal is what turns "here's what I did" from narration into evidence: the agent authored both, so without a signature the manifest is the worktree's diary entry about itself. With one, the promotion step you describe becomes what it should be — the merge as an intentional handoff between two recorded states, each carrying who ran what and what passed. Cheap addition, and it composes with the spec beside every module: the manifest names what changed, the spec says what it means.

Checked the repo: no. spec_update writes frontmatter straight to disk (its own docstring sends prose to the generic write/edit tools), spec_create scaffolds new files, and neither logs or diffs anything separately: a spec edit lands in git as an ordinary .md change like any other file. The proposal mechanism you describe does not exist.

Which makes your framing the design argument. The truth file is the one artifact every other artifact defers to, and it is the only one the agent can write with no detector at all: the mechanical check covers surfaces only (check:spec-surface compares declared exports against barrels), so a quiet narrative rewrite passes every gate until a human reads it.

Spec writes as proposals is pre-registration applied to the truth file: the diff exists before the code that depends on it, and reviewing the two separately is right because they fail differently.

The no-tree mode is the schema argument taken past its own endpoint: heyvaldemar's "never hand the agent an HTTP API" minus the API — the tool list is the boundary, and the refused shell call you recorded is the negative control doing its job in public. Worth more than the refusal itself: an attempted-and-denied call is a denominator event — the agent probed the fence, the fence held, and the attempt was observable. That's the difference between isolation and the appearance of it; a prompt-only fence produces no refused calls to count, because the persuasion happens instead.

On inter-run memory: the SPEC.md pattern transfers directly — the durable home for what survives a session is a maintained artifact the next run reads first, which is exactly this post's bet. The piece to add from this thread's discipline: a memory the agent writes is a diary, and diaries don't bind the next session to anything; sealed per run (what it read, what it concluded, which corpus state it saw), the handoff becomes a receipt the next run can cite — your pasted-in context becomes "the state as of this digest." Research agents are where that pays double, because the corpus moves under them: last week's summary of a dataset is exactly the kind of belief that needs a consumed-head, not a paste.

That bundle has a name in this series: the run receipt. Base commit, commands, evaluator identity, sealed before the verdict exists. The journal side already binds it (attempt-first, spec_hash on the spec it loaded), and the two halves stay distinct: replay validates the recorded computation, the seal witnesses the run.

What Thinkrail lacks is not the idea but the seal: its archaeology receipt is a markdown file the same session writes, so the equivalent-environment claim rests on trust in the process rather than on an anchored record.

Checked the repo, since it's open: enforcement is routing, not confinement. The worktree comes from git worktree add (workspaces.ts), which is a separate directory under the same user — sibling paths and shared credentials stay reachable by the process. The only sandbox-exec in the tree is in the test harness, denying the desktop host read of the repo root for e2e isolation — so macOS Seatbelt is already in the building, just not applied to agent sessions. Your sentinel test is the right acceptance check, and run today it fails on the deny half: the tool call would succeed and the sentinel would change.

One distinction your test already contains, worth naming: record both the refusal and the unchanged sentinel. The refusal is a step — a tool can be told to deny; the unchanged sentinel is the sensor — the world has to actually hold still. Anything the agent's report can attest alone, the agent can forge; the sentinel is what makes the claim checkable without trusting the reporter. That's the same law the geometry thread ran: enforcement by permission is the declared vantage, the sentinel is the effective one, and the gap between them is the finding.

As-builts is the exact analogy, down to the failure you name — the same hand updating both is the second-speaker problem wearing a hard hat. Construction solved it institutionally: the contractor doesn't stamp his own as-builts; a different licensed speaker does, because the two documents serve opposite parties — intent for the designer, reality for whoever maintains the building after. The repo version of the stamp is the path-scoped sign-off: any PR touching both code and spec needs both reviewers, so the as-built can't be amended inside the same approval that changed the building. Cheap fence, and it's the one that doesn't trust anybody's diligence — which, per your house-records point, is the only kind that survives the person who updates both leaving.

Checked the repo, since it's open. The review separation you're asking about doesn't exist — one CODEOWNERS gate for everything (*, five owners, require_code_owner_review on the main ruleset), so a spec edit rides the same review as the code it changed. What does exist is a mechanical drift check one layer down: check:spec-surface compares every enrolled SPEC.md's declared public surface against the module's TypeScript barrel and fails on "Spec surface drift" — which fences the cheap layer in both directions: code that changes the barrel without the spec update fails, and a spec declaring exports that aren't there fails too. What the agent can still do is update both to match whatever it did — the names check out because they were made to.

Your "last Tuesday" drift lives in the layer the check can't see: the spec's narrative — invariants, trade-offs, decisions. That layer has exactly one fence today (the owner gate), and in a mixed PR one review does both jobs at once. The two fences that would actually separate them, cheapest first: a path-scoped CODEOWNERS row (**/SPEC.md owned by a different or additional set — any PR touching spec and code then needs both sign-offs, and a spec-only change gets the spec review alone), and past that, the treatment this series runs on documents the agent follows and writes: the spec sealed at provision, edits arriving as named diffs against the sealed baseline. A spec the agent maintains is a governance file with a compiler attached — the compiler keeps the surface honest, and the seal is what keeps the story honest.

The honest answer is that the merge stays hard — the isolation just changes what kind of hard. Two worktrees that each pass their own tests and both "look reasonable" produce the nastiest conflict class there is: not textual (git resolves that) but compositional — each diff fine alone, the combination breaking an invariant neither touched. The referee for that can't be either diff; it has to be a third document that states what the module is allowed to mean, which is exactly the seat SPEC.md occupies in this design — the owning spec's invariants are what "both look reasonable" gets checked against, mechanically where the surface is concerned (check:spec-surface) and by the owning review where it isn't.

The deeper half is the record-keeping: in journal terms, a merge is a fan-in — an event binding both consumed heads, so each side's assumptions (which spec version it read, which head it built on) are on the chain, not in the agent's chat history. That's what makes a later "these two changes were each fine and together wrong" derivable instead of archaeological: the conflict propagates to both parents as a precise path set. It won't make two reasonable agents agree — nothing does — but it makes their disagreement derivable: who assumed what, at which head, visible at the merge instead of discovered in production. That's the part I'd want to see in practice too, and it's checkable without trusting anyone's judgment of "reasonable."

Checked the repo: everything is writable today. spec_update edits frontmatter only (its own docstring says prose goes through the generic write/edit tools), spec_create scaffolds new files, and neither carries a protection flag or deny list. So the read-only marking you're asking about doesn't exist in the tooling; the fence lives where you put yours, at the repo boundary: agents propose, humans merge, CODEOWNERS on the spec paths. Your setup is the load-bearing layer, and per this thread's law it's the only kind that holds: an in-session read-only flag would be advisory unless the harness enforces it, and a fence the session can weigh is a suggestion.

Where a tool-level flag would still earn its keep is earlier in the lifecycle: a bad spec edit caught at write time is cheaper than one caught at review, and protecting, say, the dependency-edge fields (the graph's load-bearing lines) from spec_update would kill the quiet-rewiring class while leaving prose to the merge gate. That's a design suggestion for upstream, not a capability that exists today.

"Reviews fail because they are optional" is the whole argument for structural boundaries in one line — the checkout lock doesn't make reviewers better, it deletes the choice, which is the same reason prompt-level defenses lose: a defense the agent can weigh is a suggestion.

On multi-session work on one branch: the answer that survives this thread's vocabulary is that the branch is a sequence of promoted states, never a shared scratchpad. Each session is a run — it starts from the last promoted (committed) state, and its only path onto the branch is the merge as intentional handoff, binding what it built on. Same-branch-sequential is safe exactly while every session begins committed; the failure mode is sessions sharing uncommitted state, which is chat-RAM with worse observability — the worktree-per-agent design quietly contains it, because a session that dies mid-work leaves a disposable dirty tree, not a poisoned branch. In receipt terms: the branch becomes the chain of run receipts, each one citing the base digest it started from — which is also what makes "which session broke it" derivable instead of argued. (Design answer, labeled as such — the repo's multi-session UX is one of the parts I haven't exercised.)