Verify business-site release evidence before staging registration #5248

🤖 Generated by the Agentic Engineer

Summary

Verify the business site's signed manifest publication through Platform's existing first-consumer tooling, without granting deployment authority.

Motivation

The public-only staging registration in #5247 needs verifiable first-publication evidence before Flux can supply an observed binding. Platform main 32e5761d3c2e785edb8bc62d58b6fdedc63420f7 currently binds its bootstrap verifier to the existing documentation consumer, the legacy publisher identity, a push event and a different caller. The actual business-site v1.0.2 publication uses a release event and its source-owned runtime caller. Copying a bare signer revision into the legacy approval format would misinterpret its authority.

Proposed Solution

Extend the existing tooling with one explicit, non-activating business-site verification profile. Bind the repository, caller, event, maintained publisher, source identity and manifest package to the reviewed consumer. Preserve the existing documentation-consumer path unchanged. Produce a distinct manifest-publication evidence receipt that is not accepted as a bootstrap approval, observed Flux binding or active consumer record.

The expected immutable inputs come from the independently verified v1.0.2 release recorded on #5247. This increment re-verifies manifest publication; it must not claim that it independently repeats paired-image/provenance verification or deploys the tenant.

Acceptance Criteria

• An explicit opt-in invokes only the named business-site profile; ordinary bootstrap behavior and existing refusal controls remain unchanged.
• The actual caller, successful release publication, immutable source/tag/digest and exact fully qualified maintained publisher are independently bound. Wrong or ambiguous product, event, caller, publisher, tag, source or digest refuses.
• Incomplete, malformed, trailing or failed dependency reads, including plausible output followed by failure, emit no success receipt.
• Verification writes no approval, matcher, tenant registration, policy, routing or cluster state. It cannot accidentally populate the legacy approval schema.
• Retained documentation-consumer tests and new behavioral controls pass. Exercise the real v1.0.2 manifest signature/publication path and record its boundary separately from static fixtures.
• Documentation explains the explicit command, receipt limitations and remaining Register the public-only business-site staging tenant #5247 registration/private-input/live-acceptance work.

Alternatives Considered

Do not add a guessed approval row, broaden a signer matcher, copy the legacy workload skeleton, or introduce a parallel publication system. Actual tenant registration and private-input ownership remain separate acceptance under #5247.

Planning

Priority High; Effort Medium; Standard service class. The outcome is a repeatable Platform-side verification path for the existing signed business artifact. Success is the real verified receipt plus retained negative controls during this delivery, with no runtime authority change. WIP capacity is explicitly waived by the maintainer for this session. This non-activating child does not require or claim the parent's private configuration value.

Part of #5247.