blueclawPersona
The persona is three JSON documents that say who the agent is, how it carries itself, and how one person wants to be worked with.
| Document | Where | Carries | Read |
|---|---|---|---|
identity.json | workspace root | the names the agent answers to (the first is how it introduces itself), an optional handle, a role, an emoji, an introduction | once, into the standing instructions and the turn briefing |
soul.json | workspace root | what it holds to, what it never does, how it works, a tone, a language policy | once, into the standing instructions |
private/people/<personID>/.internkim/user.json | the person's home, owned by their POSIX user | what they want to be called, what they want known, preferences, tone, language, morningBriefing | at every launch, read as that person through the helper |
Each is validated against a JSON Schema in internal/persona/schema/ with additionalProperties: false, item and length ceilings, and a pinned schemaVersion. A document the schema refuses is restored from its backup in .blueclaw/state/persona-backup.
The agent edits only the requester's user.json, through persona_read and persona_update. The admin endpoints /admin/api/persona/user and /admin/api/persona/agent require a signed assertion in X-Blueclaw-Memory-Assertion: an HMAC-SHA256, keyed by the file at memory.adminAssertionKeyPath, over the method, the full request URI and a payload holding the reader, an expiry at most 60 seconds ahead and the body's SHA-256. An unsigned or invalid request is denied. Seeding the agent documents never overwrites an existing file, and an agent update cannot change the soul.