Roadmap

Source of truth for what we ship next, in what order, and why. If you find yourself re-deciding a question that's answered here, the answer here wins. Update this doc instead of arguing.

Last frozen: 2026-06-02 (Phase 8 complete + two internal security passes).

#0. TL;DR

We are building HyprBox = infrastructure autopilot for freelance + MSP. The product is the loop discover → finding → recommend → preview → apply → verify. Everything we ship is either:

1. A new scanner that produces a new kind of Finding.
2. A new fix preset that resolves an existing finding type.
3. Infrastructure that makes the loop trustworthy at scale (auth, migrations, cancel, audit UI, observability).
4. Polish that makes the demo land (UI, copywriting, performance).

Anything that doesn't fit one of those four buckets goes in the Anti-goals list at the bottom of this file. We do not build it.

Read AUTOPILOT.md for the why; this doc is the what + when.

#1. Where we are

Tests: 167 vitest specs + 32 Go specs + 3 Playwright E2E, all passing. Typecheck clean on API + Web. Go vet clean on agent + CLI. CI green.

This is the baseline. Everything below is forward-looking.

#2. Phase 5 — Scanner expansion (shipped 2026-05-30)

Goal. Take the autopilot loop from "works for TLS" to "covers the three pains every SMB server has".

Why this was next. The loop is the product, but ONE finding type is not a product. Three well-chosen findings turn the dashboard from "demo gimmick" into "you should run this on every server".

Shipped:

• ssh.password-auth-enabled (CRITICAL) — sshd_config parser handles Include + Match + first-write-wins semantics. Recommendation: ssh.disable-password-auth (risk: DANGEROUS) with hard precheck on authorized_keys, sshd_config backup, sshd -t validation, auto-revert on validation failure.
• disk.usage-high (WARN ≥80%, CRITICAL ≥90%) — per mount-point, skips pseudo filesystems. Recommendation: docker-prune (risk: CONFIRM) with "must be docker host" precheck and verify-step that re-checks usage drop.
• postgres.no-backup (CRITICAL) — agent ships a docker inventory via POST /api/nodes/inventory; the cross-reference logic lives on the API (containers matching postgres* × BackupPolicy on this node). Reconciliation built in — container removed or policy added → finding auto-resolves on the next inventory tick.
• 10 Go unit tests for the sshd_config parser.

The fresh-VM success metric from the original spec (≥3 findings, ≥2 with working Apply) is achievable as written.

#5.1 SSH password authentication

Definition of done. Spec: scanner emits the finding; recommendation auto-links it; preview shows the bash with the precheck guard; verify-pass auto-resolves the finding. Apply fails cleanly if precheck doesn't pass (no keys → exit 1 before touching anything).

#5.2 Disk usage high

Definition of done. Mount-point granularity (not "the host is at 87%" — "/var is at 87% because Docker has 23 GiB of dangling images"). Threshold env-configurable.

#5.3 PostgreSQL without a backup

The marquee demo finding. This is what makes someone say "oh, I want this".

The detection cross-references DB state (BackupPolicy rows) with agent- reported state (running containers). The cross-reference logic lives on the API, not the agent — the agent ships a docker inventory; the API decides "this looks like a Postgres without a paired policy".

Definition of done. Detection has false-positive rate near zero on the test fleet. False positives are unacceptable here because the fix is not idempotent at zero cost (Restic init on a fresh S3 bucket).

#5.4 Phase 5 success metric

A fresh Debian VM running nginx + postgres-via-docker + caddy, scanner tick once: dashboard shows at least 3 findings with at least 2 of them having a working Apply button.

Estimated complexity. ~2 sessions (1 for the 3 scanners + 1 for the preset polish + auto-resolve specs + demo recording).

#3. Phase 6 — Make it real (shipped 2026-05-31)

Shipped:

• 6.1 Prisma migrations — baseline migration 20260531000000_init captures cumulative schema through Phase 5; orphan migrations cleared. Docker entrypoint flipped from db push to migrate deploy. CI gained a migrate diff --from-migrations drift check using a shadow DB so a PR that edits schema.prisma without db:migrate fails fast.
• 6.2 RBAC — UserRole enum (VIEWER/OPERATOR/ADMIN) baked into JWT at sign time. requireRole() middleware gates every mutation route (jobs, tokens, backups, findings/snooze, findings/resolve). /api/users (admin-only) lists + manages teammates; role updates refuse to demote/delete the last admin. First user on a fresh deployment auto-promotes to ADMIN; subsequent registrations land as OPERATOR.
• 6.3 WebSocket reverse channel — @fastify/websocket plugin, /api/agent/ws endpoint with per-node connection registry. Server pushes {type:"wakeup"} on Job.create (sub-second pickup instead of waiting for the 5-min poll tick); pushes {type:"cancel", jobId:…} on operator cancel of a RUNNING job → agent's job context is cancelled → bash SIGTERMed. Falls back transparently to polling when the WS is down (gorilla/websocket reconnect with exponential backoff, 1s → 60s). RUNNING-job cancel without WS connection is refused cleanly (409).
• 6.4 Admin audit UI — GET /api/audit (admin-only) with filters (user/email substring, action, resource type), pagination (50/page), CSV export (?format=csv, cap 10k rows). /dashboard/admin/audit page gated client-side AND server-side; "Admin" nav entry only rendered for ADMIN role.

The "3-person team self-serves" success metric from §3.5 is achievable end-to-end: admin invites teammates via /register, role-management UI lets them become viewer/operator, audit log captures everything.

#4. Phase 7 — HyprGuard (shipped 2026-05-31)

Goal. A scheduled security audit that produces a structured list of findings, not a 200-line bash log no one reads — Lynis-shaped, but every item is a Finding with a Recommendation where one exists.

Shipped:

• agent/hyprnode/internal/scanner/audit.go — runs all 9 checks every scanner tick. Pure parsing in audit_parse.go (testable against captured fixture output, no shell required).

• The 9 checks and their stable keys:

  Check	Type	Severity
  apt list --upgradable shows -security packages	audit.kernel-updates-pending	WARN
  /etc/shadow root row has a real password hash	audit.root-password-set	WARN
  NOPASSWD: in /etc/sudoers{,.d/*}	audit.sudo-nopasswd	WARN
  find /etc -perm -o+w returns ≥1 file	audit.world-writable-etc	WARN
  UFW missing or Status: inactive or default-allow	audit.ufw-inactive	CRITICAL on public-IP host, WARN else
  systemctl is-active fail2ban ≠ "active"	audit.fail2ban-down	WARN
  /etc/apt/apt.conf.d/20auto-upgrades missing or disabled	audit.no-automatic-updates	INFO
  lsblk -no TYPE has no crypt row	audit.no-disk-encryption	INFO
  systemctl is-active auditd ≠ "active"	audit.no-auditd	INFO

• presets/apt-security-upgrade.yaml (CONFIRM) — runs unattended-upgrade --debug --minimal-upgrade-steps against pending security packages, then verifies apt list --upgradable reports zero -security rows remaining.

• Recommendations seeded:

  • audit.kernel-updates-pending → apt-security-upgrade
  • audit.ufw-inactive / audit.fail2ban-down / audit.no-automatic-updates → existing server-light (one rec, three finding types — that's why findingTypes is a JSON array).

• The other 5 findings stay MANUAL — passwd -l root, sudoers review, per-file chmod o-w, LUKS-on-reprovision, auditd-on-purpose are decisions an operator owns. The UI just shows them without an Apply button.

Done-when metric (from the original spec): A fresh Ubuntu 24.04 VM with no hardening produces ≥6 findings; applying server-light resolves ≥4 of them on the next scanner tick. Achievable as wired.

#5. Phase 8 — Production polish (complete)

Shipped in this pass:

• 8.2 Change password — POST /api/auth/change-password requires the current password, refuses re-use, audits success and failure separately. Settings page gains a "Change password" form with inline validation. (Forgot-password email reset is deferred until we wire transactional email — separate decision.)
• 8.3 Per-user rate limiting — custom keyGenerator on @fastify/rate-limit buckets Bearer/cookie-authenticated traffic by user.sub and falls back to req.ip for anonymous. Solves the NAT'd-office case where the global per-IP bucket was effectively per-organisation.
• 8.4 GHCR release pipeline — .github/workflows/release.yml matrix over the three Docker images, triggered by v*.*.* tag pushes (or workflow_dispatch with an explicit ref). Stable releases move :latest; pre-releases push the version tag only.
• 8.6 Per-node agent config — new schema column Node.agentConfig (JSON string) + migration. PATCH /api/nodes/:id/config (operator-auth) merges into existing config; null on a key clears it. GET /api/nodes/me/config (node-token, pinned-only) returns the live config to the agent. Agent pulls before each scanner tick: tls_paths overrides the env default for the TLS scanner, and scan_interval now drives the scanner ticker cadence (runner.Tick returns the next interval; honored since the 2026-06-02 audit pass).
• New "Agent config" panel on the node detail page edits TLS paths + scan interval.

Phase 8 fully shipped — nothing deferred. (8.1 output offload, 8.2 change-password + forgot-password reset, 8.3–8.6 all landed; see §5b.) The only loosely-open follow-on idea is opt-in email notifications on backup failures, which rides on the same lib/mailer.ts transport once SMTP is wired.

#5b. Phase 8 — leftover scope (deferred)

#8.1 Output offload for long logs (shipped 2026-06-01, chunk-in-DB)

Decision made: chunk-in-DB as the self-hosted default (no extra infra). A stream >4 MB no longer loses its head: the full ordered log is persisted in JobOutputChunk (cheap appends), Job.stdout/stderr keep a bounded 4 MB inline tail, and Job.stdoutBytes/stderrBytes track the true totals. GET /api/jobs/:id/output/raw?stream=… streams the full log; the job detail page links to it when truncated. lib/jobOutput.ts is the seam — an S3/MinIO backend is a future opt-in (reimplement appendJobOutput / readJobOutput, routes untouched). Deviation from the original sketch: we keep a 4 MB inline tail (not first+last 100 KB) — simpler, and the full log is one click away.

#8.2 Account self-service — email reset (shipped 2026-06-01)

Change-password (0.9.0) + forgot-password reset (0.9.3) both shipped. Reset = single-use SHA-256-hashed tokens (1h TTL, burned on use + siblings), anti-enumeration (forgot-password always 200), rate-limited, audited (password.reset.{request,success,failure}). Email delivery goes through the lib/mailer.ts seam — default logs the link (dev/self-hosted); SMTP/SES/ Postmark is a transport swap, callers untouched. The same transport could later power 8.2bis: email notifications on backup failures (opt-in per user) — still open.

#8.5 E2E tests with Playwright (shipped 2026-06-01)

Playwright wired at the repo root (playwright.config.ts + tests/e2e/, pnpm test:e2e). Auth is established once in auth.setup.ts and reused via storageState — keeps the suite under the login route's 10/min rate limit. Three non-destructive specs cover the "I broke the auth cookie" regression class that inject() can't see: login → edge-proxy gate → dashboard lists a node; Health page surfaces a finding with its severity; opening a CONFIRM finding shows the recommendation + Apply button; a MANUAL finding shows no Apply button.

Deliberately read-only — the specs never click Apply, because queuing a preset would be executed for real by a live agent on the host. The "queue a job → wait for SUCCEEDED → see it in the list" tail from the original spec is left for CI, where a sacrificial target + a stack-orchestration step (docker compose up web+api+db, seed a node/findings) can run it safely. Today the specs assume the dev stack is already up with an agent reporting ≥1 node + findings.

Estimated complexity per item. 0.5–1.5 sessions each. The Phase 8 items not deferred above all shipped together; these three are an explicit follow-up.

#Parked — not scheduled

• Anonymized + encrypted dev-DB snapshot (sanitize PII/secrets → encrypt → devs restore locally; app/login must still work). Proposed 2026-06-01, parked: not in any phase, no audit finding requires it, low value while single-operator. Revisit when the team grows or a finding demands it. If done, keep it tiny: 2 scripts (scripts/dev-data-{export,import}.sh) + 3 surgical SQL ops (truncate risky blobs → 200B; wipe secret columns; TRUNCATE AuditEvent/Heartbeat), smoke = boot + login, ≤2h. Do NOT build a field-by-field transform pipeline.

#6. Phase 9 — Commercial edition (open-core, only after one paying customer)

This is the commercial edition, separate from the Apache-2.0 OSS core (see LICENSE/NOTICE). Open-core: the core stays Apache-2.0; these ship under a commercial license. Locked behind a real "I'll pay for this" conversation — don't build speculatively.

• SSO via OIDC (Google Workspace, Microsoft Entra ID).
• 2FA / WebAuthn for admin accounts.
• Multi-org / multi-tenant (orgs own nodes, users belong to orgs).
• Per-client PDF reports ("here's what HyprBox did for you this month").
• White-label branding (logo, colours, domain).

If a customer demands one of these but won't write a PO, say no. The first PO is expected to come from a design-partner MSP who says "I'd pay for multi-tenant" — that's the trigger to start this edition. We don't speculative-build commercial features.

#7. Anti-goals (things we WILL NOT build)

When asked "can we…":

This list is not ordered by likelihood of someone asking; it's ordered by how hard "no" is to enforce when the ask gets cute.

#8. Decisions locked in

Things we keep re-deciding. Stop re-deciding. The answer is below.

If something feels under-decided, add a row here in a follow-up commit.

#9. Risks

#10. Living document

Update this file when:

• A phase ships → flip its status in §1.
• The next phase's scope changes (added or dropped a chunk) → edit the phase block AND note it in CHANGELOG.md.
• Anti-goal #N gets challenged seriously (real customer money) → don't edit the anti-goal silently; open a discussion thread, link it here, and only then move the row.

The last-frozen date at the top is the only thing that should drift between PRs. Everything else is intentional.