Staged Releases

New

• Push to Staging, then Release — Shipping a release is now two clicks instead of one. The release moves through ready → staged → released with a real preview-deploy checkpoint in between. Push to Staging walks each repo up its staging chain (default dev → staging) and force-resets the chain tips so your preview environment lands on exactly the release branch's tip. When the staged deploy looks good, click Release to run the release pipeline (preflight → SEO audit/fix on web targets → release notes → human gate → tag the production branch).
• Yank Back from staging — If the staged deploy is broken — failed smoke tests, regression slipped through, build problems — click Yank Back in the release detail panel. Trinity force-resets each repo's staging-chain tips to the snapshot it took the moment the release reached staged, returns the release to ready, and any in-flight stories on top of the yank resume normally.
• Staging Drift detection — While a release is staged, a Staging Drift tile in the release detail panel watches whether any repo's staging tip has moved since the release was staged (someone merged something separately, a hotfix went straight to staging, etc.). When drift is detected, a Redeploy to Staging button appears inside the tile so you can refresh the staged state in one click.
• CI on Staging tile — Alongside the drift tile, a CI on Staging tile surfaces the status of CI runs against the staged tips, so you don't have to switch to GitHub to see whether the preview-deploy checks are green.
• Retry Failed Repos — When the staging walk fails mid-flight for some repos but others made it through, the release lands in staging_failed or partially_staged with a per-repo status table. Click Retry Failed Repos to re-run the walk for the repos that didn't make it, without touching the ones that did.
• Release Dashboard with tactical tiles — Four tiles at the top of every release detail panel: Run Project (boot the project locally), Run SEO (standalone SEO audit), Run Audit (standalone codebase audit), Generate Notes (release notes draft). Each runs its agent against the current release worktree without advancing the lifecycle, so you can spot-check work in progress or refine release notes before shipping. While the release is in any staged status, every tile except Run Project locks (the staging deploy is the source of truth — re-running tactical agents at that point would diverge from what's on staging).
• In Progress release status — Releases now show an explicit In Progress column on the Releases page once the first story merges, separate from Not Started (empty release) and Ready to Release (every story terminal). The Releases page lays out five columns: Not Started, In Progress, Ready to Release, Releasing, Released.
• Stop a release mid-flight — A Stop button appears while a release is releasing. Hitting it halts the release pipeline and returns the release to ready so you can adjust scope, edit a story, or push a fix — then start shipping again from where you left off.
• Reparent a PRD between releases — In addition to Move (which reassigns a PRD and all its stories to a different release), each PRD row in the release detail panel now also has a Reparent action. Reparent changes the parent release without moving the PRD's stories — useful when the release structure changes underneath you and you want to point an in-flight PRD at a different parent without dragging its work along.

Improved

• Production branch and Staging chain — The branch settings are now named for what they actually do. Production branch is the final base branch (was Main branch); Staging chain is the ordered list of branches a story walks on merge (default dev → staging). Cleaner labels in Project Settings, in the per-repo overrides, and across the rest of the app.
• Live release status updates — Release status changes (push to staging finished, drift detected, CI ticked over) now push to your desktop the instant they happen, instead of waiting for the next poll. No more refreshing the Releases page to see whether staging is done.
• Smarter conflict resolution on long-lived release branches — When a feature branch merges back into a long-lived release or chain branch and hits conflicts, Trinity's conflict resolver now uses an upstream_merge strategy that's safer for receiver branches with downstream refs already cut from them. Fewer broken release branches when conflicts pile up across a release.
• Walk-up tree fan-out — When a release's dependencies need updating after a merge, Trinity now fans out the walk-up across background jobs instead of doing it serially. Bigger release graphs (PRDs that depend on PRDs in other releases) update much faster.
• Recheck at the staging and release gates — The "every story is terminal" check now re-runs at the exact moment you click Push to Staging or Release, not just when the release first transitions to ready. Catches the edge case where a story unexpectedly reopens between when the release goes ready and when you hit the button.

Fixed

• Fix-branch diffs use the right base — When a feedback or fix loop computed what changed since the last gate, it could compare against the integration branch instead of the release branch on release-branch-isolated projects, surfacing extra noise or missing real changes. Fix-branch diffs now always compare against the release branch.
• Stale-diff predicate fixed at release approval — The release approval flow used the same stale-diff comparison as the fix loop, so it caught the same bug — the post-gate diff could include unrelated changes from the integration branch. Same fix applied; release approvals now diff against the release branch every time.
• Tag reads are project-scoped — Tag lookups (used by filters, story metadata, and the tags API) could leak rows from other projects in the same scope. Every tag read now filters by project id, so you only ever see your own project's tags.
• Release approval "Request Changes" rejoins the fix loop — Clicking "Request Changes" on a release approval gate used to leave the release in an awkward in-between state. It now routes through the standard feedback fix loop so the request is acted on and the release transitions cleanly.
• Phase queries read the right column — A planning rule that decides which phase a story belongs to was reading a stale column reference, which could mis-place stories during dependency mapping after a phase was renamed or restructured. The rule now reads the canonical phase sequence number.
• Project stats reflect merged-to-release counts correctly — The Projects API stats query (used by the project list, dashboards, and the project chip) read a legacy column that no longer reflected the merged state of stories. Counts now match the in-app story status throughout.