inliver233 5c3ba9cd2e Stop reporting a tool's resource failure as a finding about the target ...

A JVM reader that dies on a large or deeply nested input -- OutOfMemoryError, an OOM kill, a
container limit, a timeout -- prints an empty result that looks exactly like a reader that read the
file and found nothing. That is the `present but unreadable` case SKILL.md §Coverage names, and it is
where a wrong "that class is not in there" gets recorded.

The new section in toolchain.md says what a failed analysis actually supports (a claim about the
route, not about the artifact) and the three things to check before a negative from a heavy tool
becomes a finding: the exit code and stderr rather than stdout alone, a re-run with room to work, and
the indexed-query route that answers most location questions without materialising anything. A
deadline you set yourself gets the same reading -- it reported nothing about the target.

Also: the README claimed the scripts "work identically on Windows, macOS and Linux", while every gate
run, every test result and every figure in the evidence record comes from one Windows host. The claim
now carries the strength it actually has -- measured on Windows, `unverified` elsewhere -- and names
the usual suspects (path separators, `os.pathsep` in `APKREV_TOOLS`, console encodings, ADB shell
quoting) so a first run on another platform has somewhere to look.

2026-10-16 19:20:45 +08:00

..

apk-reverse

Stop reporting a tool's resource failure as a finding about the target

2026-10-16 19:20:45 +08:00