schema: pin the 64-bit bounds at the precision a validator has #230

Merged

natsukium merged 1 commit from issue-179 into main 2026-09-08 22:14:16 +09:00

Conversation 0 Commits 1 Files changed 11 +151 -30

natsukium commented 2026-09-08 20:36:52 +09:00

Owner

Copy link

The integer-bounds fixtures claimed to pin the 64-bit boundary but never came near it: out-check-errors-above-u64
carried ~1e20, four orders of magnitude past u64::MAX, so it would have passed against a bound wrong by nearly any
amount. The boundary cannot be pinned exactly — i64::MAX and u64::MAX are not representable as f64, and a stock
validator (boon included) compares JSON numbers as f64, so it admits everything within one f64 step of the bound.
This moves the fixtures to the first value past that step, the closest a validator can reject, adds the signed twin
that was missing, and pins the remaining gap as its own test so a future validator that closes it fails loudly instead
of leaving the fixtures quietly over-strict. The published bounds stay exact rather than narrowing to what a validator
can enforce (narrowing would reject counts the daemon really emits); x-bound-exceeds-f64-precision discloses the gap
the same way x-max-utf8-bytes discloses the id byte limit.

• out-check-errors-above-u64.json now carries 18446744073709555712 (2^64 + 4096, the first f64 above the bound)
  against its exact-u64::MAX twin; new out-capture-row-above-i64.json does the same for CaptureRow.row with
  9223372036854777856 (2^63 + 2048) against exact i64::MAX.
• a_64_bit_bound_is_enforced_only_to_f64_precision pins all three points per sign: the exact maximum validates, one
  past it still validates (the limitation), the next representable f64 is rejected.
• Every int64/uint64 field in both published schemas gained x-bound-exceeds-f64-precision; the hand-composed
  count, exit_code and dropped envelope fields moved to the format annotation their generated siblings already
  carried, so the bound and the disclosure have one source.
• Docs: docs/reference/cli.md "JSON Schema" states the gap and the annotation, docs/reference/testing.md and the
  fixture README say why the fixtures sit where they do, and control-surfaces.md records why the bound is published
  exact rather than narrowed. CHANGELOG under Unreleased, since the annotation is part of the published surface.

Fixes #179

The integer-bounds fixtures claimed to pin the 64-bit boundary but never came near it: `out-check-errors-above-u64` carried ~1e20, four orders of magnitude past `u64::MAX`, so it would have passed against a bound wrong by nearly any amount. The boundary cannot be pinned exactly — `i64::MAX` and `u64::MAX` are not representable as `f64`, and a stock validator (boon included) compares JSON numbers as `f64`, so it admits everything within one `f64` step of the bound. This moves the fixtures to the first value past that step, the closest a validator can reject, adds the signed twin that was missing, and pins the remaining gap as its own test so a future validator that closes it fails loudly instead of leaving the fixtures quietly over-strict. The published bounds stay exact rather than narrowing to what a validator can enforce (narrowing would reject counts the daemon really emits); `x-bound-exceeds-f64-precision` discloses the gap the same way `x-max-utf8-bytes` discloses the id byte limit. - `out-check-errors-above-u64.json` now carries `18446744073709555712` (`2^64 + 4096`, the first `f64` above the bound) against its exact-`u64::MAX` twin; new `out-capture-row-above-i64.json` does the same for `CaptureRow.row` with `9223372036854777856` (`2^63 + 2048`) against exact `i64::MAX`. - `a_64_bit_bound_is_enforced_only_to_f64_precision` pins all three points per sign: the exact maximum validates, one past it still validates (the limitation), the next representable `f64` is rejected. - Every `int64`/`uint64` field in both published schemas gained `x-bound-exceeds-f64-precision`; the hand-composed `count`, `exit_code` and `dropped` envelope fields moved to the `format` annotation their generated siblings already carried, so the bound and the disclosure have one source. - Docs: `docs/reference/cli.md` "JSON Schema" states the gap and the annotation, `docs/reference/testing.md` and the fixture README say why the fixtures sit where they do, and `control-surfaces.md` records why the bound is published exact rather than narrowed. CHANGELOG under Unreleased, since the annotation is part of the published surface. Fixes #179

natsukium added 1 commit 2026-09-08 20:36:52 +09:00

schema: pin the 64-bit bounds at the precision a validator has ... 948bb77283

The integer-bounds fixtures never reached the boundary they claimed.
`out-check-errors-above-u64` carried ~1e20, four orders of magnitude
past `u64::MAX`, so it would have passed against a bound wrong by any
amount short of that; nothing sat where a wrong bound actually shows.

The boundary cannot be reached exactly: `i64::MAX` and `u64::MAX` are
not representable as `f64`, and a stock validator compares JSON numbers
as `f64`, so it admits everything within one `f64` step of the bound.
The fixtures now sit at the first value past that step, the closest a
validator can reject, and a test pins the gap itself, so a rejection
one past the maximum would fail loudly rather than silently make the
fixtures over-strict.

The published bounds stay exact rather than narrowing to what a
validator can enforce: narrowing would reject counts the daemon really
emits, and `x-bound-exceeds-f64-precision` discloses the gap the same
way `x-max-utf8-bytes` discloses the id byte limit. The envelope's
`count`, `exit_code` and `dropped` move to the `format` annotation the
generated fields already use, so the bound and the disclosure have one
source.

Assisted-by: Claude Code

natsukium force-pushed issue-179 from 948bb77283 to b9631297b5 2026-09-08 21:22:10 +09:00 Compare

natsukium merged commit e20b8702fe into main 2026-09-08 22:14:16 +09:00

natsukium deleted branch issue-179 2026-09-08 22:14:16 +09:00

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

priority/P0

Must be resolved before the v0.1.0 tag

  

priority/P1

Must be settled before the first public contract freezes

  

priority/P2

Explicitly deferred until after v0.1.0

  

release/v0.1.0

Work tracked for the first tagged release

  

status/blocked

Cannot start now: waits on an upstream release, another issue, or a recorded revisit trigger

  

status/planned

Triaged with a source-grounded plan and a passed pi review; ready to implement

  

type/bug

Shipped behavior that contradicts the docs or the code's own intent; needs a product code change

  

type/design

An open scope or trade-off question; needs a recorded decision in the owning explanation doc before code

  

type/test-gap

Documented or reviewed behavior that no test pins; usually split from a review finding, needs no product code change

  

type/tracker

Parent issue that tracks child work

No labels

priority/P0

priority/P1

priority/P2

release/v0.1.0

status/blocked

status/planned

type/bug

type/design

type/test-gap

type/tracker

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

natsukium/felis!230

No description provided.