Last verified: 2026-10-06. Scope: TEST only, under the active MCP implementation request. Production MCP remains disabled; production approval/Jira/reason controls remain required.
Azure TEST delivery run 26330, definition 394, succeeded at source 0bf06bfb50599350787822d71e31f4e7fefe9a74. Its immutable recovery receipt records Deployment generation 760, outcome succeeded, rollback not_needed, and successful database/Entra runtime activation checks. The prior run 26329 stopped before replacing generation 759 because its inherited-environment guard compared sorted settings with an unsorted expected list. The scoped ordering repair passed worker regression checks and independent review, then DEV PR6730 and TEST PR6731; Gitea builds31 and32 passed. The relay's prior failure was preserved in its event journal and acknowledged as repaired for this exact revision before run26330 was queued.
The TEST endpoint is https://thewell-test.skan.com/api/mcp/connection. Live checks verified metadata200 with canonical URL, unauthenticated401 with resource-metadata challenge, invalid bearer401, and untrusted Origin403. A preserved delegated website identity initialized MCP protocol2025-11-25, discovered3tools and172catalogued operations, read17authorized pools and273documents in one pool, and retrieved a decrypted document chunk identical to the website. Developer log settings access returned200. The exercised identity has administrator/developer/global-pool-reader roles; restricted-user denial remains unverified.
A temporary empty TEST datapool54 was created viaMCP, its prompt changed and read back, restored, and the fixture removed. The original17pool baseline was restored. Personal usage records18actions:17succeeded and1rejected unknown operation. All6fixture action IDs were found as succeeded in the developer audit. No AI inference was intentionally requested. Tokens and document text were not exported into the verification records.
Reviewed MCP Statistics PR6727 merged intoDEV at 6b1c74d31cdd96c107e684f89be240f111001f2e; its tree matches the reviewed source. Azure run26333, definition395, passed Build and failed during TEST staging: TEST frontend release retention limit reached. Its recovery receipt has no applied generation, rollback not_needed, and no recovery Secret; the live frontend spec was not replaced. A desired-candidate metadata claim may have advanced. The existing ten-full-release cap stays in force. The Statistics panel is not deployed or verified yet.
Reviewed retention helper PR6733 merged into DEV at 7de9b88e4464e3dce3784503e2a28e22723c659a, matching reviewed source 861a232bb493c1dbd0295de72b8d808b9862e726. Eight worker tests and bash syntax passed. Cleanup defaults disabled and any apply must name the exact approved release. Azure diagnostic run26336 used cleanup=false, passed Build, then stopped at an invalid retained-release reference. The retention report contains only that blocked reason; it does not yet establish eligible deletion targets. Its receipt records prior generation105/revision16, no applied generation, rollback not_needed and no recovery Secret. Nothing was deleted and the frontend spec was not replaced. PR6734 subsequently added field-specific redacted diagnostics and the standard MCP resource-discovery redirect in TEST source; neither had reached the live frontend at this checkpoint. Preserve live Deployment, owned ReplicaSet/Pod rollback releases, active switch recovery references, and shared hashed browser assets. No retained frontend release copies have been deleted by this MCP task. Host instructions require explicit approval before deleting non-temporary data; do not treat general TEST delivery permission as that specific approval.
The automatic run26338, at reviewed DEV 4267f666d8f0e56d2bb70315a346922a71418a5e, failed before frontend replacement. Its immutable artifacts identify ten canonical release copies, six owned ReplicaSets, one live Pod and nine recovery Secrets. Two old snapshots (26055 and26070) lack prior release identifiers; the other seven have valid owning and prior references. Receipt: prior generation106/revision16, no applied generation, rollback not_needed, recovery Secret null. No deletion occurred.
PR6735 integrated reviewed source 55ea9c6ccb2f2fe01b20852440d9ce4b387eac5b into DEV 89ddee336acc1fbc8621697c0fca8d943609520e; the trees are identical. Twenty focused checks passed on the designated worker, together with shell syntax and whitespace checks. Normal TEST CI keeps cleanup disabled. The helper now proposes at most two unresolved old snapshots, binds approval to their exact names and UIDs and one exact oldest unreferenced copy, reports existing deletion capability without granting permissions, rechecks deployment/references before each action, and records attempted and uncertain outcomes. Secret deletion uses Kubernetes UID preconditions. It retains the ten-copy and ten-snapshot bounds.
The current reviewable proposal is release copy 73929facc884d0f077bd51712b19e411ee6b169d-26049 (6904KiB) and snapshots thewell-frontend-recovery-26055 UID 03253576-b701-406c-acca-72df1447fe14 and thewell-frontend-recovery-26070 UID 9475691e-6059-4fdb-9bbd-a5066ddab655. All eight releases referenced by the remaining valid recovery snapshots or live/owned workload objects stay protected, as do shared hashed browser assets. Removing these three artifacts would remove those historical manual restore options; it does not target datapool knowledge or documents. This proposal is not deletion authorization. Automatic run26340 ran this exact DEV revision with cleanup disabled. Build passed; staging exited3 at cleanup_required. The fresh plan exactly matched the three proposed targets and reported existing recovery-Secret deletion permission=true. No removal or frontend replacement occurred. Receipt: prior generation107/revision16, no applied generation, rollback not_needed, recovery Secret null. The specific deletion approval question is pending. Concurrent manual rollback is not covered by a global coordination Lease; the helper instead revalidates snapshots and rejects changed state.
The same change adds a read-only TEST backend storage observer to the frontend recovery artifact: bounded /tmp filesystem capacity, current backend resource settings and accessible ephemeral-storage quota. No Secret data or file contents are exported, no permissions are granted and observation failure cannot block delivery. Run26340 produced a complete six-call observation at2026-10-06T21:48:56.860300Z, bound to backend source0bf06bf/release26330 and a ready owned Pod: /tmp capacity936643724KiB, used780469980KiB, available156173744KiB (about149GiB). The tmp volume is an emptyDir with no sizeLimit; accessible compute-resources-quota contained no ephemeral-storage hard/used keys and backend resources contain no ephemeral-storage reservation/limit. This is shared filesystem headroom, not dedicated MCP capacity. Owner-bound aggregate staging limits, expiry, cleanup and disk headroom checks remain to implement before large-file parity. No capacity or runtime settings were changed.
Application documentation belongs in the Azure TheWell Documentation repository. Operational records belong here. Protected task-local verification receipts remain under /home/ax_julian/temp/thewell-mcp-live-20261006 and the two task-scoped deployment-diagnosis directories, retained only while acceptance remains unfinished. Root chat01a112b9 owns continuation and cleanup.