[beta.30][P1] Finish admitted MCP functional, runtime and policy-race acceptance #305

Beta.29 functional checkpoint

Bounded owner evidence now confirms successful owned job execution and same-run start replay; stale competing update rejection; changed-confirmation rejection without persistence; one winner from two concurrent same-version writes; exact nonsecret default persistence; start confirmation invalidation after a definition change; and application-job cancellation from Running to Cancelled with retained execution history.

A new product failure is isolated to exact replay of successful definition update and parameter-add confirmations: HTTP 409 job_etag_mismatch occurs before recorded replay reconciliation. Track the focused DEF-B29-01 source repair in #333. #316's completed compound job-start admission repair stays closed.

Monitoring reads and owned flow validation/dry-run/readback passed within their tested scope. They did not produce a fresh monitoring trigger/clear, live flow event or receiver delivery. Polling partial job output and application cancellation do not establish native progress notifications or protocol cancellation.

This issue stays open for the replay retest, remaining profile/bootstrap/upsert/classification/tag/revision/rollback and confirmation matrix, fixed-native service timing/state, fresh secret runtime, and live monitoring/flow/event/delivery outcomes. Fresh executors and selected-consumer prerequisites remain in #304/#288.

Retained previous checkpoint and acceptance criteria

Beta.27 owner functional results

Credit the exact Execute-only job's terminal success and idempotent replay, reviewed multistep execution after live script edits, stale new-start refusal, classification-constrained canonical policy lifecycle and persisted-classification spoof denial. Preserve earlier bounded command/cancellation, terminal, typed-task/script/request, value/file and link-boundary results. Repairs #315–#318 stay delivered.

Remaining cases include the wider confirmation actor/arguments/target/revision/expiry matrix, trusted profile/tag/revision/race/rollback controls, actual native progress, fixed-native service operation timing/state, fresh secret-designated runtime, and monitoring/flow/event/owned-delivery postconditions. The unavailable QA start preview did not dispatch and does not establish a new product defect or an extra admission pass.

Use #304's current registered fixed-release fixtures and #288's selected consumer, then preserve exact cleanup under #294. Beta.28 #321/#322/#323 clarify browse and runtime prerequisites; their delivery does not close this owner acceptance issue.

Original functional specification (retained)

Classification and tracking

Unexecuted functional acceptance on disposable fixtures. Source failures in these contexts have not yet been established. P1 denotes campaign ordering. Owner acceptance parent: #294. Release epic: #282.

Observed beta.24 evidence

The corrected context ledger distinguishes directly denied calls from dependency-linked cases that were never invoked. The campaign produced no admitted tenant business execution. Draft validation, selected-schema inspection and no-call previews therefore do not establish successful confirmation, mutation, idempotency or lifecycle behavior. Existing protected live agents and retained history are not execution fixtures.

This issue completes the relevant G03/G04/G05/G10 functional contexts after actual admission and fixture registration. Preserve existing context and case identifiers, then add uniquely identified beta.25 executions and bounded current outcomes.

Required work

1. Build a case manifest from the retained operation/context ledger. For each case record selected native caller, disposable fixture, exact current target and definition/profile revisions, required permission, expected response, expected persisted side effects and cleanup. Use published schemas and supported commands.
2. Exercise preview/confirmation binding using a valid unchanged positive control followed by changed arguments, actor, target, definition/profile revision, expired confirmation and attempted reuse. A denial must occur before the prohibited side effect; verify actual postconditions rather than inferring them from the error label.
3. Exercise idempotency through identical retry/resume, conflicting payload reuse and uncertain outcome reconciliation. Record application count and read back durable state. After an ambiguous transport result, inspect authoritative state before any retry; do not issue duplicate mutations to obtain a cleaner transcript.
4. Verify admitted read-after-write and bounded runtime behavior: file size/chunk/hash consistency, permitted roots and traversal/reparse boundaries; inert terminal progress visible before completion and cancellation while in flight; designated inert-service actions and lifecycle operations confined to disposable targets.
5. Exercise registered monitoring/flow/event cases with current immutable definitions and explicit target profiles. Observe trigger/clear state, flow execution and event history, then verify expected single delivery or bounded retry/reconciliation at the owned test sink. Activate a disposable schedule only for a specifically reviewed bounded case and restore its registered state afterwards.
6. Preserve exact large identifiers as strings and keep validation, admission, execution, readback and cleanup receipts distinct. Record expected negative controls separately from successful business cases.
7. If a valid supported case reproduces a source failure, capture minimal sanitized reproduction and concrete postcondition mismatch, implement the focused fix, and rerun that case plus directly affected controls. Do not preemptively rewrite authorization because an earlier unadmitted case was blocked.

Acceptance criteria

• Every selected functional context has an actual admitted positive execution or an explicitly unexecuted dependency; no schema/preview-only business passes.
• Confirmation binds the correct actor, target, arguments and current revisions; changed, stale, expired or reused claims cannot cause unintended side effects.
• Idempotent retry/resume applies once; conflicting payload reuse is rejected and uncertain state is reconciled before retry.
• Read-after-write and independent persisted postconditions establish actual outcomes, including bounded file hashes, traversal rejection, terminal progress/cancel and inert-service state.
• Owned monitoring, flow, event and delivery cases have current revision bindings and observed durable outcomes; sink receipts establish actual dispatch without duplicate delivery.
• Each case has a unique raw receipt, current input validity, timing, selected identity, expected/actual postconditions and cleanup result.
• No protected live-agent command/lifecycle action or rerun of retained historical execution occurs.
• Reproduced failures are linked to focused repairs and valid retests; unavailable contexts remain open in [QA-CAMPAIGN] Complete 37 retained HTTP MCP contexts and owner release gates #294.

Dependencies and closure

Depends on the selected-consumer connection/admission entry steps in B25-04 (#288) and fixture readiness in B25-05 (#304). Its inert progress/cancellation results can then satisfy the remaining runtime criteria in B25-04 (#288); do not create a circular requirement that both issues must already be closed. B25-07 uses the resulting supported fixture execution path. B25-11 starts only after this phase, dependent security/workflow phases and their diagnostic/review activity finish. CI and beta.25 publication remain separate from owner functional acceptance.