Repository navigation
id(phase-14): Program ecosystem (share, fork, gallery) — core topic (research + design) #6278
Description
Program ecosystem (share, fork, gallery) — Phase 14 core topic (research + design)
Filed from the next-horizons discussion #1240, decided by Drew on 2026-11-05: all themes are planned. This issue is the core topic for Program ecosystem (share, fork, gallery). Its job is research and design — broaden the idea beyond what is already understood, set up multiple next steps, and produce implementation plans. No implementation starts here; the output is design documents and implementation issues.
Drew's principles for everything in Phase 14 (from #1240, 2026-11-05)
- Local-first is always the goal, AND a hosted version is intended: central coordination supporting a large graph of broadly accessible objects.
- Anything built must be completely usable by others hosting a small or large server themselves. P2P-hosted worlds and data behave the same as a large hosted public server; differences live in backend scale elements and access controls.
- Users connect to each other and transfer/interact directly wherever possible, so hosted resources are an offloadable backstop, not a requirement. The app must not technically need us to function. Collaborative / shared / federated / local-first / p2p.
- Our hosted instance is essentially public; other operators open theirs only as much as they want. Publishing paths: share to a big server, publish on pkarr, or self-host. All comms through iroh on the backend; first-class clients.
The idea, broadened
Programs are the platform's content. Today they are files you have. An ecosystem asks how a program travels: authorship, versioning, signing, forking with attribution, template worlds, install-into-a-world in one click, and updates flowing to installed copies. Broaden with the trust model first (F12.17 provenance is the foundation) and the local-first rule: a gallery is a registry like any other — ours can be public, anyone can run one, and sideloading a .roc file must always work.
Research questions (first pass)
- Program identity: name + author key + version + content hash; what a fork records
- Install semantics: pinning vs tracking a channel; what an update may change without world-owner approval (ABI, F12.7)
- Template worlds: a world snapshot as a starting point — state, programs, roles included or stripped
- Gallery as registry: same protocol family as world discovery (T2), different object type
Dependencies and existing pieces
Builds on F12.7 ABI (#1064), F12.8 guest SDKs (#1065), F12.9 upgrades (#1066), F12.17 provenance (#1069). Registry protocol shared with the discovery topic.
Next steps — the version ladder
- v1 — first-iteration design — its own issue, filed in the same pass and linked in the first comment below
- v2 — outline: gallery & updates — its own issue, filed in the same pass and linked in the first comment below
- v3 — outline: public gallery — its own issue, filed in the same pass and linked in the first comment below
- v4 — outline: ecosystem at scale — its own issue, filed in the same pass and linked in the first comment below
Plus a standing rule for this topic: anything the research surfaces that doesn't fit v1–v4 gets its own issue (Drew's rule: every feature, concept, or idea gets an issue), and future investigations are listed as comments here rather than lost.
Sequencing
Design queue order: F12.4 provider registry (#1061) and F12.10 scheduling/quotas (#1067) designs land first; Phase 14 v1 designs then run hosted worlds → discovery → agents spike → the rest. Implementation follows Phase 13. The drop rule applies throughout: anything that proves blocked, wrong, or superseded gets parked or closed with a note — never a silent stall.
Acceptance criteria
- A research + design output exists for Program ecosystem (share, fork, gallery): design documents broadening the topic beyond the current understanding, per the Phase 14 principles in the body (local-first plus hosted coordination).
- Multiple concrete next steps are produced as implementation plans / implementation issues filed from this topic.
- No implementation starts under this issue itself (per its own charter).
Activity
developing-today commentedon Nov 5, 2026
CODE-1844
dezren39 commentedon Nov 5, 2026
Version ladder for this topic (filed in the same pass, 2026-11-05):
Phase 14 plan of record: #6312. Discussion of record: #1240.
dezren39 commentedon Nov 6, 2026
🤖 Agent note · done
50 remaining items
developing-today commentedon Nov 9, 2026
🤖 Agent note · handed off
developing-today commentedon Nov 9, 2026
\ud83e\udd16 Agent note \u00b7 handed off\n- Agent: repo queue worker, lane code-p (repo-worker-code)\n- Session / ID: cron repo-queue-worker-shift-p run 2026-11-08 18:57 CST; task 13813\n- Found via: claimed task 13813 this shift; execution-lane assignment returned opencode (lane row 5231)\n- Task: Claimed task 13813 (small_fix) for issue #6278 (attempt 2/4). Fresh check: issue #6278 is OPEN. No hard-stop labels (held / user/owned / do-not-merge / do-not-auto-edit) on the target. Handed off to the opencode claimant \u2014 the claimant launches the bound opencode session; this lane does not work it directly. Task 13813 parked 1200s in the same pass.\n- Expectation: claimant session drives task 13813 to a terminal state.\n- Links: task 13813 \u00b7 issue #6278\n
dezren39 commentedon Nov 9, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 9, 2026
🤖 Agent note · task 13813 re-handed off to opencode claimant — FINAL attempt 4/4
handed_offagain and parked 1200s by lane code-n. Because this is attempt 4/4, if the claimant does not bind during this cycle the task exhausts its attempts — flagging for the fleet monitor / next shift.dezren39 commentedon Nov 9, 2026
🤖 Agent note · handed off
opencode; checkpointsclaimedandhanded_offrecorded on the task.dezren39 commentedon Nov 9, 2026
agent-note:v1
task 13813 (small_fix, developing-today/code issue #6278 — id Phase-14: program ecosystem research + design) picked up by lane code-l and handed off to the opencode claimant per execution-lane assignment (lane row 5231, assigned_lane=opencode). Fresh check this shift: issue #6278 OPEN, no hard-stop labels. The bound opencode session owns the research + design.
dezren39 commentedon Nov 9, 2026
agent-note:v1
event: handed_off
task: 13813 (repo-health-code-pilot, worker repo-worker-code, lane code-j)
state: handed off to opencode execution lane (assignment row 5231); parked 1200s pending claimant launch
fresh evidence: issue #6278 OPEN, labels carry no hard stops (held/user-owned/do-not-merge/do-not-auto-edit absent)
expectation: opencode claimant launches the bound session and drives task 13813 to a terminal state
dezren39 commentedon Nov 9, 2026
agent-note:v1
task: 13813
lane: code-o
stage: handed_off
state: execution lane assigned opencode (lane row 5231); handed off to the opencode claimant per runbook 1b. Fresh check 2026-11-09T06:24:37Z: issue #6278 OPEN, no hard-stop labels; no PRs in packet.
next: claimant launches the bound opencode session for task 13813 (issue #6278).
dezren39 commentedon Nov 9, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 9, 2026
agent-note:v1
state: handed-off
queue: repo-health-code-pilot
task: 13813 (small_fix, worker repo-worker-code, lane code-e), queue attempts 4/4 AT CAP
by: repo-worker-code lane code-e
at: 2026-11-09T07:13:00Z
Handed off to the opencode execution lane (assigned_lane=opencode via fleet queue lane, lane row 5231). AT-CAP WARNING: task 13813 is at attempts 4/4. Fresh check this shift: issue #6278 OPEN, no hard-stop labels. Packet scope for the claimant session: produce the id Phase-14 program ecosystem (share, fork, gallery) research and design deliverable for issue #6278 per the packet acceptance, or record the precise blocker on issue #6278. This lane does not work task 13813 directly. Parked 1200s to release the claim for claimant binding. Labels already in the parked/assigned set.
dezren39 commentedon Nov 9, 2026
🤖 Agent note · handed off — task 13813 (small_fix, issue #6278) claimed by lane code-m, execution-lane assignment opencode (lane row 5231). Fresh check: issue #6278 OPEN no hard-stop labels. Handed off to the opencode claimant to drive task 13813 to a terminal state; this lane does not work it directly.