Repository navigation
chore(fleet): point fleet job bodies at the tailscale-serve opencode route (forward becomes fallback) #1378
Description
From the #1363 close-out (2026-10-27): fleet job bodies (stewardship-cycle's OPENCODE ACCESS PATTERN block, jules-review's supervision route, orchestration-pass's session-answer route) were switched to attach via a persistent SSH forward on 2026-10-27. The Tailscale Serve route now exists and is verified — https://amd-6.raptor-pumpkinseed.ts.net/ → the laptop background service, no SSH forward, no sshd in the data path, password auth unchanged (benchmark addendum, opencode-access-benchmark-2026-10-27.md).
Update those job bodies to name the Serve URL as the primary attach route, keeping the SSH forward as the documented fallback (bootstrap/recovery, and whenever the Serve route is down). Same handling as the 2026-10-27 pattern update: stewardship-cycle body updated as its own step without read-back; jules-review + orchestration-pass via view→update. Note in the bodies: sandbox-side calls go through the sandbox's tailnet tunnel proxy, and clients should keep connections alive (per-call TLS setup on the DERP path costs ~1–2 s; keep-alive lands ~1 s/call).
Acceptance: all three bodies name the Serve URL as primary + forward as fallback; the #1357 attach-client helper (when built) uses the same order.
Acceptance criteria
- stewardship-cycle, jules-review, and orchestration-pass job bodies all name the Tailscale Serve URL (
https://amd-6.raptor-pumpkinseed.ts.net/) as the primary opencode attach route, with the SSH forward documented as fallback. - The bodies note the sandbox proxy/keep-alive behaviour (per-call TLS setup ~1-2s on the DERP path; keep-alive ~1s/call).
- feat(fleet): attach-first opencode client helper — forward lifecycle, service discovery, stdin-safe run wrapper #1357's attach helper, when built, uses the same primary/fallback order (cross-checked at its triage).
Activity
developing-today commentedon Oct 27, 2026
CODE-473
dezren39 commentedon Oct 27, 2026
Intake review
Related: from the #1363 close-out; #1357 (attach-first client helper) must match this route order; #1382 records why sandbox-side serve access is itself blocked at platform level (job bodies run in different contexts — the route order here is for the laptop/orchestrator side).
Notes: the issue's own Acceptance line is precise; the appended section formalizes it as criteria. Job-body edits are cron definitions, not repo code.
Risks: editing job bodies without read-back has bitten before — the issue already prescribes view, then update for two of the three jobs.
Suggested approach: one fleet-maintenance pass updating the three bodies, verifying each by reading the resulting definition.
— fleet monitor intake enrichment, 2026-10-27.
dezren39 commentedon Nov 1, 2026
Transition: picked up
Worker: repo-worker-code (openchamber-scheduled-lane), task 2566
Next: Revalidate issue, job definitions, and ownership before routing.
dezren39 commentedon Nov 1, 2026
Transition: blocked — packet_defect (task 2566; repo-worker-code)
Triage: No proof was found that all three cron job definitions have been updated; they are not repository code. The original unqualified Serve URL is stale: #1363 follow-up says it was remapped to the aggregator, with OpenCode on port 4096 at that time. #1382 also corrected the earlier sandbox reachability diagnosis.
Next: Provide current, verified route and accessible canonical job definitions before routing a scoped follow-up. No job definitions were changed.
dezren39 commentedon Nov 3, 2026
agent-note:v1 — state: picked-up (task 2566, OpenChamber scheduled lane)
dezren39 commentedon Nov 3, 2026
agent-note:v1 — state: blocked (task 2566, OpenChamber scheduled lane)
developing-today commentedon Nov 3, 2026
agent-note:v1
state: reviewed (coverage loop-back)
Coverage pass 2026-11-03, loop-back review: this issue was re-reviewed (drift / overlap / already-handled / stale / blockers / ordering) so every open issue in the four repos is reviewed and in the system. Verdict: still live; in the system as task 2566 (triage, blocked, priority 40) in repo-health-code-pilot. Labels audited and synced. If it is already handled at current main, its triage closes it with evidence; if oversized, the triage files the split; blockers belong on this issue.
Found via: coverage loop-back 2026-11-03