engineering-documentation-rules

Use a layered structure: long-term rules in a must-read section, current implementation notes as the maintenance entry, design proposals with landing-status labels, review conclusions, external references, and an archive for time-based records like dev logs.

Update the current-implementation document whenever module boundaries, configuration sources, integration methods, manual setup steps, or acceptance paths change. Never let dev logs substitute for the maintenance-entry documentation.

Yes. Every design draft, refactoring plan, or evolution proposal must be labeled as not implemented, partially implemented, fully implemented, or deprecated. Unmarked proposals are easily misread as the current real implementation.

No. External materials such as Excel sheets, PDFs, and third-party documents are references only. Documentation must clearly distinguish reference materials from what the runtime actually reads and from derived export artifacts.

Archive time-sensitive content like dev logs, phase checklists, and one-off troubleshooting records once they stop serving as maintenance entry points. Main directories should hold high-signal, stable content while archives preserve history without noise.

Document anything code cannot express: scene wiring, prefab configuration, Inspector references, resource mounting, startup order, and module enablement steps. Include target scripts, required fields, runtime fallbacks, and the shortest acceptance sequence.