ask 4: a LOOK row kind in the build plan, tied to the artifact the look obligation already counts #68

What Studio needs

A way to tell, from the build plan, that a step is "a person looks at this", so the Plan and Build rooms can show human validation as a real column rather than inferring it.

Today

skills/brd-to-build-plan.md defines Kind as a closed set of five: BRIEF, BUILD, PROVE, RUN, HARNESS. LOOK already exists, but in a different place: it is stage 4 of the one review pass in skills/module-review.md, with a PROOF-OF-LOOK block. Existing plans express it as a HARNESS row whose Step text names the LOOK pass.

Separately, bin/lib/obligations.tsv already has a look row: scope module, denominator required, artifact design/ui-reviews/ui-review-*.html. That is the existing machine record of "was it looked at".

Blast radius

Rating: needs care, though the code impact is nil.

• No script parses the Kind column. Searching bin/, project-bin/, project-tests/ and tests/ for the existing kinds finds only an unrelated label in report-render.js. So nothing breaks mechanically.
• Both brd-to-build-plan.md and module-review.md are stage mapped, so editing them makes every project's protocol ack stale. Notify by default, blocking under --strict-protocol.
• Backwards compatibility: a parser matching kind == LOOK misses every plan written before this change. Studio should treat a pre-existing HARNESS row whose Step names LOOK as a look row.

The risk is two records of one fact. A LOOK row marked built while no ui-review-*.html exists means the plan says a person looked and the gate says nobody did. gate-check stays honest; the plan lies.

Decision needed

1. Is LOOK a new Kind at all, or is it already served by HARNESS rows plus the look obligation?
2. If new: is a LOOK row satisfied by the same artifact the look obligation counts, so the two always agree? It should never be settable by hand.
3. Does a LOOK row count as the verification row that ends a phase? If yes, a phase could end with nothing executed.

If this and ask 5 both go ahead, bundle their prose edits into one PR so projects see one stale ack notice instead of two.