Plan in Yunxiao 云效 (Alibaba Cloud DevOps) — incl. the non-OAuth credential substrate

Motir-AI creates and updates 工作项 (work items) directly in a connected 云效 Yunxiao (Alibaba Cloud DevOps) project from a Motir plan, mirrored as motir-core work items and kept in sync.

云效 is Alibaba's R&D-efficiency platform, built on the group's own R&D practice and sold through Alibaba Cloud — what an Alibaba-ecosystem team actually plans in.

This story owns the NON-OAUTH CREDENTIAL SUBSTRATE — the second foundation in this epic, and the reason it comes before Feishu Project and CodeArts (both blocked_by it). It is blocked_by Plan in Jira for the write-back engine.

The ADR problem this story resolves

7.16.14 — OAuth is the SOLE live-source auth recorded OAuth connect as the only live-source auth and removed the paste-a-token path. 云效 has no OAuth flow for third-party applications: its OpenAPI authenticates with a personal access token the user creates by hand in the Yunxiao console (个人设置 → 个人访问令牌), scoped by granular per-token permissions and shown exactly once at creation. Three of this epic's four Chinese vendors are non-OAuth, so the ADR is a genuine blocker, not a wording detail. This story therefore delivers:

• An ADR amendment re-opening a credential path alongside OAuth — narrowly, with the reasoning recorded: paste-a-credential is permitted only where the vendor offers no third-party authorization flow, never as a convenience alternative for a vendor that does. This must not silently reinstate what 7.16.14 deliberately removed.
• A credential-kind extension to the connection store — 7.16.10 — ImportSourceIdentity today models an OAuth token pair; generalise it to hold other credential kinds under the same encryption, redaction, and revoke/disconnect guarantees.
• The connect-modal variant — a paste-a-credential connect surface (a new user-facing surface, so it needs its own design pass at expansion) that validates the credential against the live API before storing it, and never echoes it back.

Keep the substrate genuinely vendor-neutral: Feishu Project's plugin credential and CodeArts' cloud key both land on it next, so it must not harden around Yunxiao's shape.

The Yunxiao adapter

• Write API (verified). CreateWorkitemV2 creates a work item in a project — 云效's model spans 需求 / 缺陷 / 任务 / 风险 and more under one 工作项 type system, with SearchWorkitems for lookup and CreateWorkitemRelationRecord for relations. Map Motir kind / type / status / priority / assignee / parent + dependency edges onto that type system and the project's configured workflow.
• Auth header. The personal access token travels in the x-yunxiao-token request header — confirm the exact header and endpoint host against the current API reference at build time; the token is user-scoped, so the permissions the user granted it bound what Motir can write, and a permission-denied response must surface as an actionable connect-time error, not a mid-push failure.
• Sync back — 云效 supports webhooks; wire the vendor-side edit path into the engine's conflict rule.

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) so the read side can reuse it. This story ships no vendor adapter other than 云效's — Feishu Project and CodeArts each bring their own on top of the substrate delivered here.

Not yet expanded into subtasks — expand when picked up.