Prove It Live Before Done

Prove It Live Before Done

Mark's strongest reflex: he refuses to accept 'done/fixed/shipped/tests pass' on your word. He drives the real product himself and names what's still broken (that worked but now the skills path dont reflect the calls properly; got the confirmation but no email sent). Adopt his skepticism as the default — your job is to DISPROVE the completion claim, not announce it.

Core rule: a claim is not proof. Exercise the real thing.

A UI confirmation toast is NOT proof the email sent. A green workflow is NOT proof the new revision is live. A passing unit test is NOT proof the feature works through its real path. Map each claim to the right proxy and check THAT:

Step 1: Gate every forward step on a green, machine-checkable signal

Never merge, deploy, scale, or advance a phase on red or pending. Always specify the branch for both outcomes — Mark does this reflexively:

• merge it if green / merge the green ones
• Gate PASS → mark done, write next brief. Gate FAIL → write fixup, dispatch on desktop main, schedule wake
• If all 5 checks are green: stop the loop, then gh pr merge. Else resolve and re-run.

If the signal is pending, do not proceed — poll (see fleet-dispatch-and-watch) or report and wait.

Step 2: Require a multi-signal definition of done

One signal is never enough. Mark defines done by the end-to-end outcome:

• Report file exists AND commits present AND gate passes on a real machine
• Agent says DONE AND its branch is on origin (when sen-259 shows DONE and its branch is on origin)
• Code changed AND migration actually run
• Feature exists AND it exercises the intended mechanism (the right path, not a stub)
• Coverage meets the numeric bar (we need at least 90%)

Step 3: Confirm the deploy is actually LIVE

A release is incomplete until the deployed artifact is confirmed in production — not when the workflow says success.

• https://chat.beta.sentienthome.ai/ live? — hit it.
• check the v1.5.11 deploy status — by exact version, across iterations.
• Confirm the new ECS taskDef revision is running / the Render dashboard shows the version.
• If passive polling stalls, switch to the authoritative dashboard (check the render dashboard).

Step 4: Confirm a mutating command actually took effect

After any script/command/correction that changes external state, do not assume success. did it work? — paste the actual execution output and verify it. Cross-check deployment integrity against an external source (the commit URL) to confirm the specific changes shipped. did we confirm the change when we ran the script?

Step 5: Confirm the chain actually advanced

A completion signal does not imply the next stage fired. Probe it: does that mean the deploy started?, have we pushed a tagged version of the code?, is that pino work already merged in?. When multiple actors did work, demand explicit confirmation: i had another runner doing work — can you absolutely confirm nothing is live?

Step 6: Audit coverage across the WHOLE surface

Don't accept that a concern exists 'somewhere'. Sweep it:

• do we have pino log coverage across the app? — all apps, all containers.
• i need that 100% resolved across apps before moving to the next thing
• After fixing one layer, check downstream holds separate state: luke is unable to login to the monorepo — can we confirm they are also the same in RDS?
• Check adjacent/parallel categories that may have been missed.

Step 7: Reconcile against the system of record

Distrust secondary tracking state. Before accepting a 'completed' list, cross-check against git / Linear / the real machines:

• are they accounted for in linear? / did we track all the platform tickets?
• Backfill tickets from actual commits; enumerate exactly which commits/features are missing rather than asking open-endedly: its missing a lot of commits — the updated message ui, the conversation api logic... its all missing
• is the code on desktop wsl? — confirm committed code landed on the specific machine.
• Cross-check the rendered UI against the source artifact: check the html folder, you are not properly reflecting the conversation ui.

Step 8: Report the residual defect in expected-vs-actual terms

Close with what's still wrong, stated as this is my expectation / this is what im getting — never 'works for me'. If it's truly clean, say which real action you ran and what you observed.

Red flags