root
63b2aca8d8
- check_budget.py escalated a hard index-row violation to 'warn' on both branches, so INDEX_ROW_HARD could never fail anything. It fails now, and tests/unit/test_budget_measurement.py pins both thresholds. - The corpus note counted scripts/__pycache__/*.pyc, so the same commit reported 27 scripts after the suite had run and 16 on a clean checkout. - TOKENS_PER_CHAR is re-derived from a measurement (26,795 chars -> 6,065 tokens = 4.418); the comment's old figure and its arithmetic were both wrong for this file. - check_repo.py's yaml sentinel carries the type ignore, so mypy is clean with PyYAML installed as well as without it. - The CPUID test now skips with the probe's own note on a host without CPUID instead of failing, and pytest.ini points at tests/README.md, which exists, instead of an EXTENSION file that never did. Tooling: .flake8 (a measured 120-column limit), .gitattributes, .gitignore and .github/workflows/ci.yml (the five gates, the suite on 3.11-3.14 and a lint job), which is what CONTRIBUTING.md already claimed CI runs. The pull-request template it refers to now exists. Content: pitfalls P26-P34 -- the analysis-level failures the catalogue was missing (sampling read as observation, a self-built parser trusted, a verification that could not have failed, a shell-mangled command line) -- registered in the symptom index and its routing mirror. FINDINGS F11-F15 record the defects above. Tests: the coverage guard derives its subject from scripts/ rather than a hand-written list, pe_triage.py and pe_diff.py gain their first tests, and plan.py / preflight.py are declared uncovered with reasons.
Tool Verification
This directory is not part of the installed skill. It is the evidence record for measurement passes: what was actually run, on what, against which independent method, and what the target could not exercise. It exists so the coverage claims in the skill can be checked against runs instead of being trusted.
When to read it: when a claim's strength decides whether you rely on it, or when you are extending the skill and want to know whether a route has ever been exercised.
What is in here
| File | What it holds |
|---|---|
FINDINGS.md |
defects that this repository's own tools, gates and fixtures found in each other — each with its root cause and the check that now catches it |
TOOL-VERDICTS.md |
per-tool verdicts: present or absent on the development host, what was verified about it from a primary source, and what remains documentation-only |
REPO-DECISIONS.md |
the design decisions behind the layout, the strength vocabulary, and the gates, with the reason each was chosen |
EXTENSION-*.md |
one file per research pass: what the pass covered, what it verified externally, and what it deliberately did not assert |
How to read a record here
Three things make a row usable, and a row missing any of them should be treated as a note rather than as evidence:
- The command. Not "the reader was tested" — the exact invocation, so anyone can re-run it.
- The output that matters. The decisive line, not a log dump.
- The independent method. A second way of arriving at the same answer. A parser agreeing with itself is not a check; a parser agreeing with the value the file declares, or with an independent tool, is.
The rules this directory obeys
- A claim carries its grade.
observed(a command and its output exist),inferred(reasoned from an observation),unverified(assumed, or reported elsewhere and never reproduced here). - A limit cites the measurement that set it. A limit without a constraint behind it is a preference.
- Missing coverage is
unknown, never absence. "The tool was not found" and "the tool does not exist" are different statements; the first names the search. - A measurement that disagrees with a recorded conclusion re-opens it. The conclusion is not quietly edited; the change is described.
- Nothing here names a target. Binaries used for measurement are either built by this repository or are platform images that exist on any Windows installation; no third-party sample is required to reproduce a row, and none is committed.
The relationship to tests/
They are different artifacts and neither substitutes for the other.
tests/asserts what the scripts do. It runs on a bare checkout, offline, in seconds, and it is what CI gates on.docs/tool-verification/records what a route did against a real artifact, including the routes that cannot run in CI because they need a debugger, a driver, a second machine or hardware support.
A green test suite means the parsers and planners behave as documented. It says nothing about whether
a hardware route works on your machine, which is why scripts/hwprobe.py exists and why the hardware
rows in references/evidence-summary.md are graded inferred or unverified with what is missing.