Contributions should improve the end-to-end path without duplicating the authoritative implementation details in component repositories.
- Create a focused branch from
main. - Edit Markdown under
docs/and updatezensical.tomlwhen navigation changes. - Use placeholders such as
<workspace>,<namespace>, and<model-name>. - Run
.venv/bin/zensical build --clean --strict. - Check links, commands, spelling, and the privacy rules below.
- Open a pull request describing the audience and tested path.
- Link to component repositories for source-of-truth flags, schemas, and values.
- Mark point-in-time validation results with a date and avoid future guarantees.
- Never commit passwords, tokens, kubeconfig content, host addresses, machine identifiers, raw logs, prompts, model responses, or model weight files.
- Destructive commands require a visible warning, an explicit target, and a verification step.
- Examples must default to local access. Do not imply that development profiles are suitable for untrusted networks.
Write for a reader who understands basic Linux commands but may be new to k3s. Explain why a command is run, show how to verify it, and route failures to the appropriate ownership layer.