fix(confidence): stop an unreadable confidence from reading as 0.0

[CaptainMittens]

What this fixes

strtod answers 0.0 for text it cannot read. Two places treat the number
it returns as a real confidence, so a property blob carrying a malformed
value — "confidence":null, an empty string, anything non-numeric — came
back as a recorded confidence of zero. Zero is a meaningful value in
both places, so nothing looked wrong.

1. src/graph_buffer/graph_buffer.c — the wrong blob wins a merge

edge_props_confidence answers CBM_EDGE_CONF_ABSENT (-1) for an edge
that carries no confidence, so that any real confidence outranks it. The
merge in edge_props_should_replace is a plain comparison:

if (inc != cur) {
    return inc > cur;
}

A malformed value answered 0.0, which beats -1. So a blob whose
confidence the code cannot even read displaced a clean stored blob that
simply carried no confidence at all. The stored "strategy" went with it.

The function's own doc comment already promised the correct behaviour:

/* Read "confidence":<double> out of an edge property blob. Absent/unparseable
 * reads as -1 ... */

Only the absent half was true.

2. src/mcp/mcp.c — "not recorded" published as 0.00

bfs_edge_evidence_for_hop sets the confidence to -1.0 first, and the
emitter publishes any value of 0 or more as a recorded number
(%.2f in the text renderer, a real in the JSON renderer) and - / null
below zero. A malformed value therefore printed as 0.00.

That is the one number the surrounding code works to keep meaningful. A
caller reading 0.00 cannot tell "the resolver was certain this call is
wrong" from "nobody wrote a number here".

The fix

Both sites now pass an end pointer to strtod and keep the absent sentinel
when the pointer never moved — nothing was read. This is the shape
src/store/store.c:402 already uses.

const char *value = p + sizeof(conf_key) - SKIP_ONE;
char *end = NULL;
double conf = strtod(value, &end);
if (end == value) {
    return CBM_EDGE_CONF_ABSENT;
}
return conf;

Only the unreadable case changes. A real 0.0 still reads as 0.0
everywhere, and every existing confidence test passes untouched.

Tests

Two tests come with the change. Both were seen failing before the fix and
passing after — not written after the fact.

Test	File
gbuf_edge_props_unreadable_confidence_does_not_displace_absent	tests/test_graph_buffer.c
tool_trace_path_unreadable_confidence_reports_not_recorded	tests/test_mcp.c

Each carries positive controls, so a later failure points at the confidence
and not at a broken request. The mcp test asserts the hop and its readable
strategy class still come through, then asserts the output holds no
0.00.

Red, before the fix:

258 passed, 2 failed, 6 skipped
  FAIL tests/test_mcp.c:3398: strstr(ev_txt, "0.00") is not NULL
  FAIL tests/test_graph_buffer.c:261: ASSERT(strstr(edges[0]->properties_json, "\"strategy\":\"lsp\"") != NULL)

Green, after the fix:

260 passed, 0 failed, 6 skipped   (EXIT=0)

Checks run

Command	Result
make -f Makefile.cbm test-focused TEST_SUITES="graph_buffer mcp"	260 passed, 0 failed, 6 skipped — exit 0
make -f Makefile.cbm lint-ci	=== CI linters passed === — exit 0
make -f Makefile.cbm cbm	exit 0
make -f Makefile.cbm test	7633 passed, 2 failed, 8 skipped

The two full-suite failures are in tests/test_cli.c (lines 1749 and 6725)
and reproduce on a clean tree without this change. Both print
error: one or more agent cleanup operations failed, so they depend on the
coding agents installed on the machine rather than on anything here.

How this was found

By scanning for siblings of the parse bug fixed in #1875 — the same shape
of "a parse reports success while the input stays unread". These two are
the confidence-sentinel pair from that scan. Four more candidates remain
and will come as separate pull requests.

Checklist

• Signed off with git commit -s (DCO)
• make -f Makefile.cbm test run
• make -f Makefile.cbm lint-ci run
• New behaviour covered by a test

Fixes #1980

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

[CaptainMittens]

Context that is not visible from this PR on its own: it is one of four from a single scan.

After #1875 I went looking for siblings of its shape — a parse reports success while the input stays unread. The scan found six. Four are filed: #1875 (the cypher parser), this one (strtod), #1880 (atoi/atol on environment settings), and #1881 (strtoll on span timestamps).

They make the same argument as #1922: an input the code cannot read becomes a plausible value, and nothing downstream can tell it from a real one. The silence is the harm.

Here that value is 0.0, and it is worse than a wrong number. 0.0 outranks the -1 absent sentinel in edge_props_should_replace, so a blob whose confidence could not be read displaced a clean stored blob that simply carried none — and took the stored strategy with it. The function's own doc comment already promised the right behaviour; only the absent half of it was true.

Two more candidates from that scan are not filed yet. Would you rather they came as their own PRs, or folded into one of these?

[DeusData]

Approved. The strongest thing in this PR is that the code disagreed with its own documented contract, and you found it by reading the comment.

I checked it and it is exact. graph_buffer.c:1036:

Read "confidence":<double> out of an edge property blob. Absent/unparseable reads as -1 so any edge that carries a confidence outranks one that does not.

CBM_EDGE_CONF_ABSENT is -1.0, and only the absent half was ever implemented. "Only the absent half was true" is precisely right.

And the consequence is graph corruption, not just a wrong number. strtod answers 0.0, 0.0 > -1.0, so edge_props_should_replace concludes the incoming blob outranks the stored one — an edge whose confidence cannot be read displaces a clean edge that simply had none, and the stored "strategy" goes with it. That is a silent quality loss in the graph, and nothing about it looks wrong afterwards because zero is a legitimate confidence.

The MCP half is the honesty half. 0.00 published for an unreadable value is indistinguishable from "the resolver was certain this call is wrong", which is exactly the distinction -1 / null / - exists to preserve. Reusing the store.c:402 end-pointer shape rather than inventing a third convention is right.

Only the unreadable case changes, a real 0.0 still reads as 0.0, and the existing confidence tests pass untouched — that scoping is what makes this safe to take.

Your tests were seen red first, with positive controls. Asserting the hop and its readable strategy still come through before asserting the output holds no 0.00 means a later failure points at the confidence rather than at a broken request. That is the shape that keeps a regression test useful in two years.

One thing to do

This is now DIRTY, and that is my doing rather than yours. #1703 merged an hour ago and also touches src/mcp/mcp.c. A rebase onto current main should be mechanical — the two changes are in different functions. main also went briefly broken and was repaired by #1993 earlier today, so rebase now rather than onto anything older.

Once it is clean I will re-run and merge. Nothing else outstanding.

Working the class from #1875 rather than the individual bug — confidence here, timestamps in #1881, environment settings in #1880 — is why these read as one audit instead of three coincidences.

[CaptainMittens]

Rebased onto current main (5fbab7bb) — now 62b44519. MERGEABLE again.

One conflict, and it was the adjacent-line kind: #1703 added RUN_TEST(tool_trace_path_evidence_columns_match_header_issue1542) on the line this branch adds RUN_TEST(tool_trace_path_unreadable_confidence_reports_not_recorded). Both registrations belong, so both are kept, yours first. I confirmed each of the two has a TEST() definition and a RUN_TEST() registration afterwards, rather than assuming the resolution was right.

src/mcp/mcp.c auto-merged — the two changes are in different functions, as you predicted. I read the merged hunk to confirm the end-pointer check landed intact.

Built and ran the affected suites on the rebased tree: mcp and graph_buffer together, 303 passed, 4 skipped, 0 failed.

Thank you for checking the graph_buffer.c:1036 comment against the code rather than taking my word for it. The contract being written down and only half-implemented is what made this findable.

[DeusData]

Merged as 7910de59. Thank you — and sorry for the delay; the conflict you had to resolve was caused by our own #1703 merge, not by anything in your change.

The defect is a good one to have caught: an unreadable confidence reading as 0.0 is indistinguishable, downstream, from a genuine zero-confidence result. Every consumer that treats low confidence as "weak evidence" would quietly treat a parse failure as strong evidence of weakness. A sentinel that cannot be confused with a real value is the only way to keep those two cases apart.

Before merging I verified the combined tree, since #1836 landed in the same batch and also touches src/mcp/mcp.c and tests/test_mcp.c — main plus all three, mcp cypher graph_buffer, 493 passed, 0 failed.

That is your third merge today, after #2008 and #1986.