ops-claim-verification

Topics in the source

• Ops claim verification
• 0. Quote the authority clause, not its direction
• 1. Find the surface that actually records the claim
• 1b. Evidence bundles handed to an external auditor
• 2. Separate a manual reproduction from the scheduled run
• 3. One green run is not restoration
• 4. Report the finding so it survives the next reader
• 5. "Pre-existing / unrelated failure" is a claim, not a waiver

Any statement about a scheduled job, a repair, or a deployment is a claim about an environment at a moment. This skill converts it into evidence before it reaches the owner or a teammate. Read the exact line that grants or withholds permission, then enumerate what it does not cover. A policy that makes commit/push a sync service ("per-run approval is gone") usually leaves the adjacent gates standing: persistent profile/config/memory/schedule/session writes still need explicit owner scope. Removing one gate is not removing the lane next to it. If you release a teammate on a misread clause, you are the one who authorized what the owner still gates — and the teammate who refuses is right. Absence in one file is your search error, not the sender's fabrication. Locate the record first, rule second. Scheduled job outcomes live in the scheduler's per-run output, not the agent log. Common layout: /cron/output/ / .md (full stdout/stderr, Script exited with code N), while the agent log prints only the first line of the injected prompt. Grepping the log for a traceback returns 0 on a genuine failure. The wake is the signature. A logged gate decision (wake=false, skipping agent run) = the gate

This is an excerpt. Refer to the complete source and its current requirements.