graph build silently drops unknown op-list fields — a typo'd key vanishes instead of erroring #326
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Field evidence (milestone fieldtest "Surface honesty on stderr", 2026-07-24, source-blind against the release binary):
aura graph buildsilently ignores unknown fields in an op-list element. Feedingdrops the intended binding with no diagnostic — the correct key is
bind— so a typo'd key makes a consumer's parameter vanish silently and the built blueprint differs from the author's intent with zero signal. Observed while authoring op-lists from the binary alone; the wrong graph builds, registers, and runs.This contradicts the closed-vocabulary posture (C25: a closed, typed construct set) and the surface-honesty direction: the op-script grammar is a machine contract, and unknown keys are author errors, not extension points. Fix pattern: reject unknown fields at parse (
serde(deny_unknown_fields)on the op-list element types, or an equivalent explicit-key check), refusing with the offending key and op index. One care point: check whether any stored/replayed op-script artifacts rely on today's lenient parse before tightening (registered blueprints are canonical JSON, not op-lists, so the blast radius should be parse-time inputs only — verify).Provenance: fieldtest spec
fieldtest-milestone-stderr-honesty(friction finding "op-script surface undiscoverable + silent unknown-field drop" — the discoverability half is tracked on #323).