# Wall-E Coding Acceptance Contract

Wall-E coding runs must not treat model prose as proof of completion. Every build run now has a typed acceptance contract that maps the task to required validators before a subtask or final completion can succeed.

## Contract Shape

Planner subtasks may include an `acceptance` object:

```json
{
  "task_kind": "frontend-ui",
  "write_policy": "must-write",
  "validators": [
    "frontend.static_contract",
    "frontend.screenshot_evidence",
    "frontend.browser_runtime"
  ]
}
```

The orchestrator also derives a contract when the planner omits one. Frontend tasks are detected from changed frontend files or UI/web task language.

## Frontend Validators

- `frontend.static_contract` checks local assets and HTML-to-JS inline event handlers. If HTML calls `toggleAudio()` or `openMusicLightbox()`, a loaded inline or local script must define that global function.
- `frontend.screenshot_evidence` requires successful `browser_screenshot` evidence for frontend changes.
- `frontend.browser_runtime` uses `browser_smoke_test` or the orchestrator's final auto-smoke path. It loads the page in headless Chrome through CDP, captures runtime exceptions, console errors, failed requests, and safe-clicks interactive elements such as `[onclick]`, buttons, role buttons, and hash links.

## Enforcement Points

- Subtask gate: after a worker changes files, Wall-E runs the fast contract checks before tests/review. Static frontend failures retry the subtask with concrete failure text.
- Final gate: before Wall-E can report success or commit, Wall-E re-runs frontend static checks, requires screenshot evidence, and runs browser runtime smoke on discovered HTML entrypoints.
- Telemetry/progress: each validator emits structured `acceptance_validator` progress and anonymous `coding_acceptance_validator` telemetry with validator name, status, and failure count.

## Scope Control

Vague UI prompts such as "improve UX" or "make it world class" are bounded improvement tasks by default. The planner should produce 1-3 high-impact changes unless the user explicitly asks for a rebuild. For frontend subtasks, HTML, CSS, and JS changes must stay in the same subtask when they form one interaction contract.

## Why This Exists

The failure mode that motivated this contract was a successful-looking frontend run that produced HTML with inline handlers whose JavaScript functions did not exist. Screenshots and file-change checks did not catch it. The new contract catches the defect statically and, at final completion, through a real browser runtime check.
