An unknown field discards the whole declaration rather than the key it
did not recognise, so a machine that takes a project's commit before it
takes a dev-updater that understands it loses that project's components,
strip, staleWhen and resources at once. Nothing looks broken afterwards:
the card becomes a project that declares nothing, which is the ordinary
case, and the only thing saying otherwise was a line in this server's log
on a machine the person holding the phone cannot read.
project_config now answers a ProjectFile carrying the parse error beside
the declaration, and AppEntry::declaration_state returns both halves from
one read -- the manifest wants both, and the file is on that path. The
card draws its own sentence about what it means and what to do, then the
parser's own words, which name the file, the position and the offending
field; that half is selectable, since the fix happens on the other
machine.
Nothing is blocked by it. What was already accepted is what runs, so an
unrelated typo cannot stop a project that was working -- asserted in the
test, along with the error naming both the field and the file.
Seen on the emulator both ways: a project whose file gained a field from
the future says so under its action row, and the whole message goes when
the file parses again.
Raised by the tdep-survey session after its alsoWatch commit hit exactly
this against the older binary running here.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
irisandClaude Opus 5
0b7164bb30