eric/ReleaseKit
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

Complete implementation handoff documentation

Browse Source
This commit is contained in:
Eric Rakestraw
2026-10-05 21:06:16 +00:00
parent d0247d1ccb
commit 539877ecc7
7 changed files with 140 additions and 72 deletions
Download Patch File Download Diff File Expand all files Collapse all files

33
docs/roadmap/implementation.md
View File

@@ -1,6 +1,6 @@
# ReleaseKit staged implementation plan
Status: In progress. Stages 1–17 are complete; later stages remain pending.
Status: Complete. Stages 1–18 are complete.
Date: 2026-10-05
@@ -170,8 +170,10 @@ directory. A profile supplies product identity, remote, candidate commands,
optional build specification, and optional Gitea delivery declaration. The
command supplies the version rather than persisting it in the profile.
Use this eventual profile shape; add each optional responsibility only when its
stage implements it:
This composite profile shows the implemented fields together; working
[source-only](../../examples/releasekit.json) and
[binary-producing](../../examples/releasekit-binary.json) profiles are maintained
under `examples/`:
```json
{
@@ -192,8 +194,7 @@ stage implements it:
}
```
This is a planned example, not an existing file or working invocation. Command
entries also accept an `env` map. Run argument vectors directly, without
Command entries also accept an `env` map. Run argument vectors directly, without
implicit shell parsing. A repository that needs shell syntax selects `sh` or
`bash` explicitly. Run commands in the captured repository directory and supply
`RELEASEKIT_VERSION` and `RELEASEKIT_CANDIDATE` for candidate-specific checks.
@@ -920,7 +921,7 @@ was used.
## Stage 18: Complete the initial implementation and handoff documentation
Status: Pending. Depends on Stage 17.
Status: Complete. Depends on Stage 17.
1. Map each initial capability in the feature roadmap to its implemented owner
and existing behavioral evidence. Record the concrete package and dependency
@@ -946,6 +947,26 @@ implemented boundary accurately. Completion depends on local implementation
and development evidence; architectural review, a broader testing plan,
consumer migrations, and release/deployment decisions follow this sequence.
Evidence and handoff: `docs/internal/overview.md` records both public Go
facades, all 14 implemented Go packages, the absence of third-party module
dependencies, capability ownership, and representative behavioral tests. The
README and canonical CLI, configuration, consumer, integration, development,
and release documents describe the implemented behavior; the policy and product
roadmaps no longer present completed facade, delivery, or workflow work as
pending. `go test ./...`, `go run ./internal/apicheck`, local Markdown link and
fragment checks, and prose whitespace checks pass. All three maintained
Woodpecker examples parse with local PyYAML 6.0.3, with the token mapped only in
each delivery step. Local Git and HTTP fixtures exercise source-only delivery,
binary delivery, publication recovery, and the ReleaseKit tagged-source workflow.
The Woodpecker workflows remain prepared, not activated. No live runner,
configured deployment secret, immutable deployment pin, hosted Gitea delivery,
or ReleaseKit source release was used or verified. Consumer migrations and
measurement of removed consumer infrastructure remain future adoption work.
The implementation is ready for the maintainer's subsequent architecture
review; broader testing and release or deployment decisions remain outside this
completed implementation sequence.
## Coverage of the feature roadmap
| Initial target responsibility | Implementing stages |