Add non-argv JSON input mode for ei create / ei update

[Flare576]

Add non-argv JSON input mode for ei create / ei update

Summary

Today the ei CLI only accepts write payloads via --json <json>, which means the full record ends up on the command line.

That is workable, but it is not great for the most sensitive Ei write paths — especially persona reflection, where the payload may contain a full persona identity or full Person-log record. We already improved the skill examples from fixed /tmp filenames to mktemp, but the final invocation still looks like:

ei update persona "$PERSONA_ID" --json "$(cat "$TMP_JSON")"

That keeps the JSON out of a predictable file path, but it still pushes the full payload through process argv.

Problem

Current write examples normalize an OS-level plaintext exposure path:

• full JSON is visible to the ei process as a command-line argument
• local process inspection / command logging can expose the payload
• the most sensitive current examples are in skills/ei-reflect/SKILL.md, but the limitation is really in the CLI surface itself, not just that skill

This is a privacy-hardening gap, not an immediate blocker.

Current behavior

• src/cli.ts documents only --json <json> for create/update
• no stdin input mode
• no @file / --json-file mode
• skills work around quoting problems with temp files, then interpolate the file contents back into argv

Desired outcome

Add at least one supported non-argv JSON input mode for ei create and ei update.

Any of these would satisfy the underlying problem:

1. --json-file <path>
2. --json-stdin
3. --json @/path/to/file.json

I do not care which one we choose as long as:

• agents have a first-class way to submit large/sensitive JSON without putting it on argv
• existing --json <json> behavior keeps working for backwards compatibility
• docs and shipped skills can stop teaching --json "$(cat "$TMP")" as the best available pattern

Recommendation

My bias: add one explicit input mode rather than trying to make --json polymorphic in too many ways.

Two boring options:

Option A — --json-file <path>

Pros:

• obvious to humans
• easy to document
• easy to test
• no shell quoting games

Cons:

• still uses a temp file if the caller is generating JSON on the fly

Option B — --json-stdin

Pros:

• best privacy story for generated payloads
• composes well with scripting runtimes
• no temp file required

Cons:

• slightly more ceremony in docs/examples
• need to define interaction with TTY/no-stdin cases clearly

If we only do one, I slightly prefer --json-stdin for the privacy-sensitive reflection/correction flows.

Acceptance criteria

• ei create ... supports at least one non-argv JSON input path
• ei update ... supports at least one non-argv JSON input path
• existing --json <json> still works unchanged
• CLI help documents the new mode clearly
• src/cli/README.md documents the new mode clearly
• skills/ei-reflect/SKILL.md and any other shipped skill examples using --json "$(cat ...)" are updated to prefer the new mode
• targeted CLI process tests cover success + usage errors for the new mode

Suggested tests

• create via new input mode
• update via new input mode
• malformed JSON via new input mode → non-zero exit, clear error
• missing file / empty stdin / bad flag usage → non-zero exit, clear error
• backwards-compat regression check: existing --json <json> still works

Why now

This came out of the CLI-first skill cleanup work:

• original reflection skill was touching state.json directly
• that was fixed by moving reflection fully onto CLI-backed reads/writes
• the remaining low-severity hardening gap is that the write payload still travels via argv

So this is the natural next step if we want the CLI-first path to also be the cleaner privacy path.

— Beta

[Flare576]

Adjacent hazard on the same surface: omitted booleans silently reset

Surfaced while planning the dual-lens reflection work. Not proposing a scope change to this issue — flagging it because it lives on the same write path, and this issue's acceptance criteria already commit to updating the shipped skills where it bites.

The hazard

updatePersonaEntity (src/cli/persona-corrections.ts) is a full-record replace, and the schema uses z.boolean().default(false). Any caller that omits a boolean does not "leave it unchanged" — it resets it to false, silently and successfully.

That is fine when a caller does a faithful ei --id → edit → ei update round trip. It fails when a caller constructs a record from anything less than the full entity, or when a field is newer than the caller's understanding of the schema.

It has already been hit once

preserveHiddenToolGrants() (src/core/persona-tools.ts) exists specifically because of this. Documented in AGENTS.md under "Persona Tool Grants Survive Provider Disable": an editing surface cannot see tools whose provider is disabled, so a well-behaved full-record edit would silently revoke grants the editor never knew about.

That fix is per-field. Every boolean added since inherits the hazard without inheriting the mitigation.

Why it is relevant here

This issue's acceptance criteria include updating skills/ei-reflect/SKILL.md and other shipped skills that currently use --json "$(cat ...)". Those skills teach the read-modify-write round trip — precisely the pattern where an omitted field silently resets. Whoever touches them for the input-mode change will be standing on top of this.

Two adjacent facts worth having in one place:

• TUI and web are safe. They send partials through Processor.updatePersona(personaId, Partial<PersonaEntity>), and PersonaState.update() spreads. Only the CLI/MCP full-record path is exposed.
• pending_update is wiped by any full-record update, and that is intentional. External writers pull before writing, so they see it and can tell the user. Documented in skills/ei-persona/references/cli.md. Not a defect — noting it so it does not get "fixed" alongside the boolean issue.

Options, if this is folded in

1. Do nothing. Keep adding per-field preservation as each hazard is discovered.
2. Generalize preserveHiddenToolGrants into a preserve-on-omit list for fields where absence should mean "unchanged" rather than "default."
3. Distinguish omitted from explicit-false at the schema layer, so .default(false) only applies on create.

Option 3 is the real fix and the most invasive. Option 2 is incremental and matches existing precedent.

Why this issue and not a new one

Fully separable — but the fix touches the same validation module, the same skills, and the same round-trip documentation this issue already changes. Doing them in one pass is cheaper than twice. Split it out if the input-mode work is already large enough.

---

Filed from planning for dual-lens reflection, which adds external_reflection_only?: boolean to PersonaEntity — a new field that inherits this hazard on day one.