decode("[]") returns the corrupted string '[' instead of parsing or erroring

[antrixy]

Description

The TOON decoder fails to decode a root-level empty array []. Instead of
returning an empty list (or raising an error), decode("[]") returns the string
'[' — a single character, with the ] silently dropped. The canonical
empty-array forms ([0]:, items[0]:) decode correctly, so this is specific to
the bare [] form.

This is a silent-corruption bug: the input is neither parsed nor rejected, but
turned into wrong data that flows downstream with no signal.

Reproduction Steps

Steps to Reproduce

from toon_format import decode

print(repr(decode("[]")))        # Output: '['           ❌  (note: not even "[]")
print(repr(decode("[0]:")))      # Output: []            ✅
print(repr(decode("items[0]:"))) # Output: {'items': []} ✅

Expected Behavior

Per TOON spec v3.0, input "[]" has two acceptable outcomes:

• Error — per §6, an array header's bracket segment "MUST parse as a
  non-negative integer length N"; [] has no integer, so it is not a valid
  header. Strict mode is the default (§13) and §14 is the authoritative
  MUST-error checklist. A raised error is conformant.
• The string "[]" — per §5 (root-form discovery), a depth-0 line that is
  neither a valid array header nor a key-value line decodes as a single
  primitive, which for [] is the literal string "[]".

decode("[]")  # raises a decode error (strict, default)
# or
decode("[]")  # == "[]"   (primitive fallback)

Actual Behavior

decode("[]")  # == '['

The decoder returns '[' — the ] is dropped. This is neither a clean parse,
the correct primitive string "[]", nor an error. Even the most lenient reading
(treat [] as a primitive) yields "[]", not '[', so this is a parser defect
independent of any spec-version question. The dropped character points at an
off-by-one in the root-form / bracket-handling path.

Environment

• Package version: 0.9.0b1 (installed from git+https://github.com/toon-format/toon-python.git)
• Runtime: Python 3.14
• OS: macOS 26.5.1

Additional Context

Found via differential round-trip testing across TOON implementations. The bare
[] form is what the TypeScript reference (@toon-format/toon 2.3.0) currently
emits for an empty root array, so this input arises when data crosses between
implementations. For contrast, the TS decoder reads all three forms:

Decoder input	@toon-format/toon 2.3.0	toon_format 0.9.0b1
"[]"	[]	'[' (corrupted)
"[0]:"	[]	[]
"items[0]:"	{items: []}	{'items': []}

The spec is a fast-moving Working Draft (v1.0 → v3.0 in ~one month). If 0.9.0b1
targets a pre-v3.0 point where [] had defined semantics, the fix may be "parse
[] to []" rather than "error" — but returning '[' is incorrect under any
version.

[antrixy]

Adding a related failure mode at HEAD (e475c82), plus the normative anchors that pin the expected behavior.

Decoding the two-byte document [] returns the string "[]" instead of an empty array:

from toon_format import decode
decode("[]")   # returns '[]' (str) — expected: [] (list)

Since spec v3.1, [] is the canonical encoder output for a root empty array, so any conforming encoder's output for an empty root array fails to round-trip through toon-python. Observed concretely with the reference TS encoder (@toon-format/toon 2.3.0), whose encode([]) emits exactly [].

Normative anchors (spec v3.3, Working Draft 2026-05-21):

• §9.1 (Decoding): "decoders MUST accept key: [], [], and the legacy forms key[0<delim?>]: and [0<delim?>]: as empty arrays."
• §5 (Root form discovery): "Else if the document has exactly one non-empty line and it is the literal token [], decode an empty root array (§9.1)."
• §4: "The literal token [] in object field position (key: []) and root position ([]) decodes as an empty array (§9.1)."
• §13.2 (Decoder conformance checklist): "Accept empty arrays in both forms: key: [] / [] and legacy key[0]: / [0]: (§9.1)."
• CHANGELOG [3.1] (2026-05-18): "Empty arrays canonicalized … Decoders MUST accept both canonical (key: [], []) and legacy (key[0]:, [0]:) forms."

The [ corruption originally reported here and the "[]" string result appear to be the same missing rule (no []-literal branch in root-form/token handling), surfacing differently by context. The field-position form key: [] is likely affected as well and worth checking in the same fix.

Found via differential testing with toon-diff (TS→Python handoff on the seed corpus).