acceptance

# Verify (Builder Self-Evidence)

You are the **builder** for a delivery. A separate review step judges it against
either an existing **verify plan** or checks you author before testing. Some
criteria demand **evidence** (a screenshot, a DOM snapshot, CLI output…). A
criterion that declares `requiredEvidence` **cannot pass on your text alone**:
if the artifact is missing, the structural gate marks it `uncertain` and the
delivery is held.

## Read the project layer first (when the repository has one)

Before touching an environment, check for `.agents/acceptance/`. A repository
that verifies itself keeps its own layer there, and it outranks any guess you
would otherwise make:

| File                     | What it owns                                                 |
| ------------------------ | ------------------------------------------------------------ |
| `PROJECT.md`             | Start/stop commands, ports, services, auth, surfaces, probes |
| `PROCESS.md`             | The run process: approval gate, execution rules, teardown    |
| `common-mistakes.md`     | Project living log — what earlier rounds got wrong here      |
| `probe-mock-patterns.md` | Project living log — how to force state on this product      |

**The division of labor:** the project layer owns _how this repository is run_;
this skill owns _what a valid acceptance round is_ (plan, evidence, report,
immutable round, the hard rule below). Where they disagree on running, the
project layer wins. Where they disagree on what may be published, this skill
wins. Never invent a start command, a port, or an auth flow that `PROJECT.md`
already answers, and never work around a divergence silently — fix the adapter
in place during the run.

No `.agents/acceptance/` means the repository has no project layer yet. Continue
with the portable path below; if the run needs an adapter, bootstrap one first —
[project-adapter.md](references/project-adapter.md).

Read both living-log layers before executing a round that drives a product
surface: this skill's generic
[common-mistakes.md](references/common-mistakes.md) and
[probe-mock-patterns.md](references/probe-mock-patterns.md), plus the project's
own copies. Record new project-specific learnings in the project layer only.

## Applicability invariant

This skill applies whenever the delivery needs real verification. **It requires
no ids at all** — nothing about it is conditional on where it runs:

- **Were you handed an operation id** (a verify plan already exists for this
  run)? Discover that plan and satisfy it.
- **Otherwise** — the normal case — author the checks yourself and publish a
  structured report round.
- **Attaching to something specific?** Pass `--subject` (`task:<id>`,
  `topic:<id>`, or `document:<id>`) when the caller named one. Otherwise omit it:
  `lh acceptance run ingest` attaches the round itself when it can, and creates a
  standalone acceptance when it cannot.

Never report this skill inapplicable, and never go hunting through the
environment for an id to make it applicable. Missing ids are the default state,
not a degraded one.

So while you do the work, capture the proof and submit it. The loop:

```
discover or author plan  →  pick the surface  →  capture evidence  →  publish the round  →  self-check coverage
```

The skill package is portable, but execution capabilities are surface-specific:
`agent-browser` serves Web/Electron, while native macOS and iOS Simulator require
a local macOS display and their platform tools. No repository-specific scripts are
required; rounds land under `.acceptances/`, which the CLI keeps out of git for
you (see [report.md](./references/report.md#directory-layout)).

## Two entry points — an operation id is NOT required

Every evidence command targets a **verification session** (a round). How you name
that session is a choice, not a prerequisite:

| You have                        | Target the round with                                                                                                     | Path                                                   |
| ------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------ |
| An operation id you were given  | `--operation "$OPERATION_ID"`                                                                                             | This document: discover the plan, satisfy its criteria |
| No plan — you author the checks | Publish a whole directory with `lh acceptance run ingest`; it creates the round and, when needed, a standalone acceptance | [references/report.md](references/report.md)           |

**The authored path is the default.** You have an operation id only when the
invocation names one — a task, a caller, or the user hands it to you. Do not read
the environment looking for one, and do not treat its absence as a problem to
solve: a round created without an operation is simply recorded as `standalone`.

`--operation` and `--run` are interchangeable on `result submit` and
`result list`. (`evidence list` takes neither — it keys off a positional
`<checkResultId>` you read from `result list`.) On a later repair round, pass the
previously printed `--acceptance <acceptanceId>` so the new snapshot joins the
same history.

On the first ingest, always supply `--requirement "<one-sentence business goal>"`.
The requirement describes what the whole acceptance judges, not the narrower
scope of one round. It is immutable once recorded.

## HARD RULE — programmatic gates are NEVER acceptance checks

This is a binding constraint on every check you author, enforced at ingest —
not a style preference.

Every check MUST be an outcome a **person decides about the delivery**: what
the user sees, hears, reads, or receives. The repo's own automated gates are
not that. The following MUST NOT appear as a check, in any round, under any
phrasing: