Product Support Lifecycle

Release → upgrade → diagnose → AI triage → answer. Five stages, one loop — and you can see the last one yourself.

🛟 Five stages, one loop

Every stage states what we do, how it is judged, what it produces, and where the details live.

StageWhat happensJudgementArtifactsDetails
1. Release
Build & publish		• Version authority: MRRC.iss → installed version.txt
• Three gates before anything ships: unit tests (incl. inline-JS syntax guard), full-site audit, artifact-level hotfix acceptance 3/3
• Windows packages build on a real Windows host (WDSP DLL → PyInstaller → Inno)
• Site carries latest.json (installer/previous/hotfix) and patch.json (hotfix)		Success = server-side SHA256 of the published bytes matches the manifest (local download links are not trusted)MRRC-Setup.exe · MRRC-Setup-<ver>.exe · previous archive (all in git) · latest.json · patch.jsonRelease process · Site audit tool
2. Upgrade
One click, or hotfix on restart		• Web UI → menu → ⬆️ Software Update → Install Now; or type U in the launcher window
• Download (background, SHA256-verified, atomic rename) → stop service → one UAC → silent install → automatic restart
• Roll back to the previous version with the same path
• Hotfix channel patches www/**, loose app modules and vendor without reinstalling		state.json.lastResult.status == "ok" — confirmed by the new version itself at startupupdates/state.json, upgrade.request, updates/install-<ver>.logOne-click upgrade + troubleshooting · 10 Windows traps (RC-002) · Hotfix coverage rules
3. Diagnose
One-click diagnostics bundle		• Menu → 🐞 Something went wrong → fill in the symptom → build the bundle
• Bundle = log tails + redacted config (whitelist; secrets replaced) + environment snapshot + automatic health summary
• Never packaged: user database, certificates/keys, session secrets; upload only when the user clicks it
• Health summary reads at a glance: freshness, audio health, hotfix/WDSP state, startup count & time span (restarts vs crashes), audio-device verdict		The summary must let the user (and the maintainer) tell environment from defect without reading raw logsdiagnostics/summary.txt · diagnostics/env.json · logs/ · state/config-redacted.iniSupport bundle + auto triage
4. AI triage
Scheduled, evidence-first		• A cron job polls the receiver, fetches new reports, digests them and asks the project AI with this triage skill
• The skill fixes the discipline: conservative verdicts, no verdict without evidence, environment is not a defect, every answer must be actionable
• Structured JSON conclusion (verdict/status/category/diagnosis/solution/evidence/keys)
• Guards: idempotent, never auto-publishes by default, half-packets skipped, per-run cap, timeout, narrow-PATH aware		Materials insufficient → need_more_info (never a guessed verdict); defect → needs_code_change + file/functiondist/support_answers/<id>.{digest.md,answer.json,card.html} + published answer cardAutopilot tool · Triage skill
5. Answer
Public, searchable, self-service		• Every conclusion becomes a card: id / symptom / diagnosis (with evidence) / conclusion / what to do / status
• Published to the public answers page — searchable by report id or keyword, #id jumps straight there
• Known-issue cards are written from the user-visible symptom (e.g. “🐞 page buttons do nothing” → restart MRRC to pull the hotfix)
• If it is a defect: workaround first, then fix; hotfix if patchable, otherwise a release; the card is then marked fixed in <version>		The user can solve it themselves from the card; otherwise the case enters the fix flow with evidence already attachedwebsite/answers/index.html (public), one card per report idPublic answers page · Features → lifecycle

✅ Loop invariants (use as the acceptance checklist)

  1. Installed version authority = version.txt; upgrade success = lastResult == "ok".
  2. Every release has a usable rollback target (in git, and not a known-bad version).
  3. Three gates before publish: tests + inline-JS guard, site audit, artifact hotfix acceptance.
  4. Hotfix scope is explicit (www/**, loose app modules, vendor); everything else is a release.
  5. The diagnostics bundle never contains user DB / certificates / secrets, and only leaves the machine when the user clicks upload.
  6. Auto triage never publishes by default, is idempotent, and says need_more_info when evidence is thin.
  7. Every answer is actionable and searchable by report id.
  8. Every incident adds a guard (test / tool / check) or it is not done.

🛡️ Incident-driven guards

Every incident must leave a guard behind — otherwise it is not fixed.

IncidentGuard added
IOLoop wedge / Bluetooth-DAC silent TX (RC-001)Heartbeat watchdog + thread dumps + TX-init timing probes
10 silent upgrade failures (RC-002)Ten fixes + regression tests, and “the new version self-confirms” for success
Packaging missed upgrade_core → /api/update ModuleNotFoundErrorAdded to spec _APP_MODULES; rule: newly imported modules must be registered
GBK console + emoji killed the log tee threadLauncher stdio forced to UTF-8 + _safe_print + line buffering
A quote broke the page JS → all buttons dead (6.1.12)Inline-JS syntax guard in tests (node --check, every page)
Site drift: broken links, mixed stylesheets, lagging Chinese pagesdev_tools/site_audit.py + strict test wired into the suite

🚪 Entry points