remit v0.4.18

A gate-1 evaluator can read the research when the record lives elsewhere

With personal records, including every shadow install, the gate into refined
raised its evaluator in the primary worktree and pointed it at the item in the
records clone, outside that worktree. A sandboxed seat could not open it: on
Windows, Codex runs as a separate account and was refused research.md, so an
item that asked for research returned BLOCKED at its first gate every time.
The research raise's own kept output had the same problem.

Now a raise in the primary worktree gets the item the way every gate after a
delivery already did. Its artefacts are copied into the worktree for the raise
and taken away afterwards, and its output is kept there and brought home to the
record. The copy's folder ignores itself, so an interrupted raise leaves nothing
for Git to stage. The evaluator at that gate is also handed the research whole
in its briefing, as it is handed the brief, so it no longer depends on opening a
file.

A Codex raise writes only to its own worktree

A Codex raise inherited any [sandbox_workspace_write] writable_roots from the
practitioner's own ~/.codex/config.toml, so a root written for another project
was writable from every raise. remit now clears that list for the raise, and the
worktree, its scratch root and the system temp are its only writable places.

An unrun delivered-when line does not pass

An evaluator could pass a delivery while saying the proof for one of its
delivered-when lines was UNRUN. Its pull request then left draft as ready, even
when the unrun part was exactly what was failing. Evaluators are now told that a
delivered-when line whose proof they could not see run is not met, and that a
verdict leaving one unmet is not a pass. It is a FAIL where the delivery could
have produced the proof, and BLOCKED where nothing before the pull request
can, such as hosted CI. remit still does not read CI.

Upgrading

Nothing to migrate. An item stopped BLOCKED at its gate into refined
because research could not be read continues with remit resume. If your
Codex config lists writable_roots for another project, your own Codex
sessions keep them; only remit's raises clear them.

Validation: the kept-output suite adds a personal-records item with research,
taken through the gate into refined. It asserts that the research raise and
its evaluator keep output inside the primary worktree, that what research kept
reaches the record, and that the evaluator finds that output and the item's
research.md in the worktree and is handed the research. It also asserts that
the copy is gone afterwards and Git reports nothing under the item path. The
invocation suite asserts that a Codex raise clears writable_roots and that the
research handed to an evaluator reaches its briefing. The full Linux unit tier
passes.

remit v0.4.17

Full Changelog: v0.4.16...v0.4.17

remit v0.4.16

Every delivery has a showcase

A draft PR used to arrive with a four-part note and test logs: evidence for an
evaluator more than for the practitioner. Now every delivery carries a showcase
with:

• the problem and the chosen approach;
• optionally, how its evidence was taken: the setup, any stand-in for a real
  service or setting, and a command kept in the repository that takes it again;
• one scenario per line of the brief's ## Judged delivered when section, with
  evidence from runs the builder executed and kept;
• what could not be shown, and why.

Screens are shown by screenshots, APIs by real requests and responses, and
scripts by transcripts.

The builder writes showcase.md beside its kept runs, and the draft PR's
## Showcase section repeats it when it fits, or points to its record. At the gate into accepted, remit fails a
delivery before raising any evaluator when the showcase is missing, has a
scenario citing no kept run, or shows an image no cited run names. The
must-fix goes to a fresh builder and the PR stays draft. A repair that changes
only the showcase or its runs keeps the same candidate: remit records the
repaired showcase, shows it in one PR comment, checks it again and raises the
evaluator on it. An empty build answering any other must-fix is still refused.

The evaluator is handed the showcase and told to open every image it shows,
then say scenario by scenario what it saw. An evaluator that cannot open images
returns BLOCKED, never PASS. A new shipped rubric, showcase, has it judge
whether the evidence shows what each scenario claims.

When the delivery passes into accepted, remit records the showcase with the
images and runs it cites in the item's showcase/ folder. Once that record is
pushed, an open PR gets one comment that shows the showcase with its images,
linked to the record commit when the record is on GitHub. A repair round's superseded screenshots never reach the record's
history.

The installer reports a new outcome, collides: a shipped rubric whose id the
host already uses, in the same gate and section, for text remit has no record of
shipping. The host's rubric stays, the shipped one is
not installed, and the line quotes the shipped text.

Validation: a new unit suite drives real local Git and the synthetic seam and
GitHub fixtures through a screenshot delivery, a missing showcase, an image no
run took (repaired once with a new candidate and once in the runs alone), an
empty build answering a product must-fix, and a transcript-only delivery
through closure. It
asserts that only the accepted evaluator is handed the showcase, and that a
failed round's screenshot never reaches the record. The full Linux unit tier
passes. No live model, harness or real GitHub rendering has been exercised yet.

Upgrade before the next build. An item already published without a showcase
fails the showcase check at its next gate into accepted and is repaired within
the usual build rounds. Items already accepted,
closing revalidation, the four-part note and publication.md are unchanged.

remit v0.4.15

Claude workers no longer restrict other sessions in the checkout

A Claude worker could temporarily create .claude/settings.local.json in its
working folder with Remit's Git, GitHub, Agent and destructive Docker denies.
When that folder was the main checkout, the practitioner's interactive Claude
session inherited those restrictions. Concurrent workers also shared the file,
and cleanup could delete settings the practitioner saved while a worker ran.

Worker deny rules now travel only through that Claude invocation's
--disallowedTools and --settings arguments. Both command and agent-tool hook
scripts live in the individual run directory. Worker startup and completion
no longer create, overwrite or delete project Claude settings or hook files.
The existing worker restrictions remain in force, including the separate
permission for exact evaluators to inspect their snapshot with Git.

Validation covers overlapping workers in one checkout, restrictions during and
after another worker exits, settings created during a run, existing settings,
and a failing worker. The regression executes the registered hook commands;
it reproduces the shared-file leak and cleanup deletion on v0.4.14. Focused
Linux and native Windows checks and the existing invocation suite were run;
the full Linux suite gates publication. These tests use synthetic Claude
responses and do not claim a live-model evaluation or the full Windows tier.

Upgrade before starting new workers. Already-running old invocations retain
their old behaviour and can recreate the shared file. Existing project settings
are not automatically deleted on upgrade: they may contain your own rules.

remit v0.4.14

Empty fetch bookkeeping no longer invalidates evaluations

An ordinary git fetch --all in Remit's snapshot repository can create an empty
.git/FETCH_HEAD even though that repository has no remotes. Because the file
was absent when Remit recorded its baseline, the audit rejected the evaluation
as changed Git controls despite the file containing no fetched references.

Preparation now creates the empty file before recording the baseline. Ordinary
and repeated empty fetches leave the audit clean. Changed contents, removal,
directory replacement, source edits and other Git-control changes remain checked.
There is no new command restriction or general exclusion of FETCH_HEAD contents.

Validation: the regression invokes real Git with its default FETCH_HEAD writing
on Linux and native Windows. It checks initial state, ordinary and repeated
fetches, nonempty fetched references, removal, directory replacement and source
mutation. The previous release fails the ordinary-fetch checks. The existing
Linux snapshot suite also passes, and the full Linux tier gates publication.
The full Windows tier and Zenith's live evaluation have not been run.

Upgrade before retrying the affected items. New evaluations get the corrected
baseline. Existing retained invalid attempts follow the recovery added in
v0.4.13: a resume may first finalize and clear the old rejected attempt; a
subsequent resume starts a fresh evaluation of the same delivery. Existing
snapshots and saved verdicts are not rewritten or retroactively accepted.

remit v0.4.13

Completed evaluations no longer wedge while saving evidence

An evaluation that wrote a result directly under results/ could finish, then
fail while Remit saved its evidence. Remit created results, tried to create
results/. again, and stopped with "File exists". An invalid snapshot audit then
left a prepared locator that every resume revisited without completing recovery.

Remit now creates the results destination before copying either top-level or
nested files. The existing recovery path can finalize a retained invalid attempt
and safely clean up its owned snapshot. Each finalization attempt keeps its stderr,
exit status and failed operation outside temporary coordinator files. Audit errors
now identify the actual rejection; Windows diagnostic diffs preserve line endings
and explicitly mark truncation.

New disposable snapshot repositories disable automatic Git maintenance and
object packing before recording their baseline. This prevents Git housekeeping
from changing the pinned internal files during normal inspection. Host Git
settings are untouched, and source changes, altered Git controls and explicit
packing remain detectable. Maintenance is a reproduced failure mechanism; the
exact command that changed Zenith's original snapshot was not established.

Validation: focused Windows and Linux checks cover clean and invalid evidence
with top-level and nested results, interrupted recovery, copy-error diagnostics,
Windows line endings and bounded diffs. A real Git maintenance trigger stays clean
with the new setting; an explicitly enabled control packs objects and fails audit.
Coordinator tests recreate the old wedge, recover without another evaluator, and
then retry the same delivery without rebuilding. Full Linux tests gate release;
the full Windows tier and live model evaluations were not run.

For an already-retained invalid evaluation, the first remit resume <item> can
finish saving the rejected attempt and remove its locator while still reporting
that old evaluation as invalid. A subsequent resume starts a fresh evaluation of
the same delivery. Do not delete evidence or alter snapshot metadata manually.

remit v0.4.12

Snapshot preparation recovers and respects endpoint metadata

On managed Windows machines, endpoint software can attach sec.endpointdlp
metadata to freshly copied files. Remit rejected that metadata during snapshot
preparation and cleanup. When failed preparation left a snapshot behind, every
later resume could stop at the retained failure marker without retrying.

Remit now ignores this exact metadata name on files and directories without
reading or stripping it or changing endpoint settings. Preparation and audit
continue to check ordinary file contents, other alternate streams and reparse
points. The same exception lets normal cleanup dispose of owned snapshots.

Resume now recognizes failed preparation, checks the candidate, gate, location
and snapshot ownership, and retries cleanup before preparing the same delivery
again. It preserves the original failure and each cleanup attempt's diagnostics.
Foreign snapshots and snapshots showing evaluator invocation are retained.
Continuing cleanup failure reports its cause instead of silently trapping the
item behind an invalid marker. Snapshot errors identify the path, stream or
inspection operation, and binary files no longer flood preparation logs with
ignored-NUL warnings.

Validation: the full Linux unit tier gates publication. Focused native Windows
tests passed 48 metadata assertions, 40 preparation-recovery assertions and 10
long-path assertions. They cover metadata attached before preparation's manifest,
later metadata changes, preserved source and metadata bytes, detection of actual
source edits, and owned cleanup. Endpoint metadata is synthetic in these tests;
Zenith's live endpoint agent and delivery gates have not been exercised. The full
Windows tier and live model evaluations were not rerun.

After upgrading, retry affected items with the normal remit resume <item>
command. No manual deletion of valid owned failed-preparation remnants or change
to endpoint monitoring is needed for the reported metadata failure.

remit v0.4.11

Windows evaluations start with intact arguments

Exact evaluations on Windows could fail before Codex started, reporting that
hooks.state was a string instead of a map. Remit constructed the correct value,
but the Windows Job worker passed it through .NET argument quoting to MSYS
env.exe, which consumed backslashes inside quoted arguments.

The shared worker now writes each argument as a literal in a temporary POSIX
launcher. The shell handles the MSYS transition, preserving configuration values
for every harness using this path. The existing Windows Job still supervises and
reaps the process tree; hook trust and command restrictions remain in place.

Validation: native Windows regression checks exact arguments, environment, stdin,
exit status and termination of a started descendant. The v0.4.10 negative control
fails on corrupted arguments. A native Codex 0.154.0 probe through the full exact
evaluation path reproduces the reported startup error on v0.4.10 and succeeds
with this change. It uses a local synthetic provider and an explicit read-only
sandbox: it proves startup and cleanup, not a product verdict or workspace-write
sandbox execution. The full Linux unit suite gates publication; the full Windows
tier and other native harnesses were not rerun for this transport correction.

After upgrading, the blocked evaluation can be retried through Remit's normal
resume command. No Codex downgrade or shared configuration edit is required for
this startup defect.

remit v0.4.10

Safe record-push recovery

When another writer advances the remote branch, Remit now replays its record commit
without leaving the primary checkout on old product files. Incoming additions,
changes and deletions reach both the index and working tree. Unrelated staged,
unstaged and untracked practitioner work is preserved and stays out of the push.
Overlapping changes refuse replay while retaining the local record and local work.

Complete public releases

v0.4.9 introduced the Release workflow, but its first tag push produced no run and
needed a manual dispatch. Publication now listens to both the artifact's main push
and its tag push. Either event verifies the committed version, tag and notes before
creating the entry; duplicate events and retries preserve one release and its text.
An older tag does not retake Latest. This uses the public repository's own workflow
token; no additional private-repository credential is required.

Validation: the checkout regression passes nine checks on both Linux and native
Windows, including staged/unstaged preservation and conflict recovery. Sixteen
release-helper checks pass with a simulated GitHub API; the artifact installation
suite passes 115 checks, including preserving the project's own release content.
The full Linux suite gates publication. Real tag-trigger and Release-entry behavior
is verified separately on the public repository when this version is published.

Upgrade using your repository's existing installation mode. This fixes future
record-push retries; it does not automatically clean up stale changes left by an
earlier version, because those may be mixed with your own edits.

remit v0.4.9

Safe record-push recovery

When another writer advances the remote branch, Remit now replays its record commit
without leaving the primary checkout on old product files. Incoming additions,
changes and deletions reach both the index and working tree. Unrelated staged,
unstaged and untracked practitioner work is preserved and stays out of the push.
Overlapping changes refuse replay while retaining the local record and local work.

Complete public releases

A published artifact tag now triggers the public repository's GitHub Release entry,
using these authored notes. Retries preserve existing release text, and rerunning an
older tag does not mark it Latest. This uses the public repository's own workflow
token; no additional private-repository credential is required.

Validation: the checkout regression passes nine checks on both Linux and native
Windows, including staged/unstaged preservation and conflict recovery. Eleven
release-helper checks pass with a simulated GitHub API; the artifact installation
suite passes 115 checks, including preserving the project's own release content.
The full Linux suite gates publication. Real tag-trigger and Release-entry behavior
is verified separately on the public repository when this version is published.

Upgrade using your repository's existing installation mode. This fixes future
record-push retries; it does not automatically clean up stale changes left by an
earlier version, because those may be mixed with your own edits.