#1787 landed correct production code and a test that cannot pass on today's
main. The test is the only thing wrong, and only in how it asks.
check_index_coverage answers in the compact table by default, where a field
name never appears:
main.go main.go coverage_unavailable metadata_match read_source_and_reindex []
The test asserts on the JSON field spelling:
strstr(response, "\"freshness\":\"metadata_match\"")
Both halves are right; they were simply written against different response
formats. The branch was cut on 2026-09-02, before that default changed, and
was never rebased -- its CI green is from a main that no longer exists. The
neighbouring coverage tests already pass "format":"json" for exactly this
reason; this one predates them.
So the request gains format=json and the assertions are untouched. Asserting
the field rather than a bare strstr for "metadata_match" is what keeps the
check exact: the value also appears in the table's recommended_action column
and would be matched by any other path's row.
Verified: build/c/test-runner mcp -> 318 passed, 0 failed, 4 skipped. Before
this change the same suite reported 317 passed, 1 failed on identical
production code.
What this is NOT: a production defect. coverage_path_freshness on main uses
cbm_path_info_utf8, exactly as #1787 intended, and the Windows second-vs-
nanosecond truncation it fixes is gone. I checked that by reading origin/main
rather than the local checkout, which was stale at 59a05eb1 and still carried
the old helper -- that misreading briefly convinced me the merge had dropped
the fix, and it had not.
Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.com>
Martin Vogel
96a2fc35df