mirror of
https://github.com/PerpetualSoftware/pad.git
synced 2026-10-26 06:19:49 +00:00
xarmian
729ae5f69c
* fix(mcp): stdio applies remote's number rule before a value becomes CLI text (BUG-4070)
On stdio, a string for a "number" param reached the CLI verbatim. An int
flag parses it base 0 (pflag's ParseInt(s, 0, 64)), so "010" was 8, "0x10"
16, "1_000" 1000 and "+5" 5; pad_chat delete's positional seq parses base
10, so "010" was 10. Remote refuses all of them (decimalIntString,
BUG-4065). A JSON number was formatted and forwarded whatever its size,
where remote refuses one of magnitude 2^53 or more as possibly rounded
(wholeInt64, BUG-4061 / ba981cb4f).
makeFanOutHandler now runs rejectMalformedNumbers after
rejectUndeclaredKeys. For every top-level param the catalog declares
"number", a string or float value goes through numericInput, remote's
rule, and a failure is refused with validation_failed naming the param,
before any action runs. A value that passes is forwarded unchanged. Other
types keep their path, where the CLI's own parse refuses them.
Tests: rows at a flag param (chat show limit), a positional (chat delete
seq) and a custom handler (chat send reply_to), and a population walk
over every catalog number param (20 today). Red on main: the walk and the
door rows fail there, e.g. "010" dispatched as --limit 010.
ToolSurfaceVersion 0.104 -> 0.105 (lead ruling e522d1be), with the
changelog in version.go and docs/mcp.md; the README, the instructions.md
heading and the wire goldens follow. The goldens move by the version
string only. The nested edits[].line_hint is BUG-4082.
Claude-Session: https://claude.ai/code/session_01Hk4vxsaKDm3E1LvsoHtHeV
* test(mcp): a valid earlier number param does not end stdio's check (BUG-4070)
M5 (the loop stops after the first number param present) survived: every
row sent one number param. A since that passes, then a malformed limit,
must still be refused naming limit.
Claude-Session: https://claude.ai/code/session_01Hk4vxsaKDm3E1LvsoHtHeV
* test(mcp): pin where a non-string, non-float number value goes on stdio (BUG-4070 r1)
r1 row 1 (hunter Low, ruled FIX): nothing pinned the claim that other
types keep their path. Rows for true, false, null, [1] and {} at the flag
door (chat show limit) and the positional door (chat delete seq) assert
the new check passes each through unchanged, and pin the text it is
forwarded as, which pflag's ParseInt or cmd_chat.go's ParseInt refuses.
The claim's wording was narrow: pad_item list and history read limit
through intParam, which refuses these types before the CLI does. The
catalog.go comment, the version.go changelog and docs/mcp.md now name
intParam too.
Claude-Session: https://claude.ai/code/session_01Hk4vxsaKDm3E1LvsoHtHeV
* docs(mcp): null is absent at intParam, not refused (BUG-4070 r2)
Comment and changelog only (lead ruling on r2's Codex Low): the r1
rewording said intParam refuses a non-string, non-float number value, but
numericInput reads null as absent, so a null pad_item list or history
limit takes its default (v0.104). The rejectMalformedNumbers comment, the
v0.105 changelog in version.go and docs/mcp.md now say so; elsewhere the
CLI's own parse refuses all of these types.
Claude-Session: https://claude.ai/code/session_01Hk4vxsaKDm3E1LvsoHtHeV