persona-kit: client-side parse strips cloud-meaningful keys — pass through unknown keys instead #195

The class (three production instances on 2026-06-04 alone)

persona-kit's parse layer drops keys it doesn't recognize during CLI preflight, BEFORE upload — so the persisted persona/agent spec silently lacks them and cloud-side features no-op with no error anywhere:

1. capabilities.teamSolve — stripped by parseCapabilities; broke team-N=1 dispatch until persona-kit#183 added an explicit pass-through (lockstep 3.0.42).
2. conditions on trigger entries — parseIntegrationTrigger keeps only {on, match, where}; a conditions key is dropped. Discovered while wiring dispatch-level label gates (cloud#1884) — the originally-prescribed fix would have been silently stripped.
3. conditions on watch rules — parseWatch strips them too, and only accepts relayfile storage events.

Each instance was found the expensive way: a cloud feature shipped, the persona was deployed, and the feature silently didn't fire. The strip happens client-side so neither cloud logs nor deploy errors surface it.

Ask

Invert the default at the parse boundary: validate the keys persona-kit knows, pass through the ones it doesn't (or at minimum: warn loudly on dropped keys at compile time, listing them). The #183 fix did this for one key; the class needs the general rule, otherwise every future cloud-side spec extension repeats the cycle: ship cloud feature → persona deploy strips the key → silent no-op → forensic session.

Workaround currently in use: route new dispatch semantics through keys persona-kit already preserves (cloud#1884 uses where strings for this exact reason) — workable but contorts the contract design around the parser's allowlist.

Refs: persona-kit#183 (teamSolve pass-through precedent), cloud#1884 (where-based workaround + the strip-class writeup in its tests' doc comments).