Public project surface
The installable skill package, public docs, scripts, tests, benchmarks, examples, and API contracts can live in the open repository.
The simple rule
If it came from actual private conversations, do not put it in a public repository or website by accident.
- Raw rollouts and provider transcripts.
- Clean-source exports and generated indexes.
- Registry data, sync bundles, and private vault exports.
- API keys, cookies, tokens, credentials, and local machine paths.
Public vs private
Private memory surface
Conversation source and local memory artifacts belong to the person who created them unless they deliberately publish a safe example.
Sync is explicit
Sync can be useful, but raw rollout sync should stay opt-in and encrypted when it leaves a trusted device.
External models are optional
External-model routes should pass through redaction and never turn model-generated associations into source-backed facts.
Good public examples
Public evidence should be claim-bounded: demo runs, benchmark outputs, community reports, and redacted examples that make their scope clear. Private source should stay private even when it is emotionally or technically compelling.
Source trail
The repository keeps the operational boundary in the public core and privacy docs.
Adapted from the repository public core, privacy, and sync docs.