Closure Note Completeness

The closure note is what the desk knows in six months: the next tech's starting point, the
client's record, the billing narrative. Grade the note against the house standard and, unlike a
pure gate, draft the missing pieces from the thread so compliance costs seconds.

1. Retrieve the ticket: full thread, time entries, classification, and the current
   closure/resolution note.

2. Grade the closure note against the house standard (override with the desk's own where
   provided):
   - Issue — what was wrong, in the client's terms, one or two lines.
   - Cause — what turned out to be behind it (or "root cause not determined" stated honestly).
   - Actions — what was actually done, specific enough to repeat or reverse.
   - Outcome — the state at close, in observable terms ("user logging in successfully"), not
     intentions ("should be fine").
   - Confirmation reference — who confirmed resolution and how, pointing at the confirmation in
     the thread (or the validation record for no-contact ticket classes).
   - Follow-ups — anything deferred, scheduled, or recommended, or explicitly "none."

3. Score each element PRESENT or MISSING, strictly from what the note says — an element buried in
   mid-thread notes but absent from the closure note is MISSING (the closure note must stand
   alone).

4. If everything is PRESENT: report pass, one line per element, and let the close stick.

5. If anything is MISSING: draft the compliant closure note from evidence already in the thread —
   an assistive summary/recap can produce the base, then structure it to the standard. Every
   sentence must trace to a thread entry; where the thread itself lacks the fact (no cause
   anywhere, no confirmation), leave an explicit placeholder like "CONFIRMATION: not yet obtained
   - confirm with <user> before closing" rather than papering over the gap. The draft documents
   what happened; it never invents what should have happened.

6. Present the draft. On approval, post it as a plain-text note (no markdown/emojis — it syncs to
   the PSA and is often client-visible in exports). Where the desk's process requires it and the
   confirmation element is genuinely missing, recommend holding the close (move it back to
   ready-to-close) until it exists.

7. For batches, output a compliance table (ticket, missing elements) and offer drafts ticket by
   ticket.

"Should be working" and other intention phrasings aren't an Outcome; require observable state or
an honest "unverified." Don't overwrite or edit the tech's existing note; post the compliant
version as an additional note and say so. Keep language simple and localizable. Posting and any
status hold require explicit approval; grading alone is read-only. This gates documentation only
— resolution truth belongs to Ticket QA Review and the Premature Confirmation Detector.