create-harness-vibe-coding 0.6.2 → 0.6.4

package/templates/optional/skills/browser-e2e/.claude/commands/wf-browser.md

@@ -0,0 +1,25 @@
+# /wf-browser [task]
+
+AI-driven browser automation via Browser Use (89.1% WebVoyager benchmark). Dual mode: CLI (~50ms per call, no LLM needed) + Python Agent API (multi-step AI reasoning).
+
+## Required
+
+- Load `wf-browser` skill.
+- Load `Harness/workflows/browser-e2e.md` for evidence contract and fallback paths.
+- Real-browser evidence required for every browser/UI claim (screenshot, state snapshot, or console output).
+
+## Modes
+
+**CLI (fast iteration):** `browser-use open/state/click/screenshot/close` — Claude Code reasons, CLI executes.
+**Agent (complex flows):** Python API with LLM observation→decision→action loop.
+
+## Flow
+
+```text
+open page → state (inspect elements)
+→ click/input (interact)
+→ state/screenshot (verify)
+→ close (cleanup)
+```
+
+Keep browser evidence in `Harness/tasks/<task-id>/evidence/*.png`.

package/templates/optional/skills/browser-e2e/.claude/skills/browser-e2e/SKILL.md

@@ -1,42 +1,42 @@
----
-name: browser-e2e
-description: Mandatory real-browser smoke and end-to-end verification using Playwright, Chrome DevTools/CDP, or documented manual browser evidence.
----
-
-# Browser E2E
-
-## When To Use
-
-Use this skill when a change affects browser-visible behavior, navigation, forms, routing, layout, or client-side integration. Web/UI acceptance requires loading the app in a real browser before claiming the UI is done.
-
-## Docs To Load
-
-- `Harness/workflows/browser-e2e.md`
-- `Harness/PLAN.md`
-- Existing project test, build, and run instructions.
-
-## Required Inputs
-
-- Target URL or command to start the app.
-- User flows or pages to verify.
-- Expected behavior and supported viewport/browser scope.
-- Selector contract: stable accessible labels/roles and `data-testid` hooks for critical inputs, buttons, filters, rows, empty/error/loading states, and other targetable UI states.
-
-## Allowed Writes
-
-- Browser test files in the project's existing test locations.
-- Evidence artifacts such as screenshots, traces, or reports in existing artifact folders.
-- Notes in `Harness/PLAN.md` when the active task asks for plan tracking.
-
-## Output Format
-
-Return changed files, commands run, browser evidence paths, verified flows, failures, and follow-up risks.
-Include the selectors used for CDP/Playwright/manual verification.
-
-## PLAN.md Updates
-
-Update `Harness/PLAN.md` only when executing a tracked plan item or recording evidence requested by the current task.
-
-## dispatch.md Usage
-
-Use `Harness/dispatch.md` only when splitting independent browser checks across workers is explicitly useful.
+---
+name: browser-e2e
+description: Mandatory real-browser smoke and end-to-end verification using Playwright, Chrome DevTools/CDP, or documented manual browser evidence.
+---
+
+# Browser E2E
+
+## When To Use
+
+Use this skill when a change affects browser-visible behavior, navigation, forms, routing, layout, or client-side integration. Web/UI acceptance requires loading the app in a real browser before claiming the UI is done.
+
+## Docs To Load
+
+- `Harness/workflows/browser-e2e.md`
+- `Harness/PROGRESS.md` and current task `tasks/<id>/PLAN.md`
+- Existing project test, build, and run instructions.
+
+## Required Inputs
+
+- Target URL or command to start the app.
+- User flows or pages to verify.
+- Expected behavior and supported viewport/browser scope.
+- Selector contract: stable accessible labels/roles and `data-testid` hooks for critical inputs, buttons, filters, rows, empty/error/loading states, and other targetable UI states.
+
+## Allowed Writes
+
+- Browser test files in the project's existing test locations.
+- Evidence artifacts such as screenshots, traces, or reports in existing artifact folders.
+- Notes in current task plan when the active task asks for plan tracking.
+
+## Output Format
+
+Return changed files, commands run, browser evidence paths, verified flows, failures, and follow-up risks.
+Include the selectors used for CDP/Playwright/manual verification.
+
+## PROGRESS.md & Task PLAN.md Updates
+
+Update `Harness/tasks/<task-id>/PLAN.md` only when executing a tracked plan item or recording evidence requested by the current task.
+
+## dispatch.md Usage
+
+Use `Harness/dispatch.md` only when splitting independent browser checks across workers is explicitly useful.

package/templates/optional/skills/browser-e2e/.claude/skills/wf-browser/SKILL.md

@@ -0,0 +1,194 @@
+---
+name: wf-browser
+description: AI-driven browser automation for E2E testing, web scraping, form filling, and UI verification. Powered by Browser Use (89.1% WebVoyager benchmark). Use for /wf-browser, browser testing, web automation, page interaction, form filling, screenshot verification, or any task requiring real browser control. Dual mode: CLI (fast iteration, no LLM needed) + Python Agent API (complex multi-step workflows with AI reasoning).
+---
+
+# WF Browser — AI Browser Automation
+
+Load:
+
+- `Harness/workflows/browser-e2e.md`
+- Official `browser-use` skill at `~/.claude/skills/browser-use/SKILL.md` (auto-installed if missing)
+- `Harness/PROGRESS.md` when work is active
+
+## Modes
+
+Choose based on task complexity:
+
+### Mode 1: CLI (fast iteration, ~50ms per call)
+
+Best for: single-page checks, quick screenshots, form fills, element inspection. No LLM needed — Claude Code reasons and issues CLI commands.
+
+```bash
+browser-use --headed open https://example.com   # Open page (headed = visible browser)
+browser-use state                                # Get page title, text, interactive elements with indices
+browser-use screenshot evidence.png              # Capture screenshot as evidence
+browser-use click 5                              # Click element by index from state output
+browser-use input 3 "user@example.com"           # Fill input field by index
+browser-use eval "document.title"                # Run JavaScript in page
+browser-use close                                # Close browser when done
+```
+
+Daemon keeps the browser open between commands — no cold-start per action.
+
+### Mode 2: Python Agent API (multi-step AI reasoning)
+
+Best for: complex multi-page workflows, dynamic navigation, data extraction across pages. Needs LLM API key.
+
+```python
+from browser_use.beta import Agent, BrowserProfile
+from browser_use.llm import ChatAnthropic
+
+agent = Agent(
+    task="Go to github.com, search for 'browser-use', click the first result, and report the star count",
+    llm=ChatAnthropic(model="claude-haiku-4-5-20251001"),
+    browser_profile=BrowserProfile(headless=False),
+)
+history = await agent.run()
+print(history.final_result())
+```
+
+## Environment Setup
+
+Run once per machine:
+
+```bash
+# 1. Install browser-use with CLI extras
+pip install "browser-use[cli]"
+
+# 2. Install Chromium browser
+browser-use install
+
+# 3. Verify installation
+browser-use doctor
+
+# 4. (Optional) Set LLM API key for Agent mode
+# Create .env file with: ANTHROPIC_API_KEY=sk-ant-...
+# Or: OPENAI_API_KEY=sk-...
+# Or: BROWSER_USE_API_KEY=bu-...
+```
+
+### Windows GBK Encoding Fix
+
+If you see `UnicodeEncodeError: 'gbk' codec can't encode character`, the install is auto-patched. If not, set env var before commands:
+
+```bash
+set PYTHONIOENCODING=utf-8
+```
+
+### Windows Daemon Patches
+
+Browser Use v0.13.1 has two known issues on Windows that are auto-patched on install. If `browser-use open` fails with "Failed to start daemon" or socket timeout, re-apply:
+
+```bash
+python -c "
+import browser_use.skill_cli.main as m
+p = m.__file__
+c = open(p, encoding='utf-8').read()
+# Patch 1: auto-clean stale state on dead PID
+c = c.replace(
+    'probe = _probe_session(session)\n\n\t# Socket reachable',
+    'probe = _probe_session(session)\n\n\t# Auto-clean stale state\n\tif not probe.socket_reachable and not probe.pid_alive and probe.phase:\n\t\t_clean_session_files(session)\n\t\tprobe = _probe_session(session)\n\n\t# Socket reachable'
+)
+# Patch 2: auto-recover from stale session instead of erroring
+c = c.replace(
+    \"f'Error: Session {session!r} is alive (phase={probe.phase}) but socket unreachable.\",\"
+    \"f'Warning: Session {session!r} has stale state (phase={probe.phase}), auto-cleaning...\",\"
+)
+c = c.replace(
+    \"sys.exit(1)\n\n\t\telif probe.phase == 'shutting_down'\",
+    \"_terminate_pid(probe.pid)\n\t\t\t_clean_session_files(session)\n\n\t\telif probe.phase == 'shutting_down'\"
+)
+# Patch 3: extend daemon startup timeout (15s -> 30s)
+c = c.replace('deadline = time.time() + 15', 'deadline = time.time() + 30')
+open(p, 'w', encoding='utf-8').write(c)
+print('Patches applied')
+"
+```
+
+### Requirements
+
+| Requirement | Version | Check |
+|-------------|---------|-------|
+| Python | >= 3.11 | `python --version` |
+| pip | any | `pip --version` |
+| Chromium | auto-installed | `browser-use doctor` |
+| LLM API key | for Agent mode only | check `.env` |
+
+## Common Patterns
+
+### Login Persistence
+
+```bash
+# Use real Chrome profile (preserves cookies/logins)
+browser-use --profile "Default" open https://app.target.com
+# Or connect to running Chrome with remote debugging
+browser-use connect
+```
+
+### E2E Test Flow
+
+```bash
+browser-use --headed open https://yourapp.local
+browser-use state                          # Verify page loaded
+browser-use screenshot step1-landing.png   # Evidence
+browser-use input 3 "test@email.com"       # Fill email
+browser-use input 5 "password123"          # Fill password
+browser-use click 8                        # Click login button
+browser-use wait text "Dashboard"           # Wait for navigation text
+browser-use state                          # Verify logged in
+browser-use screenshot step2-dashboard.png # Evidence
+browser-use close
+```
+
+### Console & Network Log Capture
+
+```bash
+browser-use eval "console.log('checkpoint');"   # Inject log marker
+browser-use eval "document.title"                # Read page state via JS
+browser-use get text 5                           # Get text of element index 5
+browser-use get value 3                          # Get value of input element index 3
+# For full console/network: use Python Agent mode with Playwright's page.on('console') and page.on('request')
+```
+
+### Error Recovery
+
+```bash
+# If daemon crashes or gets stuck:
+browser-use close          # Clean shutdown
+# Then restart:
+browser-use open <url>     # Fresh daemon starts automatically
+```
+
+## Verification Contract
+
+Every browser task must produce:
+
+1. **State evidence**: `browser-use state` output or screenshot
+2. **Action log**: sequence of commands issued
+3. **Result assertion**: explicit before/after state comparison
+
+No browser/UI claim without real-browser evidence.
+
+## Architecture Note
+
+Browser Use wraps Playwright with AI reasoning. The daemon keeps Chromium running between CLI commands (~50ms latency). The Agent mode adds an LLM observation→decision→action loop on top. This replaces fragile CSS-selector scripts with semantic element targeting via accessibility tree snapshots.
+
+Benchmarks: 89.1% WebVoyager (SOTA), 78k+ GitHub stars, MIT license.
+
+## Security
+
+- **Never log or screenshot credentials** — redact password fields, API keys, tokens before capturing evidence
+- **Chrome profiles contain sensitive data** — only use `--profile` with explicit user approval; never share profile data
+- **Screenshots may capture PII** — review before saving to task evidence directory
+- **Scraping targets need approval** — confirm the target site's ToS allow automated access before scraping
+- **`browser-use input` commands with passwords** — use placeholder values in documentation; never hardcode real credentials
+- **Agent mode sandbox** — run Agent API with `allowed_domains` restriction when possible
+
+## Return
+
+- CLI commands issued and their output
+- screenshot paths
+- agent history (if Agent mode used)
+- verification pass/fail with evidence
+- remaining risks (flaky selectors, auth issues, CAPTCHAs)

package/templates/optional/skills/browser-e2e/docs/workflows/browser-e2e.md

@@ -1,42 +1,63 @@
 # Browser E2E Workflow
 
-## Required Evidence
-
-- App start command and URL.
-- Real-browser load of the changed app before any web/UI acceptance claim.
-- Console, runtime, and network check result, including whether React/Vite/client startup errors or failed requests appeared.
-- Stable accessible labels/roles and stable test hooks such as `data-testid` are required for critical UI controls and states: inputs, buttons, filters, rows, empty/error/loading states.
-- CDP, Playwright, and manual verification must target those selectors for the critical interaction path instead of brittle DOM paths.
-- Viewports and browsers checked.
-- Screenshot, trace, video, or documented manual screenshot artifact for each critical UI flow.
-- Final pass/fail result with exact command output summary.
-
-## Chrome DevTools / CDP / MCP Checklist
-
-- Start the app with the project command and record the URL and port.
-- Open a real browser target through available CDP, MCP, browser automation, or manual tooling.
-- Wait for a stable app selector, route, or page-ready state, not just HTTP 200.
-- Capture runtime exceptions, console errors, and failed network requests before and after the flow.
-- Interact through stable accessible labels/roles or `data-testid`, not brittle DOM paths.
-- Verify at least one critical flow end-to-end in the real browser target.
-- Save screenshot, trace, video, or result artifact paths and record them in `Harness/PLAN.md` or the feature doc.
-- Clean up any dev server or browser processes started for verification.
-
-## Common Commands
-
-```powershell
-npm run dev
-npx playwright test
-npx playwright test --headed
-npx playwright show-report
-```
+Optional workflow for browser-visible testing and automation. Installed when `browser-use` CLI is available.
+
+## When Active
+
+This workflow is active when:
+1. `browser-use` CLI is installed and `browser-use doctor` passes
+2. `Harness/workflows/browser-e2e.md` exists (this file)
+3. A task explicitly references `/wf-browser` or browser E2E testing
+
+## Contract
+
+Browser evidence in this project follows the contract:
+
+1. **Every browser claim needs real-browser evidence** — screenshot, state snapshot, or console output
+2. **CLI mode is preferred for deterministic steps** — use `browser-use open/state/click/screenshot` for predictable flows
+3. **Agent mode is for dynamic exploration** — use Browser Use Agent API when the page structure is unknown or changing
+4. **Evidence goes to the task directory** — `Harness/tasks/<task-id>/evidence/*.png`
+
+## Quick Install
 
-If Playwright is not installed, prefer an existing browser test command from `package.json`. Chrome DevTools/CDP, manual screenshot evidence, or framework-specific tools are acceptable when the method, URL, flow, console/runtime/network result, and artifacts are documented.
+```bash
+# One-time setup
+pip install "browser-use[cli]"
+browser-use install
+browser-use doctor
+
+# Windows: if you see GBK encoding errors, set:
+set PYTHONIOENCODING=utf-8
+
+# Verify
+browser-use open https://example.com
+browser-use state
+browser-use screenshot test.png
+browser-use close
+```
 
 ## Fallback
 
-When no browser automation is available, run the app locally in a real browser, inspect critical flows manually, capture screenshots, and report console or network errors. Do not claim web/UI acceptance from typecheck, build, or unit tests alone. Do not install new dependencies unless the user approves.
+If `browser-use` is not installed, fall back to:
+
+1. Playwright/Puppeteer MCP server (if configured)
+2. Chrome DevTools Protocol (CDP) manual inspection
+3. `Harness/WF.md#Browser And API Evidence` manual check contract
+
+## Integration Points
+
+- **WF mode**: when browser-visible changes are made, follow the evidence contract in `Harness/WF.md#Browser And API Evidence`
+- **wf-browser**: the `/wf-browser` slash command loads this workflow + the skill via `.claude/commands/wf-browser.md`
+- **MEMORY.md**: registered as optional workflow skill
+- **README.md**: routing table row "Browser E2E testing or automation" → browser-e2e
 
-## Windows Notes
+## File Locations
 
-Use PowerShell syntax for environment variables, for example `$env:PORT='3000'; npm run dev`. Quote paths that contain spaces.
+| File | Purpose |
+|------|---------|
+| `.claude/skills/wf-browser/SKILL.md` | Skill definition |
+| `.claude/commands/wf-browser.md` | Slash command bridge |
+| `Harness/workflows/browser-e2e.md` | This file — workflow contract and install guide |
+| `~/.claude/skills/browser-use/SKILL.md` | Official Browser Use skill (user-level, auto-downloaded) |
+| `pip show browser-use \| findstr Location` | Python package install location (run to find) |
+| `~/.browser-use/` | Daemon state and browser profiles |

package/templates/optional/skills/github-pr-review/.claude/skills/github-pr-review/SKILL.md

@@ -1,40 +1,40 @@
----
-name: github-pr-review
-description: GitHub pull request review workflow using available GitHub CLI, local git diff, checks, and CI evidence.
----
-
-# GitHub PR Review
-
-## When To Use
-
-Use this skill when reviewing a GitHub pull request, responding to PR feedback, checking CI status, or summarizing review findings.
-
-## Docs To Load
-
-- `Harness/workflows/github-pr-review.md`
-- `Harness/PLAN.md`
-- Repository contribution, test, and review guidelines.
-
-## Required Inputs
-
-- PR number, branch, or comparison range.
-- Review goal: bug hunt, approval readiness, CI diagnosis, or feedback response.
-- Expected test and check requirements.
-
-## Allowed Writes
-
-- Local files needed to address approved review feedback.
-- Review notes or evidence in existing docs only when requested.
-- `Harness/PLAN.md` when tracking review work.
-
-## Output Format
-
-Return findings first by severity with file and line references, then open questions, tests/checks run, and change summary if edits were made.
-
-## PLAN.md Updates
-
-Update `Harness/PLAN.md` only when the PR review is part of a tracked implementation plan.
-
-## dispatch.md Usage
-
-Use `Harness/dispatch.md` when independent review areas can be assigned separately, such as backend, frontend, and CI.
+---
+name: github-pr-review
+description: GitHub pull request review workflow using available GitHub CLI, local git diff, checks, and CI evidence.
+---
+
+# GitHub PR Review
+
+## When To Use
+
+Use this skill when reviewing a GitHub pull request, responding to PR feedback, checking CI status, or summarizing review findings.
+
+## Docs To Load
+
+- `Harness/workflows/github-pr-review.md`
+- `Harness/PROGRESS.md` and current task `tasks/<id>/PLAN.md`
+- Repository contribution, test, and review guidelines.
+
+## Required Inputs
+
+- PR number, branch, or comparison range.
+- Review goal: bug hunt, approval readiness, CI diagnosis, or feedback response.
+- Expected test and check requirements.
+
+## Allowed Writes
+
+- Local files needed to address approved review feedback.
+- Review notes or evidence in existing docs only when requested.
+- Current task `tasks/<id>/PLAN.md` when tracking review work.
+
+## Output Format
+
+Return findings first by severity with file and line references, then open questions, tests/checks run, and change summary if edits were made.
+
+## PROGRESS.md & Task PLAN.md Updates
+
+Update `Harness/tasks/<task-id>/PLAN.md` only when the PR review is part of a tracked implementation plan.
+
+## dispatch.md Usage
+
+Use `Harness/dispatch.md` when independent review areas can be assigned separately, such as backend, frontend, and CI.

package/templates/optional/skills/python-backend/.claude/skills/python-backend/SKILL.md

@@ -1,40 +1,40 @@
----
-name: python-backend
-description: Python backend workflow for API changes, service logic, FastAPI-style routes, and unittest or pytest verification.
----
-
-# Python Backend
-
-## When To Use
-
-Use this skill when changing Python API routes, service logic, persistence boundaries, background jobs, or backend tests.
-
-## Docs To Load
-
-- `Harness/workflows/python-backend.md`
-- `Harness/PLAN.md`
-- Project backend README, API docs, dependency files, and test configuration.
-
-## Required Inputs
-
-- Target behavior, endpoint, service, or bug.
-- Existing test command and runtime setup.
-- Database, environment variable, or fixture constraints.
-
-## Allowed Writes
-
-- Python source, tests, fixtures, and backend docs in the task scope.
-- Local evidence artifacts such as test output snippets.
-- `Harness/PLAN.md` when the task requires plan tracking.
-
-## Output Format
-
-Return files changed, API or behavior summary, tests run, important logs, migration/config notes, and remaining risks.
-
-## PLAN.md Updates
-
-Update `Harness/PLAN.md` only when executing a tracked plan item or recording required validation evidence.
-
-## dispatch.md Usage
-
-Use `Harness/dispatch.md` for separable backend work such as API implementation, database changes, and test coverage.
+---
+name: python-backend
+description: Python backend workflow for API changes, service logic, FastAPI-style routes, and unittest or pytest verification.
+---
+
+# Python Backend
+
+## When To Use
+
+Use this skill when changing Python API routes, service logic, persistence boundaries, background jobs, or backend tests.
+
+## Docs To Load
+
+- `Harness/workflows/python-backend.md`
+- `Harness/PROGRESS.md` and current task `tasks/<id>/PLAN.md`
+- Project backend README, API docs, dependency files, and test configuration.
+
+## Required Inputs
+
+- Target behavior, endpoint, service, or bug.
+- Existing test command and runtime setup.
+- Database, environment variable, or fixture constraints.
+
+## Allowed Writes
+
+- Python source, tests, fixtures, and backend docs in the task scope.
+- Local evidence artifacts such as test output snippets.
+- Current task `tasks/<id>/PLAN.md` when the task requires plan tracking.
+
+## Output Format
+
+Return files changed, API or behavior summary, tests run, important logs, migration/config notes, and remaining risks.
+
+## PROGRESS.md & Task PLAN.md Updates
+
+Update `Harness/tasks/<task-id>/PLAN.md` only when executing a tracked plan item or recording required validation evidence.
+
+## dispatch.md Usage
+
+Use `Harness/dispatch.md` for separable backend work such as API implementation, database changes, and test coverage.

package/templates/optional/skills/ts-react-frontend/.claude/skills/ts-react-frontend/SKILL.md

@@ -1,43 +1,43 @@
----
-name: ts-react-frontend
-description: TypeScript React frontend workflow for components, state, routing, typecheck, tests, builds, and browser smoke evidence.
----
-
-# TypeScript React Frontend
-
-## When To Use
-
-Use this skill when changing React components, hooks, routes, client state, styling, build configuration, or frontend tests.
-For user-visible changes, typecheck, build, and unit tests are not enough; include real-browser smoke or screenshot evidence before claiming acceptance.
-
-## Docs To Load
-
-- `Harness/workflows/ts-react-frontend.md`
-- `Harness/PLAN.md`
-- Existing frontend README, package scripts, design system, and test setup.
-
-## Required Inputs
-
-- Screen, component, or flow being changed.
-- Expected behavior and acceptance criteria.
-- Existing package manager and verification commands.
-- Selector contract: stable accessible labels/roles and `data-testid` hooks for critical inputs, buttons, filters, rows, empty/error/loading states, and other targetable UI states.
-
-## Allowed Writes
-
-- Frontend source, styles, tests, and focused docs in task scope.
-- Generated evidence such as screenshots or test reports in existing artifact paths.
-- `Harness/PLAN.md` when tracking a plan item.
-
-## Output Format
-
-Return changed files, UI behavior summary, commands run, browser or test evidence, and unresolved risks.
-Include selectors added or verified for CDP/Playwright/manual checks.
-
-## PLAN.md Updates
-
-Update `Harness/PLAN.md` only when executing a tracked task or recording required validation evidence.
-
-## dispatch.md Usage
-
-Use `Harness/dispatch.md` when independent frontend tasks can run in parallel, such as components, tests, and browser checks.
+---
+name: ts-react-frontend
+description: TypeScript React frontend workflow for components, state, routing, typecheck, tests, builds, and browser smoke evidence.
+---
+
+# TypeScript React Frontend
+
+## When To Use
+
+Use this skill when changing React components, hooks, routes, client state, styling, build configuration, or frontend tests.
+For user-visible changes, typecheck, build, and unit tests are not enough; include real-browser smoke or screenshot evidence before claiming acceptance.
+
+## Docs To Load
+
+- `Harness/workflows/ts-react-frontend.md`
+- `Harness/PROGRESS.md` and current task `tasks/<id>/PLAN.md`
+- Existing frontend README, package scripts, design system, and test setup.
+
+## Required Inputs
+
+- Screen, component, or flow being changed.
+- Expected behavior and acceptance criteria.
+- Existing package manager and verification commands.
+- Selector contract: stable accessible labels/roles and `data-testid` hooks for critical inputs, buttons, filters, rows, empty/error/loading states, and other targetable UI states.
+
+## Allowed Writes
+
+- Frontend source, styles, tests, and focused docs in task scope.
+- Generated evidence such as screenshots or test reports in existing artifact paths.
+- Current task `tasks/<id>/PLAN.md` when tracking a plan item.
+
+## Output Format
+
+Return changed files, UI behavior summary, commands run, browser or test evidence, and unresolved risks.
+Include selectors added or verified for CDP/Playwright/manual checks.
+
+## PROGRESS.md & Task PLAN.md Updates
+
+Update `Harness/tasks/<task-id>/PLAN.md` only when executing a tracked task or recording required validation evidence.
+
+## dispatch.md Usage
+
+Use `Harness/dispatch.md` when independent frontend tasks can run in parallel, such as components, tests, and browser checks.