chore(upstream): sync marcode through a3a8cbd6

[maarco]

What Changed

Daily upstream sync. Merges pingdotgg/t3code@a3a8cbd60539b4af4de8f96c892dbd07a2b6c041 (32 commits, f035a0f4..a3a8cbd6) into main as a normal two-parent merge commit (c13db692).

Notable upstream work in this delta: v0.0.34, the hosted legacy-model manifest (pingdotgg#8227), Claude pre-emptive compaction (pingdotgg#8144), thread↔pull-request linking (pingdotgg#8160), un-settled threads returning to the top of the list (pingdotgg#8231), the macOS service PATH fix that keeps provider CLIs reachable (pingdotgg#8173), the push fix that stopped writing a feature branch's commits to its base (pingdotgg#8228), and case-insensitive terminal/markdown link detection (pingdotgg#7488, pingdotgg#8081).

Twelve files conflicted. Each was resolved by hand, combining both intents — no whole-file ours/theirs, no reset/restore/stash/clean/force push.

Conflict decisions

apps/server/src/persistence/Migrations.ts (hotspot: persistence)
Marcode's 033_ProjectWorkspaceLayout offsets every shared migration by one, so upstream's two new migrations were renumbered on the way in: 042_ProjectionThreadLinkedPullRequest → 043, 043_ProjectionThreadsUnsettledAt → 044. Upstream's 042 filename would otherwise have collided with Marcode's 042_AuthSessionClientConnection. The ported migration test's toMigrationInclusive ids were updated to match.

apps/server/src/cloud/bootService.ts / .test.ts (hotspot: server-runtime)
Took upstream's launch-agent PATH export and kept Marcode's MARCODE_HOME key, which resolveLauncherBaseDir requires. Both assertions now run: Marcode's env-name pin and upstream's new PATH assertion. The Marcode pin moved onto the shared macRenderOptions so it exercises the same call shape as the rest of the suite.

apps/server/src/environment/ServerEnvironment.ts / .test.ts, packages/contracts/src/environment.ts
Purely additive on both sides — kept workspaceLayoutMutations alongside upstream's threadPullRequestLinking capability.

apps/web/src/components/ChatView.tsx (hotspot: web-runtime)
Kept Marcode's title-only ChatHeader (thread actions are portaled into FloatingPillNav) and took upstream's settleThread hook; handleNewThread is already declared a few lines below, so only the new binding was taken.

⚠️ The one that would have broken silently. Upstream renamed its project-scoped PR opener to openProjectPullRequest/activeProjectRepository and introduced a new openThreadPullRequest that resolves a thread's linked PR. Marcode's ThreadActionsCluster call site used the old names and sits outside the conflict region, so a clean merge would have quietly repointed the pill nav at the linked-PR opener. Followed upstream's rename at Marcode's call site instead. This is the change most worth a second pair of eyes.

apps/web/src/components/ChatMarkdown.tsx (hotspot: editor-runtime)
Took upstream's editor-label and remote-open imports plus the workspace basename lookup, and kept the floating-editor seam. Dropped upstream's useRightPanelStore/useActiveEnvironmentId imports: Marcode retired the right-panel file surface, so openFile has no call site here and environmentId now derives from threadRef. The existing rightPanelStore.test.ts pin (store.openFile is undefined) is what makes re-introducing upstream's path a type error rather than a silent regression.

apps/web/src/components/chat/OpenInPicker.tsx
Took upstream's editorLabelForPlatform refactor (labels lifted out of the option table) and kept Marcode's filled FolderOpenFilled glyph.

apps/web/src/components/ThreadTerminalDrawer.tsx
Kept Marcode's xterm link provider (the documented deliberate divergence, retained for terminal search). Upstream's change here only swaps an inline regex for isTerminalUrl inside its ghostty activation handler; Marcode classifies through extractTerminalLinks, which already picks up the case-insensitive URL_PATTERN that merged cleanly into terminal-links.ts. So the fix lands on Marcode's path too, via the shared producer.

scripts/build-desktop-artifact.test.ts
Kept both imports and both assertions; only the provisioning-profile fixture path stays Marcode-shaped.

pnpm-lock.yaml
Kept Marcode's @xterm/* entries alongside upstream's Clerk bumps. pnpm install --frozen-lockfile succeeds against the merged tree, which is what validates this resolution.

Coupled changes

Neither coupling fired. pnpm-workspace.yaml moved only Clerk versions (Effect catalog entries unchanged), and infra/relay/package.json is untouched — so no sync:repos for effect-smol or alchemy-effect.

Fork-boundary sweep

Grepped the merged tree for upstream identity Marcode renames. No silent breaks:

• T3CODE_HOME, t3code.service, WORKTREE_BRANCH_PREFIX, boot-service naming — all still Marcode-correct.
• T3_BOOT_SERVICE_UNIT, T3_SERVICE_LAUNCHER_CONTEXT, @t3tools/*, the t3 package/CLI name, refs/t3code/* and t3code:* storage keys — deliberately left upstream-shaped. Upstream's new t3code:resume-compaction-dismissed:* key follows that same convention, so it was kept as-is.

Two decisions worth a maintainer's call

1. apps/server/src/provider/ModelManifest.ts fetches from raw.githubusercontent.com/pingdotgg/t3code/main/.... Left pointing at upstream: it is a schema-validated, read-only GET of a public "which models are current vs legacy" file, with the checked-in model-manifest.json as fallback. Repointing it at maarco/marcode would make the remote copy identical to the bundled one and defeat the feature. Flagging it because it is a new outbound call the fork inherits.

2. .github/workflows/desktop-macos-preview.yml (new) runs on blacksmith-12vcpu-macos-26, a runner label the fork cannot reach. Left as-is: it is gated behind a preview:mac label that nobody applies here, it is not a required check, and it matches how release.yml and mobile-showcase-screenshots.yml are already carried. Rewriting it would add merge surface for a workflow that never fires. The ci.yml runner pin in scripts/upstream-sync-workflow.test.ts is unaffected and still green.

Why

.github/upstream-sync.yml schedules a daily merge of upstream into the fork. This delta conflicted, so per docs/operations/upstream-sync.md it was resolved by hand on a branch and opened as a draft review PR rather than pushed automatically.

UI Changes

No Marcode-authored UI change. The conflict resolutions preserve existing Marcode surfaces (title-only chat header, pill-nav thread actions, floating editor, xterm terminal, filled folder glyph) rather than altering them. Upstream's own user-visible additions in this delta — the resume-compaction banner, thread↔PR linking, HEIC attachment support, the settle/restore shortcut — have not been driven in a browser here; per the runbook's step 5, that runtime verification is still owed before this leaves draft.

Verification

Focused, per the changed scope. Not the full workspace suite — CI owns that.

• pnpm install --frozen-lockfile — clean
• Typecheck: @t3tools/contracts, @t3tools/web, t3 (server), @t3tools/scripts — no errors (Effect lint suggestions only, all pre-existing)
• vp test run — 30 files / 524 tests passing across: bootService, ServerEnvironment, all 13 persistence/Migrations/, ProjectionRepositories, ProjectionSnapshotQuery, decider.settled, projector.settled, serverSettings, ChatMarkdown (+ workspace-images), terminal-links, editorLabels, Sidebar.logic, rightPanelStore, versionSkew, contracts/settings, contracts/orchestration, build-desktop-artifact, upstream-sync-workflow, sign-macos
• vp fmt --check on all 14 resolved files — clean
• vp lint on the changed directories — warnings only, all pre-existing at main (including ThreadTerminalDrawer's unused ContextMenuItem type import, verified against HEAD~)

Not verified here

• Runtime/browser verification (runbook step 5) — this container has no display; the web and mobile hotspots in this delta have not been driven at 390px/820px.
• vp run icons:check — assets/** and apps/desktop/resources/** are untouched by this delta, so it should not apply, but it was not run.
• Root-container caveat — no chmod-based permission test appeared in the focused set, so nothing was suppressed on that basis.

Checklist

• This PR is small and focused — one concern: the upstream merge
• I explained what changed and why
• I included before/after screenshots for any UI changes — no Marcode-authored UI change; upstream's UI additions still need the runbook's live pass before this leaves draft
• I included a video for animation/interaction changes — n/a

---

Generated by Claude Code

[maarco]

CI is stalled repo-wide — not this PR

Standing down on CI here, because the blocker is outside this branch. Recording it once rather than re-running again.

What happened on c13db692:

1. CI run 32985346461 recorded startup_failure 9 seconds after starting, before any job body executed. It then kept creating jobs after it had been marked complete (Mobile Native Static Analysis was created at 15:32:30; the run was marked failed at 15:30:55). All 9 jobs sat queued on stock ubuntu-24.04 / macos-26 labels.
2. I re-ran it once. That cleared the failure conclusion (run_started_at reset to 15:45:04), but the run has since sat queued for ~15 minutes with zero jobs created and zero check runs on the PR.

Why this is not this PR's failure:

• .github/workflows/ci.yml is byte-identical to main — this merge touched only release.yml and added desktop-macos-preview.yml. Confirmed with git diff HEAD^1 HEAD -- .github/workflows/ci.yml (empty).
• All 17 workflow files parse as valid YAML.
• The PR is trivially mergeable: its first parent is main's head (133f3f73), so there is no merge ref for Actions to fail to compute.
• The decisive one: PR Size (32985278705) has also been stuck queued since 15:29:25 with updated_at never advancing. That workflow is a ~25-second github-script job that has completed successfully on every prior run, and it runs on pull_request_target against main — it does not touch this branch's code at all. It is stalled too.

So every Actions run on this repository since 15:29 UTC is stuck, regardless of workflow, trigger, or ref. Nothing in this diff can produce that.

What would unblock it: most likely an account-level Actions problem — a spending/billing limit on included minutes, or a GitHub incident. Worth checking Settings → Billing → Actions spending limit, and githubstatus.com. Once runners are scheduling again, re-running 32985346461 should be enough; no push is needed.

Local verification, for what it is worth while CI is unavailable (full detail in the PR description): pnpm install --frozen-lockfile clean, typecheck clean on contracts/web/server/scripts, 524 focused tests passing across 30 files, vp fmt --check clean on all 14 resolved files, lint warnings only and all pre-existing. That is not a substitute for the four required checks — this PR should not leave draft until Check, Test, Mobile Native Static Analysis, and Release Smoke are actually green.

My one re-run is spent. I am leaving the PR watched; if CI comes back red once runners recover, I will treat it as real and root-cause it rather than re-running.

---

Generated by Claude Code

[github-actions]

Thread transfer impact

⚠️ The latest CI run did not produce a thread transfer result for c13db69.

This comment will update automatically after the next completed run.

[maarco]

Correcting two things I got wrong, and: this PR is superseded

1. Actions was not down. My previous comment was wrong.

I claimed a repo-wide Actions outage. That was incorrect, and I should not have asserted it.

The scheduled Upstream Sync workflow ran on the same ubuntu-24.04 runner as ci.yml's Check job and completed normally on 8/27 (17:59, ~90s) and 8/28 (18:26, ~90s) — both after this PR's runs were already stuck. Runners were healthy the whole time.

What actually happened is that this PR's runs were created at 15:29–15:30 on 8/26, never got scheduled, and GitHub expired them as cancelled on 8/29. With four XXL upstream-sync PRs (#53, #55, #56, #58) open simultaneously, each fanning out ~9 jobs, capacity contention is the likelier explanation than an outage. I did not prove that, and I'm not going to assert a second theory as fact — the honest statement is: these runs were never scheduled, and I misdiagnosed why.

2. My headline "silent break" finding was wrong.

The PR description flags the ThreadActionsCluster rename as "the one that would have broken silently." Having re-read the merged source, that was a misreading:

const openThreadPullRequest = useCallback((number) => {
  const projectId  = linkedThreadPullRequest?.projectId  ?? activeProject?.id;
  const repository = linkedThreadPullRequest?.repository ?? activeProjectRepository;
  ...

openThreadPullRequest falls back to the project when a thread has no linked PR — it is a strict superset of openProjectPullRequest. Leaving Marcode's call site alone would have been correct, and would have gained the linked-PR behavior for free. My change narrowed it: the pill nav now always resolves the project repository and ignores a thread's linked PR, and the gate moved from threadRepository (linked ?? project) to the narrower activeProjectRepository.

Not a break, but a small regression introduced by my resolution rather than prevented by it. #56 and #58 both read this correctly and dropped openProjectPullRequest as unreachable. They were right; I was not.

3. This PR is superseded by #58 — recommend closing unmerged

Verified locally: a3a8cbd6 is an ancestor of #58's head 0a265857, so #58's f035a0f4..018d7f27 delta strictly contains this one. #58 has all four required checks green, resolves 24 paths including everything resolved here, and gets the openProjectPullRequest call right. It also caught a Migrations.test.ts slice(-10) pin that my focused local run missed and CI here never got to run.

So there is nothing worth salvaging from this branch, and no reason to spend contended CI capacity driving it to green. My recommendation: close #55, #56, and #53 unmerged and review #58. I'm leaving that call to you rather than closing it myself, in case you want to compare resolutions across them first.

The local verification recorded in the description (frozen-lockfile install, four typechecks, 524 focused tests, fmt/lint) did all genuinely pass — but it never faced CI, and CI is what caught the migration-pin issue in #58. Treat this branch as unverified.

---

Generated by Claude Code