fix(installer): persist the installer tier as TIER in .env

[IronicRayquaza]

Fixes #7325

Update: Rebased onto current main (2026-10-04); Windows and macOS generator tests re-run and passing.

Summary

TIER is declared in .env.schema.json and read back by several components, but no installer ever writes it. The Linux phase 06, macOS and Windows env generators only put the tier into a header comment:

# Tier: 1 (Entry Level)

The readers therefore see an empty value, or fall back to their own default:

Reader	Effect today
ods status-json (--arg tier "${TIER:-}")	reports "tier": "", although its help promises mode/tier/model
ods mode, ods model current (grep "^TIER=") and ods.ps1 model current	never show a tier
ods-cli _regenerate_compose_flags, host agent TIER = env.get("TIER", "1")	always pass --tier 1 to resolve-compose-stack.sh
bootstrap-upgrade.sh compose-flags recovery	falls back to tier 1

TIER only appeared after a later host-agent model activation wrote it. This also matters for the open tier-0 memory-overlay fixes (#6077 / #5467): they resolve the overlay from the tier, and the tier never reaches the resolver.

Fix

Write TIER=<installer tier> beside MODEL_PROFILE in:

• installers/phases/06-directories.sh (TIER=$(dotenv_value "${TIER}"))
• installers/macos/lib/env-generator.sh
• installers/windows/lib/env-generator.ps1

On reinstall it is regenerated from the installer's tier, the same way LLM_MODEL and GGUF_FILE already are.

AI Assistance

Claude Code (Claude Opus 5.5) found the defect in an audit of the live main tree. It added the assertions first; the macOS and Windows generator tests failed on main with "must persist TIER". It also drafted the fix and this description. I reviewed the diff and the validation.

Release Lane

• Stable hotfix targeting release/2.6.x
• Mainline change targeting main
• Next-minor work targeting the next feature/minor release
• Not sure; reviewer should help classify

Changed Surface

• Docs only
• Tests only
• Dashboard UI
• Dashboard API / host agent
• Installer / bootstrap / lifecycle
• Docker Compose / service manifests
• Model routing / Hermes / capabilities
• Network exposure / auth / proxy
• Dependencies / runtime wiring

Risk And Validation

• Risk level: Low. It adds one schema-declared key to each generated .env. No Compose file interpolates TIER, and every reader already expects it.
• Validation run:
  • git diff --check
  • Focused tests listed below

Commands/results:

$ bash tests/test-macos-env-schema.sh                  # on main, with the new assertion
[FAIL] tier 1 .env must persist TIER for ods-cli and the host agent
$ bash tests/test-macos-env-schema.sh                  # with the fix: all PASS, tiers 1 and CLOUD validate against the schema

$ pwsh tests/test-windows-llama-memory-budget.ps1      # on main: "Generated .env does not persist TIER"
$ pwsh tests/test-windows-llama-memory-budget.ps1      # with the fix: [PASS]

$ bash tests/smoke/installer-env-smoke.sh              # with the fix
  ✓ .env validates against schema
  ✓ Installer tier is persisted as TIER
  ✓ No duplicate keys in .env

$ shellcheck --exclude=SC1091,SC2034 -S error <changed .sh files>   -> clean

Operational Change Check

• This is not an operational change.
• This is an operational change and validation is recorded above. It adds one line to each generated .env, and all three generators are exercised by existing tests that also validate the output against .env.schema.json.

Notes For Reviewers

I ran the smoke test under Git Bash on Windows. All .env assertions passed; its final grep -ohP function-resolution check needs PCRE grep, which Git Bash lacks, so that check exits early there. It runs normally on the Linux CI image.

🤖 Generated with Claude Code