Complete approved staging/production release workflow and profile-bound deployment evidence

Parent-Issue: #1
Follow-Up-To: #22 / PR #46
Blocked-By: operator-selected public HTTPS origin, authenticated environment/resource ownership, scoped Cloudflare credentials, protected deployment approvals, backup/log-retention facts and actual profile/host evidence

Context

PR #46 supplies structural Wrangler configuration checks, separated release environments, fail-closed readiness/evidence preflight and protected workflow scaffolding. The release validator intentionally outputs deploymentApproved:false, and the reviewed workflow stops before any Worker publish. On 2026-11-11 the owner approved merging that non-deployable code foundation only, while deferring #22/REQ-001/002/003/004/007/008 operational acceptance here. No approval to deploy or clear quarantine is inferred.

Requirements

Provision/verify distinct local, staging and production Wrangler configurations and actual Cloudflare Worker/SQLite DO/OAuth KV namespaces, secrets, callback origins and least-privilege token permissions. Verify resource ownership from the provider, not only fabricated metadata. Reject missing values, wrong account/namespace, staging-production mixing and default-on workers.dev or preview URL exposure.
Supply required environment-scoped release config, peer config, secret-name inventory and evidence manifest through GitHub protected environments. Use protected, exact-main build/config hashes, independent human approval and a fresh provider-side identity/readback receipt. Never expose production credentials to PR CI.
Replace the currently unconditional non-publishing approval gate with an authenticated fail-closed release decision that can approve only verified evidence with explicit operator consent. The Cloudflare publish step remains impossible until this is complete; no code-only merge of PR Add fail-closed release and restore groundwork (#22; release deferred to #50/#51) #46 counts as release approval.
Verify the actual stable HTTPS origin and selected public profile. Manual browser/application/security readiness, live subscription/host readiness and public Events/autonomous readiness are separate profiles with build/config-bound independently observed test evidence. Missing optional host, delivery, provider or safe-egress evidence keeps that unsupported capability disabled.
Execute approved staging deployment and storage-preserving update/rollback rehearsals with current Worker/DO schema and actual provider state, then a separately approved production procedure. Refuse unsupported newer-schema rollback without wiping/renaming storage.
Complete the executable operator runbook for provisioning, scoped secret injection and rotation, emergency intake/outbound pause, confirmed browser close/delete during normal pause, profile promotion, backup and log retention disclosure, monitored rollback and quarantine handoff to the independent reconciliation work tracked in the companion follow-up.
Record actual staging/production evidence, usage and deployment-time pricing separately from local/CI/dry-run or synthetic Cloudflare fixtures. Do not claim zero cost, universal erasure, host support, or an unexecuted successful release.

Acceptance

Exact head/build/profile/environment configuration plus true provider resource IDs and current release evidence pass the authenticated approval gate; missing/mismatched evidence fails before deployment.
A protected staging release is explicitly approved, deployed and read back against expected Cloudflare identities; production requires a separate approval and profile-specific evidence.
A deliberate recovery/rollback rehearsal preserves private namespaces, leaves missing post-snapshot authority quarantined (see companion issue), and includes real operator receipts.
Absent optional Events/host proofs cannot enable their public claims, even if feature flags are true.
All operator inputs not yet supplied remain documented as blocked, not passed.

Evidence

PR #46
Exact-head preflight/CI
Staging settings-only read job (not deployment authorization)

This follow-up is not permission to deploy.

Add fail-closed release and restore groundwork (#46)

feat(release): authenticate manual promotion against Cloudflare and e…

feat: authenticated protected manual release gates (#50)

Verified production quarantine bootstrap — 2026-11-11 (Cloudflare readback)

After owner approval of a non-public, no-intake bootstrap, the authorized uf host provisioned the previously absent agent-table-production Worker from merged main commit be9406939674ad50b8bb1a2c6b824b1db605e587, plus a separate OAuth KV namespace. This is an actual Cloudflare provider operation and readback, not synthetic fixture evidence or staging/production release acceptance.

Account ID: 0fbaae27d3ff021bc17109f1493d0b2d; Worker name: agent-table-production; Worker ID: d06750fd640548af95e36148af8bb78b.
Production OAuth KV: agent-table-production-oauth-kv / c8de0c5e6b6b4e3f8f85616d21d0af5a. The staging and restore KV IDs are different.
Cloudflare-listed independent production SQLite DO namespace IDs: TableDO=eba282857f264cbb8d44f6bf09d9683a, GuestDO=79a35011db33425698071d18ecf693c2, OAuthTokenDO=6d123d720f704560a6dfab8c55a09c16, AdmissionDO=24d3fc7ec68c4bf89a768911d718cfae.
Uploaded version e58521c7-15a5-448f-adf6-40d5646f2445, with confirmed No targets deployed. Provider cf workers get agent-table-production readback shows references.domains=[], subdomain.enabled=false, subdomain.previews_enabled=false.
Candidate built from exact main SHA using Wrangler 4.158.0 dry-run and upload. Runtime vars: production identity and approved eventual origin https://agent-table.outliner-online.com; RESTORE_QUARANTINE=false because it is a new non-restored namespace; all admission/create, subscription, Events and outbound notification switches false. No public origin is currently bound. Secrets have not been injected yet.

Remaining blockers for Issue #50: backup/recovery-safe storage and injection of distinct keyring secrets; production origin/DNS/HTTPS and its separately approved public binding; staging workers.dev/preview exposure currently still enabled and needs an impact review; environment-scoped tokens and JSON/evidence inputs; real protected approval, host tests, usage/retention receipts and a storage-preserving rollback rehearsal. No published availability or release clearance is claimed, and Issue #51 remains independent.

Read-only live release-readiness check — 2026-11-11 10:36–10:45 UTC

No deployment, credential change, namespace mutation, or quarantine clearance was performed. Reviewed main at merge SHA be9406939674ad50b8bb1a2c6b824b1db605e587; the corresponding push Validation run #43004985583 completed successfully for that exact SHA, with the single verify job and all steps green. PR #52 is already merged; the remaining issue acceptance is operational, not another copy of #52.

Read-only authenticated GitHub Environment inspection:

Both staging and production exist, require a kitamura-tetsuo human review, have prevent_self_review: false, and restrict deployment to protected branches. This is structurally compatible with the owner-selected review policy, but no actual approved deployment run has been observed.
staging Environment secret names: CLOUDFLARE_ACCOUNT_ID, CLOUDFLARE_API_TOKEN only.
production Environment secret names: CLOUDFLARE_ACCOUNT_ID only.
The current reviewed workflow also needs CLOUDFLARE_READ_TOKEN, RELEASE_CONFIG_JSON, PEER_CONFIG_JSON, RELEASE_SECRET_INVENTORY_JSON, RELEASE_EVIDENCE_JSON, and RELEASE_OPERATIONS_JSON scoped to the target Environment. Their absence is a hard gate, not an implicitly approved default. Do not provision tokens automatically or copy an unrelated existing token.

Read-only Cloudflare API inspection with the pre-existing authenticated owner CLI session:

agent-table-staging Worker: settings/deployments/secrets readable, four DO namespace bindings, one KV binding, one custom-domain claim. However its workers.dev subdomain and preview URLs are currently enabled. The fail-closed manual release gate correctly requires both to be disabled before approval; an existing working staging endpoint does not prove eligibility.
agent-table-production Worker: settings/deployments readable, four DO bindings, one KV binding; its workers.dev and preview settings are disabled, but it has zero deployed Worker secret bindings and zero custom-domain claims in the inspected listing. Thus it does not meet release readiness.
These observations do not establish full resource ownership, actual backup/log retention, operational approval, supported public profile, a stable HTTPS origin for both environments, or a verified staging/production deployment and rollback. No secret values, callback URLs, or private application content were read into evidence.

Precise prerequisites before any protected staging run: owner-approved exact Worker/origin/profile configuration and peer separation; environment-scoped least-privilege read/write credentials plus the six missing inputs; resolve staging public-subdomain/preview exposure; independent backup/log retention and measured-usage disclosures; fresh protected owner approval. Production needs a separate approval and complete resource setup. #51 independently blocks any restored-state quarantine clearance; #24 still needs two eligible owners and observed idle-host round trips.

No new PR was opened because the next acceptance steps are currently blocked on these explicit external/operator facts. This comment is a read-only blocker record, not release authorization or a passed real-host test.

Owner-authorized follow-up: production secret injection and staging ingress hardening (2026-11-11)

Owner explicitly replied K3 and S1 ok to the staged approval request (Slack approval thread). On authorized host uf:

Generated independent cryptographically random 32-byte AES key material in process memory for agent-table-production's INVITATION_RESPONSE_KEYRING and CALLBACK_CREDENTIAL_KEYRING, in valid {current:{id,key},previous:[]} JSON envelopes, and piped each directly into wrangler secret put against the pinned, non-public production config. No secret values were sent to chat/Slack/GitHub, logged, or written to a backup file. Cloudflare's authenticated name-only readback returned both secret_text bindings. K3 explicitly forgoes local/offline recovery of these keys; lost key material can make previously encrypted records unrecoverable and complicate future rotation. Do not claim a key escrow or tested disaster recovery.
Read staging's exact Cloudflare Worker agent-table-staging subdomain state (enabled:true, previews_enabled:true), then updated only its /workers/scripts/agent-table-staging/subdomain resource using the documented POST body {enabled:false, previews_enabled:false}. Independently GET-read it back false/false. Subsequent cf workers get confirmed the existing custom-domain binding agent-table-test.outliner-online.com and all four historical DO namespace IDs were unchanged. https://agent-table-test.outliner-online.com/health still answered HTTP 200. The previously reachable workers.dev/Preview URLs are intentionally disabled.
Confirmed both protected GitHub Environments exist with owner kitamura-tetsuo as required reviewer, prevent_self_review:false (approved same-account policy A), and protected_branches:true; the release workflow additionally enforces exact refs/heads/main. Environment secret name-only readback: staging currently has only CLOUDFLARE_ACCOUNT_ID, CLOUDFLARE_API_TOKEN; production currently has only CLOUDFLARE_ACCOUNT_ID. Missing scoped CLOUDFLARE_READ_TOKEN and release JSON manifests remain blockers. can_admins_bypass:true is present; the in-workflow GitHub approval-history verifier still fails closed absent an actual owner approval.

Public release remains blocked: production still has no custom domain/DNS/route and both workers.dev/Preview entry surfaces remain disabled. No real protected staging/production deployment, rollback rehearsal, or #50 acceptance was performed. Do not close this issue.

2026-11-11 authenticated bootstrap / verification progress (non-release):

Protected GitHub staging and production Environments now each list CLOUDFLARE_ACCOUNT_ID, CLOUDFLARE_API_TOKEN, CLOUDFLARE_READ_TOKEN. The names are confirmed; values/scopes are not yet proven.
PR #53 adds owner-reviewed, GET-only credential probes for both Environments. It also fixes release-provider validation against the actual Cloudflare Worker Version API. Local tests: 70 release/scripts, 301 unit, 201 integration, 2 restore, dry-run build green; hosted PR CI pending/queued.
Direct GET-only Cloudflare probes via the already configured uf token (not the new GitHub Environment read tokens) authenticated successfully for both Workers' settings, subdomain state, secret names, deployments, active version, KV, domains and Durable Object lists. Actual active versions expose script.named_handlers and script_runtime.migration_tag=v3, but omit the API-optional script_runtime.exports. The new gate validates the independent evidence without accepting missing classes, stale migrations, or wrong active-version namespace bindings.
The corrected provider gate deliberately blocks staging (provider-version-config-unverified): the current staging Worker lacks RELEASE_ENVIRONMENT, RELEASE_BUILD_SHA, RELEASE_PROFILE, RESTORE_QUARANTINE. It blocks production (provider-origin-not-exclusive): no approved custom-domain binding exists yet. Both remain operator gates.
The GitHub read tokens must still pass separately approved protected Environment jobs after test: verify Cloudflare read tokens in protected release Environments #53 merges. No staging/production publish, production DNS/domain binding, restore-quarantine clearing, or public capability enablement is authorized by this comment.

test: verify release read credentials and real Cloudflare version met…

2026-11-11 follow-up to the earlier non-release progress note:

PR #53 was squash-merged into main at 58f35f28cc860dae29408dd9f66db89addfc3472 after Validation run #43019333739 succeeded, including browser E2E. No reviews or unresolved threads were present.
The protected, GET-only Cloudflare read-token verification was dispatched for each Environment and is waiting for explicit owner approval: staging #43021005711, production #43020993277. Both are pinned to the exact merged SHA.
Approval requests were delivered to the owner in kitamura-tetsuo.slack.com self-DM, with separate exact run identifiers. Neither job can access Environment secrets or execute until protected review approval. These are credential read probes, not releases.
Staging release metadata and the production custom domain remain separately blocked. No public routes, DNS records, intake, Events, outbound delivery or quarantine state were changed.

Issue #50 continuation (updated 2026-11-12 JST; original waiting hypothesis corrected with executed-job evidence):

The owner authorized both exact-main, GET-only protected credential probes in ChatGPT (ok). GitHub's deployment-review approval history records approved by kitamura-tetsuo for staging run 43021005711 (Environment ID 26890527477) and production run 43020993277 (ID 26890542756). Both used exact protected main SHA 58f35f28cc860dae29408dd9f66db89addfc3472, required owner reviewer and prevent_self_review:false.
Both approved jobs actually started and executed with the existing deployment:false GitHub Environment configuration. GitHub API/UI status appeared stale during the GitHub Actions outage opened 2026-11-11 20:48 UTC. This disproves the hypothesis that deployment:false prevented execution.
staging: completed/failure; checkout, Node setup and pinned-main SHA verification passed, but the parallel Cloudflare read probe failed READ_CREDENTIAL_BLOCKED credential-read-refused:durable-objects.
production: completed/cancelled; checkout and pinned-main SHA verification passed; Cloudflare read probe failed READ_CREDENTIAL_BLOCKED credential-read-refused:domains. Do not infer an exact cause of cancellation from the outage alone.
Because the verifier performs multiple Cloudflare GETs in parallel and reports the first refusal, other missing read scopes may also exist. Owner action required: inspect/update the staging and production protected Environment CLOUDFLARE_READ_TOKEN permissions to cover Account → Workers Scripts → Read (Worker domains and DO namespaces) and Account → Workers KV Storage → Read for account 0fbaae27d3ff021bc17109f1493d0b2d, without granting write permissions. If a token must be rotated, update only its corresponding protected GitHub Environment secret privately; never paste a token into an issue, Slack or ChatGPT. Resubmit and separately approve new GET-only Environment runs after correction.
PR #54, an exploratory change from deployment:false to deployment:true, was closed without merge once actual job execution disproved the premise. Its local checks had passed (70 Node scripts, 301 Vitest, 10 E2E, TypeScript, Biome, Wrangler dry-run), but GitHub CI had remained queued during the outage. main is unchanged by fix: reliably release protected read-only credential checks after approval #54.
No staging/production Worker publication, public DNS binding, key rotation, quarantine clearance, or Events/subscription activation was approved or performed under these GET-only approvals. Those release decisions remain separately gated.

The read-token permission issue is distinct from GitHub's outage; Issue #50 remains open pending real-provider evidence and the previously documented release-readiness criteria.

Follow-up: verified token policy identity and diagnostic PR (2026-11-12 JST)

The owner supplied an account-token policy using permission group afa629b86102452b8b744a5485b870e1 and two individual Worker IDs. Authenticated read-only Cloudflare GET /accounts/{account_id}/tokens/permission_groups returned Individual Workers Metadata Read-Only for that ID, scoped to com.cloudflare.edge.worker.script. This is consistent with the account-wide domains / durable-objects GET refusals; this correlation is a configuration diagnosis, not proof of every missing permission.
Actual Cloudflare group lookup also returned account-scoped Workers Scripts Read = 1a71c399035b4950a1bd1466bbe4f420 and Workers KV Storage Read = 8b47d2786a534c08a1f94ee8f9f599ef. The current verifier requires account-level Worker domain/DO lists and KV namespace metadata. Adding these grants broader read access (Worker source content / KV values) than the probe uses. This scope expansion remains an owner decision, with no token policy mutation performed.
PR #55 improves the fail-closed read probe to aggregate all denied endpoint labels within two dependency phases, adds two regression tests, and documents the account-wide scope tradeoff. Isolated uf local checks: Node 72, Vitest 301, restore 2, E2E 10, typecheck, lint, Biome, Wrangler dry-run all pass. GitHub Validation run 43103148208 completed success for head SHA c29a0a3133a1ccaa04cc8b17498ac254f52a997a, with zero review submissions and zero unresolved review threads; PR #55 was subsequently squash-merged to main at 6cb6593b7fa3fe6fb526ce7f39da7d3a97f5bb16. This is a diagnostic code change only and is not release approval.

Issue #50 operational evidence sourcing (2026-11-12 JST; policy references only, not provider/account acceptance):

Cloudflare's SQLite-backed Durable Objects offer up to 30 days of point-in-time recovery for an individual DO database; this does not establish an account-wide snapshot, successful restore drill, preservation of encryption keyrings, or rollback compatibility. Official API documentation.
Cloudflare's Workers Logs page currently documents 3 days retention on Free and 7 days on Paid (maximum 7 days) with plan-dependent included/write pricing. Worker logs require the observability configuration; no current account plan, log availability, Logpush delivery, or actual retention setting has yet been proved. Cloudflare notes a 2026-12-01 pricing change. Official Workers Logs documentation.
Current public unit pricing must be taken from the Workers and Durable Objects pricing pages immediately before each release. Actual Cloudflare account usage/billing receipts and chosen recovery/log policy remain blocked, not assumed.

Do not mark RELEASE_OPERATIONS_JSON.retention.*.status=operator-verified or cost.usageObserved=true from documentation alone. The operator-approved evidence and a controlled storage-preserving rehearsal are still required.

Scope update acknowledged; protected GET-only reruns awaiting owner approval (2026-11-12 JST)

The owner selected #50 A and reported that the staging/production CLOUDFLARE_READ_TOKEN read scopes were updated. This is a user statement, not yet a successful authenticated provider readback. No token value was disclosed or inspected.

Both exact-main workflow_dispatch invocations to .github/workflows/verify-release-credentials.yml succeeded at protected main SHA 6cb6593b7fa3fe6fb526ce7f39da7d3a97f5bb16:

staging: run 43104683889, waiting for reviewer kitamura-tetsuo, Environment ID 26890527477.
production: run 43104688167, waiting for reviewer kitamura-tetsuo, Environment ID 26890542756.

Both jobs declare deployment:false and contain only Cloudflare GET probes; execution has not started, so provider credentials and live Worker/DO/KV ownership are not yet verified. Owner must individually approve the two pending Environment reviews. No Worker publish, DNS/domain change, namespace reset, token mutation, or public-profile promotion occurred. The release approval remains independent and blocked.

Protected readback passed; exact-main CI and live provider state (2026-11-12 JST)

GitHub's protected Environment review history confirms owner kitamura-tetsuo approved both newly dispatched GET-only runs at main SHA 6cb6593b7fa3fe6fb526ce7f39da7d3a97f5bb16. staging #43104683889 and production #43104688167 completed success, each proving READ_CREDENTIAL_VERIFIED workers=2. They did not publish.
A fresh manual Validation #43106158834 (workflow_dispatch, exact main) completed success through all named tests, Workerd/restore, two-Worker subscription, Wrangler dry-run and browser E2E. An earlier main push #43103940999 failed intermittently when the deliberately unread two-Worker SSE response ended before SDK acknowledgement; PR #56 hardens that test only and awaits CI/review.

Fresh separate authenticated Cloudflare GET readback on operator host (no provider writes, full namespace IDs deliberately not posted publicly):

agent-table-staging: exactly one enabled custom domain agent-table-test.outliner-online.com; workers.dev and preview URLs both disabled; four distinct SQLite DO namespaces and one OAuth KV; expected keyring secret names and Turnstile secret name present; current traffic 100% to one version. Existing plain text bindings lack RELEASE_ENVIRONMENT, RELEASE_BUILD_SHA, RELEASE_PROFILE and RESTORE_QUARANTINE required by the release-provider gate. Migrating this live Worker into the protected release profile needs separate reviewed deployment/bootstrap authority.
agent-table-production: four distinct SQLite DO namespaces (all separate from staging) and its own OAuth KV; required keyring secret names present; workers.dev/previews disabled, 100% to one deployed version; existing PUBLIC_ORIGIN text is https://agent-table.outliner-online.com, and manual release flags are present. However no custom-domain binding currently exists for the production Worker. This origin is configured text only, not a verified publicly serving HTTPS hostname.

Protected GitHub Environment secret names were inspected (not values). Both staging and production have CLOUDFLARE_ACCOUNT_ID, CLOUDFLARE_API_TOKEN, CLOUDFLARE_READ_TOKEN, with expected required-reviewer/branch policy. Both lack RELEASE_CONFIG_JSON, PEER_CONFIG_JSON, RELEASE_SECRET_INVENTORY_JSON, RELEASE_EVIDENCE_JSON, RELEASE_OPERATIONS_JSON. Consequently, the approved release workflow is still blocked before a real staging/production publication, even though read-token access and exact-main CI have passed. Operator-verified log/backup/usage evidence and a storage-preserving rollback rehearsal also remain outstanding.

The owner has not authorized a new Worker publish, production hostname/DNS exposure, log setting change, secret rotation, or change to public capabilities in this step. Do not infer any such authorization from the GET-only job approvals.

Latest exact-main Validation and two-Worker flake fix (2026-11-12 JST)

PR #56 was squash-merged into protected main at 6a1153e6179de2f8f0140e707420033f5e063ebc. The change handles a test-only race when deliberately slow/unread SSE backpressure ends a subscriptions/listen stream before SDK acknowledgement; it preserves durable replay/reconnect checks and does not alter Worker runtime, schema, bindings, traffic, or Cloudflare resources.
At that exact new main SHA, both push Validation #43108432199 and independent manual workflow_dispatch Validation #43108476496 have completed successfully, with job verify passing.
The staging and production protected GET-only read credential probes #43104683889 and #43104688167 passed previously on 6cb6593b7fa3fe6fb526ce7f39da7d3a97f5bb16; their original approvals were for read-only jobs, not release/publish authority. They verified both Worker-resource reads without making provider changes.

Still blocked, not accepted: five protected Environment JSON inputs per environment remain absent (RELEASE_CONFIG_JSON, PEER_CONFIG_JSON, RELEASE_SECRET_INVENTORY_JSON, RELEASE_EVIDENCE_JSON, RELEASE_OPERATIONS_JSON); verified provider usage/log-retention/backup and restore receipts remain incomplete; staging's current public Worker has no release-profile build receipt; production's PUBLIC_ORIGIN is only a text binding with no Worker custom domain. The current fail-closed staging release gate requires the peer Worker domain, so even staging cannot be published through the reviewed gate without separately reviewed/authorized domain and storage-preserving Worker bootstrap. No deployment, namespace migration, custom-domain/DNS mutation, secret registration, profile promotion, quarantine clear or rollback drill was performed. Issue #50 remains open pending independent operator decisions/approvals.

fix(release): verify paused Cloudflare version and service bindings a…

fix: fail-closed paused-state readback after Cloudflare rollback (#50)

ci: include normal-pause readback in release-script checks (#50)

Issue #50 — exact-main validation complete; protected production release remains on hold (2026-11-12 UTC)

Implementation and independent CI evidence

PR #61 merged: fail-closed scripts/release-pause-readback.mjs, six regression tests, and runbook evidence. It detects the actual staging finding that a pinned Wrangler version rollback may leave Worker service-level text bindings divergent from the active version.
PR #62 merged: the release-pause verifier is now separately linted in CI instead of being omitted from the hardcoded release-file list.
Exact current main: 381c4e7378b2d95a3b8342f045a3e4d5521ada00. The independently dispatched, workflow_dispatch Validation run #43202336603 on that exact SHA succeeded, including release-script lint, typecheck, application/unit tests, Workerd integration, restore runtime, Wrangler dry-run and browser E2E. The main-push Validation #43202287487 and both PR checks also succeeded.
These changes were code, tests, CI and documentation only. No new hosted deployment was made by these merges.

Existing independently observed hosting state — unchanged

Staging agent-table-staging: 100% active version f0701beb-db3a-4c6a-b224-7e988d438bc4; https://agent-table-test.outliner-online.com/health reports status=ok, profile=manual, build 3dd1ea8f0d2d670400b51c5325ea5e25374a3b3d. Normal intake/outbound pause was restored by a canonical settings-bound redeploy, not by trusting the version-only rollback. Measured staging receipt.
Production agent-table-production: 100% active version 8e099f35-8fa7-4e16-878c-43daa89fa218; https://agent-table.outliner-online.com/health reports status=ok, profile=manual, build be9406939674ad50b8bb1a2c6b824b1db605e587. No Complete approved staging/production release workflow and profile-bound deployment evidence #50 protected production deployment has occurred; it is not running the new main build.
The approved seven-day synthetic staging browser Close/Delete trial completed with a refreshed closed browser state and independent post-delete TABLE_NOT_FOUND for both get and transcript reads. Receipt. This does not prove erasure of downstream copies/backups.

Operator disclosures still genuinely blocked — do not fabricate a pass

Cloudflare account billable-usage API returned 403 billable-usage.api.resource.insufficient_permissions. Older/alpha billing queries returning [] do not prove $0 billed. Earlier Cloudflare GraphQL measured Worker request/DO activity, but account-specific billed storage/charges still need authorized Billing evidence.
Current production Worker readback: observability.enabled=false, logs.enabled=false, traces.enabled=false, logpush=false; this establishes that Workers Logs persistence is disabled for this Worker, not a universal statement about provider analytics, agent-delivered content or backups.
Cloudflare's published SQLite Durable Object PITR/Workers Logs and pricing references are included in the runbook; the account's actual recoverability, log-retention/disclosure limits and billed DO/KV usage have not been independently attested. No real PITR restore or newer-schema rollback was attempted. Independent post-snapshot authority reconciliation is separately blocked by Implement independently authorized restored-state reconciliation and quarantine clearance #51.

Exact remaining controlled path

Obtain account-specific Cloudflare Billing read evidence (appropriate read-only permission or owner-supplied dashboard receipt) and documented operator backup/log policy/limitations; record accurate usage/pricing without claiming zero cost or universal erasure.
Refresh the exact-381c4e7 production target and staging peer config/evidence/operations/secret-inventory in the production protected Environment after a nonpublishing preflight; recheck live DO/KV identity, health, retention and provider settings.
Obtain a separate owner approval for the specific production change and then explicit GitHub production Environment approval for the precise run. Proposed narrow scope: manual profile, existing production origin/DO/KV, no storage reset, RESTORE_QUARANTINE=false only for this non-restore release, ALLOW_NEW_GUESTS=false, ALLOW_NEW_TABLES=false, ENABLE_MCP_SUBSCRIPTIONS=false, ENABLE_OPENAI_EVENTS=false, ALLOW_OUTBOUND_NOTIFICATIONS=false. Publish only through the authenticated, fail-closed protected deploy-production.yml; postverify both Cloudflare service settings and active version, HTTPS health/build, namespace continuity and normal pause.
Only then decide whether Complete approved staging/production release workflow and profile-bound deployment evidence #50 acceptance is met; keep Complete approved staging/production release workflow and profile-bound deployment evidence #50 open now. Public/live/Events/autonomous enablement and quarantined-restore clearance are not part of this proposed production release.

The general instruction to finish the issue does not override the issue's explicit production-approval or independently verified operator-disclosure gates. No production write is being requested or executed by this comment.

#50 production paused-release owner authorization acknowledged; exact-main candidate verified offline (2026-11-12 UTC)

The owner has now explicitly answered #50 PRODUCTION_PAUSED_RELEASE 承認 in the agent-table project conversation. This is approval of the previously disclosed narrow intended change (existing production origin/storage, manual-only, all new guest/table admission, subscriptions, Events and outbound notifications disabled, no restore or storage reset). It is not a GitHub Environment approval, and it does not waive the required independently reviewed retention/usage evidence. No production publish has been attempted.

Fresh authenticated Cloudflare readback against existing, unchanged Workers using the newly merged scripts/release-pause-readback.mjs on exact main 381c4e7378b2d95a3b8342f045a3e4d5521ada00:

Production: PAUSE_READBACK_VERIFIED at active version 8e099f35-8fa7-4e16-878c-43daa89fa218, deployment 5d3def57-d3c4-4576-a8a9-7bc81cf717b6, build be9406939674ad50b8bb1a2c6b824b1db605e587.
Staging: PAUSE_READBACK_VERIFIED at active version f0701beb-db3a-4c6a-b224-7e988d438bc4, deployment a9593cdb-3af3-4fa5-b458-3da460542f8b, build 3dd1ea8f0d2d670400b51c5325ea5e25374a3b3d.
The verifier fetched both service-level settings and active-version bindings and crosschecked real Cloudflare KV/four SQLite DO namespace ownership, separate custom domains and disabled workers.dev/previews. Both hosted environments remain in normal pause with all five switches false.

Preparation for a potential future protected production deployment:

Independently selected the current production Worker data-resource bindings, code migrations and release flags, preserved the existing staging config as peer, and prepared a private, nonsecret exact-main manual candidate with only RELEASE_BUILD_SHA advanced.
Candidate SHA-256: 0c3cb9dedf9cdf4e2f3cf4d1f36b83e9c07e0c0e2ebacc3fcca0c069797619a3. Inventory contains only independently read Worker secret names, not secret values.
Exact-main manually triggered Validation #43202336603 succeeded. The candidate's offline release-preflight.mjs returned PREFLIGHT_MANIFEST_VALID, deploymentApproved:false. wrangler deploy --dry-run with Cloudflare credentials removed succeeded and shows all five operational switches disabled, same production KV binding, four DO classes, the intended origin and new build SHA. The current remote main HEAD still matches that exact SHA.

Blocking operator requirement remains: a fresh Cloudflare billable-usage API read still returned HTTP 403 / billable-usage.api.resource.insufficient_permissions. Actual account-specific billed DO/KV usage and independent backup/log retention acceptance remain unavailable. Existing Cloudflare Workers Logs switches are off, but this cannot prove all platform/provider retention. Do not write usageObserved:true or operator-verified without real review. Thus the candidate remains non-deployable under the existing approval gate; no GitHub protected Environment secrets were overwritten, no protected production workflow was dispatched, and no Cloudflare resource/data was changed.

Next: obtain owner-authorized Cloudflare Billing/dashboard read evidence and accurate retention/backup limitations, then regenerate and review fresh private operations/config/evidence, run the protected no-publish production config verification, and obtain a separate GitHub production Environment approval for the exact deployment run. Continue to keep Issue #50 open and all public/Events/autonomous flags disabled.

Billing read authorization received; browser authentication remains an external prerequisite (2026-11-12 UTC)

The owner explicitly authorized #50 BILLING_BROWSER_READ 承認 for read-only review of Cloudflare account-specific Billing/Usage. No permission change, payment, key generation, API token disclosure or deployment was authorized by this phrase.

The connected browser-extension control endpoint refused access because this chat was not opened in the originating browser context. As a separately attempted safe read-only fallback, a cloud browser opened the official https://dash.cloudflare.com/ site and was redirected to its /login sign-in form: this browser has no authenticated Cloudflare session. Credentials/OTP were neither requested from tool storage nor entered; no account actions occurred. The already configured scoped cf token continues to return 403 billable-usage.api.resource.insufficient_permissions for account-level billing usage.

Real billed usage remains BLOCKED, not zero or verified. To proceed, the owner can provide a redacted, period-labeled Billing/Usage + Workers/DO/KV dashboard receipt, sign into Cloudflare in the browser connected to ChatGPT's Browser extension and reopen the work there, or grant a dedicated least-privilege Billing-read credential through the established secure environment (not via Slack/GitHub). Account-specific retention/recovery-limit acceptance is also pending.

The exact-main 381c4e7 production manual pause candidate, its PREFLIGHT_MANIFEST_VALID/deploymentApproved:false, credential-free Wrangler dry-run and live dual-surface pause readbacks remain as previously recorded. No protected Environment secrets overwritten; no GitHub production deployment workflow dispatched; no production Cloudflare write. Issue #50 stays open pending independently verified disclosures and the separate protected Environment approval.

Billing screenshot triage — Argo/Spectrum only (owner-provided receipt; 2026-11-12 JST)

The owner supplied an account Billing → Billable usage (Beta) screenshot, Current Month. Visible panels show:

Argo traffic: “Cumulative total this month: 0 B” with Daily / All zones selected.
Spectrum: “Cumulative total this month: 0 B bytes” with Daily / All zones selected.
The immediately preceding CSV ser,ts,val / All zones,1794268799000,0 / All zones,1794355199000,0 / All zones,1794441599000,0 is consistent with the Argo traffic bytes chart, not an account-currency invoice. The timestamps are 2026-11-09/10/11 23:59:59 UTC (2026-11-10/11/12 08:59:59 JST).

Evidence classification: ACCEPTED only as the two displayed product usage panels (Argo and Spectrum, each 0 B for the displayed current-month cumulative summary). NOT ACCEPTED as billed Workers, Durable Objects or KV usage, overall spend, backup/log retention, or actual invoice value. The screen itself warns billable usage is an estimate, updated daily, and monthly calendar periods may differ from a billing period. It is not evidence of $0 Cloudflare spend.

Next required owner receipt: redacted current-period Workers & Pages, Durable Objects and Workers KV product-specific Billable usage panels showing product names, units/amounts and period; plus independent operator acknowledgment of backup/log recovery/retention limitations. Separate protected GitHub production Environment review remains required.

No production release, configuration write, approval-gate change, or unsupported usageObserved:true / retention:operator-verified assertion is made. Existing exact-main paused production candidate and evidence remain unchanged.

Owner-provided production Workers and OAuth KV dashboard receipts (2026-11-12 JST)

The owner supplied two more Cloudflare dashboard screenshots in the Issue #50 conversation. These are live product metrics, not billed-currency evidence.

Production Worker agent-table-production → Overview

Existing custom domain agent-table.outliner-online.com; workers.dev shown Disabled.
Four Durable Object bindings (ADMISSION, GUESTS, OAuth serialization, TABLES) and one OAUTH_KV binding, consistent with independently verified architecture.
Last 24 hours: Invocations 471, CPU Time 329 μs as displayed (aggregation semantics not inferred), Errors 0.
Workers Logs and Traces both shown Disabled.
Latest visible deployment short ID 8e099f35 agrees with the earlier independent production active-version readback. This is not a Complete approved staging/production release workflow and profile-bound deployment evidence #50 production release.

Production agent-table-production-oauth-kv → Metrics

Dashboard summary range November 1–November 30.
Reads 0, Writes 0, Lists 0, Deletes 0, Storage 0 B, KV count 0.
Last-24-hour operation charts report no available data.

Classification: ACCEPTED as owner-provided visual observations of displayed Worker/KV operational metrics, supplementing the earlier independent provider checks. NOT ACCEPTED as proof of $0 billed, account-wide monetary Workers/DO/KV usage, zero future spend, or empty Durable Object SQLite storage. Worker invocations demonstrate real read traffic despite normal intake/outbound pause.

Next targeted receipt is product-level DO namespace metrics (the Worker Bindings panel links to its namespaces) or account-level DO usage, plus the separately requested operator retention/recovery limitations decision. The protected production Environment approval also remains mandatory. No production deployment or configuration mutation; no fabricated usageObserved/deploymentApproved pass.

Owner-provided Durable Object Metrics screenshot (2026-11-12 JST; supplementary live usage evidence)

Following the requested navigation from the production Worker's Durable Object binding, the owner provided a Cloudflare Metrics screenshot. The visible date selector is Last 24 hours, aggregation scope All deployed versions; the active deployment short version ID 8e099f35 agrees with the existing production active Worker version independently read earlier.

The displayed metrics for the selected Durable Object view are:

Requests: 0
Errors: 0
Storage operations: 0
Request wall time: 0 ms
Billable duration: 0 GB-sec
Request type (Alarm/HTTP/RPC), WebSocket messages, and invocation error categories: all shown 0, with no chart data.

Scope caveat: The screenshot is cropped above the namespace title, so the exact selected DO namespace/class cannot be independently attributed solely from the image; the owner had been instructed to follow the TABLES binding. It is not evidence that all four production SQLite DO namespaces or their stored bytes have zero activity, and zero billable duration in this 24-hour view does not establish zero monetary charges or account-wide invoice totals.

This is accepted as a period-scoped owner-provided DO metrics receipt, supplementing earlier authenticated Cloudflare GraphQL Workers/DO request activity, independent Cloudflare Worker bindings and KV usage observations. Still pending: sufficiently scoped actual usage/cost disclosure (without claiming a $0 invoice), operator acceptance of backup/log/agent-copy retention and restore limitations, a fresh build/config-bound production operator decision, and separate protected production GitHub Environment approval.

Production remains at the prior paused Worker; no release workflow dispatched or production write performed.

#50 owner retention-limit acceptance; fresh hosted pause readback; production operator packet preparation (2026-11-12 JST)

Owner explicitly replied #50 RETENTION_LIMITS 承認 after the scoped disclosure. Acceptance is limited to the known limitations, not proof that a backup can be recovered or every copy deleted:

Cloudflare's SQLite Durable Object PITR API advertises restoration to an earlier point within 30 days, but no real production object-level PITR restore drill, full account-backup scope or recovery success has been established. Cloudflare SQLite storage documentation.
The present production Worker dashboard shows Workers Logs and Traces disabled; earlier provider readback also found Logpush off. If Workers Logs were enabled, current Cloudflare published limits are 3 days on Free, 7 days on Paid; current account plan, actual retained provider diagnostics/backups and any third-party logs are not independently attested. Cloudflare Workers Logs documentation.
Agent-delivered copies and platform/provider backups cannot be recalled merely by browser table deletion. Neither restored authorization nor universal erasure is being claimed.

Observed usage and pricing disclosure, not a claimed invoice:

Production Worker user dashboard: 471 invocations, 0 errors in a displayed last-24-hour window, with active prior version 8e099f35. Owner screenshot summary.
Production OAuth KV dashboard: 0 reads/writes/lists/deletes, 0 B, 0 keys in its November 1–30 summary; no claim about separate SQLite DO storage.
Selected production Durable Object Metrics view: 0 requests, 0 storage operations, 0 GB-sec billable duration in displayed last 24 hours; selected namespace title not visible, not a 4-namespace/account-wide zero claim. Owner screenshot summary.
Earlier independent authenticated Cloudflare GraphQL sampled adaptive dataset for 2026-11-04–11 UTC measured production Worker requests and account-wide DO invocation activity. Prior provider measurement.
Actual billed account currency/DO storage charges remain UNKNOWN, because account Billable Usage API returned 403; the supplied Argo/Spectrum billing chart and other usage screenshots are not an invoice. Current unit pricing reference: Cloudflare Workers (includes Workers KV and DO) and Durable Objects. No assertion of $0 spend or plan type is warranted. The release packet may record cost.usageObserved=true solely in the literal sense of real provider metrics having been observed, with this explicit limitation; it must not be presented as actualBilledChargesVerified.

Fresh independent provider pause check performed on the authorized operator host after the consent: both production and staging returned PAUSE_READBACK_VERIFIED on service settings and 100%-traffic active versions; production remains 8e099f35-8fa7-4e16-878c-43daa89fa218 (build be940693...) and staging remains f0701beb-db3a-4c6a-b224-7e988d438bc4 (build 3dd1ea8f...). Both are manual with normal intake/outbound pause. Exact candidate main SHA 381c4e7378b2d95a3b8342f045a3e4d5521ada00 and production candidate SHA-256 0c3cb9dedf9cdf4e2f3cf4d1f36b83e9c07e0c0e2ebacc3fcca0c069797619a3 still match their original reviews; GitHub main was checked independently. Production Environment secret names include both Cloudflare tokens and all five release JSON inputs, but secret values were not read or exposed.

The next stage will prepare a fresh target-bound operator disclosure and test the fail-closed gate. Any protected production deployment still requires the owner's separate explicit GitHub production Environment approval after dispatch; no credential rotation, profile promotion, authorization restore, data wipe or public Events/subscription/outbound activation is authorized.

#50 — protected production manual release prepared, awaiting GitHub Environment approval (2026-11-12 UTC)

Owner authorizations recorded in this conversation: #50 PRODUCTION_PAUSED_RELEASE 承認, #50 RETENTION_LIMITS 承認. They permit preparation/dispatch of a paused manual release and acceptance of explicitly documented retention limits; neither substitutes for GitHub's separate protected production Environment approval.

Expected main SHA: 381c4e7378b2d95a3b8342f045a3e4d5521ada00; remote main and independently checked clean candidate checkout matched.
Production manual candidate JSON SHA-256: 0c3cb9dedf9cdf4e2f3cf4d1f36b83e9c07e0c0e2ebacc3fcca0c069797619a3; all five production capability flags false, RESTORE_QUARANTINE=false, existing production DO/KV/bindings retained, no restore/wipe. Environment = production, profile = manual.
Read-only production+staging verification: PAUSE_READBACK_VERIFIED; previous production deployment 8e099f35-8fa7-4e16-878c-43daa89fa218 observed before dispatch. Neither endpoint was mutated during this readback.
Operator decision record, including owner-reviewed retention policy, no-restore, v11/non-destructive rollback, measured usage and pricing source, validated locally with validateRelease and verifyOperationalDecision: ISSUE50_OPERATOR_DECISION_VALID, with deploymentApproved:false expected before GitHub protected approval. JSON SHA-256 4988a6615d9ee62b777e02fc1c3bf8d2bcc72b1c85c2f36b361d488782dee1a4.
Protected GitHub Environment had all eight required secret names. Updated five review inputs successfully (in order): RELEASE_CONFIG_JSON, PEER_CONFIG_JSON, RELEASE_SECRET_INVENTORY_JSON, RELEASE_EVIDENCE_JSON, RELEASE_OPERATIONS_JSON; GitHub metadata confirmed updates 2026-11-12 13:17:28–13:17:32Z. Provider authentication tokens were not overwritten or exposed.
Exact-main manual CI validation: https://github.com/kitamura-tetsuo/agent-table/actions/runs/43202336603 — success before dispatch.
Dispatched deploy-production.yml using workflow_dispatch at main with explicit exact expected_sha. Result: https://github.com/kitamura-tetsuo/agent-table/actions/runs/43225956518, created 2026-11-12T13:17:57Z, confirmed waiting, pending deployment production Environment ID 26890542756 and one reviewer. No deploy success or runtime postverification has yet been observed.
Requested the owner to review GitHub Environment via Slack: https://kitamura-tetsuo.slack.com/archives/D201BTR5L/p1794489589396369 . GitHub UI approval is required; Slack acknowledgement alone does not satisfy this gate.

Retention/cost caveats remain as in #50 (comment): production PITR recovery window/drill unverified, provider/agent retained copies cannot necessarily be recalled, account invoice currency inaccessible (403), and measured usage does not prove $0 billed.

Current status: HOLD at protected GitHub Environment approval. Follow up after owner UI action with run logs, postdeploy verification, paused invariant, and Issue acceptance update. Do not claim production released, issue fully accepted, or billable usage zero until evidence exists.

#50 operator cost acceptance update (2026-11-12 JST)

The owner explicitly stated after protected production Environment approval: an exact/final account bill is not required for this issue's release acceptance; they accept proceeding with measured usage and published pricing available, and may pause service if an invoice is unacceptable. This acceptance does not prove charges are zero, establish a prepaid limit, or authorize an unbounded billing configuration.

Observed facts remain distinct: Cloudflare Worker invocations and selected Durable Object metrics were read from production dashboards; OAuth KV showed zero activity/0 B in the shown monthly view; account-level final bill and invoice remain unknown because the available account billing API returned 403. No automatic cost-stop mechanism has been configured or tested.

GitHub Environment reviewer gate for production run https://github.com/kitamura-tetsuo/agent-table/actions/runs/43225956518 is no longer pending (the pending-deployments API returned []); GitHub reports the candidate job queued for ubuntu-latest. Deployment success and live release postconditions remain unverified until the run completes.

#50 protected production attempt #1 failed closed; semantically identical byte-normalized retry awaits separate GitHub approval (2026-11-12 22:xx JST)

First owner-approved run: https://github.com/kitamura-tetsuo/agent-table/actions/runs/43225956518, exact-main SHA 381c4e7378b2d95a3b8342f045a3e4d5521ada00, GitHub production Environment approved by kitamura-tetsuo. Tests succeeded (33 files, 201 tests, separate restore-runtime 2 tests and Wrangler dry-run), then the nonpublishing candidate preflight failed with PREFLIGHT_BLOCKED evidence-target-mismatch. The provider-authentication, Wrangler publish and postverification steps were skipped. It would be false to count this as a production deployment.

Diagnosis and narrow remediation: Offline scripts/release-preflight.mjs passed with the exact source config/evidence files. The original production-candidate JSON contained a terminal LF; a discrepancy of environment-secret transport bytes is the leading hypothesis, but the GitHub secret values themselves are not readable and root cause is not independently proven. Produced a new candidate differing by only the final LF byte; jq -s '.[0]==.[1]' confirmed semantic JSON equality. New SHA-256: 303520c2b5da8854369661bfcb8af9a8c1d3bdcea0d17382fc57713052ffc945 (old 0c3cb9dedf9cdf4e2f3cf4d1f36b83e9c07e0c0e2ebacc3fcca0c069797619a3). Updated only .configSha256 in evidence and operator decision, leaving all other parsed JSON fields identical (verified with jq); the new exact-file offline preflight and verifyOperationalDecision both passed. New evidence/operations file SHA-256 values: a0472739d9c96bd5b7d17415b35aad600865f0feac5bccd11a43065b21c8865a / bc87887ea2c894879913a1f0d717ce9f974952351aff79ebcabe680e5ea05962.

Updated 3 production protected Environment input secrets (RELEASE_CONFIG_JSON, RELEASE_EVIDENCE_JSON, RELEASE_OPERATIONS_JSON) with metadata readback 13:39:17–19Z. Did not change the peer config, secret inventory, provider tokens, production bindings, names, flags, origin, profile, main code, namespace or data.

Before retry dispatch, independent Cloudflare PAUSE_READBACK_VERIFIED on current production config confirmed unchanged active version 8e099f35-8fa7-4e16-878c-43daa89fa218, deployment 5d3def57-d3c4-4576-a8a9-7bc81cf717b6, build be9406939674ad50b8bb1a2c6b824b1db605e587, admission=paused; main still 381c4e....

New, separately gated run: https://github.com/kitamura-tetsuo/agent-table/actions/runs/43229649298 created 13:41:11Z, verified waiting with one reviewer on protected production Environment ID 26890542756. No reviewer approval or new publication observed at this writing. Requested fresh owner UI approval here: https://kitamura-tetsuo.slack.com/archives/D201BTR5L/p1794490933143179. Do not use the first run's approval for the new byte hash. If the retry fails, collect the new precise failure code before any further changes.

Owner's cost acceptance remains limited to proceeding without a confirmed invoice amount; account billed total remains UNKNOWN, not $0. Other retention/restore limitations unchanged. #50 remains open pending new run approval, production publish and postverification.

Final acceptance — Issue #50 manual-profile staging/production release PASS (2026-11-12 JST)

Scope of acceptance: Protected manual profile, intake/outbound/Events paused, existing production resources and private content retained, no PITR restore, no reconciliation clearance and no claims of support for live, events or autonomous profiles. The independent recovery-authority problem remains OPEN in #51, and overarching #22 remains open for that part.

New production release: independently verified

Owner explicitly approved the second protected production run, and GitHub approval history returned state=approved, reviewer kitamura-tetsuo, environment production for production run #43229649298. workflow_dispatch was pinned to immutable main SHA 381c4e7378b2d95a3b8342f045a3e4d5521ada00.
GitHub Actions outcome: completed/success, including immutable source check, npm install, application + isolated Workerd gates, nonpublishing config/evidence preflight, authenticated Cloudflare resource ownership and approval checks, exact-config Worker publish, postpublish Worker/DO/KV/domain/build readback, and ephemeral candidate cleanup. Production preflight config SHA-256: 303520c2b5da8854369661bfcb8af9a8c1d3bdcea0d17382fc57713052ffc945.
Separate Cloudflare API readback from operator device with readCloudflareDeployment and verifyDeployedConfiguration for production and staging passed: production agent-table-production, origin https://agent-table.outliner-online.com, active 100% version ce3f4589-57f1-467c-88fa-a9adbfa3628d, deployment 8e706372-7485-4400-a765-f0a57b7bb9e6. Production retained its original four class-owned SQLite Durable Object namespaces and OAUTH_KV namespace (all identities verified against provider; IDs intentionally not repeated in this public comment). Staging remained at active f0701beb-db3a-4c6a-b224-7e988d438bc4 and deployment a9593cdb-3af3-4fa5-b458-3da460542f8b, with a distinct Worker, KV and Durable Objects.
Independent normal-pause verification: node scripts/release-pause-readback.mjs with the reviewed production candidate, authentic staging peer config, and independently observed expected active version yielded PAUSE_READBACK_VERIFIED for production version ce3f4589-..., deployment 8e706372-..., exact build 381c4e7378b2d95a3b8342f045a3e4d5521ada00 and admission=paused. This checks both Worker service settings and active-version bindings, including the regression from fix: fail-closed paused-state readback after Cloudflare rollback (#50) #61/ci: include Issue #50 pause readback in release-script lint #62.
Provider effective text bindings all returned false: ALLOW_NEW_GUESTS, ALLOW_NEW_TABLES, ENABLE_MCP_SUBSCRIPTIONS, ENABLE_OPENAI_EVENTS, ALLOW_OUTBOUND_NOTIFICATIONS, RESTORE_QUARANTINE=false. The latter means no restore was performed and does not imply authorization to release a restored snapshot. The manual profile has no public event/autonomous capability claim.
HTTPS GET /health separately returned status=ok, production environment production, profile manual, build SHA 381c4e7378b2d95a3b8342f045a3e4d5521ada00. Staging /health remained ok, profile manual, build 3dd1ea8f0d2d670400b51c5325ea5e25374a3b3d.

Other acceptance evidence

Protected staging initial publish and provider readback: staging run #43151011535 and staging receipt.
Owner-approved real staging same-config update + pinned rollback, including retained SQLite synthetic transcript seq=1..4, unchanged distinct production, admission still disabled: rehearsal receipt. This was code-version rollback only, not PITR backup restore.
Seven-day synthetic staging same-guest browser Close/confirmed Delete with independent TABLE_NOT_FOUND on both table and transcript after deletion: browser receipt. This demonstrates application lifecycle, not guaranteed erasure of agent-delivered copies or provider backups.
Fail-closed evidence was actually exercised: first production run #43225956518 stopped on PREFLIGHT_BLOCKED evidence-target-mismatch before publish. Normalized semantically identical JSON (terminal LF removed), re-bound its SHA in evidence and operator record, and subjected the new hash to fresh independently reviewed GitHub approval: retry receipt.
Existing runbook now contains emergency intake/outbound pause, independent dual-surface service/version readback, rollback mismatch refusal, profile promotion, retention and cost disclosures and quarantine handoff; PR #61 and PR #62 merged, exact-main Validation #43202336603 succeeded.

Explicit non-claims and follow-ups

Cost: actual product usage and current published pricing were observed, but account invoiced amount is UNKNOWN (billing API 403), not $0. The owner explicitly accepted proceeding without a finalized invoice here. There is no automatic stop-on-billing control asserted.
Retention: owner accepted written limitations here; Cloudflare SQLite PITR restore/window on actual production data was not drilled, and agent/provider-retained copies cannot be recalled or universally erased.
Issue #51 remains OPEN/BLOCKED for independent post-snapshot revoked/deleted/expired authority, reconciliation, controlled RESTORE_QUARANTINE clearance, and genuine restoration exercise. This release did not restore, clear quarantine, rename/delete namespaces or enable unsupported Events/subscriptions/egress. Issue #22 continues as parent contract tracking.

Disposition: All Issue #50 requirements applicable to the owner-approved staged and production manual paused-release scope have concrete provider, CI, browser and retention/usage acceptance evidence. Close #50 as completed without implying #51 or public/live/event/autonomous release acceptance.

Navigation Menu

Repository navigation

Complete approved staging/production release workflow and profile-bound deployment evidence #50

Context

Requirements

Acceptance

Evidence

Verified production quarantine bootstrap — 2026-11-11 (Cloudflare readback)

Read-only live release-readiness check — 2026-11-11 10:36–10:45 UTC

Owner-authorized follow-up: production secret injection and staging ingress hardening (2026-11-11)

Follow-up: verified token policy identity and diagnostic PR (2026-11-12 JST)

Scope update acknowledged; protected GET-only reruns awaiting owner approval (2026-11-12 JST)

Protected readback passed; exact-main CI and live provider state (2026-11-12 JST)

Latest exact-main Validation and two-Worker flake fix (2026-11-12 JST)

30 remaining items

Issue #50 — exact-main validation complete; protected production release remains on hold (2026-11-12 UTC)

#50 production paused-release owner authorization acknowledged; exact-main candidate verified offline (2026-11-12 UTC)

Billing read authorization received; browser authentication remains an external prerequisite (2026-11-12 UTC)

Billing screenshot triage — Argo/Spectrum only (owner-provided receipt; 2026-11-12 JST)

Owner-provided production Workers and OAuth KV dashboard receipts (2026-11-12 JST)

Owner-provided Durable Object Metrics screenshot (2026-11-12 JST; supplementary live usage evidence)

#50 owner retention-limit acceptance; fresh hosted pause readback; production operator packet preparation (2026-11-12 JST)

#50 — protected production manual release prepared, awaiting GitHub Environment approval (2026-11-12 UTC)

#50 operator cost acceptance update (2026-11-12 JST)

#50 protected production attempt #1 failed closed; semantically identical byte-normalized retry awaits separate GitHub approval (2026-11-12 22:xx JST)

Final acceptance — Issue #50 manual-profile staging/production release PASS (2026-11-12 JST)

New production release: independently verified

Other acceptance evidence

Explicit non-claims and follow-ups

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Complete approved staging/production release workflow and profile-bound deployment evidence #50

Description

Context

Requirements

Acceptance

Evidence

Activity

kitamura-tetsuo commented on Nov 11, 2026

Verified production quarantine bootstrap — 2026-11-11 (Cloudflare readback)

kitamura-tetsuo commented on Nov 11, 2026

Read-only live release-readiness check — 2026-11-11 10:36–10:45 UTC

kitamura-tetsuo commented on Nov 11, 2026

Owner-authorized follow-up: production secret injection and staging ingress hardening (2026-11-11)

kitamura-tetsuo commented on Nov 11, 2026

kitamura-tetsuo commented on Nov 11, 2026

kitamura-tetsuo commented on Nov 11, 2026

Follow-up: verified token policy identity and diagnostic PR (2026-11-12 JST)

kitamura-tetsuo commented on Nov 11, 2026

kitamura-tetsuo commented on Nov 11, 2026

Scope update acknowledged; protected GET-only reruns awaiting owner approval (2026-11-12 JST)

kitamura-tetsuo commented on Nov 11, 2026

Protected readback passed; exact-main CI and live provider state (2026-11-12 JST)

kitamura-tetsuo commented on Nov 11, 2026

Latest exact-main Validation and two-Worker flake fix (2026-11-12 JST)

30 remaining items

kitamura-tetsuo commented on Nov 12, 2026

Issue #50 — exact-main validation complete; protected production release remains on hold (2026-11-12 UTC)

kitamura-tetsuo commented on Nov 12, 2026

#50 production paused-release owner authorization acknowledged; exact-main candidate verified offline (2026-11-12 UTC)

kitamura-tetsuo commented on Nov 12, 2026

Billing read authorization received; browser authentication remains an external prerequisite (2026-11-12 UTC)

kitamura-tetsuo commented on Nov 12, 2026

Billing screenshot triage — Argo/Spectrum only (owner-provided receipt; 2026-11-12 JST)

kitamura-tetsuo commented on Nov 12, 2026

Owner-provided production Workers and OAuth KV dashboard receipts (2026-11-12 JST)

kitamura-tetsuo commented on Nov 12, 2026

Owner-provided Durable Object Metrics screenshot (2026-11-12 JST; supplementary live usage evidence)

kitamura-tetsuo commented on Nov 12, 2026

#50 owner retention-limit acceptance; fresh hosted pause readback; production operator packet preparation (2026-11-12 JST)

kitamura-tetsuo commented on Nov 12, 2026

#50 — protected production manual release prepared, awaiting GitHub Environment approval (2026-11-12 UTC)

kitamura-tetsuo commented on Nov 12, 2026

#50 operator cost acceptance update (2026-11-12 JST)

kitamura-tetsuo commented on Nov 12, 2026

#50 protected production attempt #1 failed closed; semantically identical byte-normalized retry awaits separate GitHub approval (2026-11-12 22:xx JST)

kitamura-tetsuo commented on Nov 12, 2026

Final acceptance — Issue #50 manual-profile staging/production release PASS (2026-11-12 JST)

New production release: independently verified

Other acceptance evidence

Explicit non-claims and follow-ups

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions