proof-of-work

> Claims without evidence fail the people who depend on > your work. Proof-of-work is humility in practice: > "it looks correct" is not "I verified it works." # Proof of Work ## Table of Contents - [Overview](#overview) - [The Iron Law](#the-iron-law) - [Usage Standards](#usage-standards) - [Validation Protocol](#validation-protocol) - [Integration](#integration) - [Validation Checklist](#validation-checklist-before-claiming-done) - [Red Flag Self-Check](#red-flag-self-check) - [Exit Criteria](#exit-criteria) ## Overview The "Proof of Work" methodology prevents premature completion claims by requiring technical verification before stating that a task is finished. For example, instead of assuming an LSP configuration functions after a restart, we verify that the server starts and that tools respond to queries. This approach confirms the solution works before the user attempts validation. Before claiming completion, provide reproducible evidence of the solution's performance and address edge cases. All claims must be backed by actual command output captured in the current environment. ## The Iron Law **NO IMPLEMENTATION WITHOUT A FAILING TEST FIRST** **NO COMPLETION CLAIM WITHOUT EVIDENCE FIRST** **NO CODE WITHOUT UNDERSTANDING FIRST** The Iron Law prevents testing from becoming a perfunctory exercise. If an implementation is planned before tests are written, the RED phase fails to drive the design. Understand the technical rationale for an approach and its limitations...