Prototype: Evaluate form definition results against success criteria

[mryhmln]

Note: Moved from codeforamerica/safety-net-blueprint#100. Not yet committed to doing this — preserved for future consideration.

Parent

Part of #85 — Prove form definition contracts can drive workflow UI

Goal

Evaluate the prototype results against #85's success criteria, warning signs, and kill criteria. Produce a written recommendation on whether form definition contracts are a viable approach for driving workflow UI.

Success criteria to evaluate

• Task queue columns render from YAML — adding/removing a column requires only YAML change
• Detail view renders sections, fields, and annotations from the form definition
• Action buttons appear/disappear based on visibleWhen conditions (state + role), no hardcoded logic
• Switching roles changes visibility without code changes — same form definition, different output
• A domain expert can read the form definition tables and confirm the UI matches expectations
• Frontend codebase has zero references to domain concepts (SNAP, Medicaid, expedited, etc.)

Warning signs to assess

• visibleWhen expression complexity
• Form definition size and maintainability
• Render performance with visibility evaluation
• Special cases needed in the generic renderer
• Domain expert reviewability vs UI mockups

Kill criteria to check

• Can real-world UI requirements be expressed without escape hatches?
• Is the renderer simpler or more complex than domain-specific UI code?
• Does the YAML indirection help or hurt debugging?

Depends on

• #99 (end-to-end UI walkthrough must complete first)

Done when

• Each success criterion marked pass/fail with evidence
• Warning signs assessed with specific observations
• Kill criteria evaluated
• Written recommendation: proceed / adjust / stop
• If proceed: list of issues for next phase