docs/book/src/contributing/privacy.md
ZeroClaw artifacts are public — git history, releases, fixtures, snapshots, the docs book, every rendered locale. Anything you commit ships with the project forever. Treat privacy as a merge gate, not best-effort.
In code, docs, tests, fixtures, snapshots, logs, examples, error messages, or commit messages:
This list isn't exhaustive. The principle: if it would identify a real person or grant access to something, it doesn't belong in the repo.
Test fixtures, examples, error messages, and snapshots use generic project-scoped placeholders instead of real identity data. Recommended palette:
| Use case | Examples |
|---|---|
| Actor labels | zeroclaw_user, zeroclaw_operator, zeroclaw_maintainer, test_user, user_a, project_bot |
| Service / runtime labels | zeroclaw_bot, zeroclaw_service, zeroclaw_runtime, zeroclaw_node |
| Environment labels | zeroclaw_project, zeroclaw_workspace, zeroclaw_channel |
| Hostnames | example.com, host.invalid, 192.0.2.x (RFC 5737 documentation range) |
| Email addresses | [email protected], [email protected] |
Test names, assertion messages, and fixture content stay impersonal and system-focused — avoid first-person language and identity-specific framing.
If a test or doc genuinely needs a role-shaped identity, use ZeroClaw-scoped roles only: ZeroClawAgent, ZeroClawOperator, ZeroClawMaintainer. Don't borrow real names, even pseudonyms — pseudonyms drift back into being real over time.
GitHub @-mentions in PR/issue comments are different — addressing a contributor by their handle is how you talk to people on GitHub, and @WareWolf-MoonWall is not a privacy violation. The rule is about content stored in the repo (code, tests, fixtures, docs), not about conversation in PR/issue threads.
If you're capturing an incident trace, log payload, or external response in a test fixture: redact and anonymize before committing. Real session IDs, real user IDs, real hostnames, and real auth tokens all need to go through a scrubbing pass first. The redacted version is what ships; the original stays out of git.
Before pushing, scan the staged diff specifically for identity leakage:
git diff --cached
The shapes to look for: anything that looks like an email, a URL with a non-public hostname, a long random-looking string that might be a token, a name that isn't yours and didn't come from a project-scoped placeholder.
If a CI run captured a real value (a real session ID in a snapshot, a real user agent string with identifying info, etc.) and got committed, it's a privacy incident — open an issue, scrub, force-push if it just landed, and contact the maintainers if it landed on master.
The last category — accidentally committing a real identity — is hard to undo. Once a real name or email lands on master it propagates through forks, mirrors, and clones immediately. Squashing or force-pushing fixes the public branch but doesn't reach the copies. The cheapest fix is the pre-commit scan; everything after that is harm reduction.