π LogiDAV Documentation System
This directory contains the documentation infrastructure for the LogiDAV ERP system, with a cronjob-first approach.
Overviewβ
This documentation system prioritizes cronjobs as the entry point for understanding critical workflows. Cronjobs are production-critical, run silently, and represent significant operational risk if undocumented.
Directory Structureβ
docs/
βββ README.md # This file
βββ system-crontab.md # β SOURCE OF TRUTH for all cronjobs
βββ cronjobs/ # Auto-generated cronjob documentation
β βββ README.md # Cronjob documentation system guide
β βββ menzzo-v2-sales.md
β βββ menzzo-v2-products.md
β βββ ... (115 cronjob docs)
βββ meta/
β βββ documentation-progress.md # Coverage tracking and TODO list
βββ [other docs...]
Quick Startβ
View Documentation Coverageβ
cat docs/meta/documentation-progress.md
Current status:
- 164 total cron entries
- 115 unique commands
- 95 documented (82% coverage)
- 20 undocumented (18% needing investigation)
- 46 critical risk commands (sales, payments, refunds, stock)
Generate/Update Documentationβ
python3 tools/cronjob_doc_generator.py
This regenerates all cronjob documentation from system-crontab.md.
Validate Documentationβ
# Regenerate the cronjob docs locally
python3 tools/cronjob_doc_generator.py
# Then verify the updated docs before pushing
git diff -- docs/
π― Documentation Philosophyβ
1. Cron-First Approachβ
Why cronjobs first?
- π Silent Workflows: Run in background without visibility
- β οΈ Production Critical: Sales, payments, stock mutations happen here
- π¨ High Risk: Failures can have immediate business impact
- π Discoverable: System crontab is a concrete artifact
- π Traceable: Maps to concrete Symfony Command classes
Cronjobs are the entry point to understanding:
- What automated workflows exist
- When they run and how often
- What data they touch
- What external systems they interact with
2. Code-First Documentationβ
- Documentation is generated from source (system-crontab.md)
- Validation runs in the documented update flow before changes are pushed
- Documentation should not get out of sync when the generator is rerun after cron changes
- Manual enhancements are layered on top of generated structure
3. Obsolescence by Designβ
All documentation includes:
last_verified: YYYY-MM-DD
regeneration:
trigger: "Cron definition or command code changed"
instruction: "Re-run documentation agent"
This makes staleness explicit rather than hidden.
4. Risk-First Prioritizationβ
Commands are classified by risk:
- π΄ CRITICAL (46): Sales, payments, refunds, stock mutations
- π‘ HIGH (40): Products, sync, orders, imports
- π’ MEDIUM (8): Logs, stats, alerts, notifications
- βͺ UNKNOWN (21): Needs assessment
Critical commands must be documented first.