documentation

name	documentation
description	Guidelines for creating and maintaining documentation in the Nothingness project. Use when adding architecture docs, design docs, or complex logic explanations.

Documentation Standards

When to Document

• Architecture Changes: Whenever a new major component (service, screen, complex widget) is added or refactored.
• Complex Logic: Algorithms (like FFT processing or Auto-Scaling) require a design doc.
• Standards: When establishing new team rules (testing, naming, etc.).

Where to Document

• All documentation lives in the docs/ directory.
• docs/architecture/: System design, data flow, component interaction.

Format

• Markdown: Use standard GFM.
• Mermaid: Use Mermaid diagrams for all visual flows (graphs, sequences, class diagrams).
• Links: Use relative links to other docs (e.g., [Overview](architecture/overview.md)).

Style

Keep docs straightforward—no marketing fluff or filler:

• State what the component does and how to run it.
• Avoid buzzwords ("reporting surface", "purpose-built", etc.).
• Prefer short, direct sentences; skip padding and restatements.

Agent Behavior

• Do not pollute context: Do not read all docs into context unless specifically asked.
• Update Index: Always update docs/README.md when adding a new file.
• Reference: When explaining a complex topic to the user, reference the existing doc rather than re-explaining from scratch, unless asked for a summary.