Skip to content

moooon

Motir

Vibe your whole project. Bring an idea — Motir's three AI layers plan it, track it, and ship it, end to end. You're looking at Motir, built in Motir.

  • Vibe Project
  • Open Source
  • AI Agent
  • AI Loop
1
requests
0
upvotes
145
planned
1,366
shipped

Motir · Roadmap

MOTIR-1723Blocked

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

Opened by Zhu Yue ·

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.

Discussion

No comments yet.

Adding to this discussion signs you in on app.motir.co and brings you back to this request.

Add a comment