---
status: resolved
opened: 2026-08-31
located-in: [mesh-host]
fixed-by: mesh-host — something after the declaration is refused whole
amended-design:
---

# 016 — Anything after the declaration in a file was ignored

## Symptom

A JSON decoder reads one value and stops. The host's declaration parser used one, so a file
holding a declaration **followed by anything at all** — a stray line, a second declaration, the
tail of a truncated rewrite — parsed as the first value and the rest was never looked at.

The machine applied something, reported success, and what it applied was not what the file said.

## Why this matters

The host refuses a partial declaration everywhere else, in these words: *a host that applied the
parts it understood would leave a machine that looks configured and is not.* This was the same
fault in its quietest form — not a part left out, but a part never seen, with nothing anywhere
saying so.

**It was live and invisible.** The end-to-end harness had been appending a line to the substrate
bundle by accident ([015](../015-a-command-with-no-answer-was-read-as-success/00-report.md)), and
every bootstrap in every run applied a bundle with a junk line on the end. Nothing failed, so
nothing was looked at, and the corruption was found only by tracing a different bug backwards.

**That is the argument for refusing rather than tolerating.** A file with something after it is
more likely to be damaged than deliberate: an interrupted write, two files concatenated, a
generator that emitted twice. Applying the first value is applying something nobody wrote.

## What was done

After decoding, the parser requires end of input. Trailing whitespace is not "something after it"
— refusing that would make every file an editor writes unusable.

*Checked by a valid declaration with a stray line after it, with a second declaration after it,
and with garbage after it, each refused; and by the same declaration with trailing blank lines,
accepted.*