yannikzz/ui-contract/ui-contract-baseline

Baseline — measure the as-built state

Produces as-built.md at the repo root (skeleton: as-built-outline.md), and fills in the legacy-strategy section of the config file that ui-contract-setup created.

For the interview discipline, call the Skill tool with "decision-interview". For recording the legacy strategy, call the Skill tool with "decision-record". For the deliverable's language and terminology, call the Skill tool with "deliverable-language".

Preconditions

Artifact paths come from `docs/ui-contract/config.md`'s paths table. If that file doesn't exist, the specs are at the repo root. Never assume a path the config contradicts.

Why this exists

Skipping it on an existing project means writing a structural spec that invents a region tree with no relationship to reality. Enforcement then locks that invention into the type system, and the whole repo lights up red.

That is why the structural spec hard-stops without this file — it is a stop, not a reminder.

Record what is, not what should be

The single discipline of this unit. Use the names the code actually uses, even bad ones. Record the parameter values actually present, including the three inconsistent copies. Every improvement you make while transcribing destroys the mapping that the reconciliation depends on.

Judgements about what should be belong to the structural spec, one step later.

Reading mockups with suspicion

A mockup is an exploration, not a spec:

• Repeated elements are usually copy-paste artifacts. Six identically-named rows in a sidebar, five rows of the same string in a list — ask "is this intent or placeholder" before writing it down as a structural fact.
• Ownership follows geometry, not intuition. A bar that extends over the right-hand column does not belong to the left card. Facts like this change the whole region tree — and therefore change where new features are allowed to go.
• When the mockup contradicts the code, record both and let the user decide. Do not silently pick a side.
• Value drift (9px / 13.5px and friends) is normal in mockups. Converging it belongs to the visual spec, not here.

Ask about legacy only after measuring

Once the gap table is filled in, and not before, ask how existing code should be treated:

Do not recommend one of these from first principles. The gap table's "cost to close" column is what makes this answerable — read it back to the user and let the numbers argue.

Whatever they choose is hard to reverse, excluded real alternatives, and has a nameable revisit condition. It gets a decision record.

Before you call this done

• [ ] Every finding states its source and reliability; inferred facts are marked as hypotheses
• [ ] Names are as-found, not improved
• [ ] The gap table has a cost estimate on every row
• [ ] Naming collisions with the future allowlist are listed
• [ ] The legacy strategy was asked after the gap table existed, and recorded as a decision record