feat: merge records a conditional fact instead of applying it

[ShocOne]

Phase 7.4, step one — the guard that closes the class of bug this phase exists for.

The problem, precisely

Behaviour is unconditional by construction: one Writable, one ReturnedOnRead, one RejectedValues per attribute. Writing a fact that holds only under a precondition into any of those turns it into a claim about every case.

That is exactly how the pilot came to suppress matchType's read-back for every tag on the strength of an observation about static ones, and how endpoint-agent came to sit in objectType's rejected set.

The fix

A fact with a precondition goes into the description with its condition stated, and nothing generates from it.

Both halves are load-bearing. Applying it is the bug. Dropping it silently would lose evidence somebody paid a live run for.

The guard sits immediately after the suspected-facts guard, in the same shape and for the same reason — both say "this fact is not a strong enough claim to put in the schema", differing only in why.

Result gains Conditional alongside Ignored rather than reusing it. Ignored would be the wrong word: these facts are strong enough to act on and were withheld because the schema cannot express the condition, not because the evidence was weak. Somebody deciding whether to trust a schema needs to tell those apart.

The condition reads first in the prose, because the claim is wrong without it:

matchType is not returned on read
when objectType is endpoint-agent, matchType is not returned on read

Four tests, and the control matters as much as the subject

Driven through Apply rather than the internal helper.

• The subject: a Corroborated conditional fact — deliberately strong, so the test cannot pass because it was too weak — does not reach Behaviour, and does reach the description with its condition.
• The control: the same fact without a condition still reaches Behaviour. Without this, the suite would pass if merge had quietly stopped applying returnedOnRead altogether — a different bug wearing the same green tick.
• Both branches: two facts from one gate are both recorded and neither wins. An attribute whose description carries only one branch reads as though that branch were the whole truth, which is where this started.
• Idempotence: a second merge changes nothing, which merge -check depends on.

Mutation tested: disabling the guard fails two of them, the second with neither branch may win: false — one branch silently winning, the original bug reproduced exactly.

Step two is deliberately not here

Behaviour holding conditional variants, so emission can act on them, waits for the re-record. There is nothing conditional in the committed facts yet to shape the storage against — and designing the storage before seeing the data is how the unconditional model came to be written in the first place.

Verification

gate	result
go test ./...	pass
probe -mode verify	38 facts reproduced
merge -check	idempotent
verify	24/24, no orphans
gofumpt -l . / golangci-lint	empty / 0 issues

🤖 Generated with Claude Code