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:
capabilities.teamSolve — stripped by parseCapabilities; broke team-N=1 dispatch until persona-kit#183 added an explicit pass-through (lockstep 3.0.42).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.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).
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:
capabilities.teamSolve— stripped by parseCapabilities; broke team-N=1 dispatch until persona-kit#183 added an explicit pass-through (lockstep 3.0.42).conditionson trigger entries — parseIntegrationTrigger keeps only{on, match, where}; aconditionskey is dropped. Discovered while wiring dispatch-level label gates (cloud#1884) — the originally-prescribed fix would have been silently stripped.conditionsonwatchrules — 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
wherestrings 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).