These workplans exist only in the retired local hub. Their random pre-ADR-007
identifiers are refused by C-06 as stale references, so they cannot be
registered. Deriving from the canonical record id takes no identity from
anything: central does not hold them and the old ids die with the cache.
Records central already holds were deliberately left untouched.
Refs CUST-WP-0068-T06
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
Document the one recipe a new rapp uses to acquire runtime secrets:
standing KV secrets bind through a CCR target.rapp, leases through
grant rapp_id. Stamp the existing postgres grants and the qonto
workload CCR. Gate, delivery, and revocation are unchanged.
Converge the S3 platform-service pattern onto ADR-0007, emit the
reef-railiance live deployable inventory for the family coverage
check, and mark T02 done. Declaration edits land in rapp-openbao
and rapp-postgres.
T01: docs/rapp-platform-service-pattern.md generalizes the ownership split
already drawn in the rapp-openbao and rapp-postgres boundary docs into a
reusable four-question test, a reference rapp.yaml for platform services, the
grouped-rapp member rule, and the credential-lane position. It deliberately
does not restate the four-axis model, which railiance-master owns.
T03/T04/T05: proposals routed to the repos that own the model rather than
authored here - reef-railiance (bound_rapps lists 1 of 3 live rapps, and should
be derived rather than hand-listed), railiance-master (rapp.schema.json plus a
family declaration validator, grouped-rapp members field, wave-2 candidate
refresh), the-custodian (canon promotion of the four-axis model, which also
closes the open C-31 multi-segment prefix failures).
T02 is held until the schema settles so the platform rapps and the schema do
not converge on different answers.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Survey of the four-axis repo family model against the live cluster and all six
family repos found the concepts sound but unenforced: rapp.yaml has no schema
and has drifted three ways across the three existing rapps, the reef binding
registry lists 1 of 3 live rapps, the rapp population diverged from the
first-wave plan of record, and the model is not in custodian canon so
fix-consistency cannot check it.
Operator decisions recorded in the workplan: grouped-by-bounded-context rapp
granularity, S3 owns only its own rapps and routes schema/canon changes to the
repos that own them, canonize the model now, and build the missing wave-1
user-facing exemplar.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
