The Punch List Template

At the end of a job you walk the site and write down everything that is not done-done. Not "mostly works." Not "the AI said it works." Done means a real person did the real thing on the real system and watched it happen. This list is also the state file that survives the worker forgetting: a fresh session with zero memory should be able to read it and know both what "done" means here and whether the last thing actually got done.

Pull it out at the end of every build, and keep it alive during the build. If your punch list can't survive one compaction, it's theater.

The header

• Job / build: which project this belongs to
• Walkthrough date: when you walked it
• Walked by: who actually looked. Not who was told it works.

Each item (repeat this block for every one)

• Item: the broken, missing, or half-built thing, in one line. "Contact form" is not an item. "Contact form submits but no email arrives" is.
• Where it lives: file, page, URL, container. The next person should find it in under a minute.
• What "fixed" looks like: the observable result, written down before the fix. "Email lands in the inbox within a minute with the customer's message in it."
• Verified how: real browser, real device, real user. You load it and watch it work. A claim of done from the machine verifies nothing; it reports done with the same confidence when it's wrong.
• Verified by / date: who watched it, and when
• Signed off by: the human whose name stands behind "done." Nothing comes off this list without a name on it.

The rule

An item comes off the list one way: somebody watched the fixed thing work, for real, and signed. A punch list that lies is worse than no punch list, because now you trust something you shouldn't. Keep it honest and the job survives its workers.