Summary
PERSONA is present in the manifesto and the Clawfile surface, but it is currently metadata-only in the runtime path.
The parser, label emitter, and claw inspect path all recognize persona metadata, but the resolved driver model does not carry a persona field into materialization, and there is no clear runtime mounting or restoration path for persona content.
Why this conflicts with the documented model
Relevant docs:
MANIFESTO.md
- defines the Persona as one of the core architectural layers
- describes persona as a portable content layer with memory/history/style/knowledge
- lists
PERSONA as a core Clawfile directive
This reads as a first-class runtime feature, not merely image metadata.
Current implementation evidence
Persona appears in several early stages:
internal/clawfile/parser.go
internal/clawfile/emit.go
internal/inspect/inspect.go
internal/pod/parser.go
internal/pod/types.go
But it seems to stop there:
internal/driver/types.go ResolvedClaw has no persona field
- no obvious driver materialization path appears to mount/import/restore persona content
claw inspect can print persona metadata, but runtime behavior does not appear to change
Why this matters
Right now operators can reasonably believe persona is a working deployment concept because it is:
- in the manifesto
- in the directive set
- in inspect output
But in practice it appears inert. That creates misleading affordances in one of the core layers of the architecture.
Expected result
One of these should happen:
- implement persona as a real runtime concern with a resolved model and materialization path, or
- explicitly mark
PERSONA as planned / metadata-only until the real runtime exists
A real implementation likely needs at least:
- persona carried through
ResolvedClaw
- a source model for persona content
- deterministic mount/import behavior at materialization time
- clear interaction model with the contract and workspace
Summary
PERSONAis present in the manifesto and the Clawfile surface, but it is currently metadata-only in the runtime path.The parser, label emitter, and
claw inspectpath all recognize persona metadata, but the resolved driver model does not carry a persona field into materialization, and there is no clear runtime mounting or restoration path for persona content.Why this conflicts with the documented model
Relevant docs:
MANIFESTO.mdPERSONAas a core Clawfile directiveThis reads as a first-class runtime feature, not merely image metadata.
Current implementation evidence
Persona appears in several early stages:
internal/clawfile/parser.gointernal/clawfile/emit.gointernal/inspect/inspect.gointernal/pod/parser.gointernal/pod/types.goBut it seems to stop there:
internal/driver/types.goResolvedClawhas no persona fieldclaw inspectcan print persona metadata, but runtime behavior does not appear to changeWhy this matters
Right now operators can reasonably believe persona is a working deployment concept because it is:
But in practice it appears inert. That creates misleading affordances in one of the core layers of the architecture.
Expected result
One of these should happen:
PERSONAas planned / metadata-only until the real runtime existsA real implementation likely needs at least:
ResolvedClaw