test(harness): live-verification playbook pack for browser recipes

[shaun0927]

Why

The Goose comparison highlighted recipes/sub-recipes as a useful way to reduce repeated planning and make long-running work reproducible. OpenChrome already has the right implementation issue for this: #854 (oc playbook — declarative YAML scenario runner with inline Outcome Contracts). Creating a second recipe runner would be duplicate scope.

This issue adds the missing hardening layer around #854: a small, merge-blocking live-verification pack that proves browser recipes are useful as deterministic OpenChrome harness artifacts after implementation.

Scope

After #854 lands, add runnable browser recipe fixtures and verification documentation that exercise the playbook runner through a real OpenChrome MCP server.

Required fixtures

Add a small local fixture site under tests/fixtures/playbook/ or equivalent:

• index.html: links to a details page and contains a safe form.
• details.html: has stable text and at least one interactive control.
• optional submit.html: receives local-only form navigation; no external network side effects.

Required playbooks

Add 3 reviewable YAML playbooks under docs/recipes/ or tests/fixtures/playbook/recipes/:

1. basic-navigation.yaml — navigate, read/assert title/text, follow a link, assert URL/text.
2. safe-form.yaml — fill a local form, submit to a local fixture endpoint/page, assert post-submit state.
3. failure-recovery.yaml — intentionally assert a missing element first, then demonstrate fail-fast output with enough evidence for the host to recover.

Each playbook must use inline Outcome Contracts instead of LLM judgement.

Non-goals

• Do not implement another recipe runner; feat(cli): oc playbook — declarative YAML scenario runner with inline Outcome Contracts #854 owns the runner.
• Do not add LLM-based step generation or natural-language recipe interpretation.
• Do not use external websites or real accounts in verification fixtures.
• Do not make playbooks a new server-side orchestration tier.

Acceptance criteria

• The issue references feat(cli): oc playbook — declarative YAML scenario runner with inline Outcome Contracts #854 and does not duplicate its runner implementation scope.
• At least 3 runnable playbooks exist and are committed as text fixtures.
• Each playbook has deterministic expected outcomes through oc_assert or equivalent contracts.
• A documented command or test path exists for serving the local fixture and running the playbooks.
• Failure output includes step index, tool name, assertion failure details, and enough page state to reproduce.
• npm run build, targeted playbook tests, and npm run lint:tier pass.

Merge-blocking live verification with OpenChrome

After #854 and this issue are implemented, the PR must include live verification against a real OpenChrome MCP server:

1. Build OpenChrome.
2. Start the local fixture server.
3. Run basic-navigation.yaml through oc playbook run and confirm all assertions pass.
4. Run safe-form.yaml and confirm the local-only submit path succeeds without external network or account side effects.
5. Run failure-recovery.yaml and confirm it fails at the intended step with structured evidence.
6. Re-run basic-navigation.yaml to prove the failure playbook did not corrupt the browser/session state.

Attach console output or an MCP transcript showing all three playbooks.

Self-review checklist for implementer

• The playbooks reduce ambiguity for future regression testing.
• All verification targets are local/disposable.
• The implementation strengthens feat(cli): oc playbook — declarative YAML scenario runner with inline Outcome Contracts #854 rather than competing with it.
• The live evidence proves real OpenChrome execution, not just YAML parsing.

Curated scope, overlap handling, and verification checklist

Scope classification

• Canonical lane: live-verification fixtures/playbooks for an existing recipe runner.
• Primary deliverable: a small merge-blocking playbook pack that proves browser recipes work on local deterministic pages.
• Open PR: test(harness): local playbook verification pack (#1044) #1112 (test/1044-playbook-live-pack). Continue in that PR.
• Dependency gate: feat(cli): oc playbook — declarative YAML scenario runner with inline Outcome Contracts #854 owns the actual oc playbook runner. This issue must not create a second runner.
• Non-goal: new recipe DSL, new scheduler, or general-purpose scenario engine.

Overlap and conflict resolution

• Keep separate from feat(cli): oc playbook — declarative YAML scenario runner with inline Outcome Contracts #854: if runner behavior is missing, fix feat(cli): oc playbook — declarative YAML scenario runner with inline Outcome Contracts #854 or its PR rather than implementing runner logic here.
• Keep separate from feat(harness): automatic task checkpoints and richer session resume bundles #1035/feat(harness): deterministic task evidence digest for long-running browser work #1036/feat(harness): structured task ledger drift guard (OmniParser adoption F) #1057: those can add broader evidence/verification coverage, but this issue owns only the small browser recipe pack.
• Keep fixtures deterministic and local; avoid network sites that make merge verification flaky.

Implementation checklist

• Add a minimal set of YAML playbooks covering navigation/read/assertion, form or interaction flow, and a failure/diagnostic path.
• Add local fixture pages/data needed by those playbooks.
• Wire the playbooks into the repo's live-verification or harness command only after feat(cli): oc playbook — declarative YAML scenario runner with inline Outcome Contracts #854's runner surface exists.
• Document how to run the pack locally and what artifacts/logs indicate success.
• Add tests/static validation for playbook schema and fixture availability.

Success criteria

• The pack exercises real OpenChrome browser behavior through the recipe runner from feat(cli): oc playbook — declarative YAML scenario runner with inline Outcome Contracts #854.
• A passing run produces clear artifacts/logs; an intentional failure produces actionable diagnostics.
• The issue remains a fixture/playbook pack and does not duplicate runner implementation.
• Verification is deterministic enough for post-merge checks.

Post-merge OpenChrome live verification checklist

• Run the documented oc playbook/harness command against the local fixture pack.
• Verify all expected passing playbooks succeed and the intentional diagnostic case reports the expected failure shape.
• Confirm artifacts include playbook name, fixture URL/path, assertion results, and failure diagnostics.
• Add command output summary and artifact paths to merge verification notes.