registrystack / registrystack/registry-stack
Consolidate the closed runtime recipe contract
- Dominant language
- Rust
- Stars
- 2
- Forks
- 0
- Avg merge
- 2h 55m
- Merged PRs (30d)
- 130
Description
## Outcome
Reduce drift between the release-lock producer, Rust verifier/renderer, Compose checker, fixtures, and runbook without turning Registryctl into a general orchestrator.
The existing 1.0 runtime recipe remains the behavioral baseline. This work should consolidate ownership after 1.0, not expand its command, mount, secret, or network vocabulary.
## Design constraints
- One versioned closed contract owns supported products, actions, mounts, inputs, platforms, health probes, and hardening.
- Relay, Notary, Registryctl, and release tooling retain their current ownership boundaries.
- No arbitrary container, command, mount, secret-provider, network, or Kubernetes language is introduced.
- Generated Compose remains replaceable and operator integration remains outside Registryctl certification.
- Security-sensitive parity checks stay fail-closed and reviewable.
## Definition of Done
- [ ] One authoritative versioned source produces or validates every runtime-recipe projection.
- [ ] Python and Rust no longer hand-maintain conflicting copies of fixed action shapes.
- [ ] Generated fixtures are reproducible and checked for drift.
- [ ] Platform pins, health ports, action inputs, network authority, mounts, and hardening have one parity gate.
- [ ] A compatibility policy describes how a future recipe version is introduced and retired.
- [ ] Clean-context Compose and released-artifact journeys remain green.
## Non-goals
- Production orchestration.
- Parent Compose certification.
- Kubernetes support, which remains tracked separately.
- User-defined runtime recipes.
Contributor guide
Research direction
Start by mapping the release-lock producer, Rust verifier/renderer, Compose checker, fixtures, and runbook against the existing 1.0 runtime recipe. Identify where Python and Rust maintain conflicting action shapes, then trace the clean-context Compose and released-artifact journeys. Done means one versioned source and parity gate cover the listed projections, with reproducible fixtures and a compatibility policy.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker-compose, python, rust
- Domain
- backend, devops, release, testing, tooling
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100