Platform function never depends on a client

Platform function never depends on a client

If the platform guarantees a behaviour, that behaviour runs inside the platform. Server-side, on its own schedule, on every install — with no Claude Code, no Codex CLI, no Grok, no client of any kind installed. A client hook may make a guarantee happen sooner. It may never be the thing that makes it happen at all.

This is commandment tier because the failure is silent, it lands on the operator least able to diagnose it, and it scales with the estate.

The test

For any behaviour the product promises, ask: does it still happen on an install where no AI client has ever been installed, and where nobody is technical?

If the answer is no, it is not a platform function. It is a developer convenience that has been mistaken for one.

Why

Reaping worktrees was specified as a lifecycle rule and implemented as a SessionEnd hook in .claude/settings.json. The scheduled-job catalog says so in as many words: “Primary reaping is session-lifecycle (worktree-session-hygiene on SessionEnd). … Not a per-client CLI cron.” The portal’s own sweeper was left default-off, and observe-only even when enabled.

That arrangement needs four things to be true at once: an AI client is installed, a source checkout exists, its settings file is present, and the session ends cleanly. A consumer install satisfies none of them. An abnormally terminated session — killed, crashed, host rebooted — satisfies the last one none of the time.

So on the installs that generate worktrees server-side, through Build Studio and external agents, nothing reaps anything. Measured on the development install 2026-09-02: 193 worktrees, accumulating at 17.6 per day, individual directories reaching 39 GB. A federated peer carried 230+.

The doctrine was not missing. worktree-selection-and-reaping was authored on 2026-06-05, when the count was 119, and it already said the target was a bounded count. Three months later the count was 62% higher. Writing the rule changed nothing, because the rule was addressed to agents and humans while the machine creating the mess was the platform.

The end state is not untidiness. It is a full disk, which takes down the install — including the portal that would have reported the problem — on a machine whose owner cannot read a nomination list, has no reason to know worktrees exist, and whose first signal is that nothing works any more. At estate scale that is a support event, arriving for many owners at once, with no prior warning to any of them.

What this does not license

It does not license automatic destruction. This principle governs where a behaviour lives, not what it is allowed to destroy. destructive-actions-require-explicit-go still binds, and the two resolve cleanly:

Where the two meet, the safe design is a bounded default that needs no decision rather than an unbounded default that waits for one. A default that requires a technical action from a non-technical owner is not a safe default; it is a deferred outage. Anything genuinely irrecoverable — unmerged or unpushed work — still needs an explicit go, and prefer-reversible-containment governs the shape of what happens in between.

How to apply

Recovery is a platform guarantee

Every agentic process must be recoverable. Its work, progress and accountability outlive a client, executor, credential or employee. The platform owns recovery; an agent remembering to return to a conversation is not the mechanism.

Use the existing durable process identity and journal. A replacement executor continues the recorded work under current authority, preserving completed effects and evidence. A refreshed credential proves authority; it does not create a new business operation. Replacing an executor alone changes participation, not work identity or accountability. A separately authorized transfer of accountable ownership is supported and recorded explicitly.

Recovery means a supported path to continuation, compensation, or an explicit safe terminal disposition. It does not promise automatic success, undo an irreversible effect, restore revoked authority, or justify unlimited retries. If the outcome of a prior effect is unknown, reconcile it before repeating it. Reuse valid authorization and evidence; ask a human only for a decision or authority the process actually lacks.

The shared acceptance contract and interruption matrix live in the Durable Agentic Process architecture. Existing adapters must demonstrate that contract before being called recoverable. A new policy document is not runtime proof.

Server ownership

Decision dimensions