| Reuse before implementation | vergabe-teilnahme consumed the existing hosted registry with 65 capabilities and a dated, hashed snapshot. Source freshness and completeness checks prevent an unavailable registry from silently authorizing new work. No second registry was built. |
| Repeatable release checks | 208 provider tests and 82 customer application tests passed; application tests and migration checks now run before customer image publication. Two actual release defects were found and fixed: missing source templates and missing runner BuildKit support. |
| Less duplicate CI | Application checks run for PR updates and main, without an additional feature-branch push trigger duplicating the PR run. Main release validation remains explicit. |
| Less review-queue noise | Four completed tasks with explicit published `needs_human: false` were corrected in the Hub. The flagged queue fell from 19 to 15 (21%); the two nonterminal flagged tasks were unchanged. A fresh query after login still returned 15: 12 done, 1 cancelled, 1 todo, 1 wait. The other 13 terminal flags need source/residual review. |
| Clearer coordination | One published project owns factory integration; implementation stays in the two product repositories. Ten dependency-return records name the supplying task, source revision, next action and required evidence. Existing GLAS-WP-0015 coordination is reused. |
| Fewer stale open records | REUSE-WP-0022 is finished, customer source/release tasks are done, and both PRs now show merged. Customer deployment remains an explicit waiting task instead of being mixed with completed source work. |
These are observed improvements in discovery, validation and coordination.
Hours saved, monetary savings and autonomous throughput have not been measured.
The original 94-plan/264-task portfolio baseline is dated; no later fleet-wide
count is implied by these changes. The governed-attempt ledger remains empty and
the fourteen-day acceptance window has not started.
## Next execution sequence
1. Prepare and accept the exact G0 tenant/actor/project/profile, repository
grants, operating owners and enforceable time/spend contract. Project
adoption and publication are complete; unattended operating admission is open.
2. Close the existing GLAS-WP-0015 chain: KeyCape service-client custody and
registration, audit sender admission, deployed approval claim/consume and
native Secrets Engine delivery. Obtain current policy allow/deny evidence.
Protected runtime installation can advance alongside that chain.
3. Prove the current Railiance worker's natural claim, immediate heartbeat,
execution and accepted terminal close, including lease-loss refusal and
durable close replay. Retain one integrated delivery item plus two prerequisite
closures as the project's WIP limit.
4. Use that worker for a useful accepted change; admit and deploy the tested
vergabe-teilnahme image through its exact tenant, database, storage, access
and rollback contract (VERGABE-WP-0018-T03). Keep Railiance Fabric in its
existing medium-term placement work until its additional utility is needed.
5. Complete recovery/limit drills, then measure fourteen days: at least five
useful accepted changes across two repositories, at least 80% without
operator repair, median handling at most 30 minutes per accepted change and
routine operation at most 30 minutes per day. Preserve every attempt,
