Today · Launch plan

Launch plan

What is left before you launch, and what proves each one done. Every task names the signal that decides its status, and that status is read fresh on every load. A checklist you tick by hand becomes a record of intentions about two weeks in, because nothing ever takes a tick back.

Where to find it

  • Desktop: http://localhost:4000/, then Today → Launch plan in the sidebar.
  • Keyboard: ⌘ K, then type “Launch plan”.
  • API: GET /api/launch-plan, POST /api/launch-plan/seed, POST /api/launch-plan/task/manual

What it does for you

Tells you whether you can ship, in three answers rather than two.Blocked means a blocking task was measured and failed. Clear means every blocking task was measured and passed. Not measured means some blocking task has never been checked at all, which is a different situation and calls for a different response.
Never marks something done that stopped being true.A task's status is derived from its signal every time the page loads. Rotate a key back in by accident and the task that said done says open again, without anyone remembering to change it.
Only asks you about the things a machine cannot know.Most tasks are decided by a scan. A few are not: whether you have actually restored a backup rather than only taken one, whether a new user reaches the useful part of your product without asking you. Those you confirm, and the confirmation records who said so and when.
Builds itself from your repo, not from a template.A task appears only when something real earns it. No payment dependency means no payment tasks. The plan you get is the seven rows that are about your code, not forty rows that would fit anyone.

The three states, and why the third one matters

"Your backups are not verified" and "nobody checked your backups" are different sentences, and the day before a launch they call for opposite responses. A plan that renders the second as the first cries wolf until nobody reads it. One that renders it as done ships a product nobody checked.

So not measured is its own state everywhere: in each task's badge, in the milestone counts, and in the verdict at the top. Progress counts done against what has actually been measured rather than against the total, so a plan where most tasks have never reported does not read as mostly broken.

The page ends with a list of every scan that could not answer, and why. That list is the reason the unknowns are unknown. Without it you could stare at a quiet plan for a week without discovering that your security scan has been failing the whole time.

What decides each task

  • Security findings from the guardrails scan: exposed credentials, and anything serious still open.
  • Config from the env doctor: a variable your code reads that nothing declares.
  • Deploy from the ship preflight's build check.
  • You, for the few things no scan observes.

A scan that fails is not a scan that found nothing. Both scanners report failure in a shape that looks exactly like a clean repo, so the plan checks whether a scan answered before it counts anything. A failed scan leaves its tasks not measured, and says so.

Configure

Nothing to configure. The plan is seeded from the two answers the first run collects (what you are shipping, and by when) plus what RepoOps reads out of your repo. Press Re-seed from the repo after a dependency change and the plan updates: retired tasks disappear, new ones appear, and every confirmation you recorded is carried across.

Read more

Last updated