T02 concluded no registry carries a lane-to-workload join key. Too strong — it
was derived from ops-warden's catalog alone, which is the one place a workload
declaration would not live.
rapp-*/declarations/rapp.yaml declares workload_identity with
data_classification, criticality, readiness_state and bound_reefs for nine
workloads. ops-warden's dataclass_floor already maps synthetic/internal/
confidential/restricted to M0-M3. So workload -> classification -> minimum
maturity is a shared vocabulary spanning two repos already, and it is the
operator's maturity-derived default half-implemented by accident. criticality
is the other half and no control reads it yet.
Three real defects replace the blocking unknown: the lane-to-workload key is
only derivable by parsing path_template, whose convention is inconsistent
(rapp-qonto/keycape-client parses a bundle as a workload) and whose names
disagree with workload_identity.name; rapps declare "public" which
dataclass_floor does not map; and nine declared workloads do not cover ~17
catalog path identities.
Consequence for ownership: zone-engine does not need to build a workload
registry. It consumes rapp declarations plus dataclass_floor, and asks
ops-warden for one explicit field.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
tegwick
26e3490c9b