Mallory Estate · Process

The R&D Loop

One place to explore, discuss, spec, and route every Mallory improvement.

Ideas for Mallory live in too many places — two roadmap files, spec/plan pairs, vault notes, Q's backlog, ad-hoc chat. This is one surface: spark → discuss → spec → deck → route → build → ship. It also makes the build choice explicit and per-item — a reviewed Claude Code PR, or Q driving Goose on OpenRouter.

2026-07-19Status: proposed3 decisions for Alex

01 The problem & the insight

Too many places to think

docs/ROADMAP.md, docs/estate/04-roadmap.md, the docs/superpowers spec/plan pairs, vault project notes, Q's edge backlog, and chat. No single surface to move an idea from spark to ship — and no agreed way to decide who builds it.

Not a new principle — an applied one

The estate already decided the vault is the single source of truth (D3–D5); the edge and Hermes hold derived, rebuildable state. So the roadmap belongs in the vault, and Q's backlog becomes a view of it. And the estate already ships two ways — this just makes the choice explicit and per-item.

02 The loop — seven stages

Each stage has one owner and one artifact. A vault board note carries the status the whole way.

1
Spark · anyone
A one-line idea — chat with Q or Mallory, or /capture.
spark
2
Discuss · Q (Talk lane) + Alex
The idea sharpened — problem, shape, risks, is-it-worth-it.
discussing
3
Spec · Q writes the board note
The vault board note (canonical) + an optional deep technical spec in the repo, linked not duplicated.
spec
4
Design deck → archive · spec author
A self-contained HTML deck published to design.mallory.chat. This page is that stage, for this doc.
designed
5
Route · Alex
Set executor — claude or q-goose.
routed
6
Build · the chosen executor
A reviewed PR — no auto-merge, either path.
building
7
Ship
Merged + deployed; the board note links the PR and the deck.
shipped

Parked ideas get status: parked with a one-line why. Nothing is deleted.

03 Stage 4 is the point of this doc

Alex's addition: every substantive idea produces a published design deck in the archive before it's routed. The board is where you work; the archive is the durable, browsable, shareable record — the same split the site-design README already draws. Producing the deck is the same muscle as /morning and /week-visual: render a self-contained page, drop it in site-design/, add an index row, push. A /design-deck skill can automate the render from a board note + spec.

When is a deck required? When the item changes architecture, adds a surface, or is something you'd want to explain to a person. Trivial mechanical fixes skip stage 4 and go straight from spec → route.

04 Three layers, no duplication

Vault

Board note

the executor-agnostic brief

Problem, approach, scope in/out, open questions, status, routing. The single source of truth.

Repo · docs/design

Deep spec

the technical depth

Where the code lives. Optional; linked from the board note.

design.mallory.chat

Design deck

the shareable presentation

The durable record. Linked from the board note.

Link between layers; never copy content between them.

05 Routing — an explicit, reversible decision

→ Claude Code

high blast-radius · cross-cutting · fuzzy

The board note (+ linked spec) is the handoff pack — the existing handoff playbook. Best for most of the July sprint's work.

→ Q / Goose (OpenRouter)

well-scoped · bounded · lower-risk

Q's Delegate lane plans it → Alex approves → Hermes runs → opens a PR. The self-hosted doer, one bounded task at a time.

Heuristic: blast radius × scoping clarity. High blast radius or a fuzzy spec → Claude. Bounded, well-specified, mechanical → Q/Goose. Both paths converge on a reviewed PR with no auto-merge (the estate's gated-deploy rule). An item can be re-routed at any time — and this answers the estate's own Open Question #2 for the build lane.

06 What's reused vs what's new

Reused — almost all the machinery

  • The Q Command Center — Talk / Watch / Delegate lanes.
  • Q's q-tasks → create_tasks backlog path.
  • The vault-MCP and the cross-persona handoff protocol.
  • The Goose / Hermes doer on OpenRouter.
  • The site-design Pages archive + the /morning / /week-visual render pattern.

New — convention + one capability

  • A vault Roadmap board — 01 Projects/Mallory Roadmap/, one note per item, a MOC index, the status/executor template.
  • Q writes structured specs to the vault — the one genuinely new capability. Q's edge backlog becomes a derived view.
  • A /design-deck skill that renders a board note into a deck.
  • The routing field + the two documented handoffs.

07 First step — dogfood both paths

The board's first act is to organise and route the work already in flight — and prove both executors at once.

/status overdue-cron field

Small, bounded, clear — surface overdue cron jobs in the status verdict.

→ Q / Goose

Reminders conversational UX

A fuzzier, cross-surface flow over the parse + confirm-gated create that already ship.

→ Claude

Health per-signal freshness

Surface per-signal freshness in the health glance. The third seed.

executor TBD

Migration: the two .md roadmaps aren't deleted — the "waves shipped" record stays. Going forward they become derived views; the vault board is the source of truth for new items.

08 Open decisions — for Alex

1

Board home

Recommended: a 01 Projects/Mallory Roadmap/ folder + MOC. Or fold into the existing "Mallory Data Platform Architecture" north-star note.

2

The .md roadmaps

Retire them into the board, or keep them as auto-generated views of it?

3

Default executor when undecided

Claude — the safe, known path? Or force an explicit choice on every item?