fix: fail closed on production publishing

[SunkenInTime]

What changed

• make release-mode cloud configuration fail closed unless a build intentionally selects development or supplies a complete production Convex URL and client ID
• accept only canonical Convex client origins for production and reject the known development deployment
• guard stable desktop, Store, stable Pages, and production backend paths before version bumps, builds, deploys, uploads, publishing, or release commits
• normalize explicit Pages sync paths, reject rooted/escaping paths, and protect stable leaf, descendant, parent, and full-root selections
• add a Production-environment Convex deploy workflow that requires a production-scoped key and runs TypeScript and Convex tests first
• add prerelease-only 4.6.1+97 metadata and document the one-time external production setup

Intended channel model

Release mode is not itself the public production channel. CI and feature-branch prerelease artifacts intentionally use the named development deployment. Stable desktop and Store entry points require the main branch, the GitHub Production environment where applicable, and explicit canonical production Convex values before any version bump, build, deploy, upload, publish, or commit.

Verification

Current head: e6de852.

• Current-head GitHub Actions run: https://github.com/SunkenInTime/icarus/actions/runs/33833606390
  • Windows validate: success
  • native Windows PowerShell Test Release Safety Policy: success
  • Flutter analyze and full tests: success
  • native Convex bridge: success
  • Windows client and installer builds: success
  • public upgrade and rollback test: success
  • Linux: success
  • isolated Convex contract: success
• local Windows PowerShell release-safety suite: success
• feature-branch stable desktop, Store, stable parent Pages paths, and full-root Pages preflights: rejected before release work
• rooted and escaping Pages paths: rejected before publish work
• main-branch stable and Store preflights with canonical Convex inputs: accepted
• main-branch preflight with an arbitrary HTTPS endpoint: rejected
• feature-branch prerelease preflight: accepted
• focused CloudBuildConfig tests: 10 passed
• full Flutter tests: 611 passed, 2 expected skips
• npx tsc --noEmit: success
• npm run test:convex: 33 passed
• git diff --check: success

No production Convex deployment, deploy key, or production client values currently exist. This PR wires the fail-closed release path and documents the required external setup without fabricating those values.

This is a clean review replacement for #148.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Team

Run ID: 5a67b73c-4148-4b2b-b508-068e39dff5f6

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[greptile-apps]

Greptile Summary

This change makes public release paths require an intentional production setup while preserving development-cloud prerelease builds. Stable desktop workflow behavior was exercised for both blocked non-main dispatches and successful main dispatches, confirming that builds only become eligible after the Production environment gate succeeds. Production Convex deployment guards were also exercised and rejected unsafe refs and deploy-key classes before deployment.

T-Rex validation blocked

The pwsh/powershell tool is not installed in this environment. The PowerShell release-safety suite and direct release-preflight checks therefore could not execute for production cloud configuration or Pages sync-path handling. Those two protections are present in the reviewed source, but their behavior remains unresolved here. Configure VMs

Confidence Score: 3/5

The workflow controls exercised in this review block unsafe stable desktop and production backend deployment paths before build or deployment work begins.

The release workflow guard paths were executed with unsafe and allowed synthetic inputs. Direct execution of the PowerShell production-cloud and Pages safeguards could not occur because the environment lacks PowerShell, leaving those release controls unresolved.

Files Needing Attention: Run scripts/test_release_safety.ps1 in a Windows or PowerShell-enabled environment before relying on scripts/common_release.ps1 and scripts/publish_pages_branch.ps1 for public release operations.

T-Rex Logs

What T-Rex did

• We attempted the PowerShell release-safety suite and direct preflight cases, but the missing pwsh tool blocked execution, and we captured source and workflow excerpts to identify the guard and its release call sites.
• We exercised a stable non-main desktop dispatch and a stable main dispatch; the main dispatch made the build job eligible only after the Production gate succeeded, while the repository's PowerShell safety suite could not run in this environment.
• We exercised the production workflow's exact Bash guards with unsafe refs, an absent key, and a non-production key prefix; each stopped before deployment, and the allowed guard-only path with a synthetic production-prefixed key also stopped; evidence confirms the enforced ordering and test coverage.
• We captured before and after runtime/blocker evidence and current line evidence for convex release settings, including code excerpts and workflow-paths, and concluded the failure should be blocked because the PowerShell interpreter is absent.
• We ran non-main and main simulated stable dispatch tests and captured the exact commands, working directories, and exit codes, and we also documented guard deployment tests with before/after results and artifact-integrity verification.

_{Ran code and verified through T-Rex}

_{Reviews (4): Last reviewed commit: "fix(release): guard overlapping Pages pa..." | Re-trigger Greptile}

[SunkenInTime]

Addressed the current Greptile Pages-path finding in e6de852.

Explicit Pages sync paths are now normalized relative to SourceDir, with rooted and escaping paths rejected before publish work. Stable overlap is checked symmetrically, so the source root, updates/windows, downloads/windows, the stable leaf, and stable descendants all require the main-branch guard; prerelease-only siblings remain available on feature branches.

The Windows release-safety suite passes. Direct feature-branch publisher probes for updates/windows and . now stop at the stable branch guard; .. and a rooted path stop at containment validation.

@greptileai

[SunkenInTime]

Authoritative current-head Windows evidence is now complete and green for e6de852:

https://github.com/SunkenInTime/icarus/actions/runs/33833606390/job/100901515150

The GitHub Actions Windows validate job completed SUCCESS. Step 3, Test Release Safety Policy, ran scripts/test_release_safety.ps1 with native Windows PowerShell and completed SUCCESS at 2026-09-04T03:33:26Z. That current test suite includes the normalized Pages root, parent, stable descendant, prerelease sibling, escaping path, and rooted path cases.

The same job also completed Flutter analysis/tests, native bridge testing, Windows client and installer builds, and public upgrade/rollback testing successfully. Linux and Convex contract jobs in the same current-head run are green.

Please evaluate the unchanged current head using this authoritative Windows result rather than requiring PowerShell inside the Linux review sandbox.

@greptileai

[SunkenInTime]

The remaining P1 conflates Flutter optimization mode with the publication channel.

Flutter --release is intentionally used by CI and feature-branch prerelease artifacts, so an explicit development cloud selection must remain valid there. Rejecting development for every release-mode binary would break those required prerelease and CI builds.

The distribution boundary is the stable desktop, Store, stable Pages, and production backend entry points. Those paths require main before release work; stable and Store resolve explicit canonical production Convex values; stable desktop and Store use the GitHub Production approval boundary; and stable Pages publication is guarded before remote access or copying. Current-head Windows validate is green, including the native PowerShell Test Release Safety Policy step: https://github.com/SunkenInTime/icarus/actions/runs/33833606390/job/100901515150

The Greptile summary itself says no merge-blocking product defect was confirmed. Please reassess the finding against the intended channel model without requiring release-mode CI/prerelease artifacts to use production.

@greptileai