sylpheed-port inverted my documented->exists sweep into parsed->documented and found three live undocumented flags, with the framing that a capability existing only in an 11 000-line record is, to a reader of the interface, a capability that does not exist. The mirror on my side is env vars the CODE reads, checked against the docs. Like theirs it enumerates, so it completes rather than samples. 41 read by crates/, 19 documented, 22 not. The 22 split cleanly: 7 are read only in examples/ (per-example filters and dump paths, reachable only by editing an example's command line), and 15 are read in src/ -- live capabilities of the library and CLI. Ten are mesh/3D toggles and five are XPR_* texture-decode toggles. FOR THE PORT: none of the 15 is in the UI path. Every env var ui_layout.rs and the screen commands read is documented -- SYLPHEED_REST_RULE and SYLPHEED_KF_TIME_LEGACY. The menu lane is clean in this direction. But the five XPR_* are texture-decode toggles and the port consumes textures, so if a sprite comparison ever disagrees those are the knobs and they are invisible from the interface. LIMIT, stated rather than glossed: I verified NONE of the 15 end to end. `texture export` takes a loose file and the disc keeps its textures inside paks, so the check cost more than the answer was worth here. That matters because the port found --no-hold parsed, documented AND INERT under an interaction with --time: "parsed and reachable" is not "works". The honest claim is that 15 undocumented env vars are READ, not that 15 capabilities exist. METHOD: sweep the surface in both directions, and note that both directions enumerate and therefore complete rather than sample -- rare enough in that file to be worth preferring when available -- while neither establishes that the thing works. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2.0 KiB
2.0 KiB