ops-mason/docs/forgejo-consumer-eso-builder-review.md

Forgejo consumer ESO successor builder review

The existing builder silently assigns the same CCR-DRAFT-...-ESO path to two role-backed policies. The staged source fixes the consumer-reader-policy suffix to the actual consuming service, retains KeyCape's ESO suffix, and refuses duplicate write identities. The real regression first fails against current owner source, then 42 builder/plan/structural tests pass against the staged source. It verifies two role-backed CCRs, platform validator compatibility, exact independent namespace/SA bindings and all six structural objects. A failed source build can leave partial preparation files; it performs no native apply and such files confer no approval.

Acknowledged1.1 remains untouched; proposed 1.2 is refused by current Mason admission until accepted owner source exists. Its dedicated role uses the current typed StructuralObject openbao_role contract, so no new framework or weaker verifier is needed. Actual role/policy evidence must be owner-authenticated and independently classify created/preexisting before Warden receives a materialized-case binding. No native verifier/adapter or session is installed by this patch, and the legacy planned rollback inventory remains insufficient creation proof.

Supplementary generated-CCR refinement after Platform conditional review

Exact prior 271 packet is preserved at /tmp/forgejo-consumer-eso-refinement-original-271, alongside original c48. Platform found two additional generator gaps: hardcoded keycape target for the consumer, and delete-only consumer-role lifecycle. Both meaningful counterexamples fail against 271 source before the fix. Current staged generator derives target.workload from consuming_service only for consumer-reader-policy, preserving all KeyCape ESO output fields. A role-backed consumer CCR requires reverting consumer reference, authenticated case-created ownership, preservation of preexisting/shared objects, issued-token owner revocation or independently verified expiry before deactivation, and no new login/remint during recovery. Actual owner native authority remains required; generated wording is not an implemented revocation adapter.

Forty-four focused builder/plan/structure tests now pass. Earlier 42 and original counterexample/failure history remain retained. The old committed 1.1 bundle still mislabels the consumer workload keycape and therefore correctly fails fresh exact target matching after this correction. That historical bundle is preserved; the checker is not weakened or grandfathered. Local fixtures alone use corrected/rehashed consumer metadata, with a separate regression proving old bundle refusal. Current 1.1 unbound consumer generation changes only its previously wrong target.workload; KeyCape reader output remains unchanged. The proposed 1.2 render/type/case/source remains pending exact acknowledgment, with identical six-object structural body and no native completion claim. Fresh source build/bundle owner reconciliation must occur after exact acceptance before any native apply/materialization; old CCR or bundle approval is not silently reassigned. New source/test hashes are in validation.json and generated projection receipt.