Roam Milestone Planning

---
name: roam-milestone-planning
description: Define or revise a Roam product milestone and its engineering, adoption and offer-readiness sequence. Use for a requested goal or priority guide across those areas, not a single implementation task, routine status report, copy edit or publication operation.
---

# Roam milestone planning

Turn ambition into bounded supported outcomes and executable decisions. Preserve
Roam's broad free mechanical tools and the consumer's direction, execution
authority and acceptance. A milestone is not a new package version or release
verdict.

## Reconcile the maintained owners

Work in the Roam repository. Read `docs/understanding-roam.md`, then the relevant
direction in `internal/ROAM-NORTH-STAR.md`. Consult `internal/WORK-GUIDE.md`,
`internal/INTERNAL-V1.md` when applicable, and `internal/EXECUTION-SEQUENCE.md`
for principles, milestone scope and current action respectively. Open the
selected task cards and source-bound reports, not the entire historical archive.
If private sources are missing, name the gap; a title is not their contents.

Separate an owner's adopted decision from a recommendation, observation or
discarded experiment. Reconcile evidence by the actual artifact, environment
and reach; recency alone does not supersede a broader valid result. An old
document calling itself the live board does not make it the active cursor.
Correct conflicting routing without rewriting historical observations. Use a
distinct identifier when a new milestone collides with a legacy task or schema.

## Define the work and finish lines

Qualify recurring tasks and actual consumers, not command counts. Include
healthy/no-change work and useful partial results as well as real findings.
Name the installed artifact, repository slice, client/preset, intended decision,
acceptance consumer and recovery path where they affect the promise. Indexed
analysis and fixed execution/replay have different evidence foundations.

For each requirement, distinguish:

- a required product/authority boundary;
- a useful behavior with a narrower claim or support scope;
- an experiment whose result could change the next decision;
- a non-required opportunity with an activation condition.

Do not average away a required failure or turn every uncertain hypothesis into
a launch blocker. A named support slice does not excuse a severe known defect
in a shared boundary or an available path with a materially misleading promise. Keep
a truthful account of available breadth; do not quietly delete the free
catalogue or invent universal compatibility.

Separate engineering readiness, deliverable-offer readiness and actual demand,
retention or delivery economics. Paid engagement cannot responsibly precede its
required handling/capacity/terms, but a completed sale or retention study cannot
be a circular prerequisite for beginning any offering. Internal work can expose
a real defect without an external buyer. Keep adopted offer direction; do not
invent prices, demand, staffing or a new commercial surface to complete a plan.

## Make the sequence executable and finite

Reuse existing cards, their acceptance and the single execution cursor. The
milestone document owns scope and exits, not another daily status board. Name
dependencies, the smallest useful next output, its acceptance/refuter and what
happens if it fails or is unavailable. Do not activate the whole sequence.

Preserve a frozen candidate's identity. New unrelated work gets a separate
bounded decision instead of keeping the release open indefinitely. A blocked
external step may leave useful authorized local preparation. A narrower release
can ship independently only when its own promises and gates genuinely qualify;
that does not complete a broader milestone.

Challenge the draft from the actual agent, adopter, maintainer, evidence
consumer and buyer viewpoints. Look for omitted work, conflicting promises,
circular gates and cheaper discriminating tests. Retain correct decisions; do
not manufacture a rewrite, new command or benchmark platform. Record meaningful
revisions and the evidence boundary of this review, not a confidence score.
Check the work behind the promise as well as its wording: installation,
artifact/dependency hygiene, support burden and recovery. Readiness requires
the actual relevant path, not another document asserting that it exists.

Before handing off, check source links, owner routing, proposed versus current
state and the next executable action. Keep plans and evaluations in `internal/`.
A plan authorizes neither publishing nor source transfer, contact, spending or
work in another repository. Surface those choices only when the exact operation
needs them; missing external authority does not prohibit safe local planning.