---
name: gururmm-install-report-failed-agent-v1
description: GuruRMM legacy-installer v1 must reuse /api/install-report AND create a visible "failed-install agent" server-side (Mike, 2026-06-12)
metadata:
  type: project
---

For the SPEC-029 legacy-fleet build, Mike decided (2026-06-12) the observable-installer
requirement is satisfied by the EXISTING `install-report` channel, extended:

- **Reuse `/api/install-report`** (do NOT invent a new beacon). The MSI already POSTs rich
  machine info + event/agent logs + service status there, success AND fail (`InstallReportCA` +
  `installer/install-report.ps1` → `server/src/api/install_report.rs`, recorded to `install_reports`).
  The **new NSIS 32-bit/legacy installer must POST the same payload** — this finally covers the
  legacy tier (today it has no installer → zero install-reports = the biggest blind spot).
- **Failed-install agent IN v1 (Mike's call):** on a report indicating failure (service not Running
  after poll / no enrollment / connect-verification failed), the server **upserts a visible
  "failed-install" device record** — keyed by hostname + machine fingerprint (so retries update one
  record, no spam), carrying machine info + failed-step/reason + log refs + attempt count. Shows in
  the dashboard as FAILED-INSTALL (distinct from healthy agents), triage-able + alertable. **Reconcile**
  if the box later enrolls for real (don't leave a ghost). Success reports don't create a failed agent
  but still feed trend/near-fail analytics (failure-rate by OS/arch/version — build-shaping signal,
  mirrors SPEC-022 §5e patch telemetry).
- Installer must **verify enroll/connect before declaring success** ("don't terminate until success")
  and emit a meaningful exit + a local diagnostic bundle on fail.

Scope split: the running legacy-agent Coding Agent does the agent + NSIS installer (+ the install-report
POST). The **server-side failed-install-agent + trend analytics is a separate, sequential** work item
(can't run a 2nd agent in the same submodule checkout concurrently) → its own SPEC after the first
branch lands. See [[gururmm-log-analysis-claude-cutover]] for the server deploy shape.

**Note (Mike, 2026-06-12):** the legacy build must eventually be folded into the MAIN
production builds for **agent parity** (not a separate side-build). build-windows.sh already
emits legacy-x86/amd64 in WAVE 2, but the legacy INSTALLER + the SPEC-029 §12 fixes need to
become first-class in the promoted pipeline. For now, scoped TEST artifacts off the
`fix/legacy-32bit-agent` branch are fine (Mike OK'd) — productionize after the Win7 VM proof.