spike(aidd-ui): decide what the experience review adds over the code review #1122

Problem

aidd-ui ships 03-review, an experience review that produces evidence-pinned, nonnormative findings (PR #708). The code side already has aidd-dev review, which reads the same artefacts. It is not established that the UI review finds anything the code review misses, nor where it should sit.

Three overlaps are unresolved:

• The review could target the UI system and the feature's UI contract (is the contract coherent and complete), or the implementation (does the code respect it), or both. The code review has to read the same artefacts either way.
• A review that always reports something is cheap to produce and useless to read. If it repeats the same findings on every run, the fix belongs in the producing skills; it earns its place only if it finds project-specific things that change from run to run.
• The design lifecycle implements first, reviews, then validates the delta. The case of a blocking review is undefined: what becomes of the pending delta.

A reviewer in a community lab on the plugin framed it as two review levels, and asked whether the macro audit of an app, independent of any feature, is a better shape than a per-feature review.

Scope

A spike. Run 03-review on at least two real projects (one with a UI system, one without) alongside the code review and answer:

• Which findings only the UI review produced, which only the code review, and which both.
• Whether the same findings come back on every run (a signal to fix the producing skill instead).
• Where it should sit: a per-feature review, a standing audit of the system, or both.
• What happens to a pending delta after a blocking review: kept, reworked, or dropped, and who decides.

Acceptance criteria

• A table of findings per project, split by which review produced them.
• A recommendation on placement (feature review, audit, both) with the evidence behind it.
• The outcome of a pending delta after a blocking review is specified in the delta lifecycle, or the spike states why none is needed.
• If the review is not justified, the issue lists what to remove rather than leaving it.

Prior art in this repo

• PR feat(aidd-ui): govern UI systems and experience contracts #708 (draft): plugins/aidd-ui/skills/03-review, references/findings.md, references/fingerprint.md; delta lifecycle in 01-system/references/lifecycle.md and delta-path.md.
• aidd-dev:05-review: the code review the UI review overlaps with.
• feat(aidd-qa): make acceptance evidence reliable across real browser journeys #918 (open): acceptance evidence across real browser journeys, adjacent for rendered-browser review, which PR feat(aidd-ui): govern UI systems and experience contracts #708 lists as follow-up.

Out of scope

• Rendered-browser review and visual regression: tracked separately (feat(aidd-qa): make acceptance evidence reliable across real browser journeys #918, PR feat(aidd-ui): govern UI systems and experience contracts #708 follow-ups).
• Changing aidd-dev review beyond reading the UI artefacts.