Two P2 findings from codex round 7 on PR #878 were bookkept under the ship force-finalize rule (review-iteration cap reached; CI green; merged on green). Both are small, verified-plausible, and should land as a fast follow.
- Allow required finishing commands through the worker sandbox —
apps/desktop/src/main/services/ai/tools/orchestrationTools.ts:~2353 (PR comment 3635693954). The finishing worker (finishing.mode === "pr") must run git push / gh pr create / Linear-updating ade commands, but the orchestration worker sandbox blocklist may deny them — which would make the new finishing phase unable to actually ship. Verify against buildOrchestrationSandboxConfig + the worker blocklist, allowlist exactly the finishing command set for finishing-role workers only, add a test.
- Update scheduled follow-ups instead of appending duplicates —
apps/desktop/src/main/services/orchestration/orchestrationService.ts:~3252 (PR comment 3635693962). recordScheduledFollowup appends a new entry for an id that already exists instead of upserting → duplicate rows in manifest.scheduledFollowups when a worker re-records (e.g. after arming the durable schedule stamps scheduledWorkId). Upsert by id, preserve terminal statuses, add a test.
Context: both findings are against code introduced by PR #878 (orchestration completeness + hardening). Read the PR discussion for full codex bodies. The branch's patterns to follow: service-owned writes via directPatch, tests colocated in orchestrationService.test.ts / orchestrationTools.test.ts (Node 22, run from apps/desktop).
Two P2 findings from codex round 7 on PR #878 were bookkept under the ship force-finalize rule (review-iteration cap reached; CI green; merged on green). Both are small, verified-plausible, and should land as a fast follow.
apps/desktop/src/main/services/ai/tools/orchestrationTools.ts:~2353(PR comment 3635693954). The finishing worker (finishing.mode === "pr") must rungit push/gh pr create/ Linear-updatingadecommands, but the orchestration worker sandbox blocklist may deny them — which would make the new finishing phase unable to actually ship. Verify againstbuildOrchestrationSandboxConfig+ the worker blocklist, allowlist exactly the finishing command set for finishing-role workers only, add a test.apps/desktop/src/main/services/orchestration/orchestrationService.ts:~3252(PR comment 3635693962).recordScheduledFollowupappends a new entry for an id that already exists instead of upserting → duplicate rows inmanifest.scheduledFollowupswhen a worker re-records (e.g. after arming the durable schedule stampsscheduledWorkId). Upsert by id, preserve terminal statuses, add a test.Context: both findings are against code introduced by PR #878 (orchestration completeness + hardening). Read the PR discussion for full codex bodies. The branch's patterns to follow: service-owned writes via directPatch, tests colocated in orchestrationService.test.ts / orchestrationTools.test.ts (Node 22, run from apps/desktop).