# Delivery Surface and Claim Contract

## Purpose

Make the actual delivery boundary visible before an agent makes a capability
claim. A simulation, catalog, UI, protocol encoder, firmware build, transport,
and physical device are different surfaces. Passing evidence on one surface
does not silently promote a claim on another.

## Discover the real path

When a task includes a product catalog, UI, simulator, serial/network/CAN
transport, firmware, hardware, protocol, or documentation claim, trace the
relevant path using the source currently in the workspace:

```text
user action or public API
  -> local simulation/mock (if present)
  -> browser/client transport
  -> framing/parser/bridge
  -> firmware or service dispatch
  -> destination protocol/device
  -> returned status/error
  -> documentation and public claim
```

Inspect both sides of every claimed boundary. In particular, check whether a
parser can accept consecutive frames and resynchronize after non-frame bytes;
whether UI controls route to transport rather than only local state; whether a
firmware dispatcher implements the advertised command family; and whether a
read/unsupported command produces the documented response rather than a
generic acknowledgement.

## Claim states

Use the narrowest true state for each material deliverable:

- `simulation_only`: behavior is proved in mock/simulator only.
- `hardware_integrated`: the client-to-firmware/protocol path is exercised,
  but physical-device behavior is not yet proved.
- `hardware_verified`: a real-device or hardware-in-loop check passed with
  an explicit safety interlock.
- `blocked`: a required contract, source, device, permission, or acceptance
  layer is absent; name the missing prerequisite.

Never call a simulation-only result real control, hardware-ready, or a full
product implementation. A successful compile proves compilation, not parser
correctness, transport routing, CAN fragmentation, or actuator behavior.

## Product and provenance coverage

If `.omnius/delivery-coverage.json` is present, it is the structured claim
contract. Read its gaps and keep final wording within the declared state. For
schema version 2, each non-blocked claim must name fresh, full, content-hashed
source inspections for every relevant boundary and at least one named
contradiction check grounded in those inspections. A grep result, directory
listing, partial read, stale read, or a summary of source does not satisfy an
inspection. Treat the first missing inspection as the next discovery action;
this is a state delta, not a standing recovery instruction.
Every product series, command, parameter, and model format claimed as
supported must map to exactly one source-backed contract and provenance record.
Each selected acceptance layer must also name its canonical verification
command and have a successful receipt for that exact command in the current
run. Listing a test in the manifest does not mean it ran.
Do not fill an absent contract with guessed values, a wildcard, or a claim that
a neighboring product family probably behaves the same way. Mark it blocked or
unsupported instead.

When external/vendor material is inaccessible, distinguish local contract,
third-party guide, official vendor source, and inference. Do not describe an
unreachable source as independently verified.

## Acceptance layers

Select the smallest relevant executable checks, and retain their exact receipts:

- golden cross-language frame vectors for each framing implementation;
- serial noise/resynchronization and consecutive-frame parsing;
- browser E2E with a fake/real transport that proves UI controls emit frames;
- CAN fragmentation/reassembly where classic CAN is used;
- firmware/PlatformIO build and dispatch-path test;
- hardware-in-loop only with a stated safety interlock; and
- documentation consistency between public README, feature docs, and code.

These are evidence-selection prompts, not a standing tool order. Skip an
inapplicable layer explicitly; do not fabricate a passing result.