feat(base): support Base Home APIs and home-level shortcuts

[736087303-stack]

Summary

Please add support for Base Home APIs to lark-cli, including registered API schemas and agent-friendly shortcuts for Base Home discovery and governance.

Terminology: Base Home is the official product name. If the upstream OpenAPI schema uses a different resource or field name (for example, workspace), native commands and flags should mirror that schema, while user-facing help and skill documentation should describe the feature as Base Home.

The current base command already provides broad coverage inside a known Base token (tables, fields, records, views, dashboards, workflows, forms, roles, and permissions), but it does not expose Base Home operations.

Environment

• lark-cli version: 1.0.76
• Verified with: lark-cli base --help

Problem

In tenants that organize multiple Bases through Base Home, agents and automation currently need pre-recorded Base tokens or manual UI navigation before they can operate.

There is no obvious CLI workflow to:

1. Enumerate Base Home resources accessible to the current user or app.
2. Get Base Home metadata and permission information.
3. Enumerate the Bases presented or organized in Base Home.
4. Place a newly created Base into a specified Base Home location, or move/copy an existing Base there, when supported by the upstream OpenAPI.
5. Inspect or manage Base Home members and roles, when supported by the upstream OpenAPI.

This creates a discovery gap between tenant-level organization and token-level Base operations. It is especially limiting for AI agents that should discover resources through stable identifiers instead of relying on manually maintained links.

Requested capability

Phase 1: read-only discovery

Please register the official Base Home API surface first. Semantic shortcuts could follow names such as:

lark-cli base +home-list --as user --page-all
lark-cli base +home-get <official-id-or-token-flag> --as user
lark-cli base +home-base-list <official-id-or-token-flag> --as user --page-all

The exact identifier flag should follow the official OpenAPI schema rather than inventing a space_id. Suggested structured output should include stable identifiers, display names, access/role information, pagination metadata, and Base tokens/URLs where the upstream API returns them.

Phase 2: governed writes

If supported by the official OpenAPI, consider commands for creating, moving, or copying a Base into a Base Home location and for managing Base Home membership. Command and flag names should match the official schema; for example:

lark-cli base +base-create <official-home-location-flag> ...
lark-cli base +base-move --base-token <token> <official-home-location-flag>
lark-cli base +home-member-list <official-id-or-token-flag>
lark-cli base +home-member-add <official-id-or-token-flag> ...
lark-cli base +home-member-remove <official-id-or-token-flag> ...

Write operations that change placement, membership, or permissions should follow the CLI's existing risk classification, --dry-run, and confirmation-gate conventions.

Expected CLI integration

• Use Base Home consistently in user-facing command descriptions, help text, skill documentation, and examples.
• Preserve official OpenAPI resource and field names in native commands and machine-readable output.
• Support both --as user and --as bot where the upstream API allows them.
• Expose required scopes and identity limitations in --help and the lark-base skill.
• Preserve standard JSON success/error envelopes.
• Support normal pagination flags, including --page-all, where applicable.
• Register the underlying schemas so users can still call native resource commands before every shortcut is implemented.
• Clearly distinguish the Base Home resource identifier returned by the API from a Base token/app token.

Acceptance criteria

A user or agent can start without a pre-recorded Base token and:

1. Enumerate accessible Base Home resources through the official OpenAPI.
2. Select one using the stable identifier returned by that API.
3. Enumerate the Bases associated with it.
4. Continue with existing Base commands using a returned Base token.

A read-only first release would already close the main discovery gap; write-side Base Home management can follow separately if needed.

If the Base Home API is not yet publicly exposed by the upstream OpenAPI, the first useful outcome is to document that dependency explicitly and avoid implementing against undocumented private endpoints.

[736087303-stack]

Implementation prep update:

• Fork and feature branch are ready.
• I checked the official Feishu llms.txt Base/Docs index, the latest remote CLI metadata registry (/api/tools/open/api_definition?protocol=meta), and larksuite/oapi-sdk-go. None currently exposes a Base Home resource or method schema.
• The CLI repository does contain the scope name base:workspace:list in internal/registry/scope_priorities.json, but there is no corresponding registered endpoint, parameter schema, or response schema.

Could a maintainer confirm the public Base Home OpenAPI endpoint/schema (and whether it is user-only)? I am intentionally not implementing against undocumented private frontend endpoints. Once the public schema is available, I can continue with the read-only discovery shortcut, tests, and lark-base skill documentation.