控制台异步请求生产闭环：幂等恢复、深客户端 Module、跨 Seam 测试与受控发布

[techidsk]

Problem Statement

运维控制台已经能调用异步 Process Run HTTP Interface，并在最多 300 秒内查询结果；服务端 Async Process Runs Module 也已经实现 PostgreSQL durable acceptance、Outbox、BullMQ 调度、独立 Worker、owner 隔离、受控重试、恢复、Webhook 与保留策略。

但当前能力还不是可安全上线的产品闭环：

• 控制台每次调用都会生成新的 Idempotency-Key。如果服务端已经接受请求，但 202 响应在网络中丢失，操作者再次提交可能创建第二个付费 Process Run。这违反了“调用方超时或断线后必须用同一个 key 重试”的既有 Interface invariant。
• 浏览器侧把幂等键、HTTP transport、轮询、Retry-After、超时和 UI 回调混在一个浅层 Implementation 中，只返回 body: unknown 或自由文本错误，无法可靠表达已接受但仍待完成的 Process Run。
• 浏览器测试 mock 了全部 HTTP；真实 PostgreSQL/Redis 集成测试则绕过控制台 Client，直接手工构造身份头。没有一项测试从控制台 Client Interface 穿过可信网关、API、Dispatcher、Queue、Worker 和权威 Store。
• 本地开发代理不提供可信 caller identity Adapter，控制台无法在本地真实运行异步提交。
• 标准生产部署形状明确关闭异步入口，也不部署异步角色；现有 Production CI/CD 不运行 PostgreSQL/Redis 集成命令。当前控制台提交在标准生产形状中不可用。
• 尚未形成 internal → canary → production 的部署证据，也没有完成真实网关、角色重启、Redis 恢复、观测告警和付费图片 Process 的 staging smoke。

从操作者视角，现在最危险的不是“查询慢”，而是一次不确定提交可能在重试时重复计费；从维护者视角，测试证明了服务端内部链路，却没有证明真实调用方旅程。

Solution

交付一个可恢复、可测试、可受控发布的控制台异步请求闭环。

控制台通过一个深的 Console Process Run Client Module 提交和等待 Process Run。该 Module 为一次用户操作持有稳定幂等键，安全处理响应丢失、容量拒绝和瞬时网络故障；在 durable acceptance 后公开 runId，根据服务端 Retry-After 查询权威状态，并以结构化结果表达终态、仍待完成、明确拒绝和不可恢复故障。页面导航或 300 秒等待超时只停止客户端查询，不取消服务端 Process Run。

测试以 Console Process Run Client Interface 为最高且主要的 Seam。确定性 contract tests 使用本地 Adapter；跨 Seam 集成测试让同一个 Client 穿过测试网关、真实 HTTP、PostgreSQL、Redis、Dispatcher 和 Worker。一个最小浏览器验收覆盖真实表单行为。Production CI/CD 自动运行真实依赖集成门禁；生产保持基础同步 Compose 默认关闭，另提供显式、受控的异步部署形状，按 Runbook 从 internal 分阶段提升。

User Stories

1. As an 运维操作者, I want one click to represent exactly one submission operation, so that a lost response cannot silently create a second paid Process Run.
2. As an 运维操作者, I want an ambiguous submission to reuse its original idempotency key, so that retrying after a timeout is safe.
3. As an 运维操作者, I want the console to distinguish “definitively rejected” from “acceptance unknown,” so that I do not guess whether a paid operation started.
4. As an 运维操作者, I want the console to show the runId immediately after durable acceptance, so that I can retain a stable recovery handle.
5. As an 运维操作者, I want the console to show queued, running, succeeded, and failed states, so that I know whether to wait or investigate.
6. As an 运维操作者, I want a successful terminal Process Run to display its typed result, so that I can verify the delivered artifact.
7. As an 运维操作者, I want a failed terminal Process Run to display its stable public error, so that I can act without seeing internal exception text.
8. As an 运维操作者, I want an expired result to be reported explicitly, so that I do not confuse retention expiry with an empty result.
9. As an 运维操作者, I want a 300-second wait timeout to preserve the accepted runId, so that I can continue querying later.
10. As an 运维操作者, I want leaving the page to stop browser polling without cancelling the Process Run, so that navigation does not change paid business execution.
11. As an 运维操作者, I want to resume an accepted Process Run after refreshing the page, so that a browser restart does not lose the recovery path.
12. As an 运维操作者, I want an explicit action to start a genuinely new submission after an uncertain one, so that duplicate intent is deliberate rather than accidental.
13. As an 运维操作者, I want transient query failures to recover within the wait deadline, so that a brief gateway or network interruption does not look like Process failure.
14. As an 运维操作者, I want capacity rejection to respect Retry-After, so that the console does not hot-loop or overload the service.
15. As an 运维操作者, I want malformed or unexpected server responses to produce a clear protocol error, so that the console never displays fabricated state.
16. As an 运维操作者, I want the console to link an accepted runId to a recoverable result view, so that I do not need to copy identifiers from free-form text.
17. As an 运维操作者, I want a clear warning that submission may generate image cost, so that I understand the side effect before starting.
18. As an 运维操作者, I want the submit button disabled only for the active submission operation, so that repeated clicks cannot create concurrent duplicate intent.
19. As an authenticated caller, I want all queries scoped to my stable caller identity, so that another caller cannot observe my Process Run.
20. As an authenticated caller, I want unknown and unauthorized runId values to remain indistinguishable, so that Process Runs cannot be enumerated.
21. As a security maintainer, I want the browser to send no gateway shared secret, so that trust remains in the gateway Adapter rather than client code.
22. As a security maintainer, I want the result Location constrained to the same origin and expected resource shape, so that a response cannot redirect polling to an arbitrary host.
23. As a security maintainer, I want the gateway to remove caller-supplied identity headers before injecting trusted identity, so that callers cannot impersonate one another.
24. As a service maintainer, I want idempotency, retry, polling and response validation owned by one Client Module, so that protocol fixes have locality.
25. As a service maintainer, I want the Client Module to expose structured outcomes rather than unknown bodies and error strings, so that every caller handles the same states.
26. As a service maintainer, I want time, scheduling, transport and pending-submission persistence behind internal seams, so that deterministic tests need no real clock or browser globals.
27. As a service maintainer, I want tests to use the Client Module’s external Interface, so that Implementation refactors do not rewrite test intent.
28. As a service maintainer, I want the existing server Async Process Runs Module to remain unchanged unless a failing cross-Seam test proves a server defect, so that mature state-machine behaviour is not duplicated.
29. As a service maintainer, I want one test to cover queued → running → succeeded, so that repeated polling is proven rather than inferred from a single terminal response.
30. As a service maintainer, I want terminal failure and expired-result tests, so that every public terminal projection is supported by the Client.
31. As a service maintainer, I want an ambiguous POST test where the server accepts but the response is lost, so that replay with the same key proves no duplicate Run is created.
32. As a service maintainer, I want transient GET and 503 recovery tests, so that the 300-second wait is useful during short outages.
33. As a service maintainer, I want cancellation and timeout tests to prove the server Run continues, so that client lifecycle and Process lifecycle stay separate.
34. As a service maintainer, I want a real HTTP integration test using the same Client as the browser, so that mocked fetch tests cannot drift from the deployed protocol.
35. As a service maintainer, I want a test gateway Adapter to inject trusted caller identity, so that integration tests exercise the production trust model without exposing secrets to browser code.
36. As a service maintainer, I want a minimal headless-browser test of the submit form, progress state and terminal result, so that DOM wiring is verified at the highest useful Seam.
37. As a service maintainer, I want local development to provide a safe test caller through a development-only gateway Adapter, so that the async console can be exercised without weakening production identity rules.
38. As a release engineer, I want PostgreSQL and BullMQ integration suites to run in CI, so that a pull request cannot merge after breaking durable acceptance or dispatch.
39. As a release engineer, I want integration containers and test data cleaned after every CI run, so that retries start from an isolated environment.
40. As a release engineer, I want the standard synchronous production shape to remain disabled for async requests, so that ordinary deployment does not bypass release gates.
41. As a release engineer, I want a separate explicit async deployment shape, so that API, Dispatcher, Worker, Webhook Worker and Retention Cleaner can be released and rolled back together without changing the safe default.
42. As a release engineer, I want every async role to pass deployment preflight and readiness before internal traffic starts, so that missing secrets or mismatched Queue configuration fail before exposure.
43. As an SRE, I want an internal smoke to submit and query both a successful and failed Process Run, so that status projection and public errors are verified after deployment.
44. As an SRE, I want a Worker restart during an accepted Run to preserve one terminal outcome, so that rolling deployment is safe.
45. As an SRE, I want Redis loss followed by Queue Recovery to complete accepted Runs, so that PostgreSQL remains the authority.
46. As an SRE, I want backlog, stuck Run, Outbox lag and recovery-age readiness gates enforced before canary traffic, so that promotion depends on operational evidence.
47. As an SRE, I want async observability and alert fields populated during smoke, so that incidents are diagnosable before production traffic.
48. As an SRE, I want rollback to stop new submissions while preserving owner queries for accepted Runs, so that disabling intake does not strand callers.
49. As a product owner, I want one controlled paid image smoke through the complete asynchronous path, so that FAL, finalization, OSS persistence and result query are verified together.
50. As a product owner, I want paid smoke separated from deterministic CI, so that normal validation never incurs hidden external cost.

Implementation Decisions

• Preserve the existing Business Process, Process Registration, Process Registry and Async Process Runs domain model. Do not introduce a second Workflow model, client-selected runtime configuration or Queue concepts into the product request.
• Keep the server Async Process Runs Module as the authority for acceptance and owner-scoped lookup. Its existing submit/find Interface, PostgreSQL Store, Outbox, Queue Adapter, Worker and recovery behaviour remain the server foundation.
• Add one external Seam in the browser layer: the Console Process Run Client Interface. The UI submits a Business Process request to this Interface and receives structured progress/outcomes; it does not manage HTTP headers, polling timers or response parsing itself.
• The Client Module owns one stable idempotency key per user submission operation. It persists the pending operation before the first POST and reuses the key for every ambiguous or retryable submission attempt. A fresh key requires a new explicit user operation.
• Persist the minimum browser recovery state needed to survive refresh: request fingerprint, idempotency key, optional accepted runId, creation time and current recovery classification. Do not persist business output, gateway credentials or hidden implementation data.
• Once a 202 response maps the operation to a runId, preserve that mapping until terminal completion or explicit operator dismissal. Losing the page must not lose the accepted Run’s recovery handle.
• Return discriminated structured outcomes for terminal success, terminal failure, expired result, pending timeout/cancellation, definitive submission rejection and protocol/unavailable failure. Free-form text is presentation only and must not be the programmatic Interface.
• Keep the default client wait deadline at 300 seconds. The deadline starts after durable acceptance; submission retry has its own bounded policy so an unavailable acceptance path cannot wait forever.
• Respect valid server Retry-After values for submission capacity responses and nonterminal queries. Apply safe minimum and maximum bounds to prevent hot polling or an unbounded sleep. Use bounded backoff for transient transport failures when no valid server hint exists.
• Treat ambiguous transport failure during POST as acceptance unknown, not rejection. Retry with the same key. Treat stable validation, not-found and idempotency-conflict responses as definitive. Treat admission 429/capacity 503 as retryable without rotating the key because they do not consume it.
• Treat transient network failures and retryable gateway/server errors during GET as recoverable until the client deadline. Stable authorization/not-found responses and invalid response shapes end the current wait with a structured failure.
• Validate submission and Process Run response shapes before exposing them to the UI. Accept only the documented public states and result-expiry projection.
• Resolve Location relative to the current origin, then reject cross-origin or non-Process-Run targets before issuing a query.
• Accept an AbortSignal that cancels client retries, timers and polling only. This signal must never call a server cancellation operation; Process Run cancellation remains outside the current public Interface.
• Keep transport, clock/scheduler, idempotency-key generation and pending-operation storage as internal seams of the Client Module. Production uses browser Fetch/Crypto/Storage Adapters; tests use scripted/in-memory Adapters. These internal seams are not exposed through the UI Interface.
• Keep trusted identity in the gateway Adapter. Browser code uses same-origin HTTP and never reads or sends the gateway shared secret. The production gateway strips untrusted identity headers, authenticates the operator and injects the stable caller subject plus shared credential.
• Provide a development-only gateway Adapter or equivalent local proxy configuration that injects a fixed non-production caller and reads any shared secret only on the server side. It must be impossible to include this secret in the browser bundle.
• Update the console submission view to show the accepted runId, current public status, terminal structured result and recovery actions. A pending timeout provides “continue querying”; an acceptance-unknown state provides “retry same operation”; only an explicit “new submission” rotates the key.
• Keep the standard production Compose shape synchronous and ASYNC_PROCESS_RUNS_ENABLED=false. Add a separate explicit async deployment shape or overlay owned by the async Runbook; do not add PostgreSQL or Redis containers to the base production Compose.
• The async production shape starts the API override plus Process Dispatcher, Process Worker, Webhook Worker and Retention Cleaner against externally managed PostgreSQL/Redis. Operations and Queue Recovery remain controlled jobs rather than public HTTP roles.
• Add an operator-controlled async release entry that performs per-role environment preflight, migration, full Queue Recovery dry-run, role readiness, internal smoke and staged promotion. Normal synchronous deployment must not enable async routes implicitly.
• Rollback disables new asynchronous submissions or returns the release stage to internal while retaining PostgreSQL and the ability to query already accepted Runs. It must not delete accepted Run, owner, idempotency, Outbox or Delivery state.
• No new database schema is required for server Process Runs. Browser pending-operation persistence is local client state, not a new production database table.
• Keep POST /process-runs and GET /process-runs/{runId} contracts unchanged. Product callers still submit only exact Process identity/version and business input.

Testing Decisions

• A good test crosses the highest stable Interface and asserts externally observable outcomes: structured Client outcome, HTTP status/headers, durable Run identity, public Process Run state and absence of duplicate side effects. Tests do not assert private timer calls, internal maps, BullMQ implementation fields or SQL layout.
• The primary test Seam is the Console Process Run Client Interface. Deterministic contract tests instantiate it with scripted transport, clock/scheduler and in-memory pending-operation Adapters.
• Client contract tests cover: successful submit; queued → running → succeeded; public failure; expired result; malformed submission/query response; missing or cross-origin Location; invalid Retry-After; 300-second timeout; AbortSignal cancellation; transient GET recovery; definitive authorization/not-found failure; admission 429/503; and response bodies that are not JSON.
• The critical idempotency test simulates this ordering: the server durably accepts one request, the client loses the first response, the Client retries with the same key, and the final observable result contains the original runId with exactly one Process Run and one paid Business Capability effect.
• Add one cross-Seam integration suite where the real Console Process Run Client uses real HTTP through a test gateway Adapter into independently constructed API, Dispatcher and Worker roles backed by temporary PostgreSQL and Redis. It covers success, stable business failure, owner isolation, idempotent replay and client timeout followed by later successful query.
• Reuse existing Process Run HTTP, PostgreSQL Store, BullMQ runtime, recovery, Webhook and retention tests as prior art. Extend them only when a new Client-level failure reveals an uncovered server invariant; do not duplicate their internal cases in browser tests.
• Add one minimal headless-browser acceptance test that loads the built console, submits through the test gateway, observes accepted runId/progress, and renders the terminal result. Do not add broad snapshot or private frontend component tests.
• Add a CI job that starts the repository’s isolated PostgreSQL/Redis integration environment, runs PostgreSQL and async BullMQ integration commands serially, and always cleans containers. Keep deterministic tests as the fast default job; make the real-dependency job required before merge.
• The CI integration job uses only the dedicated _test PostgreSQL database and nonzero Redis database. It must refuse shared/production targets under existing safety checks.
• Add deployment-shape validation that renders the explicit async production configuration, verifies every role uses the same immutable image revision and Queue settings, and confirms the base production shape still has async disabled.
• Staging fault drills cover: API acceptance with Redis unavailable; Dispatcher restart after publish-before-ack; Worker termination during an active claim; Redis Queue loss and full recovery; duplicate Job; expired claim takeover; Webhook endpoint outage; and rollback with owner query preserved.
• Internal/canary smoke verifies role health/readiness, one successful Run, one stable failed Run, caller isolation, result retention projection, Queue/Outbox observability and no content leakage in logs.
• A paid image smoke runs only with explicit credentials and authorization after deterministic and staging infrastructure gates pass. It executes one approved image Business Process through asynchronous submission, real Worker, FAL/finalizer, OSS storage and owner-scoped result query, then records cost-safe evidence without logging source URLs or credentials.
• Existing synchronous /execute, Run Record console, Business Process catalog, activity logging and production build tests remain required regression gates.

Out of Scope

• Replacing PostgreSQL as the Process Run authority or BullMQ as the current Queue Adapter.
• Rewriting the existing server Async Process Runs state machine, Store, Outbox, Worker, Webhook or Retention Modules without a failing Interface-level test.
• Changing Business Process input/output contracts, production catalog membership, Runtime Skill bindings, model/provider selection or object-storage policy.
• Exactly-once execution or delivery guarantees. The system retains at-least-once scheduling with explicit downstream idempotency.
• Public Process Run cancellation, pause, priority, scheduling, streaming output or caller-selected retry policy.
• Public Process Run list/search, Attempt details or Webhook Endpoint self-management.
• Putting gateway shared secrets, database/Redis credentials or Queue configuration into browser requests.
• Adding PostgreSQL or Redis containers to the standard production Compose.
• Automatically promoting traffic to canary or production without the Runbook gates and an authorized operator.
• Running paid FAL/OSS smoke in ordinary pull-request CI.
• Changing the 300-second client wait default or the existing server Process execution timeout as part of this specification.

Further Notes

• This specification follows the delivered console work tracked in 运维控制台可溯源化：活动 trace 持久化、PostgreSQL 记录存储、服务自描述与 Preact 重写 #1. That earlier scope explicitly left asynchronous Process Run enablement out of scope; this Issue closes that next layer rather than reopening the Run Record design.
• “Complete integration” currently means real local PostgreSQL/Redis plus independently constructed API, Dispatcher and Worker roles with a controlled Business Capability. It does not mean a real browser, production gateway, production deployment or paid image provider. Completion of this Issue must keep those claims distinct.
• The server Async Process Runs Module is already deep: its small submit/find Interface hides Registration acceptance, owner isolation, idempotency, persistence and projection. The design target is to create comparable Depth and Locality on the browser side, not to flatten server Modules into the console.
• The standard synchronous deployment remains the safe default. The explicit async deployment shape exists to make release intent visible, reviewable and reversible.
• Any production rollout must follow internal → canary → production, preserve query access during rollback and record operational evidence required by the existing async Runbook.

[techidsk]

2026-08-14 继续实施状态（本地候选 b3835f1，尚未推送）：

本地代码、确定性门禁和真实依赖闭环已经完成，包括 Console 深 Client、刷新/幂等恢复、300 秒查询、真实 PostgreSQL/Redis/API/Dispatcher/Worker、浏览器验收、异步发布/故障演练/提升/付费 smoke workflow，以及异步 Worker 到 Console Run Observation 的终态与活动溯源。最新全量验证为 635 tests、check、typecheck、build 通过；真实闭环为 Store 26、Observation 25、BullMQ/Worker 9、headless Chrome 1；最终 Standards/Spec 双轴复审无 findings。

本 Issue 仍保持 OPEN，因为规格要求的生产闭环证据尚不存在：本地分支领先 origin/main 19 个提交；远端只配置了 production Environment，未注册本地新增 workflows 所需的 async-internal、async-staging、async-canary、async-production、async-paid-smoke 和 console-production-readiness；尚未执行同 revision internal → canary → production 门禁、真实网关 smoke、备份恢复 readiness 或付费 FAL/finalizer/OSS 旅程。以上需要推送授权、受保护环境/凭证配置、生产变更批准与逐次费用批准，不能用本地模拟证据替代。

[techidsk]

2026-08-15 生产推进记录：

• 最新候选为 5b3bd56935a788e948131f05fb7ec0aaba3d0ed8。CI run 31862539256 的构建、635 项测试、异步真实依赖 acceptance 与 release artifact 均成功。
• CI 发现并修复了 Linux EXIT trap 中异步旧形状回滚成功却误记为失败的问题；Linux/amd64 5 个部署脚本用例、本地全量门禁及 Standards/Spec 复核均通过。
• 已创建 async-internal、async-staging、async-canary、async-production、async-paid-smoke 与 console-production-readiness 六个 Environment；均配置 required reviewer 和仅 main 的 deployment branch policy。
• 没有触发 Async internal release：真实 HTTPS gateway、两个 caller 凭证、受控请求、Queue identity、服务器五角色 Secret、已复核 backup ID 尚未形成完整可信输入。没有用占位值绕过门禁。
• 默认生产部署在缺失 CONSOLE_PUBLIC_URL 时于上传前停止，因此候选尚未部署。

下一步仍是受保护网关、数据库/备份 readiness、候选 internal release、真实网关 smoke、三项 staging drill 与逐级 canary/production promotion。本 Issue 保持 OPEN，当前不声称生产异步闭环完成。

[techidsk]

生产闭环进展（2026-08-15）：

• 候选 fd950f6 的 deterministic gates、生产镜像构建和异步 durable acceptance 全部通过：https://github.com/hkai-ai/pipipi/actions/runs/31863161863
• 部署在任何 release 上传前因缺少 Console 网关前置条件安全停止，未修改线上容器。
• 当前活动 revision 712b25fef1e48ad08145e6027680ee3a5766f69c 的受保护只读审计产出 artifact，失败阶段为 database_audit：https://github.com/hkai-ai/pipipi/actions/runs/31863177971
• 失败取证修复已随 fd950f6 推送到 origin/main 与 personal/main。

剩余闭环不是应用逻辑，而是生产基础设施：正式 HTTPS Console 域名、受限 PostgreSQL/TLS、真实备份恢复证据，然后才能按 internal → staging → canary → production 提升。故本 issue 暂不关闭。

[techidsk]

2026-08-15 生产数据库边界取证更新：

• 已提交并双远端同步三个只读诊断增量：9f81ca7（稳定 TLS 失败分类）、79d9b08（区分客户端与 PostgreSQL 后端两跳 TLS）、6393036（验证同主机后端端口直连与数据库实例身份）。全部经过 Standards/Spec 双复核；最新全量为 715 tests passed、65 skipped，check/typecheck/build 通过。
• 受保护只读 run 31884331356 成功，未执行 DDL/DCL、未改 .env、未重启容器：https://github.com/hkai-ai/pipipi/actions/runs/31884331356
• 脱敏证据确认：应用到 DATABASE_URL 端点的固定 CA TLS 可用；该端点到 PostgreSQL 后端的入站连接不是 TLS；当前仍是超级用户登录后 SET ROLE，存在管理权限、其他数据库访问和角色成员关系；有效应用角色不能直登。
• 连接目标端口与 PostgreSQL 报告的后端端口相同，且同一目标主机没有通过“两跳 TLS + 相同 instance identity”验证的替代直连入口。因此不能通过仓库或应用服务器安全地猜一个直连端口修复；下一步需要在实际数据库服务/代理管理面启用 proxy→PostgreSQL TLS 或提供直连 TLS endpoint，并配置应用专用登录角色凭证。

在该基础设施边界修复前，生产部署门禁会继续安全失败，本 Issue 保持 OPEN；没有降低 audit 标准，也没有启用异步流量。

[techidsk]

生产异步前置只读检查已执行： https://github.com/hkai-ai/pipipi/actions/runs/31885686592

结果（artifact 不含 URL、Secret 或摘要）：

• active revision 712b25fef1e48ad08145e6027680ee3a5766f69c 的主 API 与内部 Business API 正在运行，异步入口关闭，四个异步后台容器不存在；
• candidate ebe68b8a19d149f212efcafeffd11fcff9a6a15d 的不可变镜像存在；
• PostgreSQL CA 文件存在；
• async-api.env、process-dispatcher.env、process-worker.env、webhook-worker.env、retention-cleaner.env 五份角色文件全部不存在；
• 因此前置证据中的 database URL consistency、Redis URL consistency/TLS、gateway/webhook Secret shape 与五角色 production preflight 均为 false。

本次检查没有执行 migration、没有连接 PostgreSQL/Redis/模型、没有启动或替换生产服务容器。下一步需要先通过受保护渠道配置五份最小角色 env 和批准的 rediss:// Redis；数据库代理后端 TLS/专用角色问题仍须由数据库提供方或代理管理面修复，不能从应用服务器安全猜测。

[techidsk]

已提交并双远端推送异步生产角色环境 provisioning：2b18e2230a0770370e1db51d3652e074e34fce34。

新增受保护的 Async production environment provisioning 手动入口，支持 plan/apply、五份最小权限 0600 角色环境、候选不可变镜像预检、部署锁、.env 漂移检测、失败回滚和严格脱敏 evidence。双轴 review PASS；完整门禁 747 passed / 65 skipped，check、typecheck、build 均通过。

当前 async-internal Environment 尚未配置以下两个必需 Secret，因此没有冒用现有 superuser/plaintext 数据库连接，也没有伪造 Redis：

• ASYNC_DATABASE_URL：专用非管理员 PostgreSQL URL，固定 CA，uselibpqcompat=true&sslmode=verify-ca&sslrootcert=/etc/pipipi/pg-server.crt
• ASYNC_REDIS_URL：批准的带密码 rediss:// URL

两个值就绪后下一步依次执行 provisioning plan、人工批准、apply、只读 prerequisites inspection，再进入 migration/readiness/备份恢复和 pi.ganjiuwanshi.com 的真实异步成功/业务失败闭环。此次提交自动触发的同步 Production CI/CD run 31887613886 已取消，避免在已知数据库边界未满足时误发布。

[techidsk]

继续执行后的生产输入审计：

• 已把 ASYNC_INTERNAL_GATEWAY_BASE_URL=https://pi.ganjiuwanshi.com 写入受保护 async-internal Environment。
• 已把 PAID_ASYNC_GATEWAY_URL=https://pi.ganjiuwanshi.com 写入受保护 async-paid-smoke Environment；未触发付费请求。
• 公网只读探测：/healthz 200、/readyz 200、/console 401（认证边界正常）、当前同步形状下 /process-runs 404（尚未启用异步入口）。

完整 internal 闭环仍缺下列受保护输入，当前 Environment Secret 列表为空，不能从仓库安全推导：

1. ASYNC_DATABASE_URL：专用非管理员、固定 CA、数据库后端链路也满足 TLS 的连接。
2. ASYNC_REDIS_URL：批准的带密码 rediss:// 连接。
3. ASYNC_INTERNAL_CALLER_A_AUTHORIZATION 与 ASYNC_INTERNAL_CALLER_B_AUTHORIZATION：真实网关中的两个不同主体；网关必须删除伪造内部头并注入稳定 caller 与服务器共享 token。
4. ASYNC_INTERNAL_SUCCESS_REQUEST 与 ASYNC_INTERNAL_FAILURE_REQUEST：生产 catalog 中受控成功请求和稳定 DEPENDENCY_FAILURE 请求。
5. 已复核、签名并完成恢复验证的 PostgreSQL backup ID/evidence。

这些值到位前继续运行 release/smoke 只会制造假证据或使用错误权限，因此保持 fail closed。域名类非秘密配置已由自动化消除，不再是阻塞项。