Status: active
Project: mnemoforge
This document describes the operational conditions for using and publishing SloplessCode. It is a practical release policy, not legal advice.
- Use the system with a valid
SELF_PROJECT_IDand a known release profile. - Do not publish live service data, private project notes, secrets, or internal operator-only memories in public releases.
- Treat
README.md, setup guides, and public status pages as public-facing artifacts; keep internal planning notes out of them. - Keep experimental or unstable modules disabled by default in public builds.
- Require explicit API key configuration when the server is reachable outside localhost.
- Validate release readiness before public distribution.
- Public examples must use synthetic or redacted data.
- Docker build contexts must exclude local caches, temp directories, database files, backups, and environment files.
- Human-facing summaries should not expose internal-only secrets, local paths, or private network identifiers.
- If a document mixes public and private material, split it before release.
- Publish public images only from a release template that passes the public-release checks.
- Use a clearly named public environment template instead of the internal
.env.example. - Keep Docker Hub tags and repositories explicit and separate.
- Update public docs when defaults change so the published instructions stay reproducible.
- The project may change without preserving compatibility with unpublished internal workflows.
- Public users should rely on the documented public template, readiness checks, and quickstart instructions.
- Internal operator workflows may remain private and are not part of the public contract.