[HugoXK]

fix(parts): wait for the task move before archiving the earlier part (#896)

Written-by: Dev-2

Fixes #896

Tip SHA: 2be1059

What changed

A part handoff with an armed scheduled task never archived the earlier part. moveOn finished with void rt.moveSchedules(agent.id, freshId), and runSwitch called archiveSession(agent.id) as soon as the handoff resolved, so DSH saw the old Session still active (schedule) and refused the archive; the only trace was a rt.warn line. Six sessions have leaked this way on the running product.

• core/src/host/parts.js — moveOn keeps the moveSchedules promise on the switch job instead of firing it into the void; runSwitch waits for that promise before archiving, so the archive lands after the armed tasks have moved to the fresh part. If the plain archive is still refused and the refusal reports schedule as its only activity kind, it is retried with { stopActivity: true } (the call the codebase already uses for deletions, roster.js:450, :524). A refusal caused by a job, turn or subagent is not retried: stopActivity runs every workspace/session-stop provider, so a retry there would kill that work (Security's INC on this PR). The handoff still goes out before the tasks are awaited, so the move's own latency is unchanged.
• core/test/part-archive.test.js — three cases: (1) an armed part that hands off is archived, its task is on the fresh part and none is left on the old one; (2) a failed task move still archives the earlier part with { stopActivity: true } and leaves no armed task on it; (3) a part held by a job is not force-archived — the plain archive fails, the part stays and the job is untouched, exactly as before this PR.
• patches/ds-bot/0014-flybot-branding.patch and patches/ds-bot/files/test/part-archive.test.js — regenerated (node scripts/ds-bot-patches.mjs generate, check ok).
• docs/subsystems/core-host.md — the part-move bullet states the ordering, the schedule-only condition and the stop fallback.
• changelog.d/896-part-archive-race.fixed.md.
• The branch is rebased onto current main abaebb2b in this same commit.

No start-up sweep for already-leaked parts (Chief's call, out of scope), no DSH change, no UI.

Trade-offs (deliberate, all three stated)

1. When a task fails to move, it is stopped together with its part. A task that could not be created on the fresh part still holds the old part active; leaving it there is the leak this issue fixes, so the finished part is archived with its activity stopped. The warning names the task that stayed. This is the deliberate choice.
2. A task that was already due is not moved at all. moveSchedules processes only records whose at is in the future (schedules.js:494) and leaves everything else behind, so a due task on the old part is then stopped rather than fired. That loses one due run (Test measured it: the task is dropped, not fired); the residual is written down here because a later reader would otherwise file it as a new bug. It is not fixed in this PR.
3. A refusal that mixes schedule with a job, turn or subagent is not retried. every(kind === 'schedule') fails, so the part stays unarchived with its stuck task still armed — the original leak, kept on purpose: we prefer that leak over stopping something a user still needs.

All three are consequences of the same narrow retry. The wider path is why the retry is schedule-only: Test measured that stopActivity on a running job kills it, cancels a subagent, and DSH's agent provider cancels a running turn as { kind: 'user' }, dropping queued input.

Ran

• Red on the unfixed tree, both original cases: cd core && DSH_HARNESS=… node --import ./test/harness-resolve.mjs --test test/part-archive.test.js → # tests 2, pass 0, fail 2: the earlier part is archived — undefined !== 'b'; … with its activity stopped — undefined vs ['b', { stopActivity: true }].
• After the fix, the same file: 3/3 pass (the job case added).
• Negative control for the schedule-only guard: with the schedule-only check removed from parts.js, the same file is 2 pass, 1 fail — only #896: a part held by a job is never force-archived reds, and cases 1 and 2 stay green. The guard is pinned by its own case.
• Full core suite on the rebased tree: 1336/1336 pass (cd core && TZ=UTC DSH_HARNESS=… npm test).
• node scripts/ds-bot-patches.mjs check: ok ds-bot/ = Fei2411/DeepSeek-Bot@2b10c70, ok 10 patches apply cleanly in order, ok core/ equals ds-bot/ + patches/ds-bot/.
• TZ=UTC npm run verify at the root (rebased tree): pass — core 1336, social 399, tree 125, timeline 125, scripts 332, interop 37, live-e2e 16.
• node .github/scripts/changelog.mjs check: pass.

Not run

• No smoke test: the diff is core/src/host/parts.js only; the switch path is covered by the new file plus core/test/work-dir.test.js and core/test/bot-messages.test.js, which stayed green.
• No live product instance: /home/xuke/work/FlyBot and its logs were not touched (read-only evidence).
• CI and the merge queue (GitHub).

[HugoXK]

Written-by: Dev-2

PASS request for #896 at tip 94606355d1902744fb84966c9aa93a535144e8ac (base 0c487992, T2 by risk-gate.mjs: core/src/host/parts.js=T2).

tests-ok, merge-gate, package, every plugin suite, the Node 24 job, judge, risk tier and reviewed tip are green at this tip; enqueue-guard is red only for the missing Verdict. What I ran and did not run is in the PR body.

The head is frozen: no push, rebase or new commit while the review is open. Anything a reviewer asks for comes back through the reviewer first, at a new tip, and I will ask for a fresh verdict there rather than landing on this one.

Reviewer (repo verdict), Reviewer2/Test and Security: please judge this tip. Chief is routing Test and Security separately at the same sha.

[HugoXK]

Written-by: Security

Read at 94606355d1902744fb84966c9aa93a535144e8ac (base 0c487992, 6 files +427/−12). Security conclusion: INC — the #896 fix is real and its tests are load-bearing, but the stopActivity: true retry is broader than the defect it repairs.

Ran:

• node --import ./test/harness-resolve.mjs --test test/part-archive.test.js at the tip → 2/2 pass; test/work-dir.test.js test/bot-messages.test.js → 34/34 pass (DSH_HARNESS = v832 checkout).
• Knife: the new test against the base parts.js → 2 fail; file restored byte-identical (cmp), so the tests are not vacuous.
• Probe suite at /home/xuke/.dsh/bot/workspace/pr901 (test copy with a fake schedule service gaining failAfter/failList and a jobs activity in the fake registry) → 5/5: (a) partial move — moved task stays on the fresh part, the one that failed to move is stopped, archive gets { stopActivity: true }; (b) list() failure — nothing moves, every armed task is stopped; (c) archive refused for a running job (no schedule activity at all) is retried with stopActivity and the job is killed.
• Not run: the full core suite (1333), the real DSH registry (fakes only), the live product. Nothing below is inferred from the PR body.

What stopActivity: true actually stops (DSH source, not the fixture): after the archive is written it runs every workspace/session-stop provider — schedules (dsh-schedule), jobs (running/stopping), turn (dsh-agent, cancels the running turn), and subagent (dsh-subagent, cancels running descendants). The PR's comment and changelog say "stop its activity" for a stuck task; the code cannot distinguish that case, because the retry fires on any archive failure, whatever the activity kinds were.

Reachable and silent: whenIdle waits for the turn only, not for background jobs. A part move that happens while a Bot's long bash job is still running makes the plain archive fail on job — verified in probe (c) — and the retry kills it. The user is told nothing (two rt.warn lines only). Same shape for a task that could not move: (a) leaves one task firing on the fresh part while its sibling is killed, (b) loses all of them; before this PR they kept firing on a leaked part. Neither direction is obviously right, but it is a product decision the PR body does not state, and the changelog does not mention the job/turn path.

No secrets: the new warns print the session id and DSH's error text, which for WorkspaceActiveSessionError is activity kinds only — no titles, tokens, or message content. The pre-existing moveSchedules warn prints a task title; that is not new.

Blast radius, other paths: a normal move with no armed tasks is unchanged apart from one extra list(); a move during a turn is still deferred by whenIdle; the rollback path is untouched (scheduleMove is set only after the handoff package was sent, so a failed handoff never awaits it); moveSchedules never rejects for a per-record failure, so the catch around it is narrow. One residual: moveSchedules has no timeout, and the archive is now awaited behind it — a hung service blocks the archive (the #896 leak returns) rather than destroying anything.

Suggested repair, if this is to land as-is otherwise: retry with stopActivity only when the failure is schedule activity (e.g. the registry error's .activity kinds are all schedule), and leave any other family to the existing warn — or state the product decision and mention the job-kill in the changelog. Either way the fix's test set should get one case asserting the retry does not run when a non-schedule activity is the only refuser, so the scope is pinned.

[HugoXK]

Written-by: Test

PASS at 94606355d1902744fb84966c9aa93a535144e8ac for the two #896 behaviours and for the ordering fix. On the retry I reproduce Security's INC: { stopActivity: true } stops more than the stuck task, and my probes show exactly which kinds. The head was still 94606355… when I read it just before posting (open, base 0c487992, 1 commit, 6 files); the strike at 94606355 stands by itself.

The two behaviours, driven by me, not just by the two tests. In a fresh checkout I drove the product path — update-bot with a new workDir, the same switch a context check takes — with a task armed on the Bot's Session through the schedule service, and recorded every archive attempt, move call and stop. Eighteen checks, the tip passes all of them and the unfixed tree fails nine.

• The task moves: the earlier part is archived plain (no stopActivity), the archive lands 121 ms after the task move's list started with a 120 ms delay — it waited. The task ends up on the fresh part, the old part holds none, nothing is stopped.
• The task move fails: I induced it by making the schedule service's create throw (create failed), the way a failing DSH create would. The plain archive is refused with cannot archive session 'b': the session is active (schedule), the retry archives with { stopActivity: true }, and no armed task is left on the finished part. Nothing leaks onto the fresh part.

Red-first, for the stated reason. With only the PR's core/test/part-archive.test.js grafted onto 0c487992 (no source change), both cases are red — the earlier part is archived … undefined !== 'b' and undefined !== ['b', { stopActivity: true }] — and the log names the reason, never a fixture: WorkspaceActiveSessionError: cannot archive session 'b': the session is active (schedule). My own repro at the base sees the same: 9 of 18 checks fail, and case A shows the issue's own shape from the other side — the task moved to the fresh part while the old part stayed unarchived.

Knife, tests untouched, twice over (git diff on core/src/host/parts.js only):

• revert the ordering alone (void rt.moveSchedules(...), retry kept): test A red, test B green (1/2); the repro shows the danger precisely — the archive is attempted 0 ms after the list starts, refused, and the retry then stops the task before the move can list it, so it exists on neither part (old 0, new 0). The ordering is what makes the retry safe.
• remove the retry alone (ordering kept): test A green, test B red (1/2); repro A green, B/C/D/E red — the part stays armed with schedule-1.

The retry — what is stopped, and what else. The leftover task goes: DSH's schedule provider removes the Session's armed tasks, and the archive names only the earlier Session (b); the fresh part is untouched. But the retry is not schedule-specific, and I measured the rest with the other activity kinds live on the earlier part:

• a task that was due and skipped by moveSchedules (Date.parse(at) <= now) is deleted by the retry rather than fired on the old part;
• a running job owned by the earlier part is killed (stop:job);
• a subagent of it is cancelled (stop:subagent);
• and DSH's own agent provider would cancel a running turn as { kind: 'user' }, dropping queued input. That is dsh-workspace archiveSession() writing the archive before asking every workspace/session-stop provider, then dsh-schedule stopSessionTasks, dsh-jobs registry.kill(…, "session archived"), dsh-subagent child.cancel({kind:'parent'}), dsh-agent agent.cancel({kind:'user'}). So Security's INC is right: a part merely held by a background job is force-archived and the job dies silently. Narrowing the retry to schedule refusals is the right follow-up, and the negative case (a non-schedule refusal must not be force-archived) is what I will drive at the next sha.

Frozen leaked parts. Nothing in this diff can touch the six old sessions: the new code runs only inside runSwitch, only for the switching Bot's own former Session, and only once that switch completed; no start-up sweep, no enumeration of stored Sessions, no migration. The new tests keep their fixture to the switching Bot, and neither asserts a past leak was retroactively archived.

Ran, in a fresh checkout of refs/pull/901/head (git fetch --depth=100 incl. origin/main, node_modules symlinked from the shared core, TMPDIR=/tmp):

• TZ=UTC npm run verify → exit 0: core 1333/1333, social 399/399, tree 125/125, timeline 125/125, .github/scripts 332/332, interop 37/37, live-e2e 16/16; core lint 43 warnings / 0 errors; arch-docs: OK (6 changed file(s)); 10 patches apply cleanly in order + core/ equals ds-bot/ + patches/ds-bot/; build-client --check clean.
• node --import ./core/test/harness-resolve.mjs --test core/test/part-archive.test.js → 2/2 at the tip; the same file on 0c487992 → 0/2, same refusal.
• my repro-901.mjs (drives update-bot + a fake DSH schedule/registry that honours the activity refusal) → 18 checks, 0 failed at the tip, 9 failed at the base; both knifes as above.

Not run: no live DSH instance (the fake registry implements DSH's refusal contract, copied from dsh-workspace's archiveSession, not the real service), no live schedule service, no browser/UI, and no start-up sweep — the issue deliberately excludes that, and this diff adds none.

One small body note, not a gate: the description says the archive retry happens "the way a deletion does", which is true of the call shape, but a deletion has already decided the Session ends; here the Session may still own a job. That is the INC, not a wording problem.

[HugoXK]

Written-by: Dev-2

PASS request for #896 at tip 2be10598036499624c696c0fafb60de7756a167b (base abaebb2b, T2).

Security's INC is fixed in this one commit: the { stopActivity: true } retry now fires only when the refusal's activity kinds are non-empty and every one is schedule; a job, turn or subagent holding the part is left alone, exactly as before this PR. The negative case is in core/test/part-archive.test.js (a part held by a job is never force-archived), and with the kind check removed it is the only case that reds.

The PR body now carries the trade-off in both halves: a task that fails to move is stopped with its part (deliberate), and a task already due is not moved by moveSchedules at all, so it is stopped rather than fired (written down so it is not filed later as a new bug).

tests-ok and every other check are green at this tip; enqueue-guard is red only for the missing Verdict. What I ran and did not run is in the body.

The head is frozen at 2be10598: no push, rebase or new commit while the review is open. Reviewer (repo verdict), Reviewer2/Test and Security: please judge this tip — Chief is routing Test and Security at the same sha.

[HugoXK]

Written-by: Test

PASS at 2be10598036499624c696c0fafb60de7756a167b for the two #896 behaviours, the ordering, the schedule-only retry and the negative case. The head was still 2be10598… when I read it just before posting (open, base abaebb2b, 1 commit, 6 files); my 94606355 evidence is void by the rebase, and this round was run fresh at this sha.

The negative case — which kinds I drove, and what the guard does. Through the fake registry, with DSH's real refusal shape (name: 'WorkspaceActiveSessionError', activity: [{ kind, items }], and enqueueOperation propagating that same instance — checked in dsh-workspace, so error.activity is readable in production, not only in the fake):

• job alone on the earlier part → plain archive refused (the session is active (job)), no stopActivity call, part not archived, job still running;
• subagent alone → same, subagent still there;
• turn alone (a turn that starts while the move is in flight) → same, no stop:turn;
• schedule + job together → refused with both kinds, no retry at all, part stays, job survives — and the stuck task stays armed on it. That last one is the honest edge of a schedule-only gate: when another kind also holds the part, the A part handoff with an armed scheduled task never archives the earlier part: the archive races the un-awaited task move #896 leak can still happen rather than kill the job. Safer than the INC, but it is a residual, not zero.

Positive case still works. Task move fails (create throws) → refusal is schedule only → retry with { stopActivity: true } → part archived, nothing armed left, nothing on the fresh part. Task moves cleanly → plain archive, no stop, task on the fresh part.

The two #896 behaviours and the ordering, re-run at this sha. The archive lands 121 ms after the task move's list started with a 120 ms delay (it waited), the old part keeps no task, the fresh one has it; on the failing move nothing leaks. Not carried over — same repro re-run at 2be10598.

The due task, measured — not just read from your trade-off. With a future task and an already-due task armed: moveSchedules re-creates only the future one on the fresh part (new id), leaves the due one behind; the plain archive is then refused schedule-only; the retry stops the due task — stop:schedule names exactly the due id, the old part ends archived with no armed task, and the future task is on the fresh part. So yes: a due task is dropped, not fired — one due run lost, exactly as the body now says.

Red-first, for the stated reason. The PR's three tests on abaebb2b (source untouched, test file grafted): 1 pass / 2 fail — the earlier part is archived … undefined !== 'b' and undefined !== ['b', { stopActivity: true }], with the log line WorkspaceActiveSessionError: cannot archive session 'b': the session is active (schedule); the job test passes at the base trivially, because it is a guard, not a regression case. My own repro at the base: 6 of 28 checks red, all in A/B/C, all from the same refusal.

Knifes, tests untouched, one line each (git diff on core/src/host/parts.js only):

• ordering reverted alone (guard + retry kept) → test 1 red only, 2 and 3 green;
• schedule-only guard removed (retry on any refusal) → test 3 red only, and my repro turns D/E/F/G into force-archived with the job killed, the subagent cancelled and the turn stopped — the exact INC shape, now caught by a case;
• retry removed alone (ordering + guard kept) → test 2 red only, 1 and 3 green.

Frozen six. Nothing in this diff can reach them: the new code runs only inside runSwitch for the switching Bot's own former Session, after that switch completed; no start-up sweep, no enumeration of stored Sessions or archivedSessionIds, no migration. The test fixture stays on the switching Bot and no case asserts a past leak was retroactively archived.

Ran, fresh checkout of refs/pull/901/head (git fetch --depth=100 incl. origin/main, node_modules symlinked from the shared core, TMPDIR=/tmp):

• TZ=UTC npm run verify → exit 0: core 1336/1336, social 399/399, tree 125/125, timeline 125/125, .github/scripts 332/332, interop 37/37, live-e2e 16/16; core lint 43 warnings / 0 errors; arch-docs: OK (6 changed file(s)); 10 patches apply cleanly in order + core/ equals ds-bot/ + patches/ds-bot/; build-client --check clean.
• node --import ./core/test/harness-resolve.mjs --test core/test/part-archive.test.js → 3/3 at the tip; the same file on abaebb2b → 1/3.
• my repro-901b.mjs (drives update-bot + a fake DSH registry with the real refusal shape) → 28 checks, 0 failed at the tip, 6 failed at the base; the three knifes above.

Not run: no live DSH instance or live schedule service (the fake implements dsh-workspace's refusal contract and dsh-schedule's stop, not the services themselves), no browser/UI, no start-up sweep — deliberately out of scope per the issue, and this diff adds none.

[HugoXK]

Written-by: Security

Read at 2be10598036499624c696c0fafb60de7756a167b (base abaebb2b, 6 files +487/−12), second pass after Dev-2's commit. Security conclusion: PASS — the INC is addressed; the residuals below are non-blocking.

Ran:

• Official file at the tip → 3/3 pass; work-dir.test.js + bot-messages.test.js → 34/34 pass (DSH_HARNESS = the harness checkout).
• Knife A: the three tests against the base parts.js (base abaebb2b) → cases 1 and 2 fail, case 3 green — the negative case is a regression pin, not a discriminator, which is expected. File restored cmp-identical.
• Knife B: the tip parts.js with the new guard line deleted → 10 of 14 red (the official job case plus 9 probes); only the two baseline cases and the schedule-only controls stayed green. File restored cmp-identical.
• Probe suite (14 cases, test copy with rawErrors and past-due support) → 14/14: turn-only, subagent-only, job-only; mixed schedule+job built with failCreate so the task really stays; raw ['job','schedule'] order; already-due task; missing activity, activity as a string, an entry without kind, a null entry; and a raw schedule-only refusal that still retries (the guard is not always shut).
• node scripts/ds-bot-patches.mjs check in a fresh tarball checkout (git init, index staged) → pin ok, 10 patches apply cleanly, core/ equals ds-bot/ + patches. patches/ds-bot/files/test/part-archive.test.js is byte-identical to core/test/part-archive.test.js.
• DSH shape, read from @deepseek-ai/dsh-workspace@0.2.0-rc.2 (the harness's own copy): WorkspaceActiveSessionError.activity is exactly the array the activity waterfall returned, and the four providers emit { kind: 'schedule' | 'job' | 'turn' | 'subagent', items: [...] }. The guard reads .activity structurally, so a duplicated module instance or a class-identity mismatch cannot defeat it.
• Not run: the full 1336 core suite, the real workspace registry (fakes only), the live product.

Findings:

1. The scoping holds in every direction I could build. The mixed case was the one worth being careful about: my first fixture armed a task and a job, but the task moved away before the archive, so it was not mixed at all — rebuilt with failCreate so the schedule really holds, and the part is left alone. The raw ['job','schedule'] order is blocked too, so it is not an order accident.
2. Fail-closed, as asked: no activity, a non-array, an entry without kind, or a null entry all suppress the retry. That is the safe direction, with one consequence worth knowing: a future DSH that changes the property's shape silently turns the retry off — the A part handoff with an armed scheduled task never archives the earlier part: the archive races the un-awaited task move #896 leak can return, but nothing destructive happens. The PR's fixture fabricates the same shape DSH uses today, so it cannot detect such a change; the DSH version is pinned by the harness.
3. Already-due task: schedules.js:505 skips at <= now, the part then refuses on schedule alone, and the retry stops that task with the part — fresh part gets no task, and another Session's task is untouched. That is exactly the body's trade-off 2.
4. Logs unchanged: the two warns print the session id and the error's message, which for this class is the activity kinds only. activity.items carries task/job labels and is never printed; the new guard adds no log line.
5. Residual (non-blocking): the guard judges the kinds of the refusal, not the kinds at stop time — a job that starts between the failed plain archive and the retry would still be killed. DSH has no conditional-stop API; the window is a single loop turn.
6. Residual (non-blocking, doc): in the mixed refusal the part is left active, so the A part handoff with an armed scheduled task never archives the earlier part: the archive races the un-awaited task move #896 symptom (an armed task firing on a leaked part) returns for a job/turn overlap and nothing retries after the job ends. That is the deliberate choice over killing the job, but the changelog says only "a part held by a running job or turn is left alone"; one sentence on the armed-task consequence, and on requestOf-unknown records being stopped like due ones, would keep a later reader from filing it. Not a reason to hold the tip.

The patch copy is identical, the docs line states the guard's condition ("schedule as the only activity"), framed around a failed move, and both trade-offs in the body are accurate against what I observed.

[Birfy]

Written-by: Dev2

Owner handover and base proof, read at head 2be10598 (not a new commit; nothing in this comment changes the tip).

• Base: the PR's base abaebb2b is the parent of current main 093ff4d4, and main's one newer commit touches only plugins/social/test/social.test.js. GET /compare/093ff4d4...2be10598 returns ahead_by 1, behind_by 1, diverged with exactly the PR's 6 files (+487/−12) — no file outside this PR, so the old base did not carry anything back. mergeable: true.
• Decision: no rebuild, no rebase. A rebase here would only add a tip move that voids the Security/Test evidence already measured on this sha, and the merge queue already builds against current main. If the queue run goes red on social.test.js, that is where I will rebase.
• CI at this tip: tests-ok, merge-gate, package, plugins (social|tree|timeline), Node 24, judge, risk tier, reviewed tip are all success; enqueue-guard is the only red, because no report starts with Verdict:.
• The two PASS reports on this tip (Test, Security) are prose that begins with Written-by:, so the gate reads no verdict in them. The next reviewer needs to post the conclusion in the fixed shape — first line Verdict: PASS at 2be10598036499624c696c0fafb60de7756a167b, second line Written-by: <Reviewer>, with its Ran: lines — for enqueue-guard to go green.

Labels now include agent-pr; assigned Birfy. I am keeping the tip still until a verdict lands.

[Birfy]

Verdict: PASS at 2be1059
Written-by: Reviewer
Tip SHA: 2be1059

Judged on the merge tree (main 093ff4d4 + this PR's six files), not on the PR's base abaebb2b. The branch is behind main by one commit that changed plugins/social/test/social.test.js; the merge keeps main's version of that file, so nothing main added is dropped.

The fix is the shape the issue needs: moveSchedules stops being fire-and-forget (parts.js:878), runSwitch awaits it before archiveSession (:729), and a refusal that names schedule as its only activity kind is retried with { stopActivity: true } (:738-743). The gate is the important half: a refusal listing a job, turn or subagent is not retried, so stopActivity cannot kill work a user still needs.

Each of the three cases is pinned, and I reproduced all three knives myself on the merge tree:

• reverting parts.js to main's version: cases 1 and 2 red, case 3 green;
• dropping the kinds.some(kind => kind !== 'schedule') gate so the retry is unconditional: only case 3 reds — the "never force-archive a part held by a job" guard is real, not decorative;
• work-dir.test.js stays 13/13, so the ordinary part switch is unaffected.

Ran (merge tree as described above):

$ cd core && node --import ./test/harness-resolve.mjs --test test/part-archive.test.js
# tests 3 / pass 3 / fail 0
$ node --import ./test/harness-resolve.mjs --test test/part-archive.test.js   # knife 1: core/src/host/parts.js replaced with main's
# tests 3 / pass 1 / fail 2 — not ok 1, not ok 2
$ node --import ./test/harness-resolve.mjs --test test/part-archive.test.js   # knife 2: `if (kinds.length === 0 || kinds.some(...)) return` → `if (false) return`
# tests 3 / pass 2 / fail 1 — not ok 3
$ node --import ./test/harness-resolve.mjs --test test/work-dir.test.js
# tests 13 / pass 13 / fail 0

The source was restored byte-identical after each knife (cmp clean). Not run locally: scripts/ds-bot-patches.mjs check (this box has no git); the tip's CI tests-ok covers it, and patches/ds-bot/0014 plus patches/ds-bot/files/test/part-archive.test.js are in this PR, so the generated tree was regenerated with the change.

Non-blocking, no new tip asked for:

1. The archive now waits on a promise that talks to the schedule service, and moveSchedules has no timeout: if that service hangs, the switch waits instead of finishing. Before this PR the same failure merely warned. It is the right trade for A part handoff with an armed scheduled task never archives the earlier part: the archive races the un-awaited task move #896, but it is a new way for a switch to stall, and it is worth knowing rather than discovering.
2. The rejection of job.scheduleMove is logged twice — once by the .catch attached at :879, once by the await job.scheduleMove?.catch(...) at :729. Harmless, only noisy in the log.
3. Trade-off 2 in the body is real and I confirmed it by reading schedules.js:494: a task whose at is already due is skipped by the move and then stopped with the part, so that run is lost rather than fired. Documented, not fixed here — correct call for this PR's scope.

Enqueueing now.