coderaiser / putout-editor / 36767781060

100%

push

github

docs: what the coverage gate and the 69 sites were actually about

Two entries in putout-rules.md, both written down because the measurement was
the lesson and the fix was not.

A replacer must carry a replace even when it never fixes anything. The
replaceCallbackCounts - 0 under fix:false, 1 under fixCount:1 - are what say the
callback in tester.ts was unreachable rather than merely untested, and the
loader error on removal is what says the key has to stay. An identity
replacement is the shape that satisfies both, and it is the general answer for
any plugin that only reports.

A new rule's first real test is the rest of the repository. 69 sites for
hoist-arrow-callback, and the count is what caught two mistakes: a scoped
putout run is completely silent about .ts, so a rule can look clean while half
the repository is not linted; and a guard belonging to the fixer, put in the
match, hides real code. Spec files were most of the count and are the case where
inline genuinely reads better, so the scope went in - and it went in the root
config, because a match in a package's own .putout.json does not reach another
package.

AGENTS.md carries the operational half - sweep with isTS, keep naming out of
the match, scope spec files at the root - since that is where an agent adding a
rule will read it. MEMORY.md carries the two facts worth recalling cold. The
plugin README says why the rule skips a destructured parameter, and that the
naming question is the fixer's.

The open finding for the mcp coverage gate is gone because the gate passes, and
docs/issues/ is for open problems only.

1081 of 1081 branches covered (100.0%)

Branch coverage included in aggregate %.

6684 of 6684 relevant lines covered (100.0%)

61.36 hits per line