0006 — The code-flow ladder is trunk → batch → gated; maturity.code alone picks the release process
Status: accepted (supersedes 0002; amends 0001 and 0005) Date: 2026-10-22 Issue: #109
Context
By v0.30.0, tp release picked between four processes using three inputs: maturity.code, the forge's protection on the base branch, and fragments: bool. The four processes were direct, the story pull request that prepares the release (0002), the release/vX.Y.Z pull request (0001, story 005), and the fragments batch (0005). The manual called the last three "level 1", yet each prepared a release differently. Nothing declared which one a project was in. In gobank-workflow #29, an agent prepared a release in the story-PR way while the project batched (#108).
Options
| Option | Complexity | Testability | Domain clarity | Operational risk |
|---|---|---|---|---|
A. Keep the four processes and report the mode in tp release query |
none removed; one more report | as today | the mode is still inferred from three inputs | agents and docs keep drifting from the code |
| B. Ladder 0 trunk, 1 story PR, 2 batch, 3 gated | the story-PR path stays beside the batch | one more level to cover | each level is its own process | a level most projects pass through without using; #51 renumbered |
| C. Ladder 0 trunk, 1 batch, 2 gated; drop the story PR | about 1,200 lines removed (005, 006, #75 resume, #98 close list) | one process per level | maturity.code names the process |
ten repos at code: 1 become batch projects on upgrade |
Decision
C. The step from trunk to batch is one deliberate jump, made by running tp maturity code 1, rather than an intermediate stage. fragments: is no longer read; tp check warns where it is still set. A protected base at code 0 makes tp release stop with an error and does not silently switch the process. tp --init writes code: 0, which reverses #94.
Consequences
Easier:
- One fact,
maturity.code, says how a release is prepared, sotp release query(#108) and the docs can state it rather than infer it. - Parallel stories never conflict on a shared
[Unreleased]or version.
Harder:
- A single story at level 1 still goes through the batch: a fragment, a pull request into
release,.tp-release.yml, then the release PR.merge_waitwalks that in one run. - At level 1, a hand-edited
[Unreleased]or a.tp-release-commentis an error fromtp check.
What still holds:
- 0001's two runs with the forge as the state.
- 0003's bounded wait.
- 0005's release branch and fragments.