raistlin042 0dda56914d fix(apps): read app object from data.app for +create and +update (#1087) ...

* fix(apps): read app object from data.app for +create and +update

The Miaoda OpenAPI returns the application object nested under
data.app for both POST /apps and PATCH /apps/{appId}. The CLI text
helper was reading common.GetString(data, "app_id"), which yields an
empty string against the wire format -- so `lark-cli apps +create
--format pretty` printed `created: ` with no ID.

Navigate the new nested path via GetString(data, "app", "app_id") for
both create and update. Update unit-test mocks to wrap the response
under `app`. Refresh the lark-apps skill references (example response
shape + jq paths) so agents reading them follow the right path.

Wire format is passed through to the user's JSON envelope untouched
-- no unwrapping in CLI. Consumers reading the response should use
.data.app.app_id.

The GET /apps list endpoint is unchanged: per the design doc its
items[] are flat objects, no wrapper.

* docs(apps): add required --app-type HTML to scenario 2 snippet

The "用户没有 app_id" snippet in lark-apps-html-publish.md was missing
the required --app-type flag, so copy-pasting it triggered Validate
("--app-type is required") and left $APP empty -- the following
+html-publish then failed with --app-id "". Bring the snippet in line
with every other apps +create example in the skill.

* docs(apps): simplify auth-recovery rule to error.type == missing_scope

Every apps shortcut declares Scopes, so the precheck path in
shortcuts/common/runner.go:825 is always the one that fires on scope
violations and the envelope's error.type is the stable discriminator.
Drop the keyword-sniffing of error.hint, the chain explanation, and the
bot caveat — they all reduce to one boolean: error.type == "missing_scope"
→ run `lark-cli auth login --domain apps`.

Also collapse the corresponding bullet in 快速决策 to point at this rule.

2026-05-25 23:16:30 +08:00

2.4 KiB

Raw Permalink Blame History

View Raw