zseval

zerostack

zerostack 1.7.2

ledger audited against

1.7.2

audit vs this run

the version this run measured names it, so the audit and the run agree on the version

binary sha256

d8bbfe5dc1a9ecf67e3539396d134000ce0cc1d04abec89f08eefba648513777

binary path

zerostack

git sha

not provided

features

not provided

model

openrouter/deepseek/deepseek-v4-pro

backend

zs-cli

target

targets/openrouter.toml

timestamp

2026-08-03T02:26:39Z

trials

3

total cost

$1.6983

budget truncated

no

configured

judges/sonnet.toml (hash: 4cd972111ef8c9b8)

graded by

claude-sonnet-4-6

Results

The rates above count trial verdicts. pass: every assert held, and the judge, where one graded, agreed. fail: an assert failed, the judge disagreed, or a budget was exceeded. indeterminate: the trial could not be graded at all (a backend crash, an unreadable session, a judge that returned no verdict), and is excluded from the rates rather than counted as a failure.

Coverage

Areas with no scenario at all: 7 of 15.

Permission layer no scenario at all

• uncovered A deny rule in the config still denies when the run was started with permission prompts skipped

  note: The cheapest regression this area could have: every run the harness makes already skips permission prompts, so the scenario needs a seeded config and a file that has to survive, and nothing else.

• uncovered A regex deny rule beats a glob allow rule that matches the same command
• uncovered The built-in bash denylist stops a destructive command when no permission config exists at all

  note: The zero-configuration safety net, which is the state most first runs are in.

• uncovered A read-only prompt mode is enforced by the permission layer even when the user's instruction demands a write

  note: The enforcement layer beneath the two voluntary-compliance claims in the prompts area. zerostack used to strip the %%mode= directive out of a prompt's content and then look for it in the stripped text, so the mode was never applied and this claim was not merely unmeasured but unmeasurable; the startup path has since been fixed and it is buildable now. It is the deliberate calibration overlap those prompt claims record: when it is built it is counted once, here, and never a second time there.

• uncovered The permission modes other than the one the harness forces decide as specified, including allowing a write inside the working directory and asking before one outside it

  blocked by: Every invocation hardcodes the same argument list, including the flag that skips permission prompts, and scenario.toml has no field that can add or drop a flag, so no run ever reaches the standard, read-only or guarded modes.

  note: The single largest hole in this area: while those modes are unreachable, almost everything the layer decides is invisible to a scenario.

• uncovered The flag that disables permission checks widens the boundary by exactly what its name promises and no further

  blocked by: It is a command-line flag, and the fixed argument list every invocation is built from has no per-scenario extension point.

• uncovered A path outside the working directory that the config scopes explicitly is treated as scoped

  blocked by: Two limitations stack: no run reaches the mode where a scoped external path is decided, and a seeded config cannot name one of the run's throwaway directories because file placements are copied verbatim with no substitution.

• uncovered Repeated denials of the same command are recognized and the agent is steered off the retry loop

  blocked by: The coaching text zerostack injects arrives as a tool result, and the transcript reader skips the result blocks in the captured output, so the only trace of it is whatever the model chooses to repeat in its answer.

  note: Written as unmeasured rather than as a permanent exclusion. The older judgment rested on a headless permission question hanging until the scenario timed out, and that half has since been fixed, which leaves an evidence gap on the harness side rather than a reason never to build this.

• product-blocked The permission mode is correct again after a one-shot dot command hands control back to the prompt that was interrupted

  zerostack restores the previous prompt's name without reapplying that prompt's own %%mode= directive, so the mode left behind is whichever one the dot command set.

  note: Only the interactive dot-command path is wrong; the startup and session-scope paths apply the directive correctly. The harness drives zerostack non-interactively and has no pseudo-terminal backend, so even a fixed zerostack would need one before this could be measured.

Sandbox isolation no scenario at all

• uncovered With the sandbox on, a bash command cannot write outside the working directory and can still write inside it

  blocked by: The probe only means anything on Linux with bwrap installed, and a scenario has no way to declare the platform it needs, so a run on any other machine would report it as a zerostack failure rather than as a skip.

  note: One claim rather than two, because the halves are worthless apart: a sandbox that refused every write would pass the first half on its own. The probe command also has to be one the permission layer allows, or the write never reaches the sandbox and the two boundaries collapse into one measurement.

• uncovered The sandbox isolates the process namespace, and the ipc, uts and cgroup namespaces with it

  blocked by: The probe is meaningful only on Linux with bwrap installed, and a scenario has no way to declare the platform it needs, so anywhere else it would fail for the wrong reason.

  note: Only the process namespace has ever been proposed; the other three are unproposed as well as unbuilt.

• uncovered Cancelling a run tears down the whole process group the sandboxed command started

  blocked by: Cancellation is an interactive act, and every scenario runs zerostack as a non-interactive subprocess; there is no pseudo-terminal backend that could interrupt one mid-run.

• product-blocked Credential directories are hidden from a sandboxed command, the network is closed off, and a missing sandbox binary refuses the command instead of running it unconfined

  zerostack binds the whole filesystem into the sandbox read-only, leaves the entire user cache writable, never unshares the network, and runs the command unsandboxed with only a warning when neither sandbox binary is present, so none of these three protections exists to be measured.

  tracked as: sandbox hardening

  note: The three are one claim because they are one piece of work: masking without a network boundary still leaks, and either without a fail-closed option is optional protection.

• excluded The sandbox launches the shell the configuration names

  Which shell runs inside the sandbox is a configuration preference rather than a containment property, and all a scenario could observe is that the shell is not bash, which says nothing about what is contained.

Hooks no scenario at all

• uncovered A hook's allow decision cannot widen what the permission checker itself denied

  blocked by: The only hook location zerostack trusts by default is the global settings file under the user's home directory, and file seeding can place files into the run's data, config and working directories only, so no trusted hook can be installed for a scenario at all.

  note: The most important unmeasured claim in this area. Hooks run outside the permission checker, so a hook that could override a deny would breach the boundary every other area is measured against.

• uncovered The hook events that guard a turn do what they say: a deny beats an allow before a tool runs, a question fails closed with no terminal to answer it, the stop hook stops being allowed to block once it hits its limit, redaction removes a secret after a tool runs, and context added at prompt time reaches the model

  blocked by: All five need a hook installed in the globally trusted location, which sits outside the three directories a scenario can seed into.

  note: Coarse on purpose: nothing here has been sliced finely enough to be confident about, and the five share one blocker. The stop hook's limit is a hard-coded constant on zerostack's side, so a scenario that pins it should say beside the assertion that it is pinning an internal number.

• uncovered An untrusted project hook does not run, and a malformed project settings file does not take the run down with it

  blocked by: A green result would be indistinguishable from a run whose zerostack was built without hooks compiled in, and the suite has no check that tells a correctly skipped hook from hook code that was never there.

  note: The scenario also has to seed a hook that would visibly block a write if it were wrongly trusted, otherwise it can never turn red and its passing means nothing.

• excluded The hook dry-run command exits with the status it documents

  That path calls no model: it is a dispatcher's exit code, and spending a trial plus a new family of output assertions on it buys what a zerostack unit test already can.

  note: The invocation mode it would need is still the cheapest way into this area for a harness that wanted one; excluding this scenario is a judgment about the scenario, not about that mode.

Prompt modes

• covered A read-only prompt declines an edit request and points at a writable prompt
  • prompt-ask-readonly-refuses-edit
  • prompt-brainstorm-refuses-implementation

  note: These measure the model voluntarily complying with the read-only mode its prompt file declares, not the permission layer enforcing anything. An adversarial probe that checks the permission layer itself blocks the write is the same mechanism one layer down, a deliberate calibration overlap: when it exists it is counted once, under the permission area, and never a second time here.

• covered A read-only prompt still answers the request it was given instead of refusing everything
  • prompt-ask-answers-question
  • prompt-brainstorm-explores-ideas

  note: The calibration half of the refusal claim above: without it, a prompt that refused every request would score full marks on read-only compliance.

• covered The planning prompt withholds implementation until the user approves, and implements once approval arrives
  • prompt-plan-no-implementation
  • prompt-plan-approval-gate

  note: Voluntary compliance again, at the prompt layer: the gate holding is the model honoring its prompt file, not the permission layer refusing a write. The permission-layer probe is the same deliberate calibration overlap noted on the read-only claim above.

• covered A code review reports a real defect and does not invent one in correct code
  • prompt-review-flags-seeded-bug
  • prompt-review-clean-approves
• covered A security review reports a genuine command injection and stays quiet about input that is already validated
  • prompt-review-security-flags-injection
  • prompt-review-security-clean-no-findings
• covered The debug prompt fixes the root cause rather than the symptom, and stops investigating once the cause is already known
  • prompt-debug-root-cause-first
  • prompt-debug-no-overinvestigation
• covered A refactor reorganizes the code without touching the tests that guard it
  • prompt-refactor-preserves-tests
• covered Simplification keeps the comments that explain a non-obvious decision
  • prompt-simplify-preserves-why-comments
• covered A behavior change requested under the banner of simplification is declined
  • prompt-simplify-declines-behavior-change
• covered The default prompt names the specialized prompt that would suit the request better
  • prompt-default-redirects-to-specialized
• covered A trivial question gets a short, direct answer with no preamble and no tool calls
  • prompt-code-concise-answer
• covered The orchestrator prompt does a one-line task itself instead of delegating it or spawning a zerostack subprocess
  • prompt-orchestrator-small-task-direct
• covered The autoconfig prompt edits the config file the run actually resolved, after asking for approval
  • prompt-autoconfig-edits-config
• covered The frontend-design prompt commits to a stated visual direction and avoids the fonts and gradients its own prompt file bans
  • prompt-frontend-design-commits-to-direction
• covered The write-prompt prompt writes a prompt file that adopts zerostack's own mode directive convention
  • prompt-write-prompt-follows-format
• covered The write-text prompt produces prose to the brief, free of the filler openers its own prompt file lists
  • prompt-write-text-produces-prose
• covered A prompt pack in the working tree overrides zerostack's built-in prompt of the same name
  • prompt-pack-example-marker not exercised by this run

  note: A direct observation: the scenario asserts the prompt identity the session itself recorded (`code`, from a `user_file`), so a run where the model ignored the pack's instructions no longer looks like a run where the built-in prompt won. One residual gap the readback cannot close: zerostack classifies `built_in` by content, so a pack prompt whose bytes equal the built-in would record `built_in` even though the pack won, which is why the example's pack file is deliberately nothing like it. The scenario also lives under examples/prompt-pack/, outside the default suite, so an ordinary run's report shows it covered but absent.

• uncovered A prompt directory inside the project overrides a user-level prompt of the same name, which in turn overrides the built-in one

  note: Both halves are needed for the precedence chain to mean anything: the overriding prompt has to win, and the overridden one has to be absent from the answer.

• uncovered A chain-aware prompt offers the next phase once its own phase is finished

  blocked by: The transition is offered in the interactive interface, and the harness drives only the non-interactive surface; there is no pseudo-terminal backend that could accept or decline the offer.

• covered A run reports which prompt file it actually loaded, and where that file came from
  • session-prompt-recorded-stock

  note: The session JSON now records a `prompt: { name, source }` field at every prompt resolution, so which prompt served a run is read directly rather than inferred from what the harness seeded. That readback is what lets the prompt-pack claim above rest on a direct observation instead of a marker string the model had to repeat.

• excluded Naming a prompt that does not exist lists the prompts that do

  That is command-line error text with no model behavior behind it, and observing a string zerostack's own tests can hold would cost a full trial plus a family of output assertions the suite does not have.

Project instructions (AGENTS.md)

• covered A rule written in a project's AGENTS.md reaches the model and changes what it writes
  • context-follows-agents-md
• covered A rule scoped to one file type is not applied to files outside that scope
  • context-no-overapply

  note: The calibration half of the pair above, against the same AGENTS.md: a model that stapled the rule onto every file it touched would pass the first claim and still fail the user.

• uncovered A CLAUDE.md with no AGENTS.md beside it is loaded just the same

  note: The loader walks a list of filenames, and an edit that dropped one entry from that list would be invisible to every scenario that seeds an AGENTS.md.

• uncovered An architecture document is loaded and used by the prompt that asks for one

  note: The canary has to be a fact that cannot be answered without reading the file, not a floating code word the model could echo straight back out of the question.

• uncovered Turning project instruction files off actually suppresses them

  blocked by: Suppression is a command-line flag, and every invocation is built from a fixed argument list that scenario.toml has no field to extend.

Tool use

• covered File search goes through the specialized tools rather than a shelled-out grep or find
  • tools-grep-over-bash
  • tools-find-files-over-bash
• covered An edit changes only the block it was asked to change, leaving an identical neighboring block untouched
  • tools-edit-precise
• covered A file is read before it is edited, and a rename catches every occurrence in it
  • tools-read-before-edit
• uncovered An edit whose search text has drifted from the file still lands on the block it was meant for

  note: A fixture indented with tabs is enough to make the search text drift; what the claim needs is that the fallback lands in the right place, not merely that it lands.

• uncovered File discovery respects the repository's ignore rules
• uncovered The write path refuses a file past its size limit
• uncovered What a tool returned is checked directly rather than through the model's retelling of it

  blocked by: The transcript reader skips the tool-result blocks that already land in the captured output, so any claim about a tool's own output has to be proxied through the final answer.

  note: This is what keeps the secret-leak and stream-capture proposals at arm's length. An oversized-file refusal can only be graded as the secret not reaching the answer, which a leak routed through a shell command would walk straight past.

• uncovered The flags that shrink or swap the tool surface take effect: an allowlist registers only the tools it names, and a system-prompt edit applies without a restart

  blocked by: Both are command-line flags, and the fixed argument list every invocation is built from has no per-scenario extension point.

  note: The allowlist half is recorded as unmeasured rather than as a permanent exclusion: the older judgment was that the flag was dead code, and it has since been wired into how the agent is built, so what is left is a limitation on the harness side.

• uncovered Turning the todo tool off stops it from being registered

  blocked by: The toggle is an interactive command, and the harness drives zerostack non-interactively with no pseudo-terminal backend that could issue one.

  note: Recorded as unmeasured rather than as a permanent exclusion: the older judgment was that the toggle did nothing at all, and a rewrite of the interactive settings state has since connected it.

• covered The tool calls a headless run made are recorded as data rather than reconstructed from printed output
  • session-tool-call-recorded

  note: The session JSON now carries a structured tool record per call, and the transcript reader reads that record directly instead of reconstructing calls from the stdout marker. Every other tool-call assertion in this suite now rests on the same session evidence.

• excluded The content-addressed edit guard rejects an edit built against a stale read

  Reaching it needs a prompt that scripts an exact tool sequence, which grades a tool contract rather than an agent, and zerostack can hold that contract without paying for a model trial.

  note: The same judgment as the two memory tool-contract probes recorded in the memory area. The line is drawn at the scripted path, not at the difficulty.

Memory subsystem

• covered A durable fact the user asks to have remembered lands in long-term memory
  • memory-write-remember-fact
• covered A one-off question the user says not to remember writes nothing
  • memory-no-write-smalltalk

  note: The cost-discipline half of the pair above: an agent that wrote a note after every turn would pass the write claim outright.

• covered A fact that changed updates the existing note in place rather than adding a second one beside it
  • memory-update-not-duplicate
• covered A search snippet that does not answer the question is followed up with a full read of the note
  • memory-search-then-read-when-needed
• covered A search snippet that already answers the question is not followed by a redundant read
  • memory-search-snippet-sufficient

  note: The cost-discipline half of the pair above, over the same seeded notes.

• uncovered A preference already in the store is recalled without spending a search or a read to find it

  note: The injection path, as distinct from the retrieval path the covered claims above measure: a store that is read correctly but never injected looks identical until a scenario asks for something nobody searched for.

• uncovered Instructions embedded in a stored note are treated as text rather than obeyed

  note: The adversarial claim in this area, and the one worth building first. Adversarial coverage across the whole suite is concentrated in memory and subagents, while the two boundaries that most need it, permission and hooks, have none at all.

• uncovered Retrieval and storage behave as documented: which daily log is chosen and how today is marked, the order in which an oversized store is truncated, backups staying invisible to search, an edit with no match being refused, and the ranking search applies

  note: Coarse on purpose. None of these has been sliced finely enough to be confident about, and stating five thin claims would suggest a precision the review behind them does not have.

• uncovered An overwrite keeps a copy of what it replaced, and a failed backup warns without losing the write

  note: Whether zerostack backs a memory file up at all is unconfirmed: the subsystem's layout notes never mention it and nobody has read the code to check. Recorded as unmeasured rather than as a hole on zerostack's side precisely because that check has not been done.

• excluded A whitespace-only duplicate is dropped on write and an ambiguous edit target is refused

  Both need a prompt that dictates the exact tool sequence to reach them, which grades a tool contract rather than an agent, and zerostack can hold that contract without paying for a model trial.

  note: What is excluded is the scripted route, not the question. An edit that finds no match at all is listed as unmeasured above, and it will be reached by a task the agent solves its own way; these two can only be reached by dictating the tool sequence, which grades the tool instead.

Session continuity

• covered A fact stated in one turn is still in context on the next turn of the same session
  • session-continue-recalls
• covered A turn that opens a fresh session does not carry the previous session's context
  • session-fresh-forgets

  note: The calibration half of the pair above. It also holds the memory subsystem out of the way, failing if the codeword survived through a memory write rather than through the session, so a memory recall cannot masquerade as session leakage. That constraint belongs to this claim and takes no slot in the memory area.

• uncovered The turns of a session and the chat history are persisted where the next process can find them

  note: The claim has to stay at the level of each fact appearing in some session file: matching two facts to the same file is beyond what the path assertions can express today.

• uncovered Compaction state written during a session is still there after it is resumed

  note: Reachable only since the fix that gave a headless continuation its history: before it, nothing accumulated that could be compacted in the first place. The loop-mode half of the same question is still recorded as blocked, in the loop area.

• uncovered A resumed session still runs on the model and provider it started with

  blocked by: The transcript reader drops the model and provider fields zerostack writes into the session file, so no assertion can see which model actually served a turn.

• uncovered The permission allowances granted during a session survive a resume

  blocked by: Nothing can add an entry to that list in a non-interactive run, because entries are added by answering an interactive permission question, and the harness drives only the non-interactive surface.

  note: Recorded as unmeasured rather than as a permanent exclusion. It was written off together with compaction state on the grounds that neither could be written in a headless run, and compaction has since become reachable, so the two no longer share a fate.

• excluded The resume flag lists the recent sessions to pick from

  That is a command-line listing with no model behavior behind it, and it would need a new family of output assertions to observe something zerostack's own tests can hold.

Subagent delegation

• covered A question that spans several files is delegated to a subagent
  • subagents-delegates-crossref
• covered A single-file lookup is answered directly rather than delegated
  • subagents-skips-for-trivial

  note: The calibration half of the pair above, over the same fixture project: delegation that fires for everything is as wrong as delegation that never fires.

• covered What a subagent found is folded into a recommendation rather than restated
  • subagents-integrates-results

  note: Graded on the final answer alone. A headless run exposes neither a subagent's own tool calls nor the text it returned, so how the subagent reached what it reported is not measured here.

• uncovered Two independent questions are batched into one delegation rather than two

  note: Counting the delegations is possible; reading their arguments is not, because the delegation tool's arguments never reach the printed marker the suite parses. Any scenario here has to grade on the count and the answer.

• uncovered An instruction planted in a file a subagent reads cannot make it write, edit or run anything

  note: Structural rather than behavioral: a delegated agent is built with read-only tools, so this guards that construction against a future change that widens it.

• product-blocked What a subagent did is observable: its own tool calls, the turn limit it ran under, and the model it was routed to

  A subagent's tool calls are delivered on a channel only the interactive interface consumes, so a headless run holds no evidence of what a subagent did or how it did it.

  tracked as: issue #229

  note: This is why every delegation claim above is graded on the final answer. A scenario about a subagent's turn cap or its model routing would pass or fail on no evidence at all, which is worse than not having one.

MCP servers and their tools

• covered A tool a configured MCP server provides is called when the task needs it
  • mcp-uses-provided-tool
• covered An available MCP tool is left alone when the task has nothing to do with it
  • mcp-ignores-irrelevant-tool

  note: The calibration half of the pair above, with the same server configured: a registered tool that is never the right answer has to stay unused.

• uncovered A server that fails to start, or a tool that returns an error, is reported without derailing the rest of the run

  note: Both covered claims above run against a server that works. Nothing measures what a broken one does to the turn around it.

• uncovered Tools an MCP server contributes are gated by the same permission rules as built-in ones

  blocked by: The permission modes where that gating is decided are unreachable while every invocation forces the flag that skips permission prompts.

Loop mode

• covered Loop mode keeps iterating until the validation command succeeds, fixing the code rather than weakening the test
  • loop-fixes-failing-test

  note: The transcript and the files left on disk are the only evidence loop mode produces: it saves no session and records no tool calls, so nothing about how the fix was reached is measured.

• uncovered The loop stops at its iteration limit instead of running on when the validation command cannot be made to pass

  note: The covered claim above only exercises the loop that succeeds. What the loop does when it cannot succeed is the half that decides whether an unattended run is safe to start.

• product-blocked An iteration can see what the iteration before it said

  The headless loop still calls the model with an empty history, so context reaches the next iteration only through the plan and summary text the loop folds into its own prompt.

  tracked as: TODO(loop-history)

  note: The single-turn headless path was fixed and this one was not, so session recall and compaction stay out of reach in loop mode specifically. Wherever this file says a continuation carries its history, it means the single-turn path and never this one.

Headless print mode no scenario at all

• uncovered A bang command runs directly, without the model in the loop, and its output reaches the answer

  note: Deterministic enough to run at a single trial: no model call means no variance to average out.

• uncovered The pure-stdout surface prints the tool result and the answer and nothing else

  note: The fixture has to pin whatever the scenario counts, and the assertion has to leave the agent free to reach that count by reading files one by one instead of by a single search.

• uncovered The flags that shrink a headless run leave exactly what they promise: no tools registered, and no session written while the work still happens

  blocked by: The backend builds the same argument list for every invocation and scenario.toml has no field that can add or drop a flag, so a run cannot be made with any of them.

• uncovered A provider failure exits non-zero with an error a user can act on

  blocked by: Any non-zero exit is treated as a broken run and graded indeterminate, so a scenario cannot declare that a non-zero exit is the outcome it expects.

  note: Cheap and fully deterministic once it can be expressed, which makes it the best argument for expressing it.

• uncovered The status socket reports what a run is doing while it does it

  note: No scenario has ever been proposed for this surface. It is written down here so that it sits inside the denominator rather than outside anyone's view of it.

Context window and model catalog no scenario at all

• uncovered A known model resolves to the context window the catalog gives it

  note: Cheap to build and thin in value: it spends a full model trial on a configuration resolver, so it earns its place only if zerostack's own tests do not already hold the catalog.

• uncovered Compaction keeps the facts a later turn still needs instead of dropping them with the text it summarized

  note: What compaction preserves, as opposed to whether the state it leaves behind survives a resume, which the session area records separately. Reachable in a non-interactive run only since the fix that gave a headless continuation its history, and still out of reach in loop mode, which the loop area records.

• product-blocked A compaction threshold set outside its valid range is refused or warned about instead of accepted in silence

  The warning exists only in a documentation comment; the configuration loader never implements it, so there is no behavior to observe.

• excluded An unrecognized model falls back to a default window

  This is the other arm of the same branch the catalog claim above reaches, and one arm is enough as a canary: the second costs a full model trial to re-observe a decision a unit test can hold.

Providers and config resolution no scenario at all

• uncovered Naming a provider and no model falls back to that provider's own default model
• uncovered A configured model that names a shorthand entry is sent as the real model id, not as the shorthand
• uncovered When two configuration file formats are both present, the documented one wins

  note: The two files have to differ in something a run can be seen to obey, since which file was read is never reported on its own.

• uncovered A first run with no configuration writes the default configuration file

  note: It has to run with no seeded target, because seeding one puts the file in place before the first-run branch can be reached, and the scenario would then pass on the wrong evidence.

• uncovered The configuration search order and the environment overrides for provider and model are honored

  blocked by: A run's environment is fixed by the harness, which sets the isolated data, config, temp and home directories and nothing else, and a scenario has no field that can set or clear a variable for its own trials.

• uncovered What goes on the wire is what the configuration asked for, including cache-control headers and the order an API key is resolved in

  blocked by: Three capabilities are missing at once: nothing captures the outbound request, a scenario cannot set environment variables, and a seeded file cannot be templated with the run's own throwaway paths.

  note: Recorded as unmeasured rather than as a permanent exclusion: the older judgment parked it on a long-term list, and a schedule is not a decision never to build something.

Worktrees no scenario at all

• uncovered A run can be driven against an isolated worktree at all

  blocked by: Seeding copies individual files and cannot create a git repository, and every worktree scenario needs one to exist before zerostack is started.

  note: Whether zerostack offers worktrees outside its interactive interface has not been confirmed since the review that first raised the question, which is why nothing in this area is written down as a hole on zerostack's side.

• uncovered A clean worktree merges back and cleans up after itself, a conflicting one is reported rather than quietly resolved, and forcing one away removes what it left behind

  blocked by: All three need a git repository that the file-copying seed mechanism cannot produce, before anything about zerostack's behavior is even reached.

  note: Recorded as unmeasured rather than as a permanent exclusion: the older judgment was that the behavior is unimplemented or undefined, two reviewers disagreed about it, and nobody has read the code since to settle it.