v0.2.2 - Human-Reviewed Write Recovery

Human-reviewed recovery for uncertain browser writes

Version 0.2.2 adds an opt-in strict recovery path for browser actions whose result is uncertain after a timeout or worker interruption. It persists destination-read evidence as PENDING_REVIEW and blocks further writes until a matching review decision is recorded. Strict writes bind an operation ID, payload SHA-256, and durable payload reference so a retry cannot silently change the approved input.

The Playwright demo uses real POSIX worker termination against a synthetic local destination. It verifies both the before-write and after-write cases, the pending-review block, and a separately selected retry after an explicit not_landed decision. Reviewer identity is supplied by the fixture and is not authenticated by this library. This is a host-side review gate, not destination-side idempotency or an exactly-once guarantee.

The retry and checkpoint prompts are updated to v0.1.1. The suite includes 46 passing unit tests, browser-based builder and consent tests, and the synthetic recovery demo. No model or live-service behavior benchmark was run.

v0.2.1 - Disabled Control Boundary

This preview adds an explicit prompt boundary for disabled and read-only page controls, plus a regression test for the example host allowlist.

• The risk module directs agents to use visible UI prerequisites and stop if the control remains unavailable.
• The local controller rejects an evaluate action before its executor callback.
• GitHub Actions passed on commit bfb9c8258fc60c9f436e4337a50f236ded87b57a: 42 unit/contract tests, builder and skill parity, browser workflows and local recovery demos.

This is not a fix for Browser Use or another vendor agent. No LLM or live vendor runtime was tested. The prompt is guidance; the example allowlist only governs actions routed through that controller. See the scoped evidence in docs/verification.md and the motivating Browser Use report.

v0.2.0 - Read before replaying a write

Your browser saved the draft. Its worker died before recording success. Should recovery click Save again?

This preview adds a persisted host controller and a reproducible worker-kill demo to the original prompt modules.

• Flush DISPATCHED before execution; stop on persistence failure.
• Bind a stable operation ID to the exact payload hash, origin, account, action kind and count.
• Recover with a fresh browser read, then persist CONFIRMED or ABSENT.
• Keep failed reads unresolved; retry ABSENT only in a separate explicit phase.
• Retain intermediate checkpoints, destination snapshots and real screenshots.

Actual final results: 41 unit/contract checks passed. Both CI jobs passed at commit 630d773. Two actual SIGKILL cases read back 0 before Save / 1 after Save in distinct new processes. A deliberate unguarded two-Save control created 2 rows. Injected HTTP 503 did not become ABSENT.

Final CI and environment · English method · 中文方法

Extract the source ZIP, enter its browser-agent-blueprint folder:

npm install
npx playwright install chromium
npm test
npm run demo:write-ahead

Node 20+, macOS/Linux. On Linux use Playwright's --with-deps option when needed. No model key or existing browser profile is required.

The source ZIP contains all 104 tracked files, independently compared byte for byte to the commit. The evidence ZIP contains the final synthetic checkpoints, target snapshots and screenshots. The JSON report is also available separately. SHA256SUMS.txt covers all three downloads. Old release assets remain unchanged.

This is one task owner with sequential workers against a local target that has no deduplication. It is not server-side idempotency, exactly-once delivery, concurrent-host validation or a power-loss test. The target survives worker death, not its own death. File fsync is used; the parent directory is not fsynced.

中文版：新增写前状态保存、操作与载荷绑定、独立读回核对和失败即停；附中英文说明及真实证据。受控场景读回 0/1 条，不受控两次保存为 2 条。属于合成宿主测试，不宣称生产环境可靠性或 Star 增长。

v0.1.1 · Browser task-profile builder

v0.1.1 · Task-profile builder / 在线任务配装

Choose a browser task, inspect the original instructions, then copy or download the text without installing Node or calling a model.

• English/Chinese controls; original prompt text stays in English.
• Six base profiles exactly match the CLI. Integration contracts and workflows are explicit optional additions.
• Included-source list, actual UTF-8 bytes, SHA-256 and manual clipboard fallback.
• Direct offline builder/index.html, with no model calls, uploads or analytics on that page.

Try now: https://lydiatools.github.io/browser-agent-blueprint/builder/ · 中文

Offline: extract browser-agent-blueprint-v0.1.1.zip, then open browser-agent-blueprint/builder/index.html in Chrome. No server or Node is needed for this page. The optional Playwright recovery runner still requires its existing Node/browser setup.

The 12 original prompt modules and deterministic runtime remain unchanged at module version v0.1.0. This page assembles instructions; it does not install a browser, run an agent, implement a scheduler or establish live Muse/Grok/Codex compatibility. Review and map the text to your actual host before use. The original v0.1.0 tag and release assets remain fixed.

中文：解压后直接打开 builder/index.html，可选择任务、预览、复制或下载原始指令。界面中英文切换不翻译模板。配装页没有模型调用、内容上传或统计代码；工具接入、持久存储与权限需要实际宿主实现。旧版 v0.1.0 安装包保持原样。

Validation covers four assembly/source cases, six real browser workflow groups, existing host-policy checks and existing analytics-consent tests. These are developer checks, not adoption or Star-growth evidence. MIT; independent original templates, not leaked vendor prompts.

v0.1.0 — 12 modules, 4 workflow templates, 6 demo scenarios

Demos are deterministic host-control scripts against a local browser, not a model-driven agent. Muse/Grok/Codex integration contracts are not live-tested.

Browser Agent Blueprint v0.1.0 includes:

• 12 original copyable .txt prompt modules.
• 4 browser workflow templates.
• 6 reproducible demo scenarios, including separate-process resume.
• 22 host-control unit tests.
• English and Chinese quick-start documentation.
• MIT license and explicit provenance.

Start with npm run assemble -- content, or run the local browser demo.
Use demo:prepare followed by demo:resume to verify the save count stays at 1.

Known limits: no model invocation, no automatic scheduler, no production crash-consistent dispatch, and no live vendor integration benchmark.

Which side effect does your browser adapter classify incorrectly — autosave, redirects or a timed-out submission? Share a synthetic reproducer.

Maintainer: https://github.com/LydiaTools