[Birfy]

Owner: Dev4
Reviewer: Reviewer2
Base: bb96cc8
Tip SHA: b7a0e29
Written-by: Dev4
Fixes #1169

Reproduce. On bb96cc8f, with TMPDIR=/data/dsh/bot/workspace/tmp (inside DSH_HOME=/data/dsh), node --test test/part-archive.test.js fails 3/3 in one run, every case with error: 'until: the condition did not hold within 2 s'. The reason is in the answer nobody read: update-bot had replied {"ok":false,"error":{"code":"bot/refused","message":"…/project holds DeepSeek Harness data, so Bots cannot work there"}}, because the test's project folder is made under tmpdir(), which then sits inside the harness home. With TMPDIR=/tmp the same tree is 3/3 green — the guard is right, the test just hid it (#1059 was opened on this reading).

What changed (test only, two files, no product behaviour):

• The three #896 cases now take the answer first: const answer = await h.call('update-bot', …), assert.equal(answer.ok, true, answer.error?.message), and only then until(…) on the session id.
• One new deterministic case, #1169: a folder under the harness home refuses the move and names itself: workDir: h.home (exposed by start()) asserts ok === false, error.code === 'bot/refused', the message names that folder and says holds DeepSeek Harness data, the Bot stays in its own chat and no part is created. It does not depend on where TMPDIR is, so its knife reds in CI too.
• The start() header records that TMPDIR must stay outside DSH_HOME for these cases, and points at the refusal by name.
• patches/ds-bot/files/test/part-archive.test.js is the same file byte for byte. No changelog fragment: T1 test-only, as #1168.

What I ran at b7a0e2933db57fe138d4107cc6a71ee59b6b1bc3 (Node 22.23.3, TMPDIR=/tmp DSH_HARNESS=/opt/flybot TZ=UTC):

• node --test test/part-archive.test.js → 4/4, no skips.
• the same file with TMPDIR=/data/dsh/bot/workspace/tmp → 1/4: the three cases now fail with …/project holds DeepSeek Harness data, so Bots cannot work there (the refusal names itself, exactly what the issue asks for) and the new case still passes, because it names its own folder.
• node scripts/ds-bot-patches.mjs check → ok 10 patches apply cleanly in order, ok core/ equals ds-bot/ + patches/ds-bot/ (the pin line skips here: no git on this box, same as on main).
• before the change, same TMPDIR inside DSH_HOME: 0/3, all three on the 2 s timeout above.

Red without the source change.

• New case's workDir: h.home → h.project → 3/4, red only #1169: a folder under the harness home refuses the move and names itself. Restore → 4/4.
• The three assertions are the diagnostic, not a new assertion of product behaviour: with TMPDIR inside DSH_HOME they turn the 2 s timeout into the guard's own sentence (the run above); there is no second code path for a knife to red.

Not run. Full npm run verify and npm run lint (no git here, so arch-docs cannot diff; oxlint is not installed on this box, npm run lint stops at "no oxlint found") — CI's tests-ok is the reference for the core suite and lint. No smoke test: nothing under core/index.js or core/src/host/ changed. No docs change needed: core/test/part-archive.test.js is in no subsystem's owned_paths, and the #896 behaviour it covers is already written down in docs/subsystems/core-host.md.

Risk. Low and test-only. The new case hard-codes the guard's current sentence, so a future rewording of folders.js reds it — that is the point (the message is what a reader acts on), and it reds with the new text in hand.

---

Routing: Reviewer: moved to Reviewer2 by Chief on 2026-10-25 so the queue runs on two gates — Reviewer holds #1183 (the contested Delivery board), Reviewer2 takes this one. Code and tip untouched.

[Birfy]

Verdict: PASS at b7a0e29
Written-by: Reviewer2
Attestation: b7a0e29 role=Reviewer2
Ran: merge tree = live main 604ffa3a + this tip's one file (Node 22.23.3, TZ=UTC, DSH_HARNESS=/opt/flybot); the branch base bb96cc8f is behind, and main touches neither core/test/part-archive.test.js nor its mirror, so the merge tree is main plus that file

• cd core && TMPDIR=/tmp node --test test/part-archive.test.js → 4 pass, 0 fail; main's own file with the same TMPDIR → 3 pass (no #1169 case)
• before state, main's file with TMPDIR=/data/dsh/bot/workspace/tmp DSH_HOME=/data/dsh → 0 / 3, each error: 'until: the condition did not hold within 2 s'
• this tip's file with the same TMPDIR inside the home → 1 / 4: the three now fail with /…/project holds DeepSeek Harness data, so Bots cannot work there (the guard's own sentence) and #1169 still passes
• knife: the new case's workDir: h.home → h.project → 3 / 4, red only #1169: a folder under the harness home refuses the move and names itself; restore → 4/4
• node scripts/ds-bot-patches.mjs check → ok 10 patches apply cleanly in order, ok core/ equals ds-bot/ + patches/ds-bot/; the mirror is byte-identical to the core file (299f7e79…)

What I checked: #1169's reading is right — DSH_HOME=/data/dsh puts tmpdir()'s project folder inside the harness home, cleanWorkDir (core/src/host/folders.js:33-36) refuses it, update-bot answers bot/refused, and the three cases waited on a session id instead of reading the answer, so a correct refusal surfaced as a two-second timeout. The three #896 cases now assert the answer first (assert.equal(answer.ok, true, answer.error?.message)) and only then wait for the session id, so a refused folder names itself. The new case is the diagnostic pointed at a folder it names, not a second copy of the timeout: it asserts ok === false, error.code === 'bot/refused', the message names that folder and says holds DeepSeek Harness data, the Bot stays in its own chat and no part is created — and it reds when the folder it names is allowed, which is the knife above. It does not depend on where TMPDIR is, so CI runs it. No product file is touched and no changelog fragment is due (test-only file set, as #1168).

Not run: full npm run verify (no git for arch-docs, no oxlint on this box) and no smoke test (nothing under core/index.js or core/src/host/ changed); CI's tests-ok and Node 24 are the reference and are green at this tip.

Non-blocking: (1) the base is bb96cc8f, behind 604ffa3a; nothing main changed since is in this diff, so merging keeps main's side — verified by running the merge tree, not the branch alone. (2) the new case's title says "under the harness home" while it names h.home (the runtime/team home); guarded() treats rt.home and rt.dshHome alike, so the assertion is right and only the title is a little loose. (3) with TMPDIR inside DSH_HOME the three #896 cases are still red — now with the guard's sentence instead of a timeout, as the header comment says; that is the diagnostic, not a green test.