fix(farm): stop a plan secret persisting in the run's permanent receipt

[SUaDtL]

writeReport serialized plan.meta verbatim, and the run-scoped change made that permanent rather than transient: .farm/farm-report.json used to be clobbered by the next run, while .farm/runs/<runId>/ accumulates indefinitely with no prune path. meta.setup, setupEachAttempt and setupInputs are raw shell-command arrays and apiBaseUrl is a URL — so a token in a setup command was a perfectly legal plan that landed on disk forever.

Redaction, not an allowlist — the issue's premise was wrong

The issue states there is "no control — schema or runtime — on what meta carries into the report." There is. checkPlanObject is a closed-object check, and plan-contract.test.ts:139 already pins that an unknown meta property throws at parse.

The sink allowlist the issue proposed ({name, repo, model, apiBaseUrl, setup}) would have been a second copy of an existing control and caught nothing. The exposure is the opposite shape: the allowed fields are the dangerous ones. So the free-text fields are redacted instead.

What the adversarial pass broke — all reproduced end-to-end

I ran a four-lens refutation workflow against my own first cut. It found three real defects and one hollow test.

🔴 The Markdown receipt was not redacted at all. The first cut wrapped the JSON sink and left farm-report.md reading raw plan.meta three lines later. A run with meta.name = "nightly sk-ant-MDPROOF-9999" produced a redacted JSON receipt and a Markdown sibling whose H1 carried the token verbatim, in the same never-pruned directory, on a fully green run. The projection is now computed once and both sinks read it.

🟠 AC-2 missed the strings it cited. git diff failed: <raw git stderr>, diffs directory unavailable: <fs error> and patch write failed: <msgOf(e)> all go to noteUnavailableDiff — a different function the first cut never touched — and land in both receipts. Reproduced with a blocked diffs directory inside a repo path carrying a token-shaped segment.

🟠 The redactor missed shapes a plan actually carries. Measured misses: glpat-, sk-proj- (the api[_-]?key keyword doesn't fire on OPENAI_KEY), basic auth in a clone URL, and a bare Bearer eyJ.... Three are closed. The fourth is deliberately not: a curl -u user:pass rule collides with docker run -u 1000:1000, so the gap is recorded in the code rather than papered over.

🟡 The mode test was vacuous on Windows. NTFS doesn't honour POSIX mode bits, so chmod(0o600) reads back 0o666 and the assertion passed against the unfixed implementation on the maintainer's own platform. It now declares that instead of proving nothing, and keeps its teeth on POSIX CI.

The original four ACs

atomicWriteFile preserves an existing destination's mode instead of resetting it to the umask default, opens its temp O_EXCL, and cleans up when the write fails rather than only on rename — the test that claimed to cover that path only exercised rename. The write failure is forced through an injectable open seam, because Node substitutes U+FFFD for an unencodable payload rather than throwing, so there is no "bad data" that triggers it.

Verification

Mutation-tested after the fixes, since a test that can't fail is worse than none:

mutation	result
identity projector	3 failed
Markdown reads raw plan.meta	1 failed
noteUnavailableDiff un-redacted	1 failed
noteArtifactError un-redacted	1 failed

14 new tests. Full farm suite 323 passed / 1 skipped across 5 files; typecheck clean; the shared secret-detection corpus still agrees across redactor.ts and _hooklib (test_hooklib 19 + 80 OK); farm.js rebuilt.

Not closed, stated rather than implied

Per-task .patch files in the same run directory are written raw and stay that way — a redacted patch no longer applies. And redaction reduces the blast radius of a secret in a plan; it does not make plan.meta a safe place to put one.

Hosted secret scan, and why this is a fresh branch

The three credential shapes the redactor-reach tests assert on are, by design, shaped like real credentials — that is what makes the assertions mean anything — so gitleaks reports them. They are waived in .gitleaks.toml by exact anchored value, per that file's own contract: a description naming the file and why the literal is benign, \A<value>\z, and no regex metacharacter in the body, so a waiver can never cover anything but the literal it names. The values were measured against the pinned image with --report-format json, not guessed from the source text — which is the failure mode that config's header documents at length. Verified: tracked findings 3 → 0.

The Bearer fixture is deliberately not a realistic JWT. A JWT contains dots, and a dot is a banned metacharacter in an anchored waiver body, so a realistic one could not be waived narrowly. LEAKPAYLOADNOTAREALJWT123 still exercises the redactor's Bearer\s+[A-Za-z0-9_-]{10,} rule and still trips gitleaks' curl-auth-header, so no coverage is lost.

This is a single clean commit on a fresh branch, replacing #483. The first cut committed the realistic JWT, and the commit-range scan correctly reports a secret introduced by a commit even when a later commit removes it — the tree was clean, the range was not. Force-pushing to rewrite that history is prohibited here, so the change was rebuilt instead. That is the honest fix: the literal should never have been committed in that shape.

Closes #439.