Working with findings

After /lamina-verify, findings tell you what does not match the contract. This guide covers how to read fix.md, fix product gaps, handle contract deltas, and know when to re-verify vs re-design.

Quick path

1. Read fix.md, report.md, and findings[] in run.json
2. For fix_target: product → your agent fixes app code
3. For fix_target: contract → re-run /lamina-design
4. For fix_target: ops → note in report.md only — no app or contract fix
5. Re-verify until zero open product or contract findings

Where findings live

Reading a finding

Each finding includes:

Product fixes (fix_target: product)

When the app does not match the contract, your coding agent fixes app code in a normal coding session — not during a Lamina command.

1. Open fix.md in .lamina/runs/<id>/
2. Prompt your agent:

Fix the product issues listed in .lamina/runs/<id>/fix.md.
Address each finding by id. Do not change styling — fix behavior only.

3. Re-verify:

/lamina-verify guest checkout at http://localhost:3000

Contract deltas (fix_target: contract)

When the contract itself is wrong — missing workflow, incorrect invariant, wrong permission — the finding has fix_target: contract.

1. Do not change app code to work around a contract gap
2. Re-run design with a scoped update:

/lamina-design Update checkout workflow — add email verification gate
before payment per finding checkout-email-gate-001

3. Review updated implement.md
4. Your agent implements the contract change
5. Re-verify with the same bounded flow and URL

Ops observations (fix_target: ops)

Some findings are operational observations — deployment gaps, monitoring hooks, or process notes that belong in report.md only. They are excluded from fix.md and do not require app or contract changes. They also do not block the product/contract exit condition.

Prioritization

Address findings in this order:

1. Severity — critical permission gaps and data integrity issues first
2. Dependencies — fix reachability issues before dependent workflows
3. Actor coverage — ensure all primary personas can complete core flows
4. Edge cases — scenarios and recovery paths after happy paths pass

Partial fixes

Re-verify after every fix batch, not just at the end. Partial fixes often reveal new gaps:

fix 3 findings → verify → 2 resolved, 1 new finding → fix → verify → clean

When to re-design vs re-implement

Exit condition

The fix loop ends when:

• No open product or contract findings remain in findings[] or fix.md
• /lamina-verify reports no open product or contract gaps for the named flow
• fix_target: ops observations may remain in report.md and do not block exit

Example from HavenStay

Verify caught that properties could go live without admin approval — a fix_target: product finding. The fix brief specified adding an approval gate to the publish workflow. After the coding agent implemented the fix, re-verify confirmed the gate held for all actor walks.

Next steps

• /lamina-verify — run verification
• The loop — full workflow cycle
• Troubleshooting — common verify issues