MalloryEstate Briefing
M·062Reference
← All briefings

Estate

Roadmap

From Round 1 safety-net triage through a reframed Hermes direction to the current VM-to-Goose migration.

Dated 2026-07-18Programme Estate

Situation

As of 2026-07-18, the foundational waves (capability self-awareness, the calm feed, recall, proactive notifications, modes) are shipped and live, alongside Loops→Task Workspaces, the Q Command Center R&D surface, three-persona voice routing (Round B, deployed), device-signal mode hints, a cross-persona handoff protocol, deploy-from-Tower, Model Settings routing, and Response-SLA monitoring. The active operational track is migrating the Hub's LLM cron plane off the claude.ai subscription onto self-hosted Goose + OpenRouter, triggered by a week-long auth outage on 2026-06-30.

A council-style Round 1 review (2026-06-15) reprioritised the backlog around three gaps: the autonomous dev-driver's blast radius, the absence of an operational safety net, and the dual-memory direction. Those findings reshaped the roadmap into three rounds — safety/security first, an architecture reframe (mostly de-building) second, and feature waves resumed third — and the open questions at the end of the document remain what reviewers are most asked to engage with.

Key decisions

Round 1 — operational safety & security first

Dev-driver hardening (bot identity, scoped token, branch protection, human approval, secret-safe CI, commit signing, read-untrusted gate), inbound rate-limiting/rotation, daily backup+DR, per-cron heartbeats, spend caps, vault-lane enforcement, and an eval battery — prioritised as cheap and high-leverage before building more.

Round 2 — architecture reframe (de-building)

The Hermes integration track is reframed: the vault is the single canonical source of truth, Hermes's SQLite and the edge replica are both derived/rebuildable, and the Worker stays a thin async router — never a synchronous hot-path call to Hermes.

Round 3+ — resume feature waves

Once safety/reframe work is folded in, the roadmap resumes device signals, live lookups, Round B voices/personas, Wave 7, and the rest of the planned backlog.

VM → OpenRouter/Goose migration

Moves LLM cron routines off the claude.ai subscription onto self-hosted Goose + OpenRouter with a Worker-hosted connector admin console (broker pattern, no secret persisted at the edge); distinct from Hermes-the-dev-driver, and the concrete execution of the reframed integration direction.

Acting in the world is deliberately deferred

Reminders and calendar/email/message writes are the highest-leverage, highest-risk item, held behind confirmation gates until read/recall/awareness surfaces are solid.

Risks & guardrails

Dual-memory fidelity

If Hermes becomes canonical and the edge a digest-fed replica, digest fidelity is the floor on degraded-mode quality — what should digests contain, at what cadence, without re-implementing Hermes at the edge?

Router boundary

What is a principled policy for answering at the edge vs delegating to Hermes, while keeping delegation strictly off the hot path?

Reversibility / lock-in

Hermes is pre-1.0 and changes fast — how much should the estate couple to it, and is "Hermes as canonical memory" too far?

Autonomous dev-driver blast radius

Hermes can open PRs against the estate's own repos under a real identity running --yolo — what guardrails should bound that, and where's the supply-chain/self-modification risk?

Shared-vault write lanes

Safety rests on disjoint path lanes plus rebase/retry rather than locking — robust enough, or a latent corruption risk?

Over-build check

For a one-person system, is any of this carrying more complexity than it earns, and what would a reviewer cut?

spec · docs/estate/04-roadmap.md
Mallory · Estate briefing