packages/builtin-skills/src/verify/surfaces/cli.md
The default surface for backend, CLI, library, and data-logic changes. The proof is the command's own output — text, not pixels. This is the cheapest and strongest evidence: a passing assertion or a correct JSON result is harder to fake than a screenshot, and it runs anywhere (no browser, no display).
Use this surface when your change is verifiable by running something and reading what it prints. Escalate to web.md or electron.md only when the criterion is actually about rendered UI.
--json, a structured dump) so the proof is assertable, not prose.text evidence — inline with --content
for short output, or --file for a larger dump.# CHECK_ITEM_ID is the criterion's plan item id (from `lh verify plan state`).
# short result → inline
lh verify submit --operation "$LOBE_OPERATION_ID" --item "$CHECK_ITEM_ID" --type text \
--content "$(your-cli command --json)" \
--by cli --desc "command reports the new field after the change"
# larger output (test log, full dump) → file
your-cli command --json > ./proof/result.json
lh verify submit --operation "$LOBE_OPERATION_ID" --item "$CHECK_ITEM_ID" --type text \
--file ./proof/result.json --by cli --desc "full result set"
# a test run is itself proof
your-test-runner path/to/spec > ./proof/test.log 2>&1
lh verify submit --operation "$LOBE_OPERATION_ID" --item "$CHECK_ITEM_ID" --type text \
--file ./proof/test.log --by program --desc "regression spec passes"
Provenance: cli for command stdout, program for a script/test you ran. See
../references/evidence.md for the evidence contract.
The lh CLI you upload with is already authed. A different product CLI under
test carries its own auth (API key or stored login) — configure it before
capturing its output. See ../references/auth.md.
--desc), not a 10k-line log the reviewer must
scan.