direxio-deployer 0.1.0

package/references/bug-history.md

@@ -0,0 +1,78 @@
+# 踩坑记录(按修复 PR 归类)
+
+部署链路上所有真实踩过的坑。**已全部修进 `scripts/` 下的部署文件**,新部署不会再撞;
+列在这里是为了:① 理解每个设计决策的来由;② 若有人改坏了哪处,能快速定位回退点。
+
+## p2p-matrix-as 仓库
+
+### AS PR #4 — 镜像多架构
+- **症状**:ARM 架构 EC2(t4g 系列)`docker pull` 后 `exec format error`。
+- **根因**:镜像只 build 了 amd64。
+- **修复**:CI 用 buildx 出 `amd64+arm64` 多架构镜像。`xuyanzu01/p2p-im-as:latest` 已是多架构。
+
+### AS PR #5 — 容器化体验
+- **卷权限**:命名卷默认 root:700,AS 降权到 asd(UID 10001)后打不开 sqlite → `SQLITE_CANTOPEN`。
+  修复:entrypoint chown `/opt/p2p` `/data` 后再 `su-exec asd`。
+- **无健康检查**:compose 无法判断 AS 就绪。修复:Dockerfile 加 `HEALTHCHECK` 探 `:9090/healthz`。
+- **registration 路径写死**:registration.yaml 落在 cwd 不可配。修复:加 `RegistrationPath` 配置项。
+
+### AS PR #5 遗留 — GHA 缓存(⚠️ 未合主干)
+- **症状**:长时 arm64 build 时 Azure cache 的 SAS token 过期 → `403 AuthenticationFailed`,CI 失败。
+- **影响**:**只影响"重新打 AS 镜像"**;部署默认用已发布的 public 镜像,不打包就不踩。
+- **状态**:提交过 cache-disable 修复,但没进 PR #5 的 squash-merge。**待补一个独立 PR。**
+
+## 部署脚本
+
+### ops PR #2 — 一键部署主体
+依次撞过、已全部修掉:
+1. **docker compose 插件不在 Amazon Linux**(且早期下错架构 x86 装到 ARM)→ 改用 `get.docker.com` 装,自带 compose v2。
+2. **asd.yaml chmod 600** 让容器内 asd 读不到 → cloud-init write_files 用 0600 但属主对。
+3. **Dendrite SQLite broken**(element-hq/dendrite#3435,`near "SEQUENCE" syntax error`)→ 加 `postgres:16-alpine`,Dendrite 连 PG。
+4. **Caddyfile `email {$ACME_EMAIL}` 为空** → `wrong argument count`。修复:删掉默认 email 块,Caddy 自动签不需要 email。
+5. **Dendrite 启动早于 AS 写 registration** → 竞态。修复:compose `depends_on: asd service_healthy` + `postgres service_healthy`。
+6. **旧 init-tokens.sh 经 Caddy 308 跳转** → HTTP 初始化失败。当前流程已移除该接口调用,改为等 AS 写 `/opt/p2p/bootstrap.json`。
+7. **init-tokens.sh CRLF** → `pipefail: invalid option name`。修复:文件存为 LF(`sed -i 's/\r$//'`)。
+
+### ops PR #3 — owner.json 发现
+- **症状**:client 探 `/.well-known/portal/owner.json` 得 404 → 误报 "Portal 未部署"。
+- **根因**:AS 不自带 owner.json 的 HTTP handler;它把文件写到 wellknown 卷,需 Caddy 静态 serve。
+- **修复**:
+  - asd.yaml:`wellknown.output_dir: /opt/p2p/wellknown`(宿主 `/opt/p2p` 共享目录子目录)。
+  - Caddyfile:`handle_path /.well-known/portal/*` → `root * /srv/wellknown/wellknown` → `file_server`。
+  - compose:caddy 挂 `/opt/p2p:/srv/wellknown:ro` 读同一份。
+- **后续发现**:Web client 从本地 dev origin 读 owner.json 时,HTTP 200 但缺 CORS 会被浏览器拦截,表现为 `net::ERR_FAILED 200 (OK)`。修复:Caddy 的 portal well-known handler 加 `Access-Control-Allow-Origin *`,S7 同步校验响应头。
+
+### ops VoIP — 通话连不上 = 没 TURN relay
+- **症状**:语音/视频通话信令(`m.call.*`)互通,但 WebRTC 连不上;`/_matrix/client/v3/voip/turnServer` 返回 `{}`,ICE 只有 host/srflx 无 relay → 跨 NAT/防火墙必失败。**纯后端缺口,非前端。**
+- **修复**(第一版明文 turn:3478,不上 TLS):
+  - compose 加 `coturn`(`network_mode: host` + `--use-auth-secret` + `--static-auth-secret=${TURN_SECRET}` + `--external-ip=${PUBLIC_IP}` + `--min/max-port 49160-49200`)。
+  - s3 安全组开 `3478 udp/tcp` + `49160-49200/udp`。
+  - user-data 从 IMDS public-ipv4 落 `PUBLIC_IP`,随机生成 `TURN_SECRET`,都写进 .env。
+  - dendrite entrypoint 追加 `client_api.turn`(`turn_shared_secret` 同 TURN_SECRET + `turn_uris` turn:DOMAIN:3478 udp/tcp)→ homeserver 动态签短期凭证。
+  - S7 加 turnServer 非空校验。
+- **重部署勿删**:coturn/端口/turn 段已固化进 skill;后续简化部署时不要删,否则铲掉重起会再丢通话能力。
+- **难查点**:Dendrite 的 `turn_shared_secret` 必须 == coturn `--static-auth-secret`(都来自 .env `TURN_SECRET`),不一致 → turnServer 返回凭证但 relay 拒绝。详见 `voip-turn-runbook.md`。
+
+## 机型/内存类
+- **机型默认 t3.small(2GB)**:postgres + dendrite + asd + caddy 四容器同机,2GB 实测能稳跑,不靠 swap。
+  想更省钱可换 t3.micro(1GB),但 1GB 跑 4 容器 + 首次拉镜像易 OOM,届时需在 cloud-init 装 Docker 前
+  自配 2GB swap(`/swapfile`,`vm.swappiness=10`)兜底。默认不开,避免无谓复杂度。
+- **架构固定 x86/amd64**:状态机 S3 的 AMI 锁 `.../amd64/...`,机型默认 t3.small,**不走 ARM**——
+  规避 AS PR #4 那类"单架构镜像在 ARM 上 `exec format error`"的坑(虽然现镜像已多架构,x86 更省心)。
+
+## 真·全新账号 + macOS 端到端实测踩坑(2026-06-01,已全部修)
+这批来自一次真实"干净 macOS + 全新 AWS 账号"跑 skill 的实测,是之前没做过的端到端验证:
+- **macOS 默认 bash 3.2 不支持 `declare -A`**:`orchestrate.sh` 一启动就崩。修:阶段→脚本映射改用 `case`(`phase_file()`),不再用关联数组。
+- **S0 只认 AK/SK,本机有 `AWS_PROFILE` 也误判"没凭证"**:修:直接 `aws sts get-caller-identity` 判断凭证有效性(支持 profile/AK/SK/角色),仅在 sts 失败且既无 AK/SK 也无 AWS_PROFILE 时才算等用户。
+- **user-data 超 16384 字节硬上限**:三份部署文件各自 base64 内联会超限,AWS 报 `User data is limited to 16384 bytes`。修:打成一个 `bundle.tar.gz` 单条内联,开机 runcmd 第一步解包到 `/opt/p2p`。实测降到 ~11KB。
+- **AS 读不到 `asd.yaml`(`permission denied`)**:把只读配置叠挂进 `/opt/p2p` 与降权用户 cwd 冲突。修:`asd.yaml` 改挂 `/etc/p2p/asd.yaml`,`--config` 指向新路径;`/opt/p2p` 只作共享运行输出目录。
+- **EC2 自带 `*.compute.amazonaws.com` 签不了 Let's Encrypt**(`rejectedIdentifier`)。历史修复曾给验收/试用流程加过 `<公网IP>.sslip.io` 临时域名,用于绕过 EC2 默认域名不能签证书的问题。当前正式部署接口已经移除该路径:没有最终域名时 S2 直接阻断,不创建 EC2;Matrix `server_name` 必须使用用户长期持有并能管理 DNS 的正式域名。
+- **宿主机读不到凭据文件**:AS 在容器内写 `/opt/p2p/bootstrap.json`,若 compose 未 bind mount `/opt/p2p`,本机 S5 无法从 EC2 读取。修:`asd` 挂 `/opt/p2p:/opt/p2p`,S5 用 `ssh ... sudo cat /opt/p2p/bootstrap.json`。
+- **旧 HTTP 初始化抢跑 Dendrite**:早期脚本主动发初始化请求,Dendrite 没 ready 时会返回 500,但脚本可能误判成功。当前流程已移除主动初始化请求,由 AS 启动成功后自行写 `bootstrap.json`;`init-tokens.sh` 只等待文件完整,失败即不写 `.deploy-done`,状态机如实反映失败。
+- **(client 侧,不在本仓库)** `/_as/auth` 返回容器内网 `http://dendrite:8008`,App 在用户机访问不到 → 前端遇到 `dendrite` 这类内部 host 时回退到用户输入的公网 Portal 地址。
+
+## 机型/内存类(承上)
+
+## 本机/环境类(不在仓库,属操作经验)
+- **本地代理截断 AWS/lark 的 TLS**:AWS 公共前置已 `export NO_PROXY="*"` 并 unset 代理。lark-cli 用 `LARK_CLI_NO_PROXY=1`。
+- **PowerShell 生成 SSH key 时 `-N '""'`** 把字面 `"` 当密码 → 加密私钥登录失败。正确:`-N ''`(单引号空)。

package/references/deployment-lessons.md

@@ -0,0 +1,218 @@
+# Deployment Lessons From im2.jkmf.top
+
+This note captures operational lessons from the production deployment of
+`im2.jkmf.top` on AWS from a Windows workstation. Keep it short and practical:
+symptom, cause, and what the next operator or agent should do.
+
+## AS Bootstrap Initialization
+
+Symptom:
+
+```text
+S5_INIT_TOKENS failed: read bootstrap.json timed out
+/opt/p2p/bootstrap.json was missing or incomplete
+```
+
+Cause:
+
+Current `p2p-matrix-as` builds initialize on service startup and write
+`/opt/p2p/bootstrap.json` with the login `password`, `agent_token`, and owner
+metadata. Calling the old bootstrap HTTP endpoint or scraping logs is no longer
+part of the deploy path.
+
+Fix now in ops:
+
+- Cloud-side `scripts/cloud-init/init-tokens.sh` waits for AS `/healthz` and
+  the credentials file.
+- `docker-compose.yml` bind-mounts host `/opt/p2p` into the AS container so the
+  file is readable from the EC2 host.
+- Local S5 reads the file with `ssh ... sudo cat /opt/p2p/bootstrap.json`,
+  normalizes it into local `outputs.json`, and stores `password`/`agent_token`
+  in state.
+
+## Windows Runtime Pitfalls
+
+Do not hard-code a Git Bash path. Different machines install Git/MSYS/Cygwin in
+different locations, and WSL may or may not be configured.
+
+Use a POSIX shell that actually runs the deployment scripts:
+
+```powershell
+Get-Command bash.exe -All
+bash -lc 'echo ok; command -v aws; command -v jq; command -v ssh; command -v scp; command -v curl'
+```
+
+If `bash` prints the Windows Subsystem for Linux installation prompt or exits
+before running `echo ok`, it is only the Windows WSL launcher and cannot run ops
+until a WSL distro is installed. Use another POSIX shell such as Git Bash, MSYS2,
+Cygwin, or a working WSL distro.
+
+The orchestrator now prepends workspace-local `.tools/bin` when present. This
+directory is an optional local tool cache that may be downloaded by the operator
+or system; it is not assumed to come from the original repo or from the skill.
+When `.tools/bin/jq.exe` exists, compatible Windows POSIX shells can discover it
+without manual PATH surgery.
+
+Prefer the `ssh`/`scp` that belongs to the same POSIX environment used for
+`bash`. Windows OpenSSH can reject EC2 private keys because inherited ACLs make
+the `.pem` look too open, even when Git/MSYS OpenSSH accepts it. If using Windows
+OpenSSH directly, fix the key ACL instead of disabling SSH checks.
+
+## Local Polling Can Hang While The Server Is Healthy
+
+Symptom:
+
+- `state.json` stays at `S4_BOOTSTRAP_STACK=polling`.
+- `https://<domain>/healthz` returns `{"status":"ok"}` from another shell.
+- A leftover local `curl -skf https://<domain>/healthz` or SSH child process is
+  still running after the agent/operator interrupted the deployment turn.
+
+Cause:
+
+The cloud side may have completed successfully, but a local network call can
+hang long enough that the state machine never records the successful phase. This
+is especially confusing on Windows when proxy settings, direct TCP reachability,
+or interrupted terminal sessions leave child processes behind.
+
+Fix now in ops:
+
+- S4 health checks use per-attempt curl timeouts:
+  `HEALTH_CURL_CONNECT_TIMEOUT` and `HEALTH_CURL_MAX_TIME`.
+- S5 SSH reads use non-interactive SSH options plus `SSH_COMMAND_TIMEOUT` when
+  the local `timeout` command is available.
+- If a deployment was interrupted, inspect `scripts/orchestrate.sh status`,
+  stop only leftover local `orchestrate.sh`/`curl`/`ssh` children for that run,
+  and resume with `P2P_EXISTING_STATE_ACTION=continue`.
+- If SSH to the instance is blocked but AWS access still works, attach a
+  temporary SSM role and use SSM Run Command to read `/opt/p2p/bootstrap.json`
+  without printing secrets. Remove or audit the temporary role after recovery.
+
+## DNS And State Handling
+
+For `DOMAIN_MODE=user`, S3 intentionally stops after allocating the EIP and waits
+until the real DNS A record points at that EIP. Continue only after public DNS
+resolves correctly. This avoids Caddy and Let's Encrypt racing DNS propagation.
+
+When rerunning after a resource was created, set:
+
+```bash
+P2P_EXISTING_STATE_ACTION=continue
+```
+
+This is deliberate. It prevents accidental duplicate EC2/EIP creation or unsafe
+reuse of an old deployment state.
+
+## Credential Safety
+
+Prefer a temporary `DirexioDeployer` IAM user or dedicated IAM role for routine
+deployment. Root access keys are allowed when the operator explicitly chooses
+them; report that the identity is root and remind the operator to rotate or
+remove the key when it is no longer needed.
+
+Do not store AWS AK/SK in skill files, docs, or committed repo files. Treat
+`state.json`, `outputs.json`, and `~/.direxio/nodes/<service_id>/credentials.json` as local
+secrets because they contain the portal/agent token after S5.
+
+## Route53 Delegation From Third-Party Registrar
+
+Symptom:
+
+- User chose `DOMAIN_MODE=route53` but the domain is registered at Alibaba Cloud / GoDaddy / Cloudflare (not AWS Route53 registrar).
+- S3 creates or reuses a Route53 hosted zone and upserts the A record, but public
+  DNS still does not resolve to the new IP.
+
+Cause:
+
+S3 can create the Route53 hosted zone, but Route53 does not become
+authoritative until the current registrar delegates the zone's NS records. When
+the domain administrator is a third party, the user or a provider-specific DNS
+connector must update NS delegation outside AWS.
+
+Fix procedure:
+
+1. Read the created or reused zone details from `state.json`:
+   ```bash
+   jq '.resources | {route53_zone_id, route53_zone_name, route53_name_servers}' ~/.direxio/nodes/<service_id>/state.json
+   ```
+2. Delegate those NS servers at the current registrar, or use the provider API
+   if credentials are available.
+3. Wait for authoritative NS and A-record propagation.
+4. Re-run `scripts/orchestrate.sh` with `P2P_EXISTING_STATE_ACTION=continue`.
+
+DNS propagation of new NS records can take minutes to hours. After the user
+confirms the change, verify with `nslookup -type=NS <DOMAIN>` or
+`dig NS <DOMAIN> +short`. The S3 phase's `_require_user_dns_ready()` will
+handle the A-record wait loop.
+
+Always report:
+
+- App domain and eight-digit app initialization code, with the code sourced from the backend `password` field.
+- Portal token or where it was written.
+- `~/.direxio/nodes/<service_id>/credentials.json` status and profile shape.
+- AWS region, EC2 instance ID, public IP, security group, state path, SSH command.
+- Stop-billing guidance: ask the agent to destroy this node when finished; AWS resources keep billing until teardown completes.
+- Any manual DNS record the user owns outside Route53.
+
+## Let's Encrypt Certificate Rate Limits
+
+Symptom:
+
+- S4_BOOTSTRAP_STACK health check times out after 5-10 minutes.
+- SSH reveals all containers are up and healthy (caddy, message-server, postgres, coturn).
+- `docker logs p2p-caddy-1` shows repeated errors:
+
+  ```
+  HTTP 429 urn:ietf:params:acme:error:rateLimited - too many certificates (5)
+  already issued for this exact set of identifiers in the last 168h0m0s,
+  retry after ...
+  ```
+
+Cause: Let's Encrypt allows at most 5 certificates per domain per 168 hours (7 days). Redeploying the same domain repeatedly within a week exhausts this quota.
+
+Workaround (use when the health check is the only blocker and the rate limit is temporary):
+
+1. **Add `tls internal` to the Caddyfile** so Caddy uses its built-in CA (self-signed). The directive goes on the line after the site block opener.
+
+2. Write the modified Caddyfile to the remote host. Use base64+SSH to avoid shell escaping issues:
+   ```bash
+   echo '<base64-encoded-caddyfile>' | base64 -d | sudo tee /opt/p2p/Caddyfile
+   sudo docker compose -f /opt/p2p/docker-compose.yml restart caddy
+   ```
+
+3. Wait 5 seconds, then verify HTTPS works:
+   ```bash
+   curl -sk --resolve <domain>:443:<EIP> https://<domain>/healthz
+   # Expected: {"status":"ok"}
+   ```
+
+4. Resume orchestrate.sh with:
+   ```bash
+   P2P_EXISTING_STATE_ACTION=continue bash scripts/orchestrate.sh
+   ```
+
+5. **After deployment completes**, restore the original Caddyfile (remove `tls internal`) and restart Caddy. Caddy will retry the production Let's Encrypt cert when the rate limit resets. The self-signed cert is a temporary bridge; HTTPS will show a browser warning until the production cert is obtained.
+
+Prevention:
+
+- Use a separate subdomain per deployment cycle (e.g. `__DOMAIN_A__`, `__DOMAIN_B__`) when doing repeated test deployments within 7 days.
+- Preserve the old `caddy-data` Docker volume on redeploy to carry forward the existing certificate.
+
+## Route53 Duplicate Zone Detection
+
+Symptom: A new hosted zone was created via `aws route53 create-hosted-zone` for a domain that already had a Route53 zone from a prior deployment. The NS records of the new zone do not match the NS records configured at the registrar, so DNS resolution still uses the old zone's servers.
+
+Fix:
+
+1. List all existing zones first: `aws route53 list-hosted-zones --query 'HostedZones[*].[Name,Id]'`
+2. Check which zone's NS servers match DNS: `nslookup -type=NS <domain>`
+3. If the domain is already delegated to Route53, use the matching existing zone.
+4. Delete the duplicate: `aws route53 delete-hosted-zone --id /hostedzone/<DUPLICATE_ID>`
+
+Prevention:
+
+- Before deployment, check for existing zones. If one exists and its NS records
+  match current DNS delegation, no new zone is needed; S3 will reuse it.
+- Let S3 create a new hosted zone only when deploying a domain with no matching
+  Route53 zone or when migrating DNS delegation for the first time.
+- Destroy attempts to delete hosted zones recorded as created by the deployer;
+  user-owned or pre-existing zones are retained.

package/references/deployment-optimization-audit.md

@@ -0,0 +1,317 @@
+# Deployment Optimization Audit
+
+This file maps the 2026-06-26 deployment discussion checklist to the current
+`direxio-deployer` branch. It is intentionally a deployer-side audit, not a
+claim that every App or host-agent runtime has been proven in a real session.
+
+## Status Legend
+
+- Deployer-side implemented: implemented or guarded in this repository with
+  scripts, docs, and regression tests.
+- Runtime evidence still required: this repository can prepare or check the
+  condition, but a real App, Codex, OpenClaw, Hermes, or MCP runtime must still
+  provide final evidence.
+- Deferred by design: not part of the current EC2 MVP path.
+
+## Current Best Plan
+
+Current best plan is the stricter plan now encoded in this branch:
+
+1. Keep one EC2 MVP path first, with `t3.small` default, dynamic cost estimate,
+   Route53 automation, temporary IAM user guidance, and destroy evidence.
+2. Keep all node-local deployment state under `~/.direxio/nodes/<service_id>/`.
+   Do not mutate global host MCP configs or assume one computer has only one
+   agent or one backend node.
+3. Treat S7 as automated foundation checks only. `verify runtime is an internal
+   non-polluting check`; it is not enough to declare the product complete.
+4. Require explicit user App initialization and real chat evidence before user
+   gates can be confirmed.
+5. Keep Agent/MCP validation non-polluting by default, then let the user decide
+   whether to send a real message in the Agent chat box.
+6. Keep update/reset/destroy as separate operations with separate receipts;
+   update/reset are now first-class scripts, not runbook-only manual actions.
+7. Treat update/reset follow-up as a Local refresh state: update/reset cleared
+   old credentials, user confirmations, runtime checks, and bridge install
+   proof, so the next action is to rerun S4-S7 and runtime checks.
+8. Keep Lightsail out of the current user-facing path. Lightsail remains
+   deferred until it has an independent resource model, pricing, state,
+   destroy, and test matrix.
+
+Audit anchors:
+- verify runtime is an internal non-polluting check
+- user App initialization and real chat evidence
+- update/reset are now first-class scripts
+- Local refresh
+- Lightsail remains deferred
+
+## Requirement Mapping
+
+### DEPLOY-P0-001 - Do Not Declare Completion Early
+
+Status: Deployer-side implemented, with Runtime evidence still required.
+
+Current evidence:
+- `SKILL.md` defines Product Completion Gates and says S7 green is not final
+  product completion.
+- `scripts/orchestrate.sh confirm app_initialization|real_chat|agent_mcp_runtime`
+  requires explicit evidence and rejects short generic confirmations.
+- `tests/user_confirmation_gates_test.sh` and `tests/operation_report_test.sh`
+  assert pending gates and redacted evidence.
+
+Difference from the checklist:
+- The checklist asked for product gates. The current branch implements them as
+  state/report fields instead of a single "done" word.
+
+Remaining evidence:
+- Real user App initialization and real chat evidence.
+- Real selected runtime confirmation that service-scoped MCP tools loaded.
+
+### DEPLOY-P0-002 - OpenClaw Runtime Acceptance
+
+Status: Deployer-side implemented, with Runtime evidence still required.
+
+Current evidence:
+- Runtime snippets are written under `~/.direxio/nodes/<service_id>/mcp/`.
+- `verify mcp_doctor`, `verify mcp_tools`, `verify mcp_smoke`, and
+  `verify runtime` are available.
+- `mcp_smoke` uses a read-only backend action by default.
+- `agent_mcp_runtime` confirmation requires both a passed runtime summary and
+  `DIREXIO_CONFIRM_RUNTIME_PROBE=1`.
+
+Difference from the checklist:
+- The deployer does not auto-send a test chat message. That is deliberate:
+  internal probes are non-polluting, while user-visible chat proof stays a user
+  action.
+
+Remaining evidence:
+- A real OpenClaw/Hermes/Codex runtime must prove it loaded the exact
+  service-scoped MCP snippet and can use it.
+
+### DEPLOY-P0-003 - Cost And Destroy Loop
+
+Status: Deployer-side implemented.
+
+Current evidence:
+- `scripts/pricing-estimate.sh` records EC2, EBS, public IPv4/EIP, and Route53
+  estimate fields, with fallback status when AWS Pricing cannot answer.
+- `scripts/destroy.sh` reads AWS resources back and records `destroy.evidence`.
+- `operation-report.json` includes `billing.destroy_cleanup_status` and
+  `billing.possible_remaining_billable_resources`.
+- Tests reject old wording that attached public IPv4/EIP is free.
+
+Difference from the checklist:
+- The checklist asked for deploy and destroy receipts. The current branch adds
+  operation-scoped machine-readable reports so future agents can audit residue.
+
+Remaining evidence:
+- User should still review AWS Billing Console and AWS Budget status in the AWS
+  account, because credits, tax, transfer, and usage are account-specific.
+
+### DEPLOY-P0-004 - Domain And DNS Automation Protection
+
+Status: Deployer-side implemented, with external-provider limits.
+
+Current evidence:
+- Route53 hosted zone reuse/create is automated.
+- Existing A record overwrite is blocked unless
+  `DIREXIO_CONFIRM_DNS_OVERWRITE=1`.
+- Authoritative DNS checks and tests cover hosted-zone and overwrite behavior.
+
+Difference from the checklist:
+- The current MVP automates Route53. If the domain is managed by another DNS
+  provider without an available API or authorization, the correct state is
+  waiting for authorization, not pretending completion.
+
+Remaining evidence:
+- Third-party DNS providers still need provider-specific automation before they
+  can be treated like Route53.
+
+### DEPLOY-P0-005 - Authorization And Security Boundary
+
+Status: Deployer-side implemented.
+
+Current evidence:
+- `scripts/aws-credentials.sh import-csv|verify` imports local CSV credentials,
+  tightens file permissions, blocks root identity, and redacts identity output.
+- `SKILL.md` documents the temporary `DirexioDeployer` IAM user path with
+  temporary `AdministratorAccess`, then cleanup.
+- Reports and tests assert secrets are redacted and not written to reports.
+
+Difference from the checklist:
+- The current branch chooses the practical MVP path: temporary IAM admin user,
+  no root access keys, and cleanup guidance after deployment.
+
+Remaining evidence:
+- Long-term least-privilege IAM generation is still a future hardening task.
+
+### DEPLOY-P1-001 - Instance And Region Choice
+
+Status: Deployer-side implemented.
+
+Current evidence:
+- `SKILL.md` keeps the current MVP path as EC2 `t3.small` by default.
+- Pricing is region-aware where AWS Pricing lookup succeeds, otherwise marked
+  fallback.
+- Docs steer ordinary users away from `t2.micro`/`t3.micro` as default
+  production nodes.
+
+Difference from the checklist:
+- The current plan is simpler than a user choice matrix: recommend one default
+  path, then allow explicit upgrade when the user asks for heavier usage.
+
+Remaining evidence:
+- Region choice still depends on where the user and their contacts are.
+
+### DEPLOY-P1-002 - EC2 And Lightsail Path Separation
+
+Status: Deployer-side implemented for EC2 boundary, Deferred by design for
+Lightsail.
+
+Current evidence:
+- `SKILL.md` says the current MVP deployment path is EC2-only.
+- Tests reject wording that offers Lightsail as an implemented automatic path.
+
+Difference from the checklist:
+- No current script attempts to mix Lightsail into the EC2 state machine. That
+  is the safer plan.
+
+Remaining evidence:
+- A future `deploy_mode=lightsail` must have independent provision, DNS,
+  state, pricing, destroy, and tests before being offered.
+
+### DEPLOY-P1-003 - Recovery For Nontechnical Users
+
+Status: Deployer-side implemented.
+
+Current evidence:
+- `orchestrate.sh status` prints a recovery summary with phase, billing impact,
+  resume safety, next action, and stop-loss guidance.
+- `reset` warns that resetting state can lose destroy resource records.
+- Tests cover recovery output shape.
+
+Difference from the checklist:
+- The branch moves recovery language into the state command so it is available
+  during real interrupted deployments, not only in docs.
+
+Remaining evidence:
+- Real failures should still be reviewed after live deploy runs to improve
+  phase-specific wording.
+
+### DEPLOY-P1-004 - Operation-Specific Receipts
+
+Status: Deployer-side implemented.
+
+Current evidence:
+- `operation-report.json` supports `new_deploy`, `repair_or_verify`, `update`,
+  `reset_app_data`, and `destroy`.
+- `scripts/update.sh` updates an existing EC2 node without recreating infra or
+  deleting data volumes.
+- `scripts/reset-app-data.sh` clears application data only after strong
+  confirmation and preserves infra/TLS state.
+- `scripts/destroy.sh` records AWS cleanup evidence.
+
+Difference from the checklist:
+- The checklist said update/reset first-class scripts were still future work.
+  They are now present in this branch.
+
+Remaining evidence:
+- Live update/reset should be exercised against a disposable deployed node
+  before treating them as production-proven.
+
+### DEPLOY-P1-005 - Redeploy Token Refresh
+
+Status: Deployer-side implemented.
+
+Current evidence:
+- S5 refreshes bootstrap credentials from the server.
+- S6 rewrites service-scoped `credentials.json`, `env`, cc-connect config, and
+  MCP snippets.
+- Update/reset mark S4-S7 pending and report refresh-pending status.
+- Update/reset stops only the matching service-scoped direxio-connect daemon
+  when its `WorkDir` matches the current service, so stale local bridge
+  processes do not keep using old credentials.
+- `status` reports Local refresh when update/reset cleared old credentials, user confirmations, runtime checks, and bridge install proof.
+- Runtime checks fail closed when a stale service directory or wrong WorkDir is
+  detected.
+
+Difference from the checklist:
+- The current path is service-scoped by domain-derived service id, so multiple
+  nodes can coexist without global credential pollution.
+
+Remaining evidence:
+- If a real runtime reports 401/403 after reset, first verify it is using the
+  current service-scoped credential file before blaming the backend.
+
+### DEPLOY-P2-001 - Automated And Human Acceptance Layers
+
+Status: Deployer-side implemented, with Runtime evidence still required.
+
+Current evidence:
+- Delivery wording is "Automated Deployment Gates Passed", not final product
+  completion.
+- Reports keep automatic gates separate from user confirmation gates.
+- Runtime confirmation has an explicit stricter path.
+
+Difference from the checklist:
+- The better plan is a layered state model: automated gates passed, user
+  initialization pending, real chat pending, runtime confirmation pending.
+
+Remaining evidence:
+- Human confirmation is still required for App initialization and real chat.
+
+### DEPLOY-P2-002 - User Initialization And Message Loop
+
+Status: Deployer-side implemented for wording and gates, Runtime evidence still
+required for the App loop.
+
+Current evidence:
+- Docs and delivery call the user-facing value an eight-digit app
+  initialization code.
+- Old wording around direct IM login is rejected by structure tests.
+- `confirm app_initialization` and `confirm real_chat` record user evidence.
+
+Difference from the checklist:
+- The deployer can record and guard the App path, but the App itself must prove
+  the domain plus eight-digit code flow and message readback.
+
+Remaining evidence:
+- Real App or simulator evidence that initialization completes, a user message
+  is stored/synced, and the message can be read after refresh/restart.
+
+### DEPLOY-P2-003 - Agent Agents Room Loop
+
+Status: Deployer-side implemented for internal checks, Runtime evidence still
+required for user-visible chat.
+
+Current evidence:
+- Non-polluting MCP doctor, tools discovery, read-only smoke, and aggregate
+  runtime checks exist.
+- `real_chat` cannot be confirmed from internal non-polluting probes alone.
+- `agent_mcp_runtime` requires explicit runtime probe evidence.
+
+Difference from the checklist:
+- The user-facing proof stays simple: the user sends a message and sees the
+  agent reply. Internal gate details stay as agent diagnostics.
+
+Remaining evidence:
+- Real chat in the selected host runtime, using the current service-scoped
+  agent room and token.
+
+### DEPLOY-P2-004 - Call And TURN Acceptance
+
+Status: Deployer-side implemented for basic deployment acceptance.
+
+Current evidence:
+- S7 checks Matrix `turnServer` and requires non-empty valid TURN credentials.
+- Security group and compose include coturn ports and configuration.
+- `references/voip-turn-runbook.md` distinguishes basic deploy acceptance from
+  real media-call testing.
+
+Difference from the checklist:
+- The current branch keeps real voice/video calls out of the blocking deploy
+  gate. That is better because calls depend on devices, NAT, permissions, and
+  client behavior beyond server deployment.
+
+Remaining evidence:
+- Real device call testing belongs to a VoIP-specific test pass, not every
+  normal deployment.