[leomontigatti]

T3 update review: 0.1.1-nightly.20261019.3373 → 0.1.2-nightly.20261021.3473 (7 releases)

Needs you

• Decide on the ready entry storage-cleanup-archived-threads (shared). T3's own cleanup now handles archived threads' worktrees. If you adopt it, it's a small edit to skills/housekeeping/SKILL.md: the archived-thread row moves to T3, and § 1 stops sweeping those worktrees itself. My pick: adopt. Risk: low. Housekeeping still sees a worktree that T3 keeps, and Settings → Storage → Last run says why it was kept. Details under Fixes / ready.

Fixes / ready

• shared · storage-cleanup-archived-threads → ready. pingdotgg/t3code#16473 ("storage cleanup reaches archived threads' worktrees", merge 034b506) shipped in 0.1.1-nightly.20261020.3386. compare 034b506...1688f96 returns ahead. From watched.diff, storageCleanup.ts:

  -    const { threads } = yield* projections.getShellSnapshot({ location: "active" })
  +    return { projects, threads: [...snapshot.threads, ...snapshot.archivedThreads] };
  +          const latest = (yield* projections.getThreadWorktreePaths({ includeArchived: true })) …
  

  Archived threads are now checked for removal by the same rules as live ones. They also count as users of a shared worktree, so T3 keeps a worktree an archived thread still uses.
  • Bookkeeping (in this PR): the entry moves from Watching to Ready, with a Met in and an Adopting line.
  • Proposed edit to skills/housekeeping/SKILL.md: remove the table row "an archived thread's worktree | T3's sweep skips archived threads | this sweep, until T3 fixes it" (or point it at T3), and drop the archived-thread case from § 1. The definition of a "live thread" (neither settled nor archived) stays.

Improves

• shared · delegate-task-reviews (evidence, in this PR). The delegate fixes in this range are #19759 (results no longer sent twice), #18826, #22653 (Stop on a delegate always clears it), #22709 (delegates finish when their leftover work settles) and #22581. The result now carries options and pendingApproval (packages/contracts/src/orchestratorMcp.ts). T3's instructions add: "Native subagents cannot reliably apply T3 model options … use delegate_task" when options are requested or inherited. I checked this against models.md. This thread inherits only fastMode: false, and Claude roles set their effort through the Agent tool's own effort, so nothing changes. The entry also records that a model hidden in Settings is missing from orchestrator_capabilities but still runs through delegate_task.
• shared · thread-launch-workspace (evidence, in this PR). #21032: with startFromOrigin: true, T3 now fetches from the base branch's own remote, not from origin by name:

  -        (yield* git.remoteExists({ cwd, remoteName: "origin" }))
  +        (yield* git.resolveWorktreeBaseRemote({ cwd, refName: baseRef })) !== null
  

  Every project here uses origin, so this changes nothing for scheduled-reviews or en-escena's scheduled-run-worktree.
• shared · scheduled-run-status (still watching, evidence in this PR). A miner said failed runs are now recorded as failed. That's wrong: the runSucceeded = result._tag === "Success" logic only moved. The status still records whether the launch call succeeded, not whether the run worked, so a run whose workspace setup fails still shows succeeded. What did change: run_scheduled_task_now "Returns the thread this run dispatched to, or null if dispatch failed". #17889 is still open.
• Checked, nothing to change:
  • scheduled-missed-runs: rescheduleMissedRun is unchanged, so a run missed while T3 was down still isn't caught up. The new webhook filters, replay keys and coalescing (#22194, #22234) don't affect us: we have no webhook tasks.
  • preview-tools-verification: snapshots of a desktop page now render at the display's scale, and the reported size is read from the PNG header. MAX_SCREENSHOT_WIDTH is unchanged and #20899 is still open, so the entry stays watching.
  • background-subagents-keep-t3-tools: #19464 settles Claude background agents when their process exits. #16598 stops a /goal from reading as complete while a background subagent is still running. Both fit the entry.
  • pr-watch-is-native: #15783 auto-settles only empty inactive threads. A thread that's babysitting a PR isn't empty, so this doesn't touch it.
  • own-thread-readable: t3_thread_read timeline items gained senderThreadId (#18194). currentThreadId and pullRequests are unchanged.
  • pcp · cleanup-unlinks-env: cleanup now passes --force to git worktree remove, but only for a worktree with submodules. pcp has no .gitmodules, so the entry still holds. Optional edit for pcp's docs/agents/t3-dependencies.md: add to Breaks if "pcp gains a submodule (T3 then removes with --force)".
  • en-escena · architecture-review-needs-app: docs/user/background-service.md gained a service.env section. It still says nothing about scheduled tasks running while the app is closed, so the entry stays watching.

Not covered

• infra (~/.t3/projects/infra): no docs/agents/t3-dependencies.md on any branch.

Still ready

• storage-cleanup-archived-threads: housekeeping hands archived threads' worktrees to T3's cleanup.

---

Method: I triaged the 372 release items by title down to 181 and checked them by hand; most were web refactors. Two gpt-6-luna miners read the two largest watched files (OrchestratorMcpService.ts and ScheduledTaskService.ts, 4.9k diff lines). I checked their findings and corrected the run-status one. I read the other 25 changed files of watched.diff in full myself. WATCHED_PATHS needs no change. Drift check: every Used by file and heading in the shared file exists. Recent commits to skills/ and the projects' agent docs add no T3 rule that an entry doesn't cover. Still open, no change: #17889, #16559, #17813, #11078, #14758, #16924, #17703, #20899, discussions/18047.

🤖 Generated with Claude Code