dodo-mcp 1.2.0 → 1.3.0

package/docs/ARCHITECTURE.md

@@ -261,16 +261,20 @@ gateways Report ผูก revision, dataset, dependency lock, config และ h
 
 ## Tool surfaces
 
-- Complete capability catalog 138 individual definitions (Core 104 + Advanced Agent Runtime 17 + Sub-agents 4 + Android ADB 13)
-- Full live catalog ค่าเริ่มต้น 134 definitions; owner เปิด Sub-agent MCP exposure แล้วเป็น 138
+- Complete capability catalog 158 individual definitions (Core 104 + Advanced Agent Runtime 17 + Sub-agents 4 + Android ADB 13 + Source Recovery 10 + Deployment 10)
+- Full live catalog ค่าเริ่มต้น 154 definitions; owner เปิด Sub-agent MCP exposure แล้วเป็น 158
 - Compact catalog 20 definitions: overview, discover และ gateways รวม `dodo_mobile`
 - Hybrid catalog 49 definitions: compact core ตามด้วย direct tools
 
 `schemas/tools.json` เป็น complete full schema ส่วน compact และ hybrid เป็น schema แยก
 พร้อม metadata ของ optional feature ค่า `exposeSubagentsToMcp=false` จะกรองสี่
 Sub-agent definitions ออกจาก Full และกรองสี่ operation names ออกจาก gateway schemas,
-instructions และ `dodo_discover` ของ Compact/Hybrid โดยจำนวน gateway names ยังคง
-19/49 การเลือก surface หรือ feature exposure ไม่เปลี่ยน permission
+instructions และ `dodo_discover` ของ Compact/Hybrid โดยจำนวน tool definitions ยังคง
+20/49 การตั้งค่า `disabledDiscoverOperations` กรอง operation เพิ่มจาก discover และ
+gateway enum, ตัด Hybrid direct duplicate และไม่สร้าง gateway ที่ว่าง จึงทำให้ catalog
+runtime ต่ำกว่าค่าสูงสุดได้ Full direct catalog ไม่รับผลจากค่านี้ ทุก variant cache ด้วย
+canonical feature key และคำนวณ overview/stats จาก catalog ที่ serve จริง การเลือก
+surface หรือ feature exposure ไม่เปลี่ยน permission
 
 ## Personal และ managed access mode
 
@@ -369,3 +373,83 @@ Owner UI อยู่ `configUi/workbench.js/.css` ใช้ authenticated same-
 `aiAdmin.ts` บน private listener เท่านั้น CLI/advanced web controls ใช้ IPC dispatcher,
 setup/config validation ชุดเดิม ไม่มี secret fallback หรือการเปิด permission อัตโนมัติ
 รายละเอียด [ADR-045](adr/045-ai-providers-multiproject.md)
+
+## Journal write intent and owner recovery
+
+The applier uses one mutation lock for forward and inverse plans. The shared
+project queue also covers private owner rollback. Every original before-image is
+saved and verified before the first source write; sources are checked again
+after backup, before each syscall and before publication where applicable.
+Creation uses exclusive hard-link publication from a same-directory temporary
+file, preventing a late-arriving destination from being replaced. Modification
+uses atomic rename. Neither is a multi-file atomic transaction.
+
+Persisted journal states remain compatible: `pending` → `backed_up` → `written`
+(write intent, recorded **before** syscall) → `done` (verified after-state).
+A syscall can succeed without its next SQLite update succeeding. Compensation
+therefore examines every attempted step, including the currently failing one,
+and restores only a verified owned after-state from verified backups.
+
+A rollback creates a private inverse plan with reversed operation order and
+swapped before/after hashes. Its own backups contain pre-restore bytes.
+`journal-v2:<changesetId>` records direction/source linkage in the existing
+private metadata store; it grants no authority. Boot reconciliation verifies both
+ends of moves, current hashes and backup integrity, then finalizes bookkeeping
+in a transaction. All-before state is failed; mixed/unknown state is blocked for
+recovery. No source bytes are rewritten at startup.
+
+MCP rollback checks changeset ownership in the applier, so Full/Compact/agent
+paths cannot diverge. Authenticated owner administration exposes
+`recover.rollback` through the existing dispatcher, with strict arguments
+`changesetId`, `idempotencyKey`, `workspaceId`, `workspaceEpoch`. Web callers also
+send the selected project's reviewed context headers. The owner session is
+revalidated after queuing. This low-level operation is not a whole-project
+snapshot restore; the reviewed snapshot interface is described by ADR-052 below.
+
+Git staging now holds the real index lock while using a separate candidate
+index. A repository-wide, NUL-delimited staged-path inspection runs before and
+after staging, with relative-diff filtering disabled. Success publishes the
+candidate index only if the original still matches. Normal failure removes the
+candidate; uncertain commit outcomes retain it for owner inspection. No stash,
+reset, clean, remote push or private checkpoint commit is performed.
+
+## Source Recovery foundation
+
+Leased project runtimes own default-on scoped content snapshots, SQLite references
+and reservations, and a CAS independent of resource GC. Source mutations capture
+and verify before effects; protected async job startup holds the shared queue.
+See [ADR-051](adr/051-source-recovery-foundation.md). Reviewed session/restore flow: [ADR-052](adr/052-reviewed-source-restore.md).
+
+## Recovery R03
+
+`RecoveryDrift` persists expected manifests independently of snapshots. Applier advances expected entries inside the same transaction as final verified journal commit. Target writes compare hashes; commands scan the source scope; job termination observes changes before releasing its mutation ticket. Idle scans are bounded and coalesced. Private owner acknowledgement uses exact content digest + workspace/epoch and revalidates authority after asynchronous reads.
+
+`RecoveryGitCopies` builds independent bare repositories from verified CAS bytes, private indexes and create-only refs; it never stages or rewrites working Git. Optional owner-selected storage pins canonical directory identity. Git reservations/copies share recovery quotas; source retention prunes matching owned copies. Verification checkpoints require fresh owned verification evidence before publication. See [ADR 053](adr/053-content-drift-and-private-git-recovery.md).
+
+
+## Recovery R04
+
+RecoveryEvidence binds pre-run source manifests to existing verify_changes jobs and recipe digests. Live inspection checks the full Recovery source scope and current recipes/runtime; observed stale state is sticky. Safe evidence projections omit logs and environment values. Revisioned owner pointers, tombstones and audit events are separate from immutable manifests and execution permissions. Retention preview and prune use the same protected-reference calculation. The dashboard is bundled as ui/recovery.js. See [ADR 054](adr/054-verified-source-checkpoints.md).
+
+## deployment provenance
+
+`RecoveryDeployments` binds immutable plans to verified manifests, recipe evidence,
+project/epoch and owner target revisions. `DockerDeploymentAdapter` uses protected
+JobManager invocations, binary private spool and bounded sealed archives. Typed
+Docker argv never consumes repo Compose hooks. `DeploymentMaintenance` is private
+owner administration with durable preview hashes, re-observation and uncertain
+receipts; it is not an MCP definition. HTTP/CLI reuse the same service and live
+context checks. See [ADR 055](adr/055-reviewed-docker-deployments.md) and the
+[usage and limits](RECOVERY.md#reviewed-docker-deployment).
+
+## database/config recovery
+
+`RecoveryDatabases` adds owner-registered SQLite migration metadata and explicit
+manifest-bound compatibility rules. `RecoveryHistory` checks them at preview,
+apply and after the pre-restore checkpoint. No database mutation adapter is exposed.
+`RecoveryConfigVault` stores AEAD ciphertext and journaled redacted restore plans
+in separate private tables; `OSRecoveryKeys` stores only keys in OS credential
+providers. Owner IPC, HTTP and CLI share the same services/queue/context checks.
+Bundled `ui/dataRecovery.js` handles both opt-ins without changing MCP catalog or
+source-secret guards. See [ADR 056](adr/056-owner-data-recovery.md) and
+[usage/limits](RECOVERY.md#database-awareness-and-encrypted-private-config).

package/docs/CI.md

@@ -0,0 +1,118 @@
+# Native Linux และ Windows CI
+
+`platform-gates` ใช้ GitHub Actions บน self-hosted runners โดยตรง **ไม่ใช้ Docker**
+ทดสอบ Node 22 และ 24 ทั้งสองระบบ การ Online หมายถึงรับ job ได้ ยังไม่ใช่ผลทดสอบ PASS
+
+| Job | Runner labels | เริ่มเมื่อ |
+|---|---|---|
+| Linux native | self-hosted, Linux, X64, linux-ci | Run workflow เลือก linux/all |
+| Windows native | self-hosted, Windows, X64, windows-ci 02 | push main หรือ Run workflow เลือก windows/all |
+
+ไม่มี pull_request trigger สำหรับโค้ดที่ยังไม่ผ่านการตรวจ เพราะ self-hosted job
+ใช้สิทธิ์ OS ของบัญชี runner เลือกเฉพาะ ref ที่เจ้าของตรวจแล้ว GitHub token เป็น
+contents:read, checkout ไม่เก็บ credential และไม่มี npm publish step
+
+## สั่งรัน
+
+GitHub → Actions → platform-gates → Run workflow → เลือก branch และ platform
+หรือใช้ GitHub CLI ที่ login แล้ว:
+
+```sh
+gh workflow run platform-gates.yml --ref main -f platform=all
+gh run list --workflow platform-gates.yml --limit 5
+```
+
+โค้ดที่ยังไม่ commit/push ในเครื่องจะไม่อยู่ใน CI เลือกสาขาทดสอบที่ push แล้วได้ด้วย
+`--ref <reviewed-branch>` แทน main อย่านำผลคนละ revision มาอ้างแทนกัน
+
+เมื่อ full gate timeout ก่อนสร้าง JSON report สามารถเลือก `windows-diagnostics`
+พร้อม `evidence_run` เช่น `35496561994-1` เพื่ออ่านความคืบหน้าที่เก็บไว้บน runner
+ผลแสดงเฉพาะชื่อไฟล์ทดสอบที่อยู่ใน repo และตัวเลข ไม่ส่ง log ทั้งก้อนออกมา
+คำสั่งตรวจหลักฐานสำเร็จไม่ได้แปลว่า application tests ผ่าน
+
+`windows-focus` ใช้ Node 24 และ worker เดียว ทดสอบชุดที่เลือกใน `scripts/windows-focus.mjs`
+พร้อม native ACL preflight เพื่อวินิจฉัย Windows failures ผ่าน npm script `ci:windows:focus`
+ผลนี้ไม่แทน `windows` ซึ่งยังต้องรัน full gate ทั้ง Node 22/24 ก่อนรับรอง candidate
+
+## เตรียม Linux runner
+
+ใช้บัญชี non-root และต้องมี Git, Python 3, make, g++, ffmpeg, ffprobe และ espeak-ng
+ใน PATH Workflow ไม่ติดตั้ง system packages หรือแก้ permission เครื่องโดยอัตโนมัติ
+เจ้าของเตรียมรายการดังกล่าวด้วย package manager ของ Linux distribution ที่ใช้อยู่
+
+Workflow ใช้ `npm ci` และ Playwright รุ่นที่อยู่ใน lockfile เพื่อติดตั้ง Chromium
+จากนั้นเปิด headless Chromium ด้วย `chromiumSandbox:true` และถ่ายภาพ fixture จริง
+ก่อนรัน build/tests ต้องมี Chromium system libraries และ user namespaces/sandbox
+ที่ใช้งานได้ หากไม่พร้อมจะหยุดพร้อมข้อความ ไม่มีการใส่ `--no-sandbox` เพื่อให้ผ่าน
+ดู [Playwright CI requirements](https://playwright.dev/docs/ci) สำหรับ OS/libraries
+ที่รุ่นนั้นรองรับ โดยตรวจ Linux distribution ของ runner ก่อนเตรียมเครื่อง
+
+Media tests บน Linux ถูกบังคับด้วย `DODO_TEST_REQUIRE_LINUX_MEDIA=1`
+จึงไม่ข้าม speech/ffmpeg tests เพราะ dependency หาย
+
+## Windows: Online แต่ job ล้มก่อน step แรก
+
+หาก annotation มี `PowerShellPreAmpersandEscape` / `InitializeSecretMasker`
+และไม่มี steps เป็นอาการใน GitHub runner ที่รายงานกับ locale ภาษาไทย
+ยังไม่ได้ทดสอบ DODO ดู [actions/runner#4686](https://github.com/actions/runner/issues/4686)
+
+สำหรับ runner ที่เปิดด้วย `run.cmd`: หยุดหน้าต่างเดิมด้วย Ctrl+C แล้วเปิด PowerShell
+แบบ Administrator ใน **โฟลเดอร์ runner ที่ติดตั้งจริง** จากนั้นรัน:
+
+```powershell
+$env:DOTNET_SYSTEM_GLOBALIZATION_INVARIANT = "1"
+$env:DOTNET_SYSTEM_GLOBALIZATION_PREDEFINEDCULTURESONLY = "false"
+.\run.cmd
+```
+
+ค่ามีผลเฉพาะ process นี้ ไม่ใช่การเปลี่ยน locale ของเครื่อง เมื่อเปิดหน้าต่างใหม่ต้อง
+ตั้งอีกครั้ง Workflow คืน globalization ปกติให้ขั้นทดสอบ ไม่ใช้ workaround
+บังพฤติกรรม locale ของ DODO หาก runner รันเป็น service การตั้งค่าใน PowerShell
+อีกหน้าต่างจะไม่เปลี่ยน environment ของ service ต้องให้เจ้าของจัดการ service นั้น
+และอย่าเปิด runner ตัวเดียวกันซ้อนกันทั้ง service กับ run.cmd
+
+Windows gate ต้องใช้ enabled Administrator token เพื่อทดสอบ owner/DACL/reparse
+บน NTFS โดยไม่ลดข้อกำหนดของ security tests
+
+## หลักฐานและสถานะ
+
+Gate รัน build, typecheck, lint, full tests, packaging, DodoBench, production audit,
+immutable tarball และ fresh install โดยไม่เผยแพร่ npm
+`test:all` มีเวลา aggregate สูงสุด 60 นาทีบน Windows และ 30 นาทีบนระบบอื่น เพราะ
+native Windows มีต้นทุนตรวจ NTFS ACL และชุด Recovery เพิ่มขึ้น ไม่ลด assertions
+และ failure ใด ๆ ยังคงทำให้ gate ไม่ผ่าน ราย test/hook มีขอบเขตเวลาแยกกัน:
+ค่าเริ่มต้น 60 วินาที ส่วน scenario ที่ทำสำเนา Git/CAS หลายรอบของ 15 ไฟล์และตรวจ
+restore/replay ทั้งวงจรให้ 180 วินาทีบน Windows โดยคง deadline ของแต่ละ operation
+ผลละเอียดอยู่บน runner ใน `<runner-workspace>/.dodo-ci-evidence/<run-id>-<attempt>/<platform>-node-<major>/`
+นอก checkout เพื่อไม่ถูก checkout cleanup ลบ จึงไม่ push/pack การ rerun ใช้ directory
+ใหม่ ไม่เขียนทับ report เก่า Linux ย้ายสำเนา evidence แบบเก่าที่อยู่ใน checkout
+ออกไปก่อน cleanup หากยังมีอยู่ ไม่เขียนทับสำเนาที่มีแล้ว
+
+GitHub log/artifact รับเฉพาะ summary ที่เลือก scalar fields ไว้แล้ว ไม่อัปโหลด raw
+test output, keys หรือ state DB กรณี test fail แสดงเฉพาะ path ของ test ใน repo,
+ลำดับ assertion (เริ่มที่ 0), หมายเลขบรรทัด และชนิด failure ไม่แสดงชื่อ test,
+expected/actual values, ข้อความ error หรือ stack ของเครื่อง รายละเอียด probe
+ที่ fail เก็บไว้ให้เจ้าของอ่านบนเครื่อง สรุป failure ก่อนหน้าแสดง revision/run ID
+ชัดเจน ไม่ปะปนกับผลรอบปัจจุบัน
+
+- `AUTOMATED_PASS`: gate ของ revision/platform นั้นผ่านครบ
+- `AUTOMATED_FAIL`: gate ล้มเหลว ดู step/summary และ private evidence
+- ล้มก่อน step แรก: runner startup failure ไม่ใช่ผลทดสอบ application
+- `MANUAL_NOT_RUN`: ยังไม่ได้ทำ manual acceptance; CI ผ่านไม่เปลี่ยนสถานะนี้เอง
+
+Linux Docker evidence เดิมยังเป็นประวัติการทดสอบเดิม ไม่ใช้แทน native Linux CI
+ตามนโยบายปัจจุบัน Strict gate รวมได้เฉพาะ clean revision/lock/source fingerprint
+ตรงกัน และ Linux origin เป็น `github-actions-native`
+
+## Release evidence
+
+Strict release gate ต้องมี macOS, native Linux และ native Windows ที่ตรง version,
+clean revision, source fingerprint และ lockfile ไม่รับผล Docker แทน native CI
+ใช้ allowlisted summary จาก workflow ได้โดยไม่ต้องคัดลอก private logs ออกมา
+Windows รัน dedicated random-item Credential Manager fixture และลบเฉพาะ item นั้น
+Linux Secret Service บนเครื่อง headless ที่ไม่ได้เปิด fixture ยังคง NOT_RUN
+
+Fresh-install smoke เริ่ม server ใหม่ด้วย private fixture เดิมเพื่อตรวจ receipt และ
+stale epoch หาก Node fetch pool คืน socket ที่เพิ่งปิด จะ retry เฉพาะ JSON-RPC
+`initialize` เมื่อเป็น connection-reset/socket-close แบบจำกัดจำนวนครั้ง ไม่มีการ
+retry `tools/call`, คำสั่งที่มีผลข้างเคียง หรือ OAuth exchange โดยอัตโนมัติ

package/docs/COMPATIBILITY.md

@@ -29,10 +29,10 @@ Effectful tools และ jobs ยังทำงานใน active workspace
 ## Tool surfaces
 
 - HTTP default: Compact 20 tools
-- STDIO default: Full 134 tools; เปิด Sub-agent MCP exposure แล้วเป็น 138
+- STDIO default: Full 154 tools; เปิด Sub-agent MCP exposure แล้วเป็น 158
 - explicit Hybrid: 49 tools
 
-Complete capability schema มี 138 operations ค่าเริ่มต้น `exposeSubagentsToMcp=false`
+Complete capability schema มี 158 operations ค่าเริ่มต้น `exposeSubagentsToMcp=false`
 ซ่อน `subagent_spawn/status/result/control` จาก MCP เท่านั้น หน้าเว็บ Chat & Tasks ยัง
 ใช้ได้ Compact/Hybrid คงจำนวน 20/49 tool names แต่กรอง operation enum, instructions
 และ discover index ให้ตรงกับ live runtime หลังเปลี่ยนค่าต้อง restart และให้ client
@@ -95,10 +95,11 @@ Directory guard ไม่ใช่ OS sandbox, repository instructions ไม่
 ## Evaluation evidence
 
 DodoBench local fixture ใช้ยืนยัน contract บน platform/revision ที่ report ระบุเท่านั้น
-ผลของ macOS ไม่แทน Linux และ Linux Docker ไม่แทน Windows native Release gate ต้องมี
-หลักฐาน macOS local และ Linux Docker ที่ revision/lock digest ตรงกัน Docker image
-ติดตั้ง Playwright Chromium เพื่อรัน browser case จริง Dedicated self-hosted GitHub
-Actions รัน Linux Docker และ Windows native candidate เฉพาะ trusted main/manual
+ผลของ macOS ไม่แทน Linux และ Linux ไม่แทน Windows native Release gate ต้องมี
+หลักฐาน macOS local และ Linux native CI ที่ clean revision/source fingerprint/lock digest ตรงกัน
+Dedicated self-hosted GitHub Actions รัน Linux และ Windows โดยตรงบน Node 22/24
+ไม่ใช้ Docker; ตรวจ Chromium sandbox และ media dependencies บน Linux ก่อนรันทดสอบ
+Workflow รับเฉพาะ trusted main/manual ดู [CI](CI.md) สำหรับ prerequisites และการสั่งรัน
 Windows manual acceptance ยังคง `MANUAL_NOT_RUN` จนกว่าจะทดสอบบน Windows 11 จริง
 
 ## AI Providers / Multi-project

package/docs/EVALUATION.md

@@ -47,21 +47,21 @@ write → read → edit → read-back ผ่าน Compact gateway
 
 ## Platform gates
 
-macOS รันจาก owner checkout ส่วน Linux gate เดียวกันรันได้ทั้ง local Docker และ
-dedicated self-hosted GitHub Actions runner:
+macOS รันจาก checkout ส่วน Linux และ Windows ใช้ dedicated self-hosted GitHub
+Actions runner โดยตรง ไม่ใช้ Docker:
 
 ```bash
 # macOS บน checkout ปัจจุบัน
 npm run release:gate
 
-# Linux จริงใน Docker image แยก พร้อม Playwright Chromium
-npm run test:linux:docker
+# Linux และ Windows native CI / Node 22, 24
+gh workflow run platform-gates.yml --ref main -f platform=all
 ```
 
-Docker build ไม่รับ `.git`, `.npmrc`, `.env`, model, release evidence หรือเอกสารพัฒนา
-private เข้า build context ตัว runner ส่งเฉพาะ revision/dirty state ที่อ่านจาก host Git
-เข้า release gate และ DodoBench ผ่าน environment attestation ที่รับได้เฉพาะใน Linux
-container จากนั้นตรวจ report กลับว่าตรงกับ revision และ lock digest เดิม
+Linux workflow ตรวจ prerequisites, ติดตั้ง dependencies จาก lockfile และ Chromium
+แล้วพิสูจน์ว่า Chromium เปิดด้วย sandbox ได้ก่อนรัน gate อ่าน [CI](CI.md)
+สำหรับการเตรียมเครื่อง ใช้ `npm run release:gate:ci` เช่นเดียวกับ Windows
+ตรวจ Git HEAD ตรง GITHUB_SHA และ source สะอาดก่อนทดสอบ
 
 `.github/workflows/platform-gates.yml` ใช้ self-hosted labels `linux-ci` และ
 `windows-ci 02` ทดสอบ Node 22/24 เฉพาะ push ที่ `main` กับ manual dispatch ไม่มี
@@ -73,10 +73,15 @@ container จากนั้นตรวจ report กลับว่าตร
 revision กับ `package-lock.json` เดียวกัน Windows ถูกระบุเป็น
 `DEFERRED_MANUAL_NOT_RUN` และไม่ถูกนับเป็น supported release platform ในช่วงนี้
 Manual external-AI, owner workspace และ Windows 11 อยู่แยกเป็น `MANUAL_NOT_RUN`
-Strict gate รับ Linux evidence เฉพาะ `docker-host-git` จาก clean checkout พร้อม
-fresh-install PASS จึงไม่รับ candidate ที่มี uncommitted source หรือ report จาก runner
-ชนิดอื่น Report บันทึก origin ว่ามาจาก local หรือ GitHub Actions ตามจริง ไม่มีคำสั่ง
-เหล่านี้ publish npm
+Strict gate รับ Linux evidence เฉพาะ `local-git` และ origin `github-actions-native`
+จาก clean checkout พร้อม fresh-install PASS และ suites ที่ผ่านจริง ต้องตรงทั้ง
+revision/source fingerprint/lock digest จึงไม่รับ uncommitted source หรือ Docker
+report เก่ามาแทน native CI Report บันทึก origin ตามจริง ไม่มีคำสั่งเหล่านี้ publish npm
+
+ผลทดสอบและ private diagnostics อยู่ใน runner ใต้ `.dodo-ci-evidence/` ข้าง checkout
+แยกตาม run ID/attempt/platform/Node ไม่เขียนทับหลักฐานจากการ rerun หรือ checkout cleanup
+อัปโหลดเฉพาะ allowlisted summary และตำแหน่ง failure ใน test source
+ไม่ส่ง raw test logs หรือ private state ขึ้น artifact
 
 ## Security invariants
 

package/docs/MANUAL_ACCEPTANCE.md

@@ -296,10 +296,10 @@ manual external-client acceptance
 Automated catalog/API/Chromium/fresh-package fixtures: **AUTOMATED_PASS**
 
 1. เปิด Local Config → Settings และตรวจว่าสวิตช์ “เปิดให้ MCP clients เห็น Sub-agent tools” ปิดเป็นค่าเริ่มต้น
-2. ตรวจ Full live catalog มี 121 tools; Compact/Hybrid มี 19/49 ชื่อและ discover หา `subagent_spawn` ไม่พบ
+2. ตรวจ Full live catalog มี 154 tools; Compact/Hybrid มี 20/49 ชื่อและ discover หา `subagent_spawn` ไม่พบ
 3. ตรวจ Chat & Tasks ยังสร้างและดูงานได้จากหน้าเว็บ
 4. เปิดสวิตช์ ยืนยันผ่าน dialog แล้วตรวจข้อความว่าต้อง restart/rescan
-5. restart fixture เท่านั้น แล้วตรวจ Full มี 125 และ Compact discover/gateway มี `subagent_spawn/status/result/control`
+5. restart fixture เท่านั้น แล้วตรวจ Full มี 158 และ Compact discover/gateway มี `subagent_spawn/status/result/control`
 6. ปิดสวิตช์อีกครั้ง restart และตรวจว่า run history ยังอยู่ แต่ MCP definitions ถูกซ่อน
 
 การ restart server จริงและ rescan ผ่าน ChatGPT/remote client จริง: **MANUAL_NOT_RUN**
@@ -363,3 +363,60 @@ credentials ผ่าน private UI ผลต้องแยกตาม provide
 Live OpenAI, Gemini, Claude, MiniMax, GLM, Kimi, Ollama: MANUAL_NOT_RUN สำหรับงานนี้
 จนกว่าจะมีหลักฐานจาก account/model จริง Browser automation และ synthetic Keychain
 round-trip เป็น AUTOMATED_PASS ไม่ใช้แทน MANUAL_PASS ของ provider
+
+## Recovery R00–R02
+
+Automation uses separate fixture projects, including Chromium desktop/narrow
+owner policy controls. Manual owner-device use and native Windows are
+`MANUAL_NOT_RUN`. R02 adds automated fixture HTTP/owner browser/restore/crash
+coverage. Before a release, an owner should create a fixture checkpoint, edit two
+files, preview one-file and session undo, inspect exact-mirror deletions, verify
+read-back, and inspect journal status after reconnect. Test backup opt-out,
+external-edit conflict and restart with fresh context. Do not exercise this manual
+gate on a production database or count automated browser tests as MANUAL_PASS.
+
+## R03 — MANUAL_NOT_RUN on owner projects
+
+In disposable projects: capture dirty/staged/untracked source; externally overwrite files while preserving size/mtime; verify target writes refuse and unrelated edits remain available. Review paginated drift, reject stale digest/epoch, then explicitly acknowledge or preview/restore. Verify emergency snapshots do not replace the baseline. Run a command that changes source and check unknown-author attribution after job completion. Confirm independent Git refs/objects, unchanged working index/HEAD/branch, and no hooks/filter markers. Remove the selected backup volume: expect refusal without fallback. Delete source and working `.git` while retaining root identity: preview/restore source only. Root replacement, real removable volumes, native Windows/Android and owner live projects require separate manual acceptance. Browser fixture automation is reported as AUTOMATED_PASS only after it runs.
+
+
+## Recovery R04
+
+Fixture browser automation covers project registration, default-on recovery, actual recipe evidence, owner names/pins, stale files, restore read-back and quota-blocked UI on desktop/narrow screens. Before a release, an owner should separately test their own project/storage and restart/reconnect workflow, inspect retained pins/names, and re-run required recipes after source/config changes. Live owner projects, Windows/Android and production/database recovery are MANUAL_NOT_RUN for this phase. Do not label a manual owner name as tested or production-known-good.
+
+## Docker deployment and recovery
+
+AUTOMATED_PASS (disposable local daemon fixture, native Node): real build/image
+source verification, deploy/health/stabilization, failure preserving known-good,
+reviewed image rollback, source restore without restarting service, unchanged
+SQLite rows/migration metadata/private fixture config in an existing named volume,
+image pin/review conflicts and exact cleanup. These results are separate from
+native Windows/Linux release gates and do not certify a user's daemon/context.
+
+MANUAL_NOT_RUN: owner production, remote Docker contexts, Windows/Linux Docker
+engines, long-duration stabilization and manual browser deployment. Before opting
+in, review the target's daemon authority and use a disposable project/service to
+exercise interrupted build/deploy, live observation, probe cleanup, reconnect,
+expired approval and reviewed rollback. Source/database recovery remain distinct.
+
+## database/config recovery — MANUAL_NOT_RUN on owner data
+
+Use disposable SQLite and a synthetic private `.env`, never production secrets.
+Enable the migration adapter through the project page; verify unbound UNKNOWN,
+owner-rule COMPATIBLE, and mismatched IDs blocking restore without changing rows.
+Check external migration drift during a source restore, and explicitly review the
+warning-only alternative if selected. Database undo/PITR remains unsupported.
+
+For each OS credential provider, opt in a synthetic file, verify actual key-store
+access, encrypted backup, redacted preview and exact read-back. Rotate; verify old
+copies still need old keys. Lock/refuse the OS store and confirm no fallback.
+Stop dependent fixture services before in-place restore. Test restart/reconnect
+using the recorded receipt; UNKNOWN must not repeat writes. Review retention,
+missing-file disable and recovery from the encrypted before-copy. Confirm no
+secrets in MCP, public routes, browser storage, logs, source snapshots or tarball.
+
+Automated browser/protocol tests are AUTOMATED_PASS only when reported. A real
+Keychain fixture round-trip is not a manual Windows Credential Manager or Linux
+Secret Service pass. Android encryption-provider support is NOT_SUPPORTED. Record
+each OS and owner-production/manual case independently; no generic DB rollback
+or disaster-recovery success is implied.