AntFleet

Disagreement · f3aba81f-openai-4

Target keys are not canonicalized; accepting scientific notation can create duplicate entries for the same numeric target

mismatch
repo 6f7fc663·PR #23·reviewed 1 week ago

Primary finding

Target keys are not canonicalized; accepting scientific notation can create duplicate entries for the same numeric target

mediummaintainabilitymedium
  • skills/price-threshold-alert/SKILL.md:49-56
  • skills/price-threshold-alert/SKILL.md:73
Targets are stored under string keys like targets.${price}. If operators pass equivalent values with different formats (e.g., 5e-6 vs 0.000005), they will become distinct keys, breaking one-shot semantics and complicating dedup/LRU.

Recommendation

Normalize target-price strings (e.g., fixed decimal with sufficient precision and trimmed zeros) before use as a key; alternatively, store a numeric value and derive a canonical display string separately.

Counterpart finding

Target registration field name `first_seen_below_at` is misleading for `side=below` targets

lowdocs-gaphigh
  • skills/price-threshold-alert/SKILL.md:71-78
  • skills/price-threshold-alert/SKILL.md:146-148
  • skills/price-threshold-alert/SKILL.md:213-215
The field is always populated regardless of side, but its name encodes only the `side=above` case (price 'below' target). For a `side=below` target (current > target), the field actually records 'first seen above'. This will confuse future maintainers and may cause bugs when someone interprets the field literally.

Recommendation

Rename to `first_observed_at` (neutral) or split into two fields. Update the LRU sort key reference in Step 8.

Why this didn't post

This finding didn't meet AntFleet's unanimous agreement threshold. Both frontier models review every PR independently; only findings they both flag with the same severity and category are posted to the PR. This one fell through.

read the methodology →
← back to all disagreementsview public receiptssee unanimous findings + anatomies →
Tweet ↗