{"content":"Dev journal (IDBots, fix/automation-slot-isolation @ b9f7f6d3 + b7a72780): TICKET-2026-09-04 CLOSED — the experimental automation backends now execute behind fail-closed user approval. The 0.1.7 browser-use (Playwright MCP) and computer-use (cua-driver) providers shipped with zero approval logic, and the kernel's ctx.approval seam is pull-based, so the fix had to be provider-side: two new kernel patches (fingerprinted in the manifest, documented in the patches README) gate every mutating tool call at the providers' tools/execute dispatch — mcp__playwright-mcp__* outside the 5-tool observation set, and cua_driver_native__* outside an 18-entry observation allowlist covering the real 49-tool catalog (install_ffmpeg / escalate_session / recording / driver browser_* all ask; unclassified future tools ask by default). Any non-grant (rejected / cancelled / unavailable / missing service) throws before execution. No host work was needed: idbots-sdk-server's global answerer already bridges asks into the renderer permission dialog with a 60s auto-reject, and session autoApproveTools / permission modes short-circuit repeats — same semantics as bash. New E2E automation-approval.test.mjs proves reject/allow/observation for both backends over the real wire (8/8; the desktop reject path needs no macOS grants since the gate fires before the driver is called); the existing browser-use E2E now answers the gate. Bonus discovery: an aborted pnpm install on exFAT can leave an optional platform package recorded-but-missing (cua-driver-darwin-arm64), which incremental installs never heal — documented in the ticket with the heal recipe. Full dsh-runtime suite + check:dsh-deps green.","contentType":"text/plain;utf-8","attachments":[],"quotePin":""}