Lark CLI Router

4. Inspect, execute, and verify

1. Treat metadata.cliHelp as a help recipe, not always a literal command. Run its concrete commands; resolve any placeholder from the loaded guide first. If the field is absent, use the guide's own commands or the selected domain's --help.
2. Prefer a matching +shortcut; otherwise use a typed resource command.
3. Before a typed call whose parameters are not already explicit in the guide, run lark-cli schema <service.resource.method>.
4. Use lark-cli api only as the documented escape hatch when no shortcut or typed command covers the endpoint.
5. Preserve any explicitly supplied --profile; never guess a profile or identity. Use lark-cli whoami when identity is material or ambiguous. Before a read through another existing profile, confirm that it belongs to the requesting user and that the profile/read is already authorized. Keep --profile explicit; do not switch the global profile or enumerate unrelated accounts. If ownership is unknown, skip that candidate and report the gap. Different app-specific openIds alone do not establish different people.
6. For writes, use --dry-run when the command supports a useful preview. If a high-risk write exits 10, present the proposed action and wait for explicit human confirmation; never append --yes automatically.
7. Separate transport completion from business success. Process exit 0 alone does not prove the requested result; for JSON output, inspect ok and errors as well. Outer ok == true does not prove each item succeeded. Do not test for a top-level code == 0; interpret domain results using the loaded guide. For batches, reconcile each requested resource identity with its returned item, error and expected result/artifact. Identify missing, duplicate and unrequested items; a duplicate never fills a missing request. Count verified successes, explicit failures and missing/unknown results against the request total, counting each requested identity at most once; report anomalies separately, and report partial whenever any requested result is not verified. For example, three requested items with one verified result, one permission error and one missing item are partial: 1/3 successful, 1 failed, 1 missing, even with exit 0 and outer ok == true.
8. After a write, follow the selected guide's domain-specific verification contract. If it defines none, perform the narrowest independent read that proves the requested state changed. A guide that explicitly forbids an opportunistic second query takes precedence. Report partial results or missing coverage.

On authentication or permission errors, load lark-shared and its embedded lark-shared/references/lark-shared-identity-and-permissions.md. Follow its user/bot and missing-scope branch, and interpret the current CLI's auth status:

lark-cli --profile "<authorized-profile>" auth status --json

Do not classify needs_refresh as unusable login. When the status says it will auto-refresh on the next user API call, an already-authorized ordinary read may proceed with explicit --profile and --as user; let the CLI renew normally. Do not initiate login, new grants/scopes or manual credential writes merely to handle that state. A ready token still does not prove target read permission.

Scope an actual target read-permission denial to its target/profile/identity and stop that route. Do not turn authentication failures or that refusal into retry loops or browser/raw-API fallbacks. It does not prove that every other already-authorized profile of the requesting user is denied. Assess another profile only after the ownership/authorization check above, and verify its own target result rather than assuming access.