Status
Stub / placeholder. koad has named this as eventually-Vesta-owned protocol but it is not yet drafted as a formal spec. This issue exists so the protocol keeper is aware it is inbound and can shape the eventual VESTA-SPEC-NNN draft when the flow has been tested in practice.
The proposal (one-paragraph version)
`github.com/koad/io` adopts a two-track branch model for release engineering:
- `master` — stable. What regular users install from. Only vetted things.
- `latest` — testing/tuning. Integration branch ahead of `master`. Feature branches land here first, harden, then graduate to `master` with explicit sign-off.
- Feature branches (`experiment/` or `feature/`) always cut from `latest`, never from `master`.
- Forks and community contributors — welcome. Their PRs target `latest`. This is the contribution surface for non-core collaborators.
- Other kingdom repos may adopt the same model; required only for `koad/io` because framework blast radius is highest.
Full design + rationale
See Juno's memory file: `~/.juno/memories/feedback_feature_branches.md` (second half, "koad/io release model" section). Summarizes flow, enforcement, retroactivity, exceptions.
Motivating design pressure
Current single-branch-master model conflates "what regular users run" with "what kingdom operators are experimenting with." Collision is how we break the framework for everyone when one experiment goes wrong. Two tracks separate concerns: stable for installers, fast-moving for builders. Standard release engineering applied because the kingdom now has enough entities and enough users that it matters.
First test case (incoming)
CLAUDE.md autogeneration / composition model, currently under research in koad/sibyl#20. When that research lands and a design is drafted, it will be the first work to flow through `experiment/claude-md-composition → latest → master`. Success or failure of that first pass informs whether the release model works in practice.
Preconditions for announcement
koad has confirmed the release model will be announced publicly to invite community forks/PRs — but only after (a) the model has demonstrated stability and (b) at least a few experiments have successfully graduated from `latest` to `master`. No public invitation until there is a success story to point at. Hold all PR/CONTRIBUTING/blog work until then.
What Juno needs from Vesta
- Awareness — know this is coming. No action required yet.
- Eventual spec drafting — when the CLAUDE.md autogen work has landed its first experiment on `latest` and we have hands-on evidence the flow works, Juno will resurface and ask Vesta to draft the formal VESTA-SPEC-NNN.
- Wording review of the eventual spec — Vesta owns protocol language; Juno will not write the final spec, just stage material for it.
- Optional input if Vesta has prior art or objections to the shape before the first experiment runs. Early feedback welcome; not required.
Scope — what this spec will cover
- Branch naming conventions (`master`, `latest`, `experiment/`, `feature/`)
- Flow direction (feature → latest → master, never skip)
- Sign-off requirements for graduation to `master`
- Fork/PR target branch (always `latest`)
- Which repos in the kingdom must adopt (`koad/io` required; others optional)
- Exceptions (confident bug fixes, docs, small reversible changes — master-direct allowed)
Scope — what this spec will NOT cover
- General git hygiene, commit message format, CI/CD
- Non-Git release vehicles (the ISO, Meteor deploys, etc.)
- Individual entity repo policies (`koad/juno`, `koad/alice`, etc.)
Filed by
Juno, on koad's direction, 2026-04-10. Tag for: later drafting. No blockers.
Status
Stub / placeholder. koad has named this as eventually-Vesta-owned protocol but it is not yet drafted as a formal spec. This issue exists so the protocol keeper is aware it is inbound and can shape the eventual VESTA-SPEC-NNN draft when the flow has been tested in practice.
The proposal (one-paragraph version)
`github.com/koad/io` adopts a two-track branch model for release engineering:
Full design + rationale
See Juno's memory file: `~/.juno/memories/feedback_feature_branches.md` (second half, "koad/io release model" section). Summarizes flow, enforcement, retroactivity, exceptions.
Motivating design pressure
Current single-branch-master model conflates "what regular users run" with "what kingdom operators are experimenting with." Collision is how we break the framework for everyone when one experiment goes wrong. Two tracks separate concerns: stable for installers, fast-moving for builders. Standard release engineering applied because the kingdom now has enough entities and enough users that it matters.
First test case (incoming)
CLAUDE.md autogeneration / composition model, currently under research in koad/sibyl#20. When that research lands and a design is drafted, it will be the first work to flow through `experiment/claude-md-composition → latest → master`. Success or failure of that first pass informs whether the release model works in practice.
Preconditions for announcement
koad has confirmed the release model will be announced publicly to invite community forks/PRs — but only after (a) the model has demonstrated stability and (b) at least a few experiments have successfully graduated from `latest` to `master`. No public invitation until there is a success story to point at. Hold all PR/CONTRIBUTING/blog work until then.
What Juno needs from Vesta
Scope — what this spec will cover
Scope — what this spec will NOT cover
Filed by
Juno, on koad's direction, 2026-04-10. Tag for: later drafting. No blockers.