Domain vocabulary for comment-checker: words with codebase-specific meaning that solutions docs and instructions cite without redefinition.
A comment that says, in prose, what its adjacent code already says — the
filled-in words or the verb-to-operator mapping ("increment" ↔ +=) are
the same fact twice. Distinct from a justification, which adds a reason the
code cannot show.
A comment that names the control construct the adjacent code already
displays ("loop over each" beside a for) — the kind that reads like
spoken code and adds nothing.
The tokens or verb→operator matches a restatement verdict was built on, published with the flag so the reason is checkable against the code. A verdict that cannot cite verified evidence is not emitted.
Structural context (the adjacent-code window) that cannot vouch for the comment because the input was a fragment: Edit/MultiEdit boundaries truncate what the hook can see. Verdicts that depend on context never convict on unreliable context — they fail open (spare). Explicit text-only rules (unlike restatement) still apply on fragments, because they need no context.
The production parse's adjacent-code snippet when the hook had the whole file and the code window is trustworthy; the only input context-aware verdicts may cite.
A per-kind/precision-recall gate on the corpus that trips when a kind's classifier weakens — including a single-case kind that goes wrong — so a weakness in one kind cannot hide inside an aggregate F1 score.
The root package (@systemfsoftware/claude-code-comment-checker) whose
bin is the comment-checker shim. It resolves the host platform package by
identity at runtime and spawns the binary — the only package that declares a
bin.
One per os-cpu pair (-linux-x64, -linux-arm64, …), generated from
scripts/lib/targets.json: ships only the compiled binary and its
manifest (os/cpu/libc fields, no bin). The launcher's
optionalDependencies pins all three to the release version.
The committed launcher manifest never lists these packages as
optionalDependencies — pnpm cannot lock the platform packages
(pnpm#3960), so the pins are injected from the targets table when the launcher
is packaged; absence in-tree is expected, not a defect.
Releases run through the shared toolchain
(systemfsoftware/pnpm-release-management), configured by release.jsonc: a
version with no vX.Y.Z git tag is owed a tag and a GitHub Release, so the
phase is derived from repository state, not a pull-request ref. Consumers take
the package from this repository's own Nix flake (built from source) at the
tag; nothing is published to a registry.
The turbo task cache that stores the mutation gate's result keyed on the gate's input set; unchanged inputs replay the stored verdict instead of re-running the mutant loop.
Two hash surfaces govern it. The task hash is the gate's own key: every file that can change the verdict must be an explicit task input — automatic coverage extends only to the script body and declared env values. The transport key (the CI cache step's key) must be a superset of the task hash surface, because an exact-key restore suppresses the post-run save: a narrower transport key does not replay stale verdicts, it discards fresh ones.
An index that lets a Claude Code / OMP installer discover and pull a plugin from a marketplace source. Distinct from the plugin manifest: the catalog declares the marketplace and lists each plugin with a source, while the manifest carries the plugin's authoritative name and version. A catalog carries no version of its own — the version lives only in the manifest, so the catalog is not a release surface.
The explicit, enumerated set of manifests a release bump updates atomically. A manifest not on the list is intentionally outside the gate: keeping a file off the surface means its version can never drift out of step, and adding a manifest to it is a deliberate decision, not a default.
A verification mechanism (a hook, a gate, a check) exits success while checking nothing — the failure mode of going green. Distinct from a false negative, which is a wrong verdict on a real check; a silent pass means the check never ran, the input never reached it, or its failure was swallowed. A hook must never claim a check that did not happen: an absent or failed checker reads the whole payload and exits with guidance, a flagged write exits with the report, and no surface ends in a blanket success. Avoid: fail-open (reserved for the classifier's deliberate spare)
- "context" had been used for both the language (scope/position) and the evidence (adjacent code) — these are distinct; adjacent syntax is the only context that carries the mention.
- "fail open" in the classifier spares a comment it cannot judge (a deliberate conservative verdict) while "silent pass" in the hook gate exits green while checking nothing (a defect) — distinct meanings, distinct domains.