Factory spawn queue — pre-written briefs (standing backlog)

Owner directive 2026-10-16 (amended same day): every brief spawns as RESEARCH FIRST, then BUILD — per feature, run the canonical research protocol (ISSUE→INWARD→OUTWARD→APPLICABILITY→INNOVATION-on-merit→ADVERSARIAL→SYNTHESIS→QUALIFY, depth adaptive per the standing law) before any construction code. The build wave spawns only on QUALIFY: PROCEED; MORE_RESEARCH loops back with named unknowns. Owner is quizzed at topic boundaries with design latitude. Briefs below carry their research question; the research wave runs first. Completion of any wave auto-triggers the next brief's spawn. Main session pops top-of-queue, adjusting only for sibling collisions.

PRIORITY 0 — B-FACTORY-PROTOCOL (owner directive 2026-10-17: the factory is a RUNTIME FEATURE, not session process)

The factory orchestration (wave spawning, contract tracking, landing gates, spawn queue, continuous backfill, mechanical>behavioral priority, scale ladder 20→30→50) becomes FIRST-CLASS CODE in three places:

Rune runtime (Go): src/go/factory/ — orchestration engine (spawn, contracts, gates, queue, backfill) as a library + thin shell; seam-registry socket "factory-orchestration" with deletion test.
TUI: factory surface — waves as threads, contracts as briefs, gate results as receipts, live worker states in the task tree.
mimo Rune (Python): the same protocol ported (factory_protocol.py) — works in both worlds during migration; parity harness proves the implementations agree before the old retires. Build: research protocol first (per the standing research-gate law), then build waves. THIS IS THE TOP OF THE QUEUE.

Queued briefs (REORDERED by owner 2026-10-17 — chat/tools/providers/visual FIRST, Sleight memory + Plan loop DEFERRED to after retirement campaign)

Owner's reasoning: the face has no chat window, no tools wired to use, no providers connected — nothing testable end-to-end. Memory compaction (Sleight) without a working conversation to compact is counter-intuitive. Visual round needs heavy owner critique and accurate design-intent portrayal. Deferred: Sleight matrices, Plan loop, self-transformation pipeline.

Priority 1 — CHAT + TOOLS + PROVIDERS (makes the face testable):

B-CHAT-LIVE (phase 2/5 depth): real chat through the library seam — conversation store wired, model-routing called, streaming to the lane, receipts. The face becomes usable.
B-TOOLS-LIVE (1.3 + toolexec in-process): tool dispatch wired through the TUI — tools_registry surfaced, live-proof receipts feed status, tool calls from chat work end-to-end.
B-PROVIDERS-LIVE (1.3): provider connections (Ollama first — it's local), auth/status/selection through model-routing library, live-proof receipts.
B-VISUAL-ROUND (0.0.5/5.3): three grounded design directions on the tested base — owner critiques iteratively (design-intent portrayal tooling: screenshots/pty captures for accurate feedback), owner picks.

Priority 2 — after the face is testable and looks like Rune: 5. B-RETIRE-CAMPAIGN (7.2/7.3): parity harness runs capability by capability, PROVEN rows trigger same-change Python removal. 6. B-WASM-EXPANSION (D30): more Rust crates migrate in-process per batteries.

Deferred — after retirement campaign: 7. B-SLEIGHT-MATRIX (3.4b/c/d): memory compaction matrices — counter-intuitive before real conversations exist to compact. 8. B-PLAN-LOOP (4.2): full Plan process. 9. B-SELF-TRANSFORM (6.2/6.2a/6.3): self-modification pipeline + taxonomy closure.

Small cleanups (noted by owner, next UI wave):

Bottom rail: remove duplicated focus/status tokens from the RAIL line (partially done — the RAIL-line render still shows them in the takeover view per owner report)
Bottom rail: truncate identity to 'Rune v' (drop build/unset noise)
Rail line generally: strip unneeded information, keep last-event + version + inspect key

In-flight (do not re-spawn)

I3-command-paths, DEP05-depth, trust-runtime, skills-engine, mcp-settings, parity-harness(landed), continuous-runtime(landed), bounded-stream(landed), live-tool-proof(landed), effect-mediation(landed), memory-invariant(landed), hard-modes(landed), cooling(landed), gateway-sec(landed), authority-map(landed), ledger-lineage(landed), curator(landed), critic-gate(landed), event-vocabulary(landed), lane-concurrency(landed), child-visibility(spawned), universal-input(landed), parity(landed), terminal-budgets(landed), graph-projection(landed), history(landed), seam-registry(landed), retirement-map(landed), evidence-spine(landed), error-wrapping(landed), pprof(landed), restore-points(landed), model-acquisition(landed), device-pairing(landed), extension-host(landed), webfeed(landed), alert-gateway(landed), workflow-engine(landed).

Blocked (need owner or predecessor)

5.3 visual directions: needs behavior-map USE + owner pick (R2-D7)
6.4 extension UI: needs 6.4 runtime (landed) + UI wiring wave
1.3d real-hardware qual: needs physical second device (owner's)
7.3 python removal: needs 7.2 harness + PROVEN rows
7.4 gitea closure: last

Scope law (owner amendment 2026-10-17)

Every factory registry, gate, and map covers the FULL codebase: TUI packages, Go subsystems/libraries, Rust crates (104, the dichotomy), and the live Python authority modules (mimo rune's deployed surfaces, retirement-tracked). No tool may be built TUI-only when the dichotomy and the retirement campaign are standing architecture.

NEW PRIORITY 0 — FIRST-RUN FLOOR + PROVIDER MIGRATION (owner directive 2026-10-17, CORRECTED: approach guidance, not spawn-now — providers are NOT prioritized ahead of current waves)

Build rune as if someone were using it publicly for the first time:

B-FIRST-RUN: first-run experience — onboarding flow, connect services, the floor of the build assumes a brand-new user.
B-PROVIDERS-EXTENSIVE: extensive cloud + local provider list (cloud: OpenAI, Anthropic, Google, Mistral, Groq, Together, Fireworks, DeepSeek, xAI, OpenRouter, + any others; local: Ollama, llama.cpp, LM Studio, vLLM), easy connect flow.
B-APIKEY-MIGRATION (owner-critical, for THIS machine): port ALL API keys and saved connections from mimo code (~/.config/opencode + mimo config stores) into rune — same keys, same semantics, respected exactly, so everything works without Nick re-entering anything. He has API keys from friends he cannot remember — the migration must be lossless. Keys persist per the security law (encrypted/OS store, never plaintext in UI/logs).

DESIGN INTENT INPUT (owner's Textual-TUI preferences — captured contracts, binding on the visual round)

docs/tui-design-capture/ holds the frozen behavior contracts from the OLD Textual TUI (rune_tui.py era) — 1575 lines of the owner's actual preferences, captured as exact contracts. These are the VISUAL ROUND's primary input alongside the behavior map:

8 role-styled bubbles: user (right, blue 0,80,120), assistant (left, green 30,60,30), system (center), confirm (gold thick border), research (blue), error (red), tool (olive, 70% width) — exact rgb values captured
Dark background rgb(30,30,40) — the base theme
Collapsible thinking bubble (dim, left, collapsed by default)
Tool widgets: left-rail style (not boxes), 90% width, status line + details + approve/reject action row
41 slash-commands with stateful subcommand trees (/model, /theme, /goal, /cron, /night, /build, /work, /queue, /connect...)
10 fixed themes (nord, dracula default, monokai, solarized, catppuccin, tokyo-night, flexoki, gruvbox)
Rune's spinner: purple rotating diamond (12 PNG frames, 6.67fps, "Rune thinking...")
Dual scrollback panes side by side, newest at bottom, 3-line input
Right-click copy menu, viewport jumps to bottom on new message These preferences are the owner's — the three visual directions must incorporate them (not copy them literally: the behavior map + D31 govern the mechanics; these govern the LOOK and INTERACTION feel).

First-run law (owner directive 2026-10-17): NO default provider — selection is mandatory at first run

Rune ships with NO provider selected, NO model configured. First run presents the provider selector (extensive cloud+local list) and the model selector; chat stays honestly unavailable ("no provider configured — select one to begin") until an explicit selection is made. The owner's own migration (API keys/connections ported from mimo) pre-selects for HIS machine, but the SHIPPED default for any new user is: nothing selected, selector presented, chat gated until chosen. This law binds B-FIRST-RUN, B-PROVIDERS-EXTENSIVE, B-APIKEY-MIGRATION, and B-CHAT-LIVE (the chat build must not silently default to Ollama — selection is always explicit).

Fresh-state detection (owner directive): the TUI must KNOW when it's a fresh state (no provider configured, no conversation history, first boot) and present the first-run experience accordingly — provider/model selector instead of chat, honest welcome state instead of empty-looking lanes. Fresh-state = no provider selection recorded + no conversation checkpoint. Not the same as error: it's the designed first-run path.

B-PERSONA-LAYER (owner, 2026-10-18: "runes persona layer is not ported either which is important")

The chat path answers as the BARE MODEL today — no identity assembly. PORT THE PERSONA: who Rune IS (identity) + how she speaks (voice) + what she remembers (memory grounding) + how she stays herself (drift governance) — the mimo harness stack is the reference; the repo's partial machinery (voice_state, persona_check, drift_core, memory_continuity) is the starting inventory. Research first (what the layer actually is, how production agents do persona), then an owner interview on what carries into the product Rune (his taste is central — it is HER identity), then the build into the Go core's context assembly (D39: intentions port).

OWNER APPROVED QUEUE (2026-10-19 — the 40-scale wave plan, rulings attached)

✅ VERIFICATION SPEED-UP (split the 10-min checkup into parallel pieces + backfill the ~20 missing receipts) — approved.
DICHOTOMY COMPLETION — approved with correction: the OpenSpec interview DID cover the one-input-box concept; the owner may need to specify finer details. LAW: the consent-card build starts from the SPEC'S EXISTING interview answers (R2-D/SA-D records), NOT from the research round's re-derivation; where the build hits an un-interviewed detail, the wave ASKS rather than assumes. The three pieces (y/n card, watching-her-work live block, waiting-line discharge) proceed.
PORT-THEN-INTEGRATE-THEN-REMOVE — owner correction to the retirement method: port the Go side, INTEGRATE it (repoint the live consumers, run integrated), THEN remove Python. "Port over and integrate the rebase before we remove." The same-change deletion pattern amends: removal happens only after a live integrated period proves the Go side in production.
THE SUB-AGENT WINDOW (owner design, verbatim intent): a TAB in the tasks pane that ONLY appears when sub-agents are in flight. Click it → one row per sub-agent with: truncated task title, which sub-agent has it, running state. Everything clickable/expandable — expanding any sub-agent shows its thinking/coding process live. On the FRONT FACE: an indication that sub-agents are in flight + HOW MANY, dynamically correlated to reality (the landed waves counter + cluster feed it).
RELEASE MACHINE — DEEP DIVE (owner: 'ive asked about this over and over'): not a patch. Pull the CI run logs for both failures, root-cause the tag-step's real failure mode, fix with tests, prove two clean cycles.
HOUSEKEEPING — approved (Go-core supervision swap + /tmp GC).
TABS/WINDOWS — approved: design interview first, then build. 50-scale distribution: 24 waves spawned this batch

12 KiB Raw Blame History