Draft Stonk — Prototype Build Plan

user-flow-map --prototype-build-plan synthesis · topic draft-stonk · mode flat · review · 2026-07-07

What this page reviews. The proposed prototype build plan synthesized from the approved design tree — the todo contract that tells /logic-wiring what to make clickable. This is synthesis mode: it reads the approved flow-tree, UX-variation, and UI-branch artifacts; it does not remap flows.

Bottom line: the tree currently supports exactly one buildable item — the approved, screens-built search-to-pick-sprint-ui experiment. All three recommended platforms fold into it (one mobile-first web playable, not parallel products). Seven sibling/downstream branches are deferred pending their own /ui-interview or /ux-variations work. Nothing is dropped.

On approval this writes design/prototype-build-plan-draft-stonk.md and updates prototype_build_plan in design/flow-tree-draft-stonk.yaml.

1 · Scope & source evidence

Section feedback:

The build plan is the explicit ledger of what to prototype now vs. later, produced after flow/UX/UI branch work exists and before /logic-wiring. Each buildable item must be small enough for one /logic-wiring (or --variant N) pass.

Source artifact	What it contributes
`design/flow-tree-draft-stonk.yaml`	Branch/UX/UI state, decisions, platform-fit, build ledger for the built experiment.
`design/ui-search-to-pick-sprint.md`	Approved UI branch packet (S1–S4, batch plan, deferred infra, non-goals).
`design/ux-variations-first-pick-speed.md`	The five UX variations under `first-pick-speed` and their status.
`design/user-flow-draft-stonk.md`	Canonical activation loop and the four proof-priority branches.

Governing decisions: ui-interview-search-to-pick-sprint-approve (2026-07-03, branch viability) and build-ui-screens-search-to-pick-sprint-ledger (2026-07-07, four batches recorded minimum-ui-reached).

User overrides / research gaps: none recorded for this synthesis pass. The plan is deliberately lean — it reflects the true state of the tree, not a gap.

2 · Build now — BP-1

Section feedback:

The only branch that has cleared both /ui-interview (branch approve) and /build-ui-screens (screens built) is the speed baseline. It is the single buildable item.

ID	Flow branch	UX variation	`ui_experiment_id`	Status	Expected prototype path
BP-1	`first-pick-speed`	`search-to-pick-sprint`	`search-to-pick-sprint-ui`	pending	`experiments/search-to-pick-sprint/search-to-pick-sprint-ui/index.html`

What BP-1 does in /logic-wiring: wire the four already-built screen states into a state-backed clickable flow — load → type "app" → select Apple (AAPL) → Make fantasy pick → AAPL in slot 1, bots on the clock — on the existing local/mock stock universe. It stops at the board preview (standings & share belong to sibling branches). No new infrastructure; advances the four ledger entries from minimum-ui-reached → wired.

Rationale for a single item: only the proof-priority branch was intentionally taken to built screens. That is by design, not an omission.

Approve BP-1 as the single build-now item, at the path shown?

Yes — build search-to-pick-sprint-ui now at that path. No — change the item, path, or status (explain below). Other / None of the above Need clarification

3 · Platform probes

Section feedback:

Platform-fit selects web_app (primary) with mobile_web_pwa and game_playable as recommended companions. A platform probe is only warranted when more than one serious platform remains. Here the three share one base and their required probes all describe the same artifact:

Platform	Status	Required probe (from flow-tree)	Satisfied by
`web_app`	selected	Mobile-first clickable web prototype.	BP-1
`mobile_web_pwa`	recommended	Responsive mobile web; no install prompt required.	BP-1
`game_playable`	recommended	Playable local mock draft.	BP-1

Proposal: no separate platform_probe items. BP-1, built mobile-first on fixtures, is the probe for all three. This honors the skill's "do not create full parallel products per platform" rule. Deferred/rejected platforms (native mobile, desktop, CLI, API, SDK, extension, marketplace, integration, event-kiosk "other") stay documented with rationale and are not buildable.

Fold all three recommended platforms into BP-1 (no separate probe)?

Yes — one mobile-first web playable covers web / mobile-web / game-playable. No — add a distinct PWA-install (or other) probe item (explain). Other / None of the above Need clarification

4 · Deferred & dropped

Section feedback:

These are not buildable yet — each needs upstream design work before it can enter a build plan. They are deferred, not dropped: the tree keeps them alive.

Branch / UX variation	Kind	Tree state	Prerequisite before build
`recognizable-watchlist-browse`	UX var of `first-pick-speed`	`pending_ui_interview`	`/ui-interview`
`guided-micro-onboarding`	UX var of `first-pick-speed`	`pending_ui_interview`	`/ui-interview`
`challenge-prompt-entry`	UX var of `first-pick-speed`	`pending_ui_interview`	`/ui-interview`
`board-first-preview`	UX var of `first-pick-speed`	`pending_ui_interview`	`/ui-interview`
`equal-dollar-standings`	flow branch	`pending` · no UX variations	`/ux-variations` → `/ui-interview`
`concept-explanation`	flow branch	`pending` · no UX variations	`/ux-variations` → `/ui-interview`
`replay-share-invite`	flow branch	`pending` · no UX variations	`/ux-variations` → `/ui-interview`

dropped None. No branch carries a reject decision.

Is the deferred/dropped classification correct?

Yes — leave all seven deferred-pending-upstream; nothing dropped. No — I want to drop or reprioritize something (explain). Other / None of the above Need clarification

5 · Build sequence & chunking

Section feedback:

NowBP-1 — one /logic-wiring draft-stonk pass wires S1→S4 clickable on fixtures. Independently reviewable.

After UATSibling UX variations enter /ui-interview, then re-run this synthesis to add build items.

Later branchesequal-dollar-standings, concept-explanation, replay-share-invite need /ux-variations first.

One item today keeps the work lightweight and independently reviewable, exactly as the synthesis contract asks.

6 · Files to write

Section feedback:

New: design/prototype-build-plan-draft-stonk.md — the build-item ledger (BP-1 + deferred/dropped table, sequence, status definitions).
Update: design/flow-tree-draft-stonk.yaml — add the prototype_build_plan object (artifacts[] + one items[] entry for BP-1) and set next_work.recommended_next_command to /logic-wiring draft-stonk.
Confirm: this page flips review → confirmed after the approved YAML is consumed.

No archive snapshot needed for the new build-plan file; the flow-tree update is append-only (adds prototype_build_plan, no existing section rewritten).

Approve the artifact destination & proposed file changes above?

Approve — write the build-plan md and append prototype_build_plan to the flow-tree. Don't write yet — hold for changes (explain). Other / None of the above Need clarification

7 · Downstream route

Section feedback:

After the build plan exists, the tracked next step is /logic-wiring draft-stonk for the first pending item (BP-1). Continuing immediately still requires /logic-wiring's own interaction gates — approval here does not authorize an unattended run.

Continue-now: proceed into /logic-wiring draft-stonk and enter its first gate under your control.
Stop / clear-context: end here; run /logic-wiring draft-stonk in a fresh session.

Post-approval route for BP-1?

Stop / clear context — I'll run /logic-wiring draft-stonk in a fresh session (recommended). Continue now — route into /logic-wiring draft-stonk's own gates in this session. Neither — don't route yet (explain). Other / None of the above Need clarification

Section feedback:

Compile responses

Aggregates every answered gate and any selected section feedback. Enabled once at least one gate is answered or one section-feedback control is set.