Beta.29 owner checkpoint accepted; beta.30 fix-forward

The owner tested released beta.29 at 4b148ebe824b3de445a12d30e95b8f5c30d53655. Its API, Web, HTTP MCP and migration deployment digests match the published record, and the required applied migrations were independently read. The mounted retained key-ring storage was verified; full key-file/backup continuity remains unverified.

Create and deliver the focused DEF-B29-01 repair in #333, then publish beta.30 through the existing required PR/main and release workflows. Update the canonical continuation guide and provide the owner a separate local-testing prompt.

Credited results: 33/35 fresh bounded functional assertions, 12/12 historical remediation assertions, 2/2 metadata-only assertions, 7/7 access-control assertions and 3/3 new-fixture cleanup assertions. The two fresh failures are manifestations of the single definition-replay defect. These populations remain separate.

#315–#318 and #321/#322 remain delivered and closed. No open owner acceptance issue satisfies all its closure criteria yet. Continue #288/#304/#305/#306/#308/#310 under #294. Owner production acceptance remains NO-GO; autofill remains deferred.

Retained previous checkpoint and acceptance criteria

Current iteration: beta.28 published; owner campaign open

The beta.27 owner checkpoint is accepted as bounded owner-test evidence. #301 is now closed for the original primary credential's reviewed Production admission, preserved grants/exact expiry, two admitted native tenant reads and associated negative/idempotency controls.

Beta.28 delivery — complete

• [beta.28][P2] Report bounded file browse truncation and unsupported continuation explicitly #321 — bounded file browse now reports truncation, returned count, applied limit and unsupported continuation.
• [beta.28][P2] Clarify loaded component identity and isolated executor prerequisites for owner campaigns #322 — owner checkpoint, actual selected component proof and independently enrolled disposable executor instructions.
• Report bounded file browse truncation and prepare beta.28 owner campaign #323 — independently reviewed, required hosted validation passed, normally merged; version remains sourced from Directory.Build.props.
• v0.1.1-beta.28 published; all required archives, checksums, SPDX inventories, digest-pinned Compose bundle, publication record and five immutable images independently verified.

Released source: 5079f000fb577fc55925c2701c22fb7221fd7821. Reviewed candidate, tested PR merge and merged source share tree 4099741e4ca0d3e3a310ac18a3458446df208c4d.

PR validation passed first attempt in 14m44s; merged-main validation passed first attempt in 17m19s. Release build passed 8/8 jobs in 19m19s; Publish release passed 7/7 jobs in 25m32s, including its build wait. Each PR/main/tag source-validation run passed 4,805 executed .NET tests (4,184 core + 36 API + 585 components), zero failed/skipped/notExecuted/error/timeout/aborted cases, plus 168 source-contract tests.

Independent public verification completed at 2026-10-19 06:35 UTC: 15/15 API asset hashes and sizes, 14 checksum entries, 13 publication artifact bindings, three native package identities, five Compose pins and five anonymous registry manifest/config identities matched the release. publication.json SHA-256: 5552100c3e2f6d3ceb5a773991703a5569a09f1f058e9bbaeba2beec3d4e1667.

The hosted completion gate passed full anonymous image pulls and disclosure/inventory scans. Independent local verification downloaded public assets and registry manifests/configs without running binaries or pulling image layers. Scan scope does not include a CVE audit. Workflow/release source remained the released SHA; publication tooling was at 4b148ebe824b3de445a12d30e95b8f5c30d53655, with the executed promote-release.py blob identical at both commits.

Artifacts are ready to deploy and test. Owner deployment and functional acceptance remain pending; this epic stays open / NO-GO for production acceptance.

Source baseline is the published beta.27 commit 836eb575cf175022c0eff1208f4a1489fc1f1983. The four repairs #315–#318 remain source-complete and closed through #319. This follow-up does not duplicate them.

Owner results credited

• Historical output remediation passed across ordinary UI/API and same-owner no-reveal MCP projections; fresh fixed-native secret acceptance remains in [beta.30][P1] Finish fresh fixed-native secret-reader and untrusted-context acceptance #306.
• Exact Execute-only job execution, idempotent replay and immutable reviewed multistep content passed; wider cases remain in [beta.30][P1] Finish admitted MCP functional, runtime and policy-race acceptance #305/[QA-CAMPAIGN] Reconcile 32 retained original HTTP MCP predicates and current release gates #294.
• Classification-constrained canonical policy lifecycle and persisted-class spoof rejection passed; profile/revision/race cases remain in [beta.30][P1] Finish admitted MCP functional, runtime and policy-race acceptance #305/[QA-CAMPAIGN] Reconcile 32 retained original HTTP MCP predicates and current release gates #294.
• No fixed-native service acceptance was established: executing protected agents were still older than the delivered repair.

Owner campaign remains open

#288 tracks actual selected-consumer version/metadata/progress. #304 tracks exact disposable fixture readiness and final cleanup. #305/#306/#308 retain functional, fresh security-reader, native prompt and value/paging contexts. #310 retains the unstarted exact 240-call/3600-second isolated hour.

Verify actual deployment digests/migration/key-ring state, preserve/recover the unavailable QA runtime, establish independent fixed-native executors and reconnect the selected consumer before resuming. The retained no-reveal auxiliary review is already applied; read its current state instead of replaying an expired historical proposal. Preserve the original primary, grants and exact expiry.

The original 438 context IDs, previous 60 appended IDs and 20 new beta.27 contexts retain their individual evidence. No combined production-readiness percentage is inferred. Owner acceptance remains NO-GO. Autofill remains deferred and untested. Private operational bindings and evidence remain outside public GitHub.

Historical beta.25 plan (retained for provenance)

Active iteration: beta.25 after the final corrected beta.24 campaign

Deliver v0.1.1-beta.25 through one reviewed integration PR to main, hosted build/publication, and verified downloadable artifacts so the owner can rerun the native HTTP MCP production-readiness campaign. Current main and published beta.24 are 623a75a from #300. Recheck version/tag allocation before the release-source change.

The final supplied evidence dated 18 October 2026 supersedes earlier beta.24 first-pass interpretations. Root-cause investigation refines the corrected retest. Configured application grants exist, but matching Production MCP operator policies are absent; both protected tenant flow reads deny before business dispatch. Independently reviewed reconciliation already succeeds in isolated Production protocol testing. This establishes a deployment-state prerequisite and setup/diagnostic follow-ups, not a reproduced grant-check code defect.

The corrected evidence also proves supported Windows protected preparation and authenticated diagnostic runtime using a complete owner-controlled path selection. Active selected-consumer migration remains unexecuted. #289 is now closed against supplied owner receipts: configured API liveness/readiness succeed and the anonymous canonical liveness alias remains protected.

Beta.25 issue map

Priorities specify campaign ordering, not incident severity.

#294 remains the acceptance parent. Existing completed source issues #283–#287, #290–#293 and #296–#299 retain their implementation history. Reopen a source defect only after a valid current reproduction. Preserve scanner #281 and the protected health regression #289.

Source and distribution delivery checklist

• Implement [beta.25][B25-02][P1] Show configured grants and effective HTTP MCP admission in credential setup and details #302, [beta.25][B25-03][P1] Validate complete Windows protected launcher paths during preparation #303, [beta.25][B25-08][P2] Explain policy evaluation under per-operation attenuated delegation #307 and [beta.25][B25-10][P2] Exercise the existing reviewed-access HTTP MCP protocol regression in Production #309 with the existing shared admission, setup, protected launcher and generic test contracts.
• Update canonical guides under docs/mcp-http, docs/integrations and docs/deployment as appropriate; validate existing layout/links. No ad hoc root reports or duplicate wizards/policy engines.
• Run meaningful focused coverage. The optional mcp-campaign protocol selection must execute Development, Production and gateway health (minimum 3), with both environment cases identified; retain bridge minimum 16 and relevant packaged Windows checks.
• Change product version only in Directory.Build.props; derive v0.1.1-beta.25 and all generated artifacts from that version.
• Review and merge one integration PR normally. Required PR and merged-main validation must succeed in under 20 minutes, with real executed tests and measured stages. Keep the hour and deployment/browser matrices opt-in.
• Tag the exact validated merge and complete generic hosted release-build/release-publish workflows. Match source, tag, evaluated version and authenticated build artifact receipt before registry writes.
• Verify every public archive, NuGet package, SPDX inventory, SHA256SUMS binding, digest-pinned Compose bundle and publication record. Include Windows MCP ZIP/SPDX and all currently required client/tooling distributions.
• Verify five fixed public image families, immutable digests, anonymous pulls, source/version metadata and existing layer/inventory scans. Preserve existing release bytes/tags and stable-channel policy.
• Record final PR/merge/build/publication URLs, artifact links, checksums and image digests. Mark build/distribution integrity complete only after public verification; functional acceptance remains pending owner testing until independently evidenced.

The four source tracks can proceed while #301 follows its legitimate product authority path. An outstanding live reviewer decision must not prevent completing the authorized source PR and beta.25 distribution. Publication does not apply the live repair or authorize the full mutation matrix.

Owner campaign gates

1. Verify the deployed release/source/catalog/destination and selected consumer, apply [beta.25][B25-01][P0] Apply reviewed Production MCP admission and preserve exact intended expiry #301 through real independent product review, and prove each original tenant's native flow read.
2. Complete [beta.30] Complete selected native consumer identity, metadata and progress acceptance #288's connection/admission stage, prepare [beta.30][P1] Complete isolated fixed-native fixtures, scoped authority and owned cleanup #304's separately owned fixtures and exact operation-specific profiles/reviews, then execute [beta.30][P1] Finish admitted MCP functional, runtime and policy-race acceptance #305, [beta.30][P1] Finish fresh fixed-native secret-reader and untrusted-context acceptance #306 and [beta.30][P2] Finish native prompt workflows and value/paging acceptance; autofill deferred #308. Their runtime evidence completes [beta.30] Complete selected native consumer identity, metadata and progress acceptance #288's remaining progress/cancel stage.
3. After all other diagnostics/reviews/alternate-identity work, execute [beta.30][P2] Run the exact isolated 240-call native HTTP MCP acceptance hour #310: Tenant A flows/list, auth/status, Tenant B flows/list, system/version repeated 60 times; 15-second schedule, concurrency 1, no interleaving or catch-up bursts. Expected successful mix is 120 core and 60 admitted reads per tenant.
4. Verify cleanup/effective auxiliary revocation and protected-state preservation. Dispose all required contexts explicitly in [QA-CAMPAIGN] Reconcile 32 retained original HTTP MCP predicates and current release gates #294. This epic remains open until its release and owner acceptance requirements are actually evidenced.

Evidence accounting and privacy

The final beta.24 ledger contains 533 native invocations across 114 operations: 307 Passed, 223 Blocked, 3 invalid tester inputs. This includes 239 schema-inspection attempts and 231 verified selected schemas; it is not a business pass count. The 438 contexts comprise 24 direct diagnostic/control successes, 171 direct denials, 229 uninvoked dependency-linked cases and 14 prohibited contexts. Four-status totals 24/400/14 are scope dispositions, not 400 reproduced defects. There were zero positive tenant business proofs and no admitted hour.

Preserve all retained case/context/finding/gap IDs and unassessed scoring values. Keep original tenants/live agents and retained historical executions protected; use separately registered disposable fixtures and verified owned sinks. Public issues/docs/PRs use synthetic identities, domains and values. Private credentials, precise operational bindings and raw campaign receipts stay in the private handoff.

Historical beta.24 and earlier planning record

Active iteration: beta.24 after finalized beta.23 retest

The beta.23 source correction was merged in #295 and released as v0.1.1-beta.23 at 86babb9d94a65c10d5b88e391ea1cba73c5c1fea. The following original beta.22 plan is retained as history; the active fix-forward release is v0.1.1-beta.24, now tagged from the reviewed merge below.

Final retest: 30 callable tools / 229 operations / 436 contexts; 17 Passed, 2 Failed, 403 Blocked, 14 Prohibited. The hour produced 120 core successes and 120 tenant denials with zero transport exceptions. Tenant admission, applied exact expiry and owner production acceptance remain unmet. No general native Codex tool-call defect was established. Full evidence stays private.

Active delivery checklist

• [beta.24][NR23-001] Canonicalize reviewed-access UUIDs and equivalent request replays #296 canonical UUID/replay fix and compatible old bindings
• [beta.24][NR23-002] Explain reviewed-access eligibility and approval rejection safely #297 safe review eligibility/failure diagnostics, independent-operator regression
• [beta.24][NR23-003] Complete protected MCP health routing through the configured API destination #289 protected API-prefix health contract and actual HTTP/auth tests (deployed owner routing remains open)
• [beta.30] Complete selected native consumer identity, metadata and progress acceptance #288 Windows supported distribution and protected migration tooling (actual native migration gate remains open)
• [beta.24][NR23-007] Add bounded operation schema lookup and verifiable catalog status #298 bounded canonical schemas/status and honest external cache distinction
• [beta.24][NR23-008] Expose safe MCP host product version and source identity #299 responding MCP host identity
• Reviewed PR, required PR/main checks under 20 minutes, immutable hosted beta build and verified public distribution
• [QA-CAMPAIGN] Reconcile 32 retained original HTTP MCP predicates and current release gates #294 operator rollout, exact approved expiry, native reconnect, admitted two-tenant matrix/endurance

Beta.24 source and public distribution complete

PR #300 merged normally as 623a75a7807cf9ac305a99740ad359df609ee5bb; tree 3fdc47840b72ce679a4a9a8c21636c16baec722d matches the reviewed PR. Source follow-ups #296–#299 closed through that merge.

Release v0.1.1-beta.24 points to the exact merged SHA. PR validation, merged-main validation, and tag validation/build each passed 4,714 executed tests with zero failures/skips; the respective .NET/source-validation jobs took 16m34s, 11m08s, and 16m55s. All eight tag-build jobs succeeded.

All seven publication jobs succeeded, including final distribution verification. All 15 public release files were independently downloaded and matched their GitHub SHA-256 digests; all 14 SHA256SUMS entries and all 13 publication artifact bindings matched. Five immutable image references are recorded in publication.json, SHA-256 f9cc6fb716e9ea833bbc26f2e3df8a3416e5b9ada5f2ef59134bbf42cc80bdd5. The hosted completion gate verifies anonymous pulls, source/version metadata, inventory and credential-disclosure scans before marking build/distribution integrity complete; this is not a CVE audit. Functional acceptance remains explicitly pending-owner-testing.

The complete tagged build took 19m04s. PR/main complete runs took 18m16s and 11m15s, within the required 20-minute gate. The separate bounded integration run passed 2 actual HTTP protocol cases plus 16 bridge controls and 10 Windows package/launcher checks on the reviewed tree, using isolated synthetic fixtures. Tagged Windows packaging repeated all 10 checks and verified 68 file digests; native reconnect and effective admission are explicitly untested in that receipt.

• Source, required validation, tag/version/source identity and public build/distribution integrity complete.
• [beta.30] Complete selected native consumer identity, metadata and progress acceptance #288 actual owner native migration/reconnect and admitted progress/cancellation.
• [beta.24][NR23-003] Complete protected MCP health routing through the configured API destination #289 deployed configured-destination health verification.
• [QA-CAMPAIGN] Reconcile 32 retained original HTTP MCP predicates and current release gates #294 independent approval, exact applied UTC expiry, effective two-tenant admission, inert-fixture matrix and isolated admitted endurance.

The release does not apply the owner's rollout, credential approval or expiry. #288, #289, #294 and this epic remain open for those unexecuted owner/native acceptance gates.

Preserve successful beta.23 fixes #290–#293 and scanner #281. Closed source items #283–#287 retain their implementation history; new regressions/follow-ups are linked above rather than declaring every blocked dependent subsystem defective. Same-principal approval must remain denied; no administrative API helper or silent expiry extension. Implementation/distribution may complete while #294 and this epic remain open for owner acceptance.

Next beta: MCP campaign correction and repeatable acceptance

Objective and source baseline

Deliver the corrective work from the 17 October 2026 native HTTP MCP acceptance campaign in one reviewed integration PR to main, then publish the next available v0.1.1-beta.N for the owner to rerun the same campaign. Planning target: v0.1.1-beta.23; the latest published release and current main are beta.22 at 2f0bd2f5b204a10a0024d8fcb3cbab7c750f28b8. Recheck tag allocation before the version change.

The campaign assessment is rework before production acceptance. This epic coordinates implementation, source validation, distribution and owner retesting; completing one stage does not certify the later stages.

The full assessment and evidence archive remain private. Public issues contain synthetic reproductions, bounded observations, source pointers and regression criteria. The implementation can reproduce these cases with disposable fixtures even when the private archive is unavailable.

Evidence and scope

• Baseline catalog: 30 tools, 223 operations, 6 resources, 8 prompts; all 30 families invoked natively, 68 distinct operations invoked. Record catalog additions/deltas in the next campaign rather than forcing new functionality into the old count.
• 430 operation/context rows: 3 Passed, 5 Failed, 408 Blocked, 14 Prohibited by the owner boundary. These are context outcomes, not a claim that 223 operations passed.
• The primary authenticates, but configured grants do not establish effective tenant visibility or target-policy admission. Policy administration already exists; the missing capability is the reviewed MCP bootstrap/credential workflow.
• All six resources were retrieved natively. All eight prompt retrievals were diagnostic; native prompt workflows are a separate acceptance gate.
• A known synthetic secret-designated run input is visible in ordinary run details. Broader unauthorized readership, MCP/API response exposure and persistence exposure still require controlled testing.
• Adapter streaming/cancellation/recovery failures were measured against a synthetic loopback replacement. They are not evidence of production HTTP MCP outages.
• A 60-minute native run issued 240 calls at 15-second cadence with concurrency one: 120 successful core reads, 120 tenant denials, zero transport/client exceptions. Core p95 was 836 ms; denied-tenant p95 was 830 ms. Successful tenant endurance remains unmeasured. The suggested 1700 ms core p95 pilot is a proposal, not an adopted SLA.

Corrective work

Delivery checklist

• [beta.23][NR-008] Add operator-reviewed MCP access bootstrap and effective-admission receipts #283
• [beta.23][NR-010] Correct local MCP delegation target contracts and preserve denial causes #284
• [beta.23][NR-011] Define and enforce connectivity permissions for local HTTP MCP credentials #285
• [beta.23][NR-012] Add reviewed MCP credential lifecycle with exact UTC expiry #286
• [beta.23][NR-001] Mask secret-designated job inputs across run projections and retained history #287
• [beta.30] Complete selected native consumer identity, metadata and progress acceptance #288
• [beta.24][NR23-003] Complete protected MCP health routing through the configured API destination #289
• [beta.23][NR-004] Enforce closed MCP tool envelopes before authorization and delegation #290
• [beta.23][NR-009] Align MCP schema ID alternatives and empty search values with runtime binding #291
• [beta.23][NR-003] Return actionable invalid-parameter errors for MCP prompt arguments #292
• [beta.23][NR-006] Make inspect_client discover exact tenant and agent targets through published search tools #293
• [QA-CAMPAIGN] Reconcile 32 retained original HTTP MCP predicates and current release gates #294
• Release image scanner: inspect OCI blob layers and reject empty coverage #281

Existing release dependency: #281 — make the public image scanner inspect actual OCI/legacy layer content and fail on empty coverage. Reuse that issue and its focused fixtures; do not duplicate it or replace already published beta.22 bytes.

Related work to preserve: #247 (reviewed pairing), #264 (temporary verifier/diagnostics), #267 (UI credential management), #279 and PR #280 (operational-input autofill remediation and existing optional persistent-browser test). NR-H1 is this campaign's unexecuted positive control, not a new assertion that the closed autofill defect remains unfixed. Other open Jobs/agent/monitoring epics remain independently tracked unless a reproduced campaign failure requires their implementation.

Sequence and dependencies

1. Agree the access and contract design: review operation target models, local permission mappings, the safe structured error vocabulary, and the operator-reviewed consent/credential receipt. Design NR-008 and NR-012 together; preserve one existing credential/pairing authority.
2. Repair the native admission path: implement NR-010, NR-011 and the NR-004/009 pre-dispatch contract fixes. Correct policy target shape and server-owned reference resolution; changing denial wording alone is insufficient.
3. Complete reviewed setup and lifecycle: implement NR-008/012 using existing pairing, UI and credential services; exact UTC expiry already exists in the backend and must survive UI/setup/receipt handling.
4. Complete independent corrections in parallel: server-side secret projections and sensitivity metadata (NR-001), supported client transport ownership/delivery (NR-007), configured-destination health (NR-002), and prompt validation/discovery (NR-003/006).
5. Run a bounded disposable HTTP MCP protocol/client integration check: reviewed access plus successful reads in two test tenants, focused negative controls, supported adapter streaming/cancellation and accurate health. Extend existing optional integration/browser tooling. Do not attach the one-hour campaign to mandatory PR checks.
6. Merge, release, then owner retest: merge the source fixes after required CI, run the hosted release build/publication, then verify public distribution integrity. Owner deployment and the full protected-environment campaign follow as explicitly recorded acceptance stages.

Design invariants

• The MCP caller can request, inspect and resume consent. A privileged operator explicitly reviews the exact identity/resource/instance/environment, permissions/scopes/roles, tenants, targets, operation set, revisions and UTC expiry. The requester cannot approve itself; broad grants are never a fallback.
• Configured credential grants, attenuated per-operation delegation, role/policy prerequisites and effective business admission are separate facts in receipts and diagnostics.
• Never request an administrative API token, revive the abandoned API-helper approach (NR-005), write backend tables, disable tenant admission, invent a target, or return existing credential secrets. New secret material uses the supported protected delivery/storage path.
• Default redaction occurs at the owning server projection as well as UI rendering. Preserve execution semantics and opaque secret-reference contracts. Any reveal is deliberate, authorized and audited, or unavailable.
• Unknown fields and invalid published types fail before delegation/business dispatch. Valid false, zero, permitted empty values, Unicode and exact decimal-string IDs keep their meaning.
• Connectivity and business mutations preserve preview/confirmation binding, stale-revision checks, owner/tenant/target authority and idempotency. Reconcile uncertain outcomes before retrying.
• The existing eight live agents and two named owner tenants remain protected. No delete/update/disable/reboot/re-enrollment, service control without a designated inert service, or production integration delivery is part of this implementation/release task. Actual AI approval responses require the operator's explicit decision.

Validation and closure

Read root/scoped AGENTS.md before implementation. Extend the smallest existing tests at the behavior-owning layer. Exercise the actual HTTP MCP protocol and local delegation path for these regressions; direct C# handler tests and schema snapshots alone missed the current failures.

Required PR and main CI must remain under 20 minutes, targeting 10–15, with meaningful nonzero tests and no weakened assertions, suppressed errors or manufactured pass receipts. Keep browser/native install/deployment/soak work in the existing opt-in paths. Use deterministic time and gated loopback fixtures where feasible.

Keep protocol/client integration test results, actual native AI-host invocations and owner-deployment evidence separately labelled. For each child, report failing-before evidence, root cause, change, relevant passing regression and remaining owner acceptance. Merge can close a source defect only when its full implementation scope is complete. Keep the campaign/acceptance issue and this epic open until the owner campaign has an explicit disposition for every required context. Prohibited tests remain prohibited rather than being relabelled passed.

Release requirements

• Use one integration branch/PR against main; include issue-by-issue changes, focused validation and release notes. Resolve review findings, merge through normal repository checks, and verify the exact merged commit's required CI.
• Change product version only in Directory.Build.props. Use the existing generic GitHub-hosted .github/workflows/release-build.yml and release-publish.yml; no local release/container builds or version-specific workflow copies.
• Before publication writes, bind tag/version/public source, successful hosted build and authenticated artifact receipt. Publish the complete current archive matrix, checksums, SBOMs, digest-pinned Compose bundle and publication record.
• Verify the fixed image repositories netratel-api, netratel-web, netratel-migrations, netratel-mcp-http, netratel-client; nonempty layer scans (Release image scanner: inspect OCI blob layers and reject empty coverage #281), immutable manifest digests, OCI metadata and anonymous pulls/downloads must agree with the publication record. Local image configuration IDs are not manifest digests.
• Preserve partial-publication journals and immutable released bytes. A release page or green tag build alone is not completed distribution.
• The beta may be distributed with owner functional acceptance explicitly pending. Do not claim production acceptance or perform owner rollout to make the release look complete.

Owner repeat-campaign gate

After the owner deploys the released beta and the supported client transport is installed, verify effective access in both approved tenants first. Resolve each tenant's exact designated agent independently; never reuse another tenant's ID as a positive target. Inspect the retained credential through the supported lifecycle and obtain the reviewed exact-expiry reconciliation. Preserve the original owner-intended UTC instant as the desired value; an actual independent operator decision is required before application. A rerun must not silently start a new thirty-day window.

Then create only owned inert fixtures/restricted auxiliary identities and execute the gap matrix in the linked acceptance issue: isolation, pagination/freshness, confirmation binding/reuse, stale revisions, idempotency/uncertain outcomes, benign execution/files/terminal/designated service, monitoring/flows/test delivery/actual operator AI decisions, redaction, untrusted-content authority resistance, native prompt workflows, transport progress/cancellation, autofill control, baseline/digest capture and cleanup.

Repeat the unchanged paced sequence for 60 minutes: approved tenant A flows/list, server auth/status, approved tenant B flows/list, server system/version (the existing two owner tenants, anonymized here); 15 seconds, concurrency one, 240 requests. With admitted fixtures the target result is 120 core successes plus 60 successful tenant reads in each tenant. Report errors, actual cadence, latency percentiles and deviations; a phase blocked by admission does not substitute for admitted endurance.

Documentation and final delivery

Update canonical docs/mcp-http/, docs/integrations/, docs/deployment/ and relevant docs/contracts/ guides. Read docs/README.md; keep implementation/history in existing categories, no ad hoc root/docs-root reports. Run the existing layout validator. Public examples and receipts use synthetic values.

Return the integration PR, merged source SHA, required checks and durations, release/tag/build/publication URLs, artifact/digest verification, supported client upgrade/reconnect instructions, concise owner campaign commands/fixtures, and a truthful source/distribution/owner-acceptance status table.