Repository navigation
docs(fork): say that GitHub marks the sync pull request merged when main moves - #40
Merged
Merged
Conversation
…ain moves Force-pushing a sync branch to main makes the review pull request's head main's tip, so GitHub marks it merged and gh pr close refuses it. Step 7 said to close it, which sent agents to check why it could not be closed.
This was referenced Oct 25, 2026
martinothamar
added a commit
that referenced
this pull request
Nov 1, 2026
…#6, #9, #15, #16, #18, #21, #27, #28, #29, #38, #40, #42) Everything that exists because this is a fork rather than upstream. CI. Upstream's workflows need Blacksmith runners and secrets the fork lacks. fork-ci.yml is upstream's ci.yml on standard runners, minus the macOS jobs, behind a single "Fork CI" check; its header lists the edits a sync reapplies. fork-guard.yml disables every workflow outside the allowlist on pushes to main and on same-repo PRs that change workflows. Both also run on pushes to sync branches, whose review PRs conflict with main and so run no PR workflows. Releases. Sandboxes install the T3 server from the release matching the desktop app's version, which was upstream's, so server changes in the fork never reached them. The manual Fork release workflow publishes the desktop apps and the server archives under one preview version, building Windows on Linux and checking it on Windows and launch-checking the Linux x64 and macOS arm64 apps as release.yml does, and the app downloads SSH hosts' servers from the fork's releases. Only a run on main publishes. A run on a sync branch only builds, scripts/fork/seed-sandbox-server.ts installs that build's server in a Sandbox for testing, and a run on main with from_run publishes the tested build once main points at its commit. T3CODE_REMOTE_SERVER_VERSION and T3CODE_REMOTE_SERVER_RELEASE_BASE_URL choose another release, and the SSH bootstrap reports that version, so a reused server on another build is told to run it rather than the desktop's own. scripts/fork/install-desktop.ts installs a release, or builds one with --from-source, beside an upstream install. The dev Agent. agents/dev is an agentctl Agent (t3code-dev) for developing the fork, built on digdir-agents' ubuntu-26.04-desktop agentctl base image, which keeps /tmp on the Sandbox disk and provides agentd's image contract, Claude Code and Codex at the versions agentd is tested with, gh, the VNC desktop with the `desktop` helper and computer-use skill, gnome-keyring for Electron's safeStorage and the boot-time workspace clone. The image adds what developing T3 Code needs: Node 26, Playwright's headless shell for the web browser tests, Vite+, Rust, ImageMagick, Podman with nested networking, agentctl and agentd copied from the published agentctl 0.1.0-preview.13 release image, the kvm grant for nested Sandboxes, SSH aliases for nested Agents, a Norwegian keyboard and a 1600x900 display, and a drop-in that keeps one OOM kill over SSH from ending the other sessions. Its nested variant, for testing the image from inside a Session, builds from source without nested Sandboxes. instructions.md describes how the fork is maintained; agentd's generated Agent sandbox section and the agentctl and computer-use skills cover the platform and the desktop, so it holds only what is specific to the fork. A sync rebases the stack onto upstream's latest stable release, a nightly that upstream promoted on its main, unless the developer names another ref. The home overlay turns off Claude Code's commit and pull request attribution. The demo-video skill, with Inter beside the base's JetBrains Mono, makes captioned demo videos of T3 Code from real screen recordings of the desktop with fframes: a storyboard, scripts that record, steer the pointer, cut takes and make contact sheets, and a fframes project template whose kit holds the look and scenes so a new video rewrites only its lib.rs. AGENTS.md says how to release and install the fork, and that nothing published on the fork may reference an upstream issue, pull request or commit in a form GitHub links, since each leaves a permanent backlink on upstream's timeline: write upstream#N instead. The rule covers only what reaches GitHub; in conversation and local files upstream links are fine. The README says what the fork adds and that it follows upstream's stable releases, how to install the desktop app from a release or from source, and how to connect to Sandboxes, and links to upstream's README for T3 Code itself. The dev image is built for both architectures and published to GHCR on main; PRs and branch runs build without publishing. The ordinary dev manifest uses that image while its nested variant builds from source. Checkout credentials are cleaned after the build, avoiding traversal of vendored gitlinks. The image pins current tested harnesses, and nested tests use cheap models with minimum reasoning. Desktop verification uses a shared Browser preview. Make provides install, install-source and pull shortcuts; pull fetches and resets main to follow the fork's rewritten history. Fork builds take the usual next-patch preview version. Release notes prefer a stable tag over a nightly at the same commit and keep newer nightlies when they descend from that stable release. Installer detection and old-app notices follow upstream's Beta branding.
martinothamar
added a commit
that referenced
this pull request
Nov 1, 2026
…#6, #9, #15, #16, #18, #21, #27, #28, #29, #38, #40, #42) Everything that exists because this is a fork rather than upstream. CI. Upstream's workflows need Blacksmith runners and secrets the fork lacks. fork-ci.yml is upstream's ci.yml on standard runners, minus the macOS jobs, behind a single "Fork CI" check; its header lists the edits a sync reapplies. fork-guard.yml disables every workflow outside the allowlist on pushes to main and on same-repo PRs that change workflows. Both also run on pushes to sync branches, whose review PRs conflict with main and so run no PR workflows. Releases. Sandboxes install the T3 server from the release matching the desktop app's version, which was upstream's, so server changes in the fork never reached them. The manual Fork release workflow publishes the desktop apps and the server archives under one preview version, building Windows on Linux and checking it on Windows and launch-checking the Linux x64 and macOS arm64 apps as release.yml does, and the app downloads SSH hosts' servers from the fork's releases. Only a run on main publishes. A run on a sync branch only builds, scripts/fork/seed-sandbox-server.ts installs that build's server in a Sandbox for testing, and a run on main with from_run publishes the tested build once main points at its commit. T3CODE_REMOTE_SERVER_VERSION and T3CODE_REMOTE_SERVER_RELEASE_BASE_URL choose another release, and the SSH bootstrap reports that version, so a reused server on another build is told to run it rather than the desktop's own. scripts/fork/install-desktop.ts installs a release, or builds one with --from-source, beside an upstream install. The dev Agent. agents/dev is an agentctl Agent (t3code-dev) for developing the fork, built on digdir-agents' ubuntu-26.04-desktop agentctl base image, which keeps /tmp on the Sandbox disk and provides agentd's image contract, Claude Code and Codex at the versions agentd is tested with, gh, the VNC desktop with the `desktop` helper and computer-use skill, gnome-keyring for Electron's safeStorage and the boot-time workspace clone. The image adds what developing T3 Code needs: Node 26, Playwright's headless shell for the web browser tests, Vite+, Rust, ImageMagick, Podman with nested networking, agentctl and agentd copied from the published agentctl 0.1.0-preview.13 release image, the kvm grant for nested Sandboxes, SSH aliases for nested Agents, a Norwegian keyboard and a 1600x900 display, and a drop-in that keeps one OOM kill over SSH from ending the other sessions. Its nested variant, for testing the image from inside a Session, builds from source without nested Sandboxes. instructions.md describes how the fork is maintained; agentd's generated Agent sandbox section and the agentctl and computer-use skills cover the platform and the desktop, so it holds only what is specific to the fork. A sync rebases the stack onto upstream's latest stable release, a nightly that upstream promoted on its main, unless the developer names another ref. The home overlay turns off Claude Code's commit and pull request attribution. The demo-video skill, with Inter beside the base's JetBrains Mono, makes captioned demo videos of T3 Code from real screen recordings of the desktop with fframes: a storyboard, scripts that record, steer the pointer, cut takes and make contact sheets, and a fframes project template whose kit holds the look and scenes so a new video rewrites only its lib.rs. AGENTS.md says how to release and install the fork, and that nothing published on the fork may reference an upstream issue, pull request or commit in a form GitHub links, since each leaves a permanent backlink on upstream's timeline: write upstream#N instead. The rule covers only what reaches GitHub; in conversation and local files upstream links are fine. The README says what the fork adds and that it follows upstream's stable releases, how to install the desktop app from a release or from source, and how to connect to Sandboxes, and links to upstream's README for T3 Code itself. The dev image is built for both architectures and published to GHCR on main; PRs and branch runs build without publishing. The ordinary dev manifest uses that image while its nested variant builds from source. Checkout credentials are cleaned after the build, avoiding traversal of vendored gitlinks. The image pins current tested harnesses, and nested tests use cheap models with minimum reasoning. Desktop verification uses a shared Browser preview. Make provides install, install-source and pull shortcuts; pull fetches and resets main to follow the fork's rewritten history. make-install.ps1, with -FromSource for a build of the checkout, and make-pull.ps1 do the same in PowerShell on Windows. Fork builds take the usual next-patch preview version. Release notes prefer a stable tag over a nightly at the same commit and keep newer nightlies when they descend from that stable release. Installer detection and old-app notices follow upstream's Beta branding.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Step 7 of the rewrite in
agents/dev/instructions.mdsaid to close the review pull request after force-pushingsync/<date>tomain. That can't be done. The push makes the pull request's headmain's tip, so GitHub marks it merged, andgh pr closerefuses: "can't be closed because it was already merged". Agents keep running into this and stop to work out why, as happened when applying #39.Step 7 now says that GitHub marks the pull request merged, so it needs no closing, and to comment that the rewrite is applied.
Only
agents/dev/instructions.mdchanges. Prettier passes on it. Per the fork's process, this lands onmainas a squash merge and folds into the setup commit at the next rewrite.