ci(fork): report the full release scope, not just mobile - #349
Merged
Conversation
The release summary asserted that server, Discord, desktop and VS Code are promoted by the poller but never said whether this SHA actually selects any of them, so the one question worth asking — what does this release move — needed a trip to the smart host to answer. Classify all seven keys instead of only mobile, using scripts/classify-deployment-diff.sh: the same script the poller runs, so the report and the fleet cannot disagree about what a diff means. Render a table of every target against the previous released SHA, note web_hot_swap on the server row because it changes promotion from a restart to a bundle swap, and call out a non-runtime-only range explicitly rather than showing five silent "no" rows. Verified against real ranges rather than by reading. 21badd0..a5ff7e4 (the upstream import, 37 runtime paths) reports every target selected; 3a7e7a4..a5ff7e4 (workflow files only) reports deploy=false and nothing promoted. The caveat is stated in the summary rather than left implicit: the poller diffs against the last SHA it actually deployed, which is not always the last released SHA, because a skipped or partly failed promotion leaves its baseline behind. When they diverge the poller selects a superset of the reported rows, never a subset, so the table cannot claim a target is moving when it is not. Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>
omegent-app Bot
added a commit
that referenced
this pull request
Aug 6, 2026
Records the `fork/dev` development and release model — **adopted and live since 2026-08-06**. This started as a proposal; the migration then ran ahead of it, so the document is now the record rather than the plan. Documentation only. Every mechanism it describes is already merged and running. ## The model `fork/dev` is the default branch, the contributor target and the release source. It is never rebased. The provenance stack `main → fork/base → fork/tim → fork/candidates` stays rebased and feeds `fork/dev` through reviewed tree deltas, so contributor bases are never invalidated by an upstream update. | In place | | | --- | --- | | `fork/dev` cut from green `fork/integration` `21badd04e`, trees proven identical | tag `fork-dev/2026-08-06.1` | | Default branch, ruleset, squash-only, required checks | live | | CI for `fork/dev` PRs and merges | #343 | | Deployment promoting exact green `fork/dev` SHAs | ops `deploy.env` | | Validation and release split | #347, #349 | | First provenance sync, upstream `2a04db134..a2ca89a` | #345, tag `fork-dev/2026-08-06.2` | | Upstream ancestry recorded so "behind" reads true | `3a7e7a458` | | Overlays drained and deregistered | #348 | ## What this revision corrects The document had drifted from what was actually built: - **Release is two workflows, not one.** `fork-ci` decides whether a SHA is valid; `fork-release` acts on that verdict via `workflow_run`. A release action must never be able to veto a validation verdict — when mobile dispatch lived inside `fork-ci`, one failed EAS call marked a valid SHA unapprovable and stranded the whole fleet. - **Check selection is *not* path-inferred**, and the document previously implied it should be. Every PR runs all four required checks; only *release* scope is classified. A path filter that errs narrow silently skips a check on a protected branch, which is worse than a slightly slower suite. - **`fork/changes` and `fork/integration` are frozen**, not fallbacks. - Ops parameterization and the `deploy.env` cutover are **done**, not pending. - Steps that were "do now" are recorded as done, with real SHAs, tags and ruleset contents. ## What the cutover surfaced Added as a section, because each cost a round trip and the old path hid all of them: - `fork/dev` had **no CI path at all** — no `push` trigger, not listed as a `pull_request` base. - **Mobile releases would have stopped silently**; nothing errors when a gated job just never fires. - Both mobile workflows **hardcoded `ref: fork/integration`** and rejected every `fork/dev` SHA. - A release failure could **strand the fleet**. - **Every PR based on `fork/changes` was already broken** by earlier rebases — GitHub reported them as 60–100 commits and 629–741 files. Each was one commit of real work on stale history, fixed by cherry-picking that commit rather than replaying the branch. That last one is the clearest evidence for the whole premise: the old model was silently corrupting in-flight work, and nobody could see it. ## Deliberately not done Clean downstream projection is deferred indefinitely and nothing depends on it. Provenance sync stays manual. The overlay machinery is still present and still passes its tests with an empty manifest; removing it touches ~20 files and is a separate decision. ## Still open PRs #317, #226 and #185 conflict when cherry-picked onto `fork/dev`; #237 and #238 live in an external fork and need their author. `fork/changes` and `fork/integration` can be deleted once those are drained. ## Also: no guidance targets an overlay any more The overlays were drained in #348, but the instructions an agent or contributor actually reads before opening a PR still sent them at `fork/discord`, `fork/vscode`, `fork/identity`, the desktop deep-links branch, or `fork/changes`. Left alone, the next client-owned change would have been opened against a **closed overlay on a frozen branch**. - **`CLAUDE.md`** (`AGENTS.md` symlinks to it): branch from and target `fork/dev` for every kind of work; `main`, `fork/changes` and `fork/integration` named as bases never to use; the "register an `integrationOverlays` entry" instructions replaced with a record that it is empty. - **`apps/discord-bot/docs/agent-turn-rules.md`**: recovery branches pointed at *"the correct base (`fork/discord` overlay / `fork/changes` / etc.)"* → `fork/dev`. - **`fork-stack.md`, `stack-ship-path.md`, `client-overlays.md`**: bannered as superseded rather than rewritten — the provenance stack they document is still current and they are the record of how the fork worked before the cutover. The two lines that literally instructed a base are corrected. Verified by grep: nothing in the repository still directs a PR anywhere but `fork/dev`. ## Validation `vp fmt --check` clean; internal anchors checked. Documentation only — no code, tooling or workflow changes in this PR. Co-authored by [@patroza](https://github.com/patroza) opened by [Patrick Roza](https://discord.com/users/95218063095377920) in chat thread **Discord** · [Discord](https://discord.com/channels/1083767712431480922/1534783738322485399/1534783738322485399) · [T3](https://t3vm/?thread=584a9ad3-243e-4308-8a13-49acdd758b17) --------- Co-authored-by: T3 Code PR Stack <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>
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
1 participant
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.
The release summary asserted that server, Discord, desktop and VS Code are promoted by the poller,
but never said whether this SHA actually selects any of them. The one question worth asking — what
does this release move — still needed a trip to the smart host.
Change
Classify all seven keys instead of only
mobile, usingscripts/classify-deployment-diff.sh— thesame script the poller runs, so the report and the fleet cannot disagree about what a diff means.
The summary now renders, against the previous released SHA:
Plus the diffed range, the classification basis, a collapsed changed-file list, and:
web_hot_swapshown on the server row, because it changes promotion from a restart to a bundleswap — a materially different operation to read as "server: yes".
norows that look like abug.
Verified against real ranges, not by reading
21badd04e..a5ff7e40c(upstream import, 37 runtime paths)deploy=true, every target selected3a7e7a458..a5ff7e40c(workflow files only)deploy=false, nothing promotedThe caveat, stated in the summary itself
The poller diffs against the last SHA it actually deployed, which is not always the last
released SHA — a promotion it skipped, or one that failed part-way, leaves its baseline behind this
one. When they diverge the poller selects a superset of the reported rows, never a subset, so the
table cannot claim a target is moving when it is not. That direction is the safe one, and it is
written into the summary rather than left for someone to rediscover.
Making it exact would mean reading poller state that lives on the smart host and is not reachable
from CI, so the report is honest about being a faithful re-computation rather than a mirror.
Co-authored by @patroza
opened by Patrick Roza in chat thread Discord · Discord · T3