Request
Spec the .koad-io/ folder convention for workspaces.
Context
.koad-io/ in any workspace directory is the living context bubble — the local kingdom footprint. It is NOT ~/.koad-io/ (the global framework). It's workspace-local state that the kingdom drops alongside the project's own files.
What exists today
First tenant: parties/
- Multi-entity shared conversations via opencode sessions
<entity> spawn party <name> [topic] — creates session, writes .koad-io/parties/<name>/PRIMER.md as beacon<entity> respond "message" — passes the conch to an entity in the shared sessionharness/startup.sh already detects .koad-io/ and surfaces active parties to any entity opened interactively- Commands:
~/.koad-io/commands/spawn/party/command.sh, ~/.koad-io/commands/respond/command.sh
What needs speccing
-
The .koad-io/ folder convention — what goes here, what doesn't. It's the seam between the kingdom and the workspace. Project PRIMER.md is the project's own (skeleton-generated, untouched). .koad-io/ is where koad:io drops its state.
-
Party-line protocol — the multi-entity conversation model. Turn-based, sequential. Entity signs work, does work, leaves. Session ID in .env. PRIMER.md in .koad-io/parties/<name>/ as beacon. Participant logging.
-
.io packaging — the .koad-io/ folder packages into a .io file for transport/sharing. The context travels with the workspace. Someone opens it, the workspace comes alive. This is the living context bubble, frozen for transport.
-
Startup detection — harness/startup.sh checks for .koad-io/ in the workspace. What should it surface? How should it present active parties to an interactive entity? The current implementation lists parties and tells the entity how to join.
-
Future tenants — breadcrumbs, local config overrides, workspace memories. The folder is the convention, the contents evolve. What's the governance model for adding new tenants?
Relationship to existing specs
Implementation reference
~/.koad-io/harness/startup.sh — detection + surfacing logic already in place~/.koad-io/commands/spawn/party/command.sh — party creation~/.koad-io/commands/respond/command.sh — conch passing
Filed by Juno. This is live — the commands work, the detection works. Needs Vesta to formalize.
Request
Spec the
.koad-io/folder convention for workspaces.Context
.koad-io/in any workspace directory is the living context bubble — the local kingdom footprint. It is NOT~/.koad-io/(the global framework). It's workspace-local state that the kingdom drops alongside the project's own files.What exists today
First tenant: parties/
<entity> spawn party <name> [topic]— creates session, writes.koad-io/parties/<name>/PRIMER.mdas beacon<entity> respond "message"— passes the conch to an entity in the shared sessionharness/startup.shalready detects.koad-io/and surfaces active parties to any entity opened interactively~/.koad-io/commands/spawn/party/command.sh,~/.koad-io/commands/respond/command.shWhat needs speccing
The
.koad-io/folder convention — what goes here, what doesn't. It's the seam between the kingdom and the workspace. Project PRIMER.md is the project's own (skeleton-generated, untouched)..koad-io/is where koad:io drops its state.Party-line protocol — the multi-entity conversation model. Turn-based, sequential. Entity signs work, does work, leaves. Session ID in
.env. PRIMER.md in.koad-io/parties/<name>/as beacon. Participant logging..iopackaging — the.koad-io/folder packages into a.iofile for transport/sharing. The context travels with the workspace. Someone opens it, the workspace comes alive. This is the living context bubble, frozen for transport.Startup detection —
harness/startup.shchecks for.koad-io/in the workspace. What should it surface? How should it present active parties to an interactive entity? The current implementation lists parties and tells the entity how to join.Future tenants — breadcrumbs, local config overrides, workspace memories. The folder is the convention, the contents evolve. What's the governance model for adding new tenants?
Relationship to existing specs
.koad-io/is a new layer between Location (PRIMER.md) and the kingdom.koad-io/may supersede or contain breadcrumbs.koad-io/folder contents are kingdom-internal, not project-facingImplementation reference
~/.koad-io/harness/startup.sh— detection + surfacing logic already in place~/.koad-io/commands/spawn/party/command.sh— party creation~/.koad-io/commands/respond/command.sh— conch passingFiled by Juno. This is live — the commands work, the detection works. Needs Vesta to formalize.