goal #79 · decision artifact · 2026-08-14

The app plan rewrite: four calls, and what each one unblocks

Goal #79 says of itself that “until the app-first plan update lands on #34 and the Phase 1–4 requirements are filed and designed, every increment here is pipeline-advancement; there is nothing implementation-ready to select.” That has been true for 33 days and it is now self-fulfilling: the artifact the goal is waiting for was overtaken by the work it was meant to sequence. This page converts “the plan rewrite is pending” into four decisions with recommendations. Nothing here needs a session to research further — the calls are @jwildfire's.

Status — closed 2026-08-16. A1 and A2 were accepted on 15 August. A3 and A4 were never answered, and @jwildfire closed the page rather than answering them; both moved to the interview on the app goal, whose prep round is #192 and whose sittings and goal ratification are #193. The record, including what A1 and A2 committed to that has not yet been done, is in the Decisions section below.

Decisions

@jwildfire · 2026-08-15 · in chat

A1 and A2 accepted as recommended; A3 and A4 held open — deferred for further discussion, not rejected.

He also said the app goal itself needs rework: he holds detail about what the app should be that the goal does not yet capture, so a structured interview was designed to draw it out before A3 and A4 are settled or the goal is rewritten. His calls are recorded on discussion #149; this entry summarises them rather than quoting him.

@jwildfire · 2026-08-16 · Operations Dashboard

“I think I’m done with this Decision. Close it out. We’ll work on improving the goal separately soon.”

The page is closed. A3 and A4 are not answered by that and are not recorded as answered here. What ships in version 1.0 of the safetyGraphics replacement and what gets written down as deferred, and whether the demo study repo becomes the canonical template other people fork, are both still open questions — and both are questions about what the app is for, which is the thing he said he wants to work on separately.

They move to the interview he was pointing at. The prep round that builds the material he reacts to is #192, and the sittings that ratify the goal statement are #193. Both already carried these two calls in their own words before this page closed — #192 seeds them into its open-question list and #193 makes answering them a condition of being done — so the transfer is a relabelling of something already in the right place rather than a hand-off that could be dropped. What changed on 17 August is that the answers now get recorded wherever the interview records them, not back on this closed page.

One thing this page should not let pass quietly. A1 and A2 were accepted on 15 August, and almost none of what they committed to has been done. A1 said the July plan report gets a supersession header and the issue tracking it is ratified and closed: the report carries no such header and #34 is still open, untouched since 14 August. A2 said four requirements get filed against surfaces that exist and five unparented app issues get adopted into the goal: none of the four was filed, and of the five, two have since closed on their own, one was adopted into the charts goal instead, and two remain unparented. The goal's own body still tells a selecting session there is nothing implementation-ready to pick, citing the very issue A1 was meant to close. That is an accepted decision that produced no work for two days, and it is recorded here rather than left for someone to discover — the interview will reshape most of it, but the reshaping is a choice someone has to make, not something that happened.

Recorded on this page 2026-08-17. He answered in the local Operations Dashboard on 16 August at 21:37 UTC, the sweep announced it three minutes later, and then nothing applied it for nine hours — which is why the published index went on saying this page was waiting for him, and why he had to ask again the next morning. The pipeline that stopped there is filed as its own requirement, #241.

The ask, in one screen

A1What replaces the 2026-07-12 v1.0 plan report, and does #34 close?
→ Recommend retire and anchor: supersession header on the old report, ratification comment on #34, close it, and let the two 2026-07-28 design reports plus shipped demo-301 v0 be the record the requirements cite.
A2What is the requirement set, given demo-301 already demonstrates most of “Phase 1”?
→ Recommend surface-anchored, not phase-named: four requirements written against surfaces that exist, with acceptance criteria measurable on the published snapshots — plus adopt the five goalless app issues into #79.
A3What is in v1.0 of the safetyGraphics replacement, and what is deferred in writing?
→ Recommend acceptance-path v1.0: a scheduled Actions run publishes a snapshot end-to-end from a forked study repo. Name the app (D-APP0). Defer the action log, blinding enforcement, mapping UI and upstreaming, explicitly.
A4Is demo-301 the canonical fork template — and therefore a goal repo whose site branch must be bounded?
→ Recommend yes, and bind it: add demo-301 to #79's backlog in goals/registry.json, fix its Actions lane, and take the free 34% off the branch. Sizing options: the companion artifact.

A1 gates A2 gates A3. A4 is independent and can be answered on its own. If only two get answered, make them A1 and A2 — they are what makes the goal selectable at all.

The situation

Between 28 and 29 July the app arc shipped ahead of its own governance: five PRs merged into open.gismo dev (local-first engine, espresso study-site shell, sidebar and the real gsm.viz overview table, the RBQM domain, the Safety domain) and demo-301 published two Project Snapshots to a live Pages site, while the documents meant to sequence that work never moved.

The 2026-07-12 v1.0 plan report is still written local-first even though @jwildfire reversed exactly that premise on 2026-07-19 (D1 — the gh_* GitHub lane is the acceptance path), #34 has sat untouched since 2026-07-24 at milestone backlog, and #79's body still tells a selecting session there is nothing implementation-ready to pick.

The result is sixteen idle days: no Phase 1–4 requirement was ever filed, five live app issues sit under no goal, demo-301 is bound to no goal in goals/registry.json at all, and its weekly pipeline has failed silently on 3 and 10 August without anyone being able to pick the fix up.

The one fact that reframes everything below. D1 made the GitHub Actions lane the acceptance path for v1.0 on 2026-07-19. That lane has never once produced a published snapshot. Both snapshots on the live site record package_snapshot: local-2026-07-29 — they came off a laptop. build-site.yaml has zero runs in its history. run-pipeline.yaml has fired twice on schedule and failed both times at package install. Pages is being served by GitHub's legacy branch builder, not by the repo's own deploy lane. The demo works; the mechanism the demo is about has never run.

What changed underneath #34

DateEventEffect on #34
2026-07-12v1.0 plan report published; D1 proposed as “C+” — local-first, GitHub demoted to optional publisher. #34 opened to dispute it.Issue's reason for existing
2026-07-19@jwildfire ratifies D1 = GitHub prerequisite (reversing C+), D2 = stay on the jwildfire fork, D6 = Snapshots in v1. Sequencing set (D5): rewrite the plan first, then file Phase 1–4 requirements.Decided — but the plan was never rewritten
2026-07-21Ruling: Stage-3 Goal 2 (safetyGraphics replacement) and open.gismo v1.0 are the same arc; the rewrite must lead app-first.Rewrite scope grew
2026-07-28A design pass runs instead of the rewrite: two design reports published (directions D-APP0–7, framework D-FW1–8), direction C approved in session, the Domain concept added by @jwildfire, and requirement #134 filed and built the same evening.Overtaken — better record now exists
2026-07-28/29open.gismo PRs #1–#5 merge to dev; demo-301 publishes ps-001 and ps-002; the site goes live.Overtaken — the plan's Phases 1–2 are largely built
2026-07-29policy.json promotes demo-301 and open.csr to auto and clears the open.gismo obotclaw App blocker (obot.agent ac613bf).#79's stated prerequisite goes stale
2026-08-03 / 08-10demo-301's scheduled Run Pipeline fails at package install, twice, unattended.The D1 acceptance path is broken and unowned

#34's own gating clause — “the prototype PR stays a draft and no open.gismo requirements are filed until D1 lands” — is doubly stale: D1 landed on 2026-07-19 and PR #1 merged on 2026-07-28. The issue is holding a gate that reality already walked around.

What in the 2026-07-12 plan is now wrong

This matters because A1 is a question about whether that document is worth rewriting. The research pass read it line by line against what shipped:

What survives: §4 “What was built” is evidence and still accurate, and the two 2026-07-28 design reports are source-grounded and current.

The four decisions

A1 · gates A2

What replaces the 2026-07-12 v1.0 plan report — and does #34 close on it?

Why now: #34 has been the named gate on everything downstream for 33 days. Its sequencing said rewrite the plan first, then file requirements. The build overtook it 16 days ago, so the gate now only blocks the paperwork.

A1-a · Rewrite the report app-first

What
Execute the 2026-07-19 sequencing literally: rewrite the report app-first with D1/D2/D6 folded in, land D3 and D4 inside that draft, then close #34 and file requirements.
Costs
A full session re-deriving design already published twice on 2026-07-28; §4 would be re-typed; requirements slip another session; the rewrite would be describing shipped code as a plan.
Forecloses
Nothing permanent — but it spends the arc's next session on narrative rather than on the Actions lane D1 made the acceptance gate.

A1-b · Retire and anchorrecommended

What
Supersession header on the 07-12 report naming D1's reversal and the 07-21 app-first ruling; close-out comment on #34 recording D1/D2/D6 as ratified and D3/D4 as re-sited; close #34. The two 2026-07-28 design reports plus demo-301 v0 become the app-first record the requirement set cites.
Costs
No single narrative “plan” document exists for the keynote. D3 (data-mapping ambition) and D4 (Shiny long-term) lose their home and must be explicitly re-sited onto issues or they vanish. The old report stays publicly deployed with a wrong §3 unless the header is unmissable.
Forecloses
The plan-report genre for this arc: from here the requirement set is the plan, and readers get design records plus requirements rather than a roadmap essay.

A1-c · Header only, leave #34 open

What
Add the supersession header and comment, but keep #34 open as the arc's design thread.
Costs
#34 stays a backlog placeholder that #79's body cites as a blocker, so “nothing is implementation-ready” stays technically true by its own text.
Forecloses
Little — but it preserves exactly the ambiguity that has held the arc for a month.
Recommendation

A1-b — retire the plan report, close #34, anchor on what shipped.

The report's reusable half and its void half separate cleanly. §4 “What was built” is evidence and survives; §3's entire architecture decision rests on the premise D1 reversed, and its own pull quote disqualifies the repo-plus-Action shape that K3 and demo-301 then built. Rewriting would mean re-deriving design that already exists in better form — framework.html's next step ③ asked for exactly this fold-in, its four-layer model is source-grounded and current, and directions.html's shell direction was not merely approved but implemented: espresso masthead, Domain switcher, provenance chip, snapshot timeline are all on the live site.

Unblocks
Closing #34 removes the only stated precondition on filing requirements, so drafting can start in the same session — and #79's boundary prose can be corrected in the same pass, which is what makes the goal selectable by an unattended session at all.

A2 · the actual unblocker

What is the requirement set, given demo-301 already demonstrates most of “Phase 1”?

Why now: goal #79 has exactly three sub-issues (#34, #134, #139), none closed, while five real app issues filed on 2026-07-29 — #136, #138, #142, #143, #144 — sit under no goal at all. The goal under-counts its own arc by five, so a session selecting app finds nothing to do.

A2-a · Faithful Phase 1–4

What
File four requirements named and scoped as the 07-12 report defines them (Local core hardening / Settings & data UX / Publish & share / v1.0 release), amended to GitHub-prerequisite.
Costs
Phases 1 and 2 are substantially built, so the text would describe the past; the acceptance gate sits third; and the phases carry no acceptance criteria in the source, so that defect is imported wholesale.
Forecloses
Framing the set around what the app now is — the phase names commit the arc to the engine-first vocabulary the 07-21 ruling rejected.

A2-b · Surface-anchored set, and adopt the orphansrecommended

What
Four requirements named for surfaces and contracts that exist: (1) the Actions publish lane green end-to-end, (2) Safety domain completion (folding #138's metric cut and #136's phase rename), (3) fork-template hardening, (4) the v1.0 release itself — each with acceptance criteria measurable against demo-301's published snapshots. Plus: a baseline comment on #134 declaring demo-301 v0 the accepted baseline, and #136/#138/#142/#143/#144 linked as sub-issues of #79.
Costs
Requires @jwildfire to edit #79 or approve a membership proposal (the goal is his to maintain); a short retro-documentation pass so shipped surfaces get the acceptance criteria they were never given; “Phase N” references in older documents need translating.
Forecloses
The “Phase N” vocabulary — future conversation happens in surface terms.

A2-c · One umbrella v1.0 requirement

What
A single “open.gismo v1.0” requirement under #79 with cross-repo sub-issues in open.gismo, gsm.safety and demo-301.
Costs
One requirement cannot carry per-surface acceptance criteria without becoming a plan document again; sub-issues without requirement text are hard to review at the gate actually in use.
Forecloses
Per-surface approval — the whole arc is approved or rejected at once.
Recommendation

A2-b — surface-anchored requirements with acceptance criteria measured on the published snapshots, plus adopt the five goalless issues.

The built-ahead-of-spec problem is real but small: the shipped surfaces are testable artifacts, not sketches — two published snapshots with per-workflow and per-step status.json, a five-file publish contract already written into build-site.yaml, and a config-driven domain registry in demo-301's study-config.yaml. Writing acceptance criteria against them is a documentation pass, not a re-derivation. Filing the original phase names instead would import the plan's missing-acceptance-criteria defect and put the D1 gate third in the queue. The membership fix matters as much as the text: #144 and #136 both cite #79 in their bodies and are parented to nothing, so the goal reads as three-issues-idle when the live arc is seven issues wide.

Unblocks
Makes #79 selectable. registry.json already binds it to open.gismo and gsm.safety, and policy.json gives both repos the auto profile — so the moment a requirement carries acceptance criteria, an unattended session can take an increment. The two most immediately implementation-ready: #138's metric cut (blocked only on @jwildfire choosing from five candidates) and #136's phase rename (one open question — whether the published output/3_reports/ path renames alongside the workflow directory).

A3 · scope

What is in v1.0 of the safetyGraphics replacement — and what is deferred, in writing?

Why now: D1 made the GitHub lane the acceptance path on 2026-07-19, and it has never run to completion. Both published snapshots carry package_snapshot: local-2026-07-29; build-site.yaml has zero runs; run-pipeline.yaml failed its last two scheduled attempts. Whatever v1.0 means, this is the gap.

A3-a · Acceptance-path v1.0recommended

What
v1.0 = a forkable study repo whose scheduled Actions run publishes a snapshot to Pages end-to-end, with Safety and RBQM as shipped, the phase/path contract settled (#136), and the app named (D-APP0). Deferred and stated as deferred: the action log (#139), payload-level blinding enforcement (#144), QTL depth beyond the current qtl0001/qtl0002, the full mapping UI (old D3), and the milestone upstream PR to Gilead-BioStats.
Costs
The release headline is a publishing capability rather than new analytics. It requires fixing the Actions install lane — unestimated work of unknown depth (the hand-rolled clone-and-install lane exists because of the SAML/pak constraint, and it does not resolve transitive deps). D-APP0 must be decided now rather than parked as #134 parked it.
Forecloses
Shipping v1.0 on a locally-produced demo — which D1 already forecloses in principle; this makes it operational.

A3-b · Feature-complete v1.0

What
Add the action log (#139), per-module blinding enforcement (#144) and gsm.safety's new 2_metrics phase (#138) to the v1.0 line.
Costs
#139 has seven undecided design questions and a real architectural tension (review state is mutable and must live outside the immutable snapshot); #144 needs payloads built without treatment-arm columns and possibly separate artifact trees. Both are net-new subsystems. September is already slipped without them.
Forecloses
A September v1.0 in any realistic reading.

A3-c · Freeze and name

What
Tag what is on open.gismo dev, declare the locally-produced demo the release, leave the Actions lane unproven.
Costs
Directly contradicts D1. demo-301's README promise — fork it and your study site publishes itself — stays false. The K3 three-step keynote story cannot be demonstrated live.
Forecloses
The K3 demo narrative, and with it the strongest differentiator the design pass identified.
Recommendation

A3-a — scope v1.0 to the acceptance path, and put the deferrals in writing.

This is the only scope that makes v1.0 mean what was already decided it means. D1 named the gh_* lane the acceptance path; that lane has never once produced a published snapshot. Everything else on the candidate list is either already demonstrably working (both domain pages, the provenance chip, snapshot compare) or is a new subsystem with unanswered design questions. D-APP0 belongs in scope because directions.html's own recommendation was “decide before requirements — the name lands in Phase 1 scope, the plan rewrite, and the keynote”, and it is now the last unmade call that touches all three.

Unblocks
Turns the Actions install failure into requirement #1 with an unambiguous pass condition — a scheduled run publishes ps-003 without a local og_run() — which is a well-scoped, testable increment an unattended session can take. Explicitly parking #139 and #144 also stops them reading as blockers, which is part of what makes the arc look impassable today.

A4 · independent of A1–A3

Is demo-301 the canonical fork template — and therefore a goal repo whose site branch must be bounded?

Why now: demo-301 is the only place the D1 acceptance path can be proved, and it holds the keynote's K3 story — yet it is bound to no goal in goals/registry.json, so no autonomous session can reach it. Its weekly cron has been failing since 3 August and nobody could pick it up. Separately, #143 says the size call must be made “before demo-301 is used as the fork template in the keynote”.

A4-a · Canonical, and boundrecommended

What
Declare demo-301 the fork template: add it to goal #79's backlog in goals/registry.json, fix the Actions install lane there, and bound the site branch — starting with the free lever in the companion artifact.
Costs
The registry.json edit sits inside the policy carve-out, so its PR needs explicit approval even though demo-301 is an auto repo. Bounding the branch means real work in the publish script and a small change to how the app shell resolves snapshot paths.
Forecloses
Little — old snapshots survive in git history, and the packed cost is already small.

A4-b · Generated template

What
Make og_init() plus an Actions template the fork story — “setting up a study repo is a command, not an artisanal clone” — and keep demo-301 as a scratch demo nobody forks.
Costs
The keynote's “fork this repo” demo then points at something that does not exist yet; more engine work before anything is demonstrable; the live site people have already been shown becomes a throwaway.
Forecloses
Using the artifact that already works as the demo, in exchange for a cleaner story later.

A4-c · Accept for the demo (the de facto state)

What
#143's mitigation 4 — accept the ceiling for the demo, solve it at first real-study onboarding — and leave demo-301 unbound.
Costs
The moment the install step is fixed, the weekly cron resumes growing the branch by roughly 100 MB of checkout per run. PUBLISHING.md's own precondition (“a retention policy belongs in this branch's contract before the schedule is switched on”) was already violated when the schedule went live. demo-301 stays unreachable by goal selection, so the Actions fix never gets picked up autonomously.
Forecloses
Nothing technically — but it keeps the acceptance-path work permanently outside the autonomy lane.
Recommendation

A4-a — name demo-301 the canonical fork template, bind it to #79 in the registry, fix its Actions lane, and take the free 34% off the branch.

The measured facts reframe #143 rather than confirming its urgency. The ~302 MB figure is exact — 317,274,322 bytes across 689 files — but 103.41 MiB of it is a byte-identical duplicate: the branch root output/ and ps-002/output/ are the same git tree object, d2f3ae3. That is 34% of the checkout, and #143 does not mention it. The genuinely gating half is the other one: full merge grants on demo-301 (auto, integration main, release site, approved 2026-07-29) with zero goal reachability is why two consecutive cron failures went unattended for eleven days.

Unblocks
Makes demo-301 work selectable, which turns the Actions install failure from an unowned defect into a takeable increment; gives #143 a decision instead of an open ceiling; and lets A2's fork-template requirement carry a concrete acceptance test — fork the repo, let the scheduled run fire, get a published snapshot.

Two corrections that need no decision

Both are stale facts in goal bodies, and sessions never edit a goal issue — so they are proposed as comments and applied by @jwildfire.

Noted in passing, not proposed: goals/registry.json lists csr with status: "active", while tonight's goal review treats it as paused. Worth reconciling whenever the registry is next touched.

What this session did not do

Evidence

Re-run directly on 2026-08-14 for this page:

ClaimHow it was checkedResult
demo-301's scheduled pipeline is failinggh run list -R jwildfire/demo-301Run Pipeline / schedule → failure on 2026-08-10 and 2026-08-03; Build Site has zero runs; every success in history is pages build and deployment (GitHub's legacy branch builder), last on 2026-07-29
site branch is ~302 MBgit ls-tree -r -l origin/site689 files, 317,274,322 bytes = 302.58 MiB. #143's figure is exact
A third of it is duplicatedgit rev-parse origin/site:output vs :ps-002/outputBoth resolve to tree d2f3ae3cefb8296212dedc628dd8134e8d4a4f50 — byte-identical. output/ 103.41 MiB · ps-002/ 103.45 MiB · ps-001/ 95.36 MiB
The obotclaw App is installed on open.gismo and open.csrGET /installation/repositories with an App token12 repositories, including jwildfire/open.gismo, jwildfire/open.csr and jwildfire/demo-301
#79 under-counts its arcGET /issues/79/sub_issues + issue sweepSub-issues: #34, #134, #139 (three, none closed). Goalless app issues: #136, #138, #142, #143, #144
demo-301 is bound to no goalobot.agent/goals/registry.jsonapp backlog = jwildfire/open.gismo, jwildfire/gsm.safety. demo-301 appears in no goal's backlog
The App blocker was clearedobot.agent git log on scripts/policy.jsonCommit ac613bf, 2026-07-29 — “Apply @jwildfire's decisions: promote open.csr + demo-301, clear the open.gismo blocker”

Everything else on this page — the plan report's stale sections, the design-report decision ledgers, the open.gismo dev build state, snapshot contents and test counts — was read from source by a parallel research pass over the two 2026-07-28 design reports, the 2026-07-12 plan report, the open.gismo and demo-301 working trees, policy.json, registry.json and the hub issue set. Where a source was thin, the page says so rather than filling the gap.

Sources