swverifylisted

# /swverify — the tests, and then what they did **In plain words.** This writes the tests, and then records what happened when you ran them. The plan says *do this, and this should happen*. The results say *I did it, and here is what actually happened*. Both come out of the same file, so the results cannot quietly describe a different test from the one that was planned. At the end you get a straight verdict — PASS or HOLD — rather than a paragraph you have to interpret. Two documents from one spec, in that order, because the second is the first with its outcome columns filled in: | Mode | `"results"` | Produces | |---|---|---| | **Plan** | `false` | Verification & Test Plan — what will be run, and what should happen | | **Results** | `true` | Verification Results — what happened, plus the gate | Generating both from the same file is the point. If the results are written as their own document, they end up describing a test run that resembles the plan rather than executing it, and nothing downstream can tell the difference. ## 0. Before writing the plan You need **the URS key file** — `--emit-keys` output from `/swurs`. Every test traces to at least one requirement key, and the script checks in both directions: a requirement with no test is reported as a coverage hole, and a test citing a key that is not in the URS is a hard error. Coverage nobody counted is coverage nobody has. Without the key file the skill still runs and says, in the document, that coverage was not c