mirror of
https://github.com/PerpetualSoftware/pad.git
synced 2026-09-11 13:28:57 +00:00
xarmian
130c854052
Codex round 17, one P1, and it is the third consecutive round where my
own fix generalized a property verified on one subset to the whole.
Round 16 gated the padded-entry refusal on "no `fields` object",
reasoning that a `fields` object makes reshapeItemFields re-emit the
entry canonically. That holds for keys IN that object. With `fields:{}`,
or a `fields` carrying some OTHER key, nothing canonicalizes
`field:["status = done"]` and it reaches the doors padded exactly as it
does with no `fields` at all — HTTP writes `status`, the CLI writes a
junk `"status "` beside it.
The predicate is now the actual question: will anything canonicalize
THIS key.
The pattern is worth naming because it is now a habit rather than an
accident:
round 15 — a premise true of schema-declared params, applied to the
compat IDs, which are undeclared precisely so it cannot hold
round 16 — the check placed below the exemption, so it covered one key
class (caught by my own test's control leg)
round 17 — a per-key property read as per-request
Each time the fix was correct for the case in front of me and wrong for
its siblings, which is the same shape as the defects this unit started
with. The canonical restructure removed it from the CODE; it evidently
did not remove it from how I reason about the code.
Mutation matrix, both directions:
revert to the per-request gate -> only the two uncovered-key legs fail
refuse even when canonicalized -> only the canonicalized control fails
The third leg of the new test is the control that makes the distinction
real: with the key present in `fields` the entry IS canonicalized, so
the call must still succeed. A fix that refused whenever anything was
padded passes the first two legs and fails this one.
Gates: gofmt clean · go vet clean · go test ./... green (29 packages) ·
the contract-drift gate ran green
(go test ./internal/mcp/ -run 'CoversEveryCatalogAction|VersionMatchesToolSurface')