Plan in Feishu Project 飞书项目 (ByteDance / Meego)

Motir-AI creates and updates 工作项 (work items) directly in a connected 飞书项目 / Feishu Project space (internationally: Lark Project; formerly Meego) from a Motir plan, mirrored as motir-core work items and kept in sync.

飞书项目 is ByteDance's own project-management platform, marketed as 抖音同款项目管理工具 — the tool Douyin itself runs on — and sold externally. It is the fastest-growing of the four Chinese-giant tools and the one most likely to appear at a modern Chinese product team.

blocked_by two foundations: Plan in Jira for the write-back engine, and Plan in Yunxiao 云效 for the non-OAuth credential substrate — 飞书项目 does not authorize third parties by OAuth either.

The connect model is a PLUGIN INSTALL, not a redirect

This is the structurally different one, and the reason it must not be estimated by analogy with the OAuth vendors. Per Feishu Project's developer documentation, a third party integrates by creating a plugin, declaring the permissions it needs, and having the customer install that plugin into their space; API calls then carry a plugin identity credential. Three token kinds exist:

• plugin_token — the plugin's own identity, which the platform also treats as a user in its own right;
• user_plugin_token — a user identity credential, representing a user's temporary delegation to the plugin (the closest analogue to an OAuth user token, and the one that keeps authorship attributed to the connecting user, per this epic's write-on-behalf-of-the-user rule);
• virtual plugin_token — development/debugging only, and explicitly not a production path.

Consequences to design for, each of which differs from every vendor Motir connects today: the connect step is an install + permission grant inside the vendor's own admin surface rather than a redirect Motir controls, so the connect UI must guide the user through an external flow and then verify installation; permissions are declared at plugin level and must be re-declared (and the plugin re-approved) if Motir's write scope later widens; and the plugin must be published or otherwise made available to the customer's space. Pin the exact token-issuing endpoints, lifetimes, and refresh behaviour against the live developer docs before building — this description records the model, not the endpoint contract.

The adapter

• Write path — the Open API supports creating work items; a plugin must be created, granted permissions, and installed into the target space before it can reach that space's data. Map Motir kind / type / status / priority / assignee / parent + dependency edges onto 飞书项目's configurable per-space work-item types and workflow — this product is heavily template-driven (different spaces model 需求 / 缺陷 / 任务 differently), so read the space's type configuration rather than hardcoding a mapping.
• Sync back — 飞书项目 exposes automation connectors with webhook triggers; use them to push vendor-side edits into the engine's conflict rule.
• Registration is an out-of-band human step (create + publish the plugin, declare permissions) — a manual subtask at expansion, larger than an OAuth-app registration because it involves a review/publish step.

Boundary. WRITE direction only; importing a 飞书项目 backlog is a hand-off to Issue importer in Epic 7. Build the API client against the shipped connector interface (7.16.4a). The credential substrate itself belongs to Plan in Yunxiao 云效 — this story adds the plugin credential kind on top of it, it does not re-implement the store.

Not yet expanded into subtasks — expand when picked up.