registrystack / registrystack/registry-stack
Document how a bundle acquires acquisitionCapabilities and holderBoundBatchMaxSize
- Vorherrschende Sprache
- Rust
- Sterne
- 2
- Forks
- 0
- Ø Merge
- 2 Std. 55 Min.
- Gemergte PRs (30 T.)
- 130
Beschreibung
Found while verifying adopter-facing configuration documentation against the v0.21.0 release.
## Gap
`products/evidence/reference/request-adapter/deployment-projects/CONFIG.md` documents the bundle-side `acquisitionCapabilities` (at most `search-then-fetch-set` and `source-batch`) and `holderBoundBatchMaxSize` (1 through 16, omission means 1), including the two-sided gate where the bundle opts in and the runtime separately enables.
But no documented authoring path can set the bundle half. `evidencectl build` reads only `governance.yaml`, `runtime.yaml`, and `public-keys/` from the target, and the closed `governance.yaml` grammar does not carry either key; the authoring form has no acquisition concept. So at v0.21.0 every compiled candidate carries the defaults (no gated kind, batch ceiling 1), and a bundle with non-default values can only exist if it is maintained directly as a deployment project, bypassing `evidencectl build` entirely.
CONFIG.md documents the keys as if an adopter could reach them, without saying that the build pipeline cannot produce them.
## Suggested fix
Pick one:
1. Document explicitly that as of the current release these two keys are only settable in directly maintained deployment projects, and that `evidencectl build` output always carries the defaults.
2. If gated acquisition and batch release are meant to be reachable through the supported build path, add a governed input for them (target governance or a build flag) and document it.
Beitragsleitfaden
Rechercherichtung
Beginne mit products/evidence/reference/request-adapter/deployment-projects/CONFIG.md, untersuche anschließend evidencectl build sowie die dokumentierten Eingaben governance.yaml, runtime.yaml und public-keys/. Verfolge, wie acquisitionCapabilities und holderBoundBatchMaxSize zu kompilierten Kandidaten gelangen; abgeschlossen ist die Arbeit, wenn die Dokumentation genau erklärt, ob unterstützte Builds Werte ungleich den Standardwerten erzeugen können und welcher Authoring-Pfad gilt.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Bewertung
- Bereich
- build-system, documentation
- Issue-Typ
- Dokumentation
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Aktivitätsstatus
- Ruhig
- Klarheit
- Größtenteils klar
- Anfängerfreundlichkeit
- 55/100