## theme check

```bash
mercemur theme check
mercemur theme check --strict
```

Lints the local templates for mistakes the server cannot catch.

The API already refuses invalid markup, so this covers the other kind: a binding that is perfectly
legal and renders the wrong thing, with no error anywhere.

| Rule | Why it matters |
|---|---|
| `boolean-attribute` | `hidden="false"` hides an element exactly as `hidden="true"` does, so a picker bound that way disappears entirely |
| `money-without-filter` | Every amount is in minor units, so a raw price renders `1999` where `19.99` is meant |
| `unknown-filter` | The only filter is `money`; anything else renders as nothing |
| `filter-on-each` | `data-mc-each` takes a list, so a filter has nothing to apply to |
| `empty-binding` | A binding with no path renders as nothing, always |

Errors exit non-zero so this works as a pre-commit or CI gate. Warnings do not fail the run unless
you pass `--strict`. It lints the **draft**, because that is what `push` sends.

## theme package

```bash
mercemur theme package -o theme.zip
```

Packs the templates and the builder config into one zip for handoff. The local state file is
excluded: it records which revision your checkout last saw, which is true of your machine and
false of anyone else's.

Packaging the same theme twice produces byte-identical output, so the archive can be checksummed
and cached.

## theme list

```bash
mercemur theme list
```

Shows each template's name, whether it is published, whether it has unpublished changes, and its
size. Live-and-edited-since is its own state rather than being collapsed into "published", because
the unpublished work is usually what you are looking for.

## webhook listen

```bash
mercemur webhook listen --forward-to http://localhost:3000/webhooks --secret whsec_...
```

Watches for new deliveries and re-sends each one to a URL on your machine, **signed exactly as the
platform signs it**, so you can build a receiver without a tunnel.

The forward carries the real `webhook-id`, `webhook-timestamp`, `webhook-event-type` and
`webhook-signature` headers, with the signature computed over `id.timestamp.payload` the same way
a production delivery is. Your receiver's own verification is what gets exercised.

<Warning>
  **Pass `--secret`.** Without the endpoint's signing secret this forwards unsigned, and any
  receiver that verifies will reject every event, which looks like a broken receiver rather than a
  missing flag. The secret is shown once when the endpoint is created.
</Warning>

Reading a payload needs the topic's own read scope **as well as** `read_webhooks`: the body of an
`orders/paid` delivery is order data, so it needs `read_orders`. A 403 names the scope to add, and
the run continues, because other topics may still be readable.

The existing backlog is skipped by default. Replaying it into a fresh receiver on every start
would fire yesterday's orders at a handler that may act on them; pass `--skip-backlog=false` if
that is what you want.

## status

```bash
mercemur status
```

Reports whether the API is answering, which build is deployed, and whether a newer CLI has been
released. Exits non-zero when the API is unhealthy, so a monitor can gate on it.

This is about the **platform**. For a problem with your own setup, `mercemur doctor` checks your
config, key and clock instead.