Build normal and debug flavors from each release version #116

Problem

CodexHub needs a long-lived diagnostics-capable build for reproducing intermittent Desktop/Gateway failures, but that must not create a second product line or a divergent version history. Treating a diagnostics build as a separate version/channel would make behavior comparisons less trustworthy and allow release/update drift.

Outcome

Every release commit/tag can produce two release-optimized build flavors from the same source and semantic version:

• normal — the default user build and current behavior.
• debug — the same product behavior plus compile-selected diagnostic capabilities owned by a separate Issue.

Flavor is build identity, not SemVer identity. For example, both artifacts built from tag v0.2.0 report version 0.2.0; build metadata separately reports normal or debug.

Architecture invariants

• Use one code line, dependency lock, commit, tag, version, application identifier, configuration schema, and runtime-home authority.
• Both flavors are release-optimized builds. debug must not mean Rust/Tauri debug assertions or an unoptimized developer build.
• The default build command produces normal; selecting debug must be explicit and deterministic.
• Installing one flavor replaces the other as the same application while preserving supported settings/runtime data. The two flavors must not run as independent CodexHub installations or start two Gateways.
• A flavor switch does not migrate or rewrite user configuration. Persistent diagnostic data is ignored safely by normal and remains governed by the recorder retention contract.
• normal retains the existing update endpoint/asset compatibility. A debug build selects a flavor-specific artifact/manifest from the same GitHub release/tag, so an automatic update never silently changes it back to normal.
• Flavor-specific behavior is selected at build time. A normal binary must not expose a runtime switch that activates debug-only recording.

Scope

• Add one build flavor input (normal|debug) to Windows portable and installer/release scripts; default to normal.
• Add a compile-time feature/constant and a small build-info interface that returns semantic version, flavor, source revision when available, and diagnostics capability state.
• Produce unambiguous artifact names, for example the existing normal name and a -debug suffix for the debug artifact, while retaining the same semantic version.
• Keep latest.json compatible for normal builds and publish a debug-flavor manifest/asset in the same release. Make update selection flavor-aware and fail closed on a mismatched manifest/artifact.
• Display a persistent, localized Debug diagnostics badge/status in the debug UI; normal UI remains unchanged.
• Add a two-flavor CI/build matrix that proves both artifacts are derived from the same commit/version and that normal remains the default.
• Document the supported build commands and the same-version flavor-switch behavior.

Non-goals

• A separate debug branch, tag series, SemVer prerelease, product identifier, runtime home, or configuration format.
• Shipping a Rust/Tauri development build to users.
• Implementing the persistent recorder, incident retention, log export, or Find and fix Responses disconnects across official and external routes #114 root-cause fix.
• Allowing normal and debug installations to coexist or run separate Gateways.
• Changing provider routing, Responses behavior, retry policy, or telemetry schemas.

Acceptance criteria

• One clean commit/tag builds both normal and debug through documented commands; both report the exact same semantic version and source revision and report different flavor values.
• Omitting -Flavor builds normal; invalid flavor values fail before compilation.
• Both artifacts are release-optimized and signed/bundled through the existing release process.
• Artifact and manifest names cannot be confused; the normal update contract remains backward compatible for installed normal users.
• Update checks/downloads stay within the installed flavor for later semantic versions and reject a flavor mismatch before install.
• Installing debug over normal, and normal over debug, preserves supported settings/runtime state and leaves exactly one application/Gateway ownership path.
• Debug UI visibly identifies the flavor; normal UI has no debug indicator or debug-only command surface.
• Normal build behavior and existing update tests are unchanged apart from additive build-info metadata.
• CI exercises both flavors and verifies version/commit parity plus default-normal behavior.

Verification

• Focused Rust tests for flavor parsing, build-info, updater endpoint/manifest selection, mismatch rejection, and default-normal behavior.
• PowerShell tests/smokes for portable and installer flavor arguments, artifact names, manifest contents, invalid inputs, and same-tag parity.
• Frontend build and UI-contract tests for debug indicator present/normal absent.
• Packaged Windows smoke for normal -> debug -> normal same-version replacement with configuration preservation and a single Gateway owner.
• Full repository-required Rust/Python/frontend gates and python scripts/report_quality_gates.py (report-only).

Expected hotset

• scripts/build-windows.ps1, scripts/build-windows-portable.ps1, and scripts/build-windows-release.ps1.
• src-tauri/Cargo.toml, src-tauri/build.rs, src-tauri/tauri.conf.json, and a small build-info module.
• src-tauri/src/app_updates.rs and focused updater tests.
• Small frontend build-info/badge wiring, localization, and UI-contract assertions.
• Release/CI documentation and scripts.

Dependencies and relationships

• No hard blocker; this can run in parallel with Move Python proxy telemetry writes to a bounded async writer #6.
• Blocks the persistent debug recorder Issue that will consume the compile-selected diagnostics capability.
• Related: Find and fix Responses disconnects across official and external routes #114 owns disconnect root-cause diagnosis; Add a privacy-safe diagnostic log export for user support #115 owns privacy-safe export.