chore: adapt upstream 7bd7f99e6cab

.agents/skills/fork-audit/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: fork-audit
+description: Compare upstream commits since the last audit against the q1code feature registry and report what upstream now provides, what upstream changed near a seam, and which new upstream extension points would shrink a seam. Use after a sync, on a weekly cadence, or before planning fork work, to keep the series small and catch semantic conflicts a clean rebase hides.
+---
+
+# Fork Audit
+
+Read `fork/FORK.md` and `fork/FEATURES.md` first. A rebase that applies cleanly can still be wrong: upstream may have renamed the function a seam calls, reimplemented a fork feature, or added the hook a seam was faking. This skill finds those.
+
+## 1. Find the range
+
+The last audit is the newest file in `fork/docs/audits/` (its first line records the upstream SHA it ended at) or, if none, the upstream SHA in the newest `fork/docs/sync-log/*.md`. The range is `<that sha>..main`. If it is empty, say so and stop.
+
+```
+git log --oneline --no-merges <last>..main
+git diff --stat <last>..main
+```
+
+## 2. Per feature, three questions
+
+Walk every `active`, `paused`, and `planned` entry in `fork/FEATURES.md`.
+
+**(a) Does upstream now provide it?** Search the range for commits whose title, touched paths, or contract changes overlap the feature's purpose (settings keys, capabilities fields, provider drivers, workflow files, docs under `docs/user/`). If upstream shipped the same behavior, propose `upstreamed` (drop the fork commits at the next sync) or a narrowing of the feature to what upstream still lacks. If upstream shipped something that makes the feature pointless, propose `dropped`.
+
+**(b) Did upstream change near a seam?** For each seam file in the entry (and in `fork/SEAMS.md`), check whether the range touches it:
+
+```
+git log --oneline <last>..main -- <seam file>
+git diff <last>..main -- <seam file>
+```
+
+Any hit is a semantic conflict risk even when the rebase was clean. Read the hunk against the seam's 3 lines: is the callee still there, same signature, same call order, same guard? Then run that feature's tests as listed in its entry, plus a flags-off parity check for the seam. Report pass or fail with the exact test command.
+
+**(c) New extension points?** Scan the range for additions that a seam could use instead of a hand-placed hook: new optional keys on `ExecutionEnvironmentCapabilities`, new registries or arrays (drivers, settings search items, commands, routes), new slot components, new per-instance settings, new env passthroughs, new `docs/internals/` pages describing an extension mechanism. For each, name the seam it would shrink or delete and whether the change is a fork edit or an upstream candidate.
+
+## 3. Also check
+
+- Upstream workflows added in the range (`.github/workflows/`): confirm they are disabled on q1/q1code (`gh workflow list -R q1/q1code`).
+- Upstream changes to `AGENTS.md`, `CONTRIBUTING.md`, `.agents/skills/`: anything that changes how the fork skills should behave.
+- Version or packaging changes (`apps/server/package.json`, `pinnedRuntime.ts`, release workflow) that affect the `base` update seams.
+- `Upstream: pr:<n>` commits in the series: check PR state with `gh pr view <n> -R pingdotgg/t3code`. Merged means note the SHA for the next sync; closed means decide `no` or retry.
+
+## 4. Output
+
+If an open sync PR exists for this range, append the audit as a comment there. Otherwise write `fork/docs/audits/<utc-stamp>.md` (first line: `Upstream: <end sha>`), commit it on `fork` or the open feature branch with `Fork-Feature: base`, `Upstream: no`.
+
+Format: one section per feature with findings under (a), (b), (c); a final "Proposed changes" list with concrete edits to `fork/FEATURES.md` (status changes, seam list updates) and any follow-up work (a `fork-feature` change, a `fork-upstream-pr` candidate, a test to add). Do not apply status changes yourself unless asked; the sync that drops commits does that.
+
+Keep findings specific: file, line, upstream commit SHA, what breaks or what improves. "Upstream touched ChatView" is not a finding.

.agents/skills/fork-audit/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Fork Audit"
+  short_description: "Compare upstream changes against the fork feature registry"
+  default_prompt: "Use $fork-audit to review upstream commits since the last audit against fork/FEATURES.md and report absorbed features, seam risks, and new extension points."

.agents/skills/fork-feature/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: fork-feature
+description: Scaffold a new q1code fork feature: registry entry in fork/FEATURES.md, flag in packages/fork-core/src/flags.ts, fork-owned directories, a seam checklist, the every-surface walk from AGENTS.md, and a plan that splits the commit series into upstream candidates and fork-only wiring. Use when starting any fork feature, before writing feature code, or when an existing feature needs its seams or flags re-planned.
+---
+
+# Fork Feature
+
+Read `fork/FORK.md` first, then the `base` and `prism` entries in `fork/FEATURES.md` as examples. This skill produces the skeleton and the plan; feature code comes after and follows the plan.
+
+## 1. Name it
+
+Pick a slug: lowercase, hyphenated, unique in `fork/FEATURES.md`. It becomes the `Fork-Feature:` trailer, the flag key, and the `// fork: <slug>` marker. Check `git log --format=%B main..fork | grep Fork-Feature` for collisions with dropped slugs.
+
+## 2. Registry entry
+
+Add an entry to `fork/FEATURES.md` with every field from its header. Status `planned` until the first commit lands, then `active`. Write the purpose as one line a stranger can test against. Fill "removal condition" honestly; a feature with no removal condition is a feature nobody will delete.
+
+## 3. Flag
+
+Add one entry to `FORK_FLAGS` in `packages/fork-core/src/flags.ts`:
+
+```ts
+"<slug>": { description: "...", default: false, scope: "server" | "client" | "both" },
+```
+
+Default is `false`. The only exception in the registry is `update-check`; do not add another without a written reason in the entry. Scope `server` for things that spawn, read files, or change env; `client` for pure UI preferences; `both` when the server decides and the client renders. Client-only state persists under a fork-namespaced localStorage key, never in `ClientSettingsSchema`.
+
+## 4. Directories
+
+Create only what the feature needs, under fork-owned locations:
+
+- `apps/server/src/fork/<slug>/` for services, reactors, drivers, RPC handlers
+- `apps/web/src/fork/<slug>/`, `apps/mobile/src/fork/<slug>/`, `apps/desktop/src/fork/<slug>/`
+- `packages/fork-core/src/<slug>*` for shared types, config schema, fork RPC contracts (fork RPCs are typed here, not in `packages/contracts`)
+- `packages/client-runtime` only for logic web and mobile both need
+
+Config the feature reads lives in `~/.q1code/userdata/fork.json` under a `<slug>` key with a schema in `packages/fork-core`. Secrets go through the server secret store, never `fork.json`.
+
+## 5. Seam checklist
+
+For each upstream file the feature must touch, write down: file, the exact extension point, the 3 lines, the flag guard (or why it is inert), and the marker. Prefer the extension points listed in `fork/FORK.md`. Reject any seam that:
+
+- exceeds 3 lines,
+- sits in the body of `ChatView.tsx`, `Sidebar.tsx`, or `ChatComposer.tsx` (use a `<ForkSlot />`),
+- restructures upstream code (that is an upstream PR first, or `Fork-Seam-Debt: yes` with a deadline in the entry),
+- would push `fork/SEAMS.md` over its 40-file budget.
+
+Run `node scripts/fork/seams.ts` after adding seams and paste the resulting rows into the registry entry.
+
+## 6. Hit every surface
+
+Walk the list from `AGENTS.md` and record a decision for each, including "not supported here":
+
+- **Entry points**: chat view, Settings (the q1code section), command palette, keybindings.
+- **Clients**: web, desktop, mobile. Shared logic in `packages/client-runtime`; fork UI in each app's `src/fork/`.
+- **Providers**: Codex, Claude, Cursor, Grok, OpenCode. One decision per adapter.
+- **Contracts**: fork RPCs in `packages/fork-core`; the only `packages/contracts` seam is `forkFlags` unless the entry justifies another optional key.
+- **Reverse states**: the flag off must fully undo the feature at runtime, and every action needs its inverse.
+- **Connection modes**: local, Tailscale, relay. Multi-environment: what happens when one environment has the flag on and another off.
+- **Docs**: user-facing behavior in `fork/docs/<slug>.md` (not `docs/user/`, which is upstream's); design notes in the registry entry.
+
+## 7. Candidate/no split
+
+Before writing code, split the planned commits:
+
+- **`Upstream: candidate`** first: generic changes upstream would plausibly take (a new optional setting, a passthrough, a bug fix, a model manifest entry). No `@q1code/` imports, no flag checks, no fork paths, no markers. Each must build and pass tests on plain `main`. Keep each under the size upstream's CONTRIBUTING.md calls small.
+- **`Upstream: no`** after: the flag, the seams, the fork directories, the docs.
+
+Write the split into the registry entry under "upstream" as a list of planned commit titles. If nothing is a candidate, say so; if everything is, the feature may be an upstream PR and not a fork feature at all.
+
+## 8. Tests
+
+List in the entry: behavior tests for the feature (server logic gets focused tests, receipts not sleeps), and one flags-off parity test proving the seam is inert when the flag is off (no process, no env var, no rendered element, no capabilities field).
+
+## 9. Commit the scaffold
+
+One commit: registry entry, flag, empty directories with an index file if the toolchain needs one, the seam checklist as part of the entry. Trailers `Fork-Feature: <slug>`, `Upstream: no`. Then implement in the order the split says.

.agents/skills/fork-feature/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Fork Feature"
+  short_description: "Scaffold a flag-gated q1code fork feature"
+  default_prompt: "Use $fork-feature to register a new fork feature, add its flag, plan its seams and surfaces, and split the work into upstream candidates and fork-only commits."

.agents/skills/fork-release/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: fork-release
+description: Cut a q1code release: pick the version from the upstream tag the fork sits on, tag `fork-v<upstreamVersion>-q1.<n>`, trigger `fork-release.yml`, verify the published artifacts (server tarball, web bundle, checksums.txt, install.sh), and hand off to the private deploy step. Use when `fork` is green and a new build should reach Mic's machines, or when a rollback needs the previous release located.
+---
+
+# Fork Release
+
+Read `fork/FORK.md` first. Releases are GitHub Releases on q1/q1code only; there is no npm publish and no desktop build. The desktop updater feed and the server's pinned-runtime installer both read from these releases (`T3CODE_DESKTOP_UPDATE_REPOSITORY=q1/q1code`, `pinnedRuntime.ts` seam under `base`).
+
+Deploying is not part of this skill and never happens from a sync or release job. Mic triggers deploys from the private repo.
+
+## 1. Pick the commit
+
+Release from `fork` only, at a commit where `fork-ci.yml` is green:
+
+```
+git fetch origin --tags
+git switch fork && git pull --ff-only
+gh run list -R q1/q1code --workflow fork-ci.yml --branch fork --limit 1
+```
+
+Do not release from a `sync/` branch or with an open sync PR unresolved unless the release is explicitly meant to skip that sync.
+
+## 2. Compute the version
+
+`<upstreamVersion>` is the version in `apps/server/package.json` on `main` at the merge base (`git merge-base main fork`), which upstream's nightly tagging keeps current, e.g. `0.0.39-nightly.20260902.1253`. `<n>` starts at 1 per upstream version and increments for each fork release on the same upstream version:
+
+```
+git tag -l "fork-v<upstreamVersion>-q1.*" | sort -V | tail -1
+```
+
+Tag: `fork-v<upstreamVersion>-q1.<n>`. The release workflow derives the package version and the About label ("q1code <version> on T3 Code <upstream version>") from it.
+
+## 3. Tag and push
+
+```
+git tag -a fork-v<upstreamVersion>-q1.<n> -m "q1code <upstreamVersion>-q1.<n>"
+git push origin fork-v<upstreamVersion>-q1.<n>
+```
+
+The tag push triggers `.github/workflows/fork-release.yml`. If it does not (workflow disabled, or push filter mismatch), `gh workflow run fork-release.yml -R q1/q1code -f tag=<tag>` and fix the trigger afterwards.
+
+## 4. Watch
+
+```
+gh run watch -R q1/q1code $(gh run list -R q1/q1code --workflow fork-release.yml --limit 1 --json databaseId -q '.[0].databaseId')
+```
+
+On failure, read the log, fix on `fork`, delete the tag locally and remotely, and start over at step 1. Never move a tag that a release already exists for.
+
+## 5. Verify artifacts
+
+```
+gh release view <tag> -R q1/q1code --json assets -q '.assets[].name'
+```
+
+Required assets:
+
+- `q1code-<version>.tgz`: server plus bundled web. Download it; `tar tzf` shows `package/dist/bin.mjs` and the web bundle under `package/dist/`. `npm pack`-style layout so `npm install <url>` works in the pinned-runtime installer.
+- `checksums.txt`: SHA-256 for every other asset. Verify the tarball against it; this is the integrity check `pinnedRuntime.ts` performs, since GitHub releases carry no registry integrity field.
+- `install.sh`: the manual install path (`curl -fsSL <asset url> | sh`). Run it with `sh -n` for syntax, and read it: it must install the tarball into the launcher layout under `~/.q1code/runtime/versions/<version>` and nothing else.
+- Web bundle archive, if the workflow publishes it separately from the tarball.
+- When the `prism` feature ships: the Prism engine (CLIProxyAPI) bundle per platform under `dist/prism/`, checksummed.
+
+Confirm the release notes name the upstream tag and SHA the build sits on. Confirm the release is not marked pre-release unless the tag is a nightly-style build.
+
+## 6. Smoke
+
+On a disposable base directory, run the install path end to end: `sh install.sh` into a temp `HOME`, start the server with `--home-dir <temp>`, check the About label reports the expected q1code and upstream versions, stop it by the PID you captured. Do not point it at `~/.q1code` or `~/.t3`.
+
+## 7. Hand off
+
+Report: tag, release URL, asset list with sizes and checksums, upstream version and SHA, and what changed since the previous `fork-v` tag (`git log --oneline <prev>..<tag>` grouped by `Fork-Feature`). The deploy step lives in the private repo (`services/q1code`, pin in `UPSTREAM.json`, `manage.sh`) and is Mic's call; do not run it, do not restart anything.
+
+## Rollback
+
+A release is never deleted. To roll a machine back, the deploy step pins the previous tag. To fix a bad release, cut `q1.<n+1>`.

.agents/skills/fork-release/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Fork Release"
+  short_description: "Tag and publish a q1code GitHub release"
+  default_prompt: "Use $fork-release to tag fork-v<upstreamVersion>-q1.<n>, run fork-release.yml, verify the tarball, checksums, and install.sh, and report for deploy."