Skip to content

Launch plan accuracy โ€‹

  • Status: in progress, opened 2026-08-23. Reconciliation applied 2026-08-24 on feat/admin-and-merchant-portals.
  • Issue: none yet. This is repair work on the plan itself, and per project-creation an item gets an issue when the work is actually intended rather than on sight.
  • Launch plan: none, this is tooling. The project's subject IS the launch plan, so it belongs to no row inside it.

What is this? โ€‹

The launch plan is what every ranking reads, and parts of it were not true. โ€‹

  • Rows read In progress while their only issue was closed.
  • Alpha P0 rows linked no issue at all, and one P0 linked two closed issues about a different subject.
  • A ranking that reads a stale row ranks a finished thing, or skips a live one.

It also carries her Prototype-to-Alpha side quest. โ€‹

  • A row-by-row pass over PROTOTYPE.md against ALPHA.md to decide whether anything currently in Prototype belongs in Alpha, with December approaching.

What is the current state? โ€‹

The changeset is applied. All eight rows landed, none was skipped. โ€‹

  • Commit bbf5def3. Applied by parsing the Current and Corrected pairs out of changeset.md rather than transcribing them, so a typo could not enter the edit.
  • Every Current block matched its target file exactly once. Afterwards exactly eight lines differed and no others: ALPHA.md 38, 62, 64, 73, 75 and PROTOTYPE.md 16, 30, 38.
  • The CLAUDE_ALLOW_PM_BUILD=1 door was used, scoped to those two files, on her 1120 decision to open it for dispatched agents. Every write went through Bash with the assignment in the leading slot, because the Write and Edit tools read only the environment the session started with.

The lane door does not cover README.md, so the two launch-README items are still waiting. โ€‹

  • The door was scoped to ALPHA.md and PROTOTYPE.md. docs/business/launches/README.md was not in it and was not touched.
  • Both items sit in backlog.md unchanged: the stale "Needs review" section, and three Prototype rows that also appear in the Not-scheduled table.

Two more issues were filed, both carrying questions rather than answering them. โ€‹

Two rows are still waiting on her words. โ€‹

  • Attribution, no-POS path: what does redeeming an offer at the counter actually mean for the staff member on the other side of it? Now tracked as #965, so the row no longer cites only closed work.
  • ToS and Privacy Policy: how far does the legal work go, on counsel review, on publishing, and on whether a dated draft is enough for an invite-only cohort? Still tracked by #141, which is open.
  • Both questions are written out in full in changeset.md, under "What questions does the operator have to answer?".

backlog.md was rewritten by a merge on 2026-08-27, and the conflict was resolved as a union. โ€‹

  • Two branches edited this file in parallel. feat/query-console-958 carried a Why-column finding that feat/admin-and-merchant-portals never had, and the destination carried a placement fact the source branch got wrong. Daisy-chaining the two collided on the one section they both touched, "Three projects map to no launch-plan row".
  • The disputed fact, settled by grep before the merge was resolved: #881 IS on PROTOTYPE.md line 31, as the "Profile completion metric" row, re-verified 2026-08-27. #882 and #886 appear in neither ALPHA.md nor PROTOTYPE.md. The source branch had checked only ALPHA.md, so its claim that all three appear nowhere was true of the file it read and wrong about #881.
  • How it was resolved: a union, not a pick. The destination's version of the fact was kept and its verification date moved to 2026-08-27. The source branch's Why-column section was kept in full, her quoted 2026-08-24 words included, because a keep-the-destination resolution would have deleted a real finding silently.
  • What now says something neither side said: the promotion clause names which issues still need her word. #886 and #882 do, because neither is placed. #881 does not, because it already is. Both sides carried a blanket claim that turned out to be half wrong once the second file was checked.

What was applied on 2026-08-24? โ€‹

PieceWhat changedCommit
The changesetEight single-row replacements, five in ALPHA.md and three in PROTOTYPE.mdbbf5def3
Task 9, split the shared issueFiled #964; line 100 cites it, line 97 keeps #3262d1ba49a
Task 10, issue-link spot checkFiled #965; line 38 cites it ahead of #704. Line 76 gains #875 and #874e7be3db4

Task 9 split an issue that was hiding startable work. โ€‹

  • #326 was confirmed OPEN, milestone Alpha, before anything was split. It was not among the twenty references the earlier state check verified.
  • It is a collection of strategic considerations whose own closing line asks for items to be promoted to individual issues as they become actionable, so the split is what the issue asks for rather than a reinterpretation of it.
  • #964 carries what makes the split useful: the mechanic already shipped (schedule.service.js, the routes, the activation sweep), the five app surfaces whose copy still reads as a calendar entry rather than the chosen buddy framing, what can start without her, and what still needs her word. A comment on #326 records the promotion.

Task 10 audited all 95 rows and found one genuine contradiction. โ€‹

  • Live state for the 108 issues and PRs both pages cite was fetched in one gh api graphql pass, not read and assumed.
  • Status is the second-to-last cell and Issues the last cell in every table on both pages, so the sweep did not depend on column count and did not skip the differently-shaped Runs throughout and Bugs tables.
  • The one contradiction: "Attribution, no-POS path" cited only #704, closed, while reading Needs operator input. #965 fixes it. The sweep goes 1 to 0.
  • The shared-issue rows were checked by hand, the blind spot the brief named. Six issues are cited by more than one row (#177, #320, #523, #678, #704, #878) and only the #704 pair was inconsistent.

Line 76 gained the two Prototype P0s that gate it, and this was the placement pass's top item. โ€‹

  • It cited only #523, the master tracker, so the actual gating work was invisible from the Alpha page.
  • #875 is a direct gate: its own title names sealed-identity material reaching admin browsers, which is this row's description failing.
  • #874 is the policy layer over the same surface, and its own table names raw phoneHash egress. It is scoping-only today, which is why it is cited third rather than first.

What was found and deliberately NOT changed? โ€‹

Six rows read Built while citing an open issue, and all six are correct. โ€‹

  • Chat (#166), Frens (#159), Light a lantern and Wave to meet (both #177), Push notifications (#161), Offers (#357).
  • Each of those issues is an epic or a long-tail tracker with genuine remaining scope: 10 to 14 unchecked boxes on the first four, four written-out deferrals on #357. The row is the alpha-scoped slice of the epic, so Built is true of the row and Open is true of the issue.
  • No issue was closed. Closing an epic is not an agent's call.

"Every P0 tracked as an issue" now appears to be satisfied, and its status was left alone. โ€‹

  • Verified mechanically: 43 of 43 rows marked P0 in a priority-bearing ALPHA.md table carry at least one issue link, 0 empty.
  • The row has no linked issue, so it is outside what task 10 was scoped to fix, and whether a Runs-throughout invariant can ever read done is a judgment about what the row means.
  • What would settle it: her word on whether that row closes when the condition is met, or stays open because new P0 rows keep arriving.

Eleven rows cite no issue at all, and none of them is a P0. โ€‹

  • Six Alpha P1s, two Alpha P2 bugs, and three untracked Runs-throughout rows.
  • The P1 subset is already in backlog.md with what would promote it. Filing against a row that may move is how a link ends up pointing at the wrong page.

Built with VitePress