CLI E2E Testcase Writer

• workflow testcase files under tests/cli_e2e/{domain}/
• tests/cli_e2e/{domain}/coverage.md

Core standard

• Make the testcase scenario-based and self-contained.
• Prove one workflow end to end: create plus follow-up read, or mutate plus teardown.
• Prefer one file per workflow or one closely related feature.
• For mutable flows, prove persisted state with read-after-write assertions, not just exit code.
• Leave prerequisite-heavy paths uncovered when they cannot be proven, and explain why in coverage.md.

Workflow

1. Explore the live CLI before writing code

lark-cli --help
lark-cli <domain> --help
lark-cli <domain> +<shortcut> -h
lark-cli <domain> <group> --help
lark-cli <domain> <group> <method> -h
lark-cli schema <domain>.<group>.<method>

2. Count leaf commands for the denominator

• A leaf command is one that executes an action — it has no further subcommands.
• If lark-cli <domain> <group> --help lists no subcommands, <group> itself is the leaf.
• Count task +create as one leaf and task tasks get as one leaf.
• Do not count parameter combinations.
• Reuse coverage already present under tests/cli_e2e/{domain}/. Do not count tests/cli_e2e/demo/.

3. Choose the proof surface before editing

4. Add or update the workflow testcase

• Use clie2e.RunCmd(ctx, clie2e.Request{...}).
• Put command path and plain flags in Args; put JSON in Params (URL/path parameters) and Data (request body).
• Prefer one top-level test per workflow with t.Run substeps.
• Register teardown on parentT.Cleanup so it survives subtest failures.
• When touching an existing command, verify the JSON response shape is stable: assert status type, field paths, and identifiers consumed by later steps before changing assertions.

5. Run and iterate

6. Refresh the domain outputs

• Update the workflow testcase files.
• Update coverage.md: recompute the denominator from live help output, mark each command as shortcut or api, and keep one command table for the whole domain.

Testcase rules

• Override BinaryPath, DefaultAs, or Format on clie2e.Request only when the testcase truly needs it.
• Use require.NoError, result.AssertExitCode, result.AssertStdoutStatus, assert, and gjson.
• Shortcut responses ({ok: bool}) assert true; API responses ({code: int}) assert 0.
• Use t.Helper() only for setup or assertion helpers that are called from multiple tests.
• Use table-driven tests only when the scenario shape repeats across inputs.
• For expected failures, assert stderr content and exit code when the environment makes them deterministic.
• If identity or external fixtures cannot be proven, leave the command uncovered and document the prerequisite rather than faking confidence.

coverage.md

• a domain-specific H1 title
• a metrics section with denominator, covered count, and coverage rate
• a summary section restating each Test... workflow, key t.Run(...) proof points, and main blockers
• one command table for all commands

# <Domain> CLI E2E Coverage

## Metrics
- Denominator: N leaf commands
- Covered: N
- Coverage: N%

## Summary
- TestXxx: ... key `t.Run(...)` proof points ...
- Blocked area: ...

## Command Table
| Status | Cmd | Type | Testcase | Key parameter shapes | Notes / uncovered reason |
| --- | --- | --- | --- | --- | --- |
| ✓ | task +create | shortcut | task_status_workflow_test.go::TestTask_StatusWorkflow | basic create; create with due | |
| ✕ | task +assign | shortcut |  | none | requires real user open_id |

• Mark each command shortcut or api.
• Write testcase entries in go test -run friendly form.
• Commands only exercised in parentT.Cleanup teardown are not counted as covered.
• Do not split covered and uncovered commands into separate sections.

Guardrails

• Run as bot identity only; do not assume --as user works.
• Do not place new real coverage under tests/cli_e2e/demo/.
• Do not depend on preexisting remote data.
• Do not fabricate open_ids, chats, docs, or other remote fixtures.
• Prefer deterministic negative cases over tenant-dependent assertions.
• Do not guess Params or Data fields when help or schema can tell you the exact shape.
• Do not hardcode obvious defaults unless the command truly requires explicit flags.
• Do not put agent, model, or vendor brand names in visible remote test data; use neutral prefixes such as lark-cli-e2e- or <domain>-e2e-.
• A command is covered only when the testcase asserts returned fields or persisted state, not just exit code.
• Cleanup-only execution is not primary coverage, except delete in the same workflow that created the resource.