spike(aidd-ui): link the UI system to code and to external design tools #1121

Problem

aidd-ui keeps its UI system as agnostic Markdown contracts. Two links are missing, and PR #708 lists them as limitations ("No Figma integration"; the Dev wireframe fallback stays until UI capability can be assumed).

1. Design to code. Nothing says which implementation file realises which contract entry. 01-system records canonical source paths per surface, but there is no index a skill can follow from a component or token in the contract to the code that implements it, nor back. Without it, drift between design and code is found by reading, not by checking.
2. Design tools. Teams already hold their design elsewhere (Claude Design, Figma, Impeccable's own documents) or only in code (legacy projects with no design system). The plugin treats external documents as supporting evidence only (authority.md), which is sound, but gives no way to bring them in, nor to know that the external source moved since the contract was last aligned.

The constraint: a participant reported that Claude Design talks to Claude Code through an MCP and that this link does not extend to other coding agents (to be verified by the spike). A plugin that depends on it would break AIDD's host-agnostic position.

This came out of a community lab on the plugin: the design-to-code mapping and the external-tool interface were the two points the presenter had no answer to.

Scope

A spike, not an implementation. Answer, with evidence from at least one real project:

• What minimal mapping from a contract entry to its implementation survives any stack? Compare one file per component against a single index file, and what each means for per-component versioning.
• Which part belongs to aidd-ui and which to aidd-dev (the implementation side owns the code; the contract is agnostic).
• What strict input contract does 01-system need so that any source (existing code, an external design export, nothing) produces the same contract shape?
• How does a contract record where an entry came from and at which version of that source, so a later session can tell it is stale?
• At planning time, when the external source changed, how does the user choose between syncing first and planning against the current contract? 01-system/actions/08-reconcile.md already classifies the differences; the question is the trigger and the choice.
• Which of the host-agnostic options cost least to keep working across Claude Code, Codex and the other supported hosts.

Acceptance criteria

• A written decision for each scope question, each one backed by a run on a real project, not by reasoning alone.
• A recommended minimal mapping format, with one example for a component and one for a token.
• A list of follow-up implementation issues, each scoped to one skill, with the ones that are not worth doing named as such.
• The decision states what happens for a project with no external design tool, and for one with no existing code.
• No dependency on a single host's native design-to-code link.

Prior art in this repo

• PR feat(aidd-ui): govern UI systems and experience contracts #708 (draft): 01-system actions 02-map and 08-reconcile, references/authority.md, "Known limitations".
• aidd-dev:01-plan in PR feat(aidd-ui): govern UI systems and experience contracts #708: revalidates UI-system revisions before implementation and stops on drift.
• ui: design to code #222 (closed): "ui: design to code" placeholder, never scoped.

Out of scope

• Importing from a specific design tool or shipping its connector: the spike decides whether one is worth building.
• Versioning the whole system per component: noted by the spike, decided only if the mapping format needs it.
• A gate on changes to widely reused surfaces: a separate increment once the mapping gives a reuse count.