Project Core Documentation Creator

L3 Worker that creates 3 core project documentation files. These are ALWAYS created regardless of project type.

Purpose & Scope

• Creates 3 core project documentation files (required for all projects)
• Receives Context Store from ln-110-project-docs-coordinator
• Heavy use of auto-discovery (architecture needs full project scan)
• Replaces placeholders with project-specific data
• Self-validates structure and content (16 questions)
• Never gathers context itself; uses coordinator input

Invocation (who/when)

• ln-110-project-docs-coordinator: ALWAYS invoked as second worker (after ln-111)
• Never called directly by users

Inputs

From coordinator:

• contextStore: Full Context Store with all discovered data

- PROJECTNAME, PROJECTDESCRIPTION - TECHSTACK (full object: frontend, backend, database, etc.) - DEPENDENCIES (from package.json) - SRCSTRUCTURE (folder analysis) - EXTERNALSYSTEMS (from .env.example) - CODECONVENTIONS (from eslint, prettier) - ADRLIST (from docs/reference/adrs/) - LEGACYCONTENT (optional, from ln-100 Phase 0 migration): - legacyarchitecture: { layers[], components[], diagrams[], dataflow } - legacyrequirements: { functional[], nonfunctional[], userstories[] } - legacytech_stack: { frontend, backend, database, versions }

• targetDir: Project root directory

LEGACY_CONTENT is used as base content when creating documents. Priority: Legacy > Auto-discovery > Template defaults.

Documents Created (3)

Workflow

Phase 1: Receive Context

1. Parse full Context Store from coordinator
2. Validate required keys (PROJECTNAME, TECHSTACK)
3. Extract architecture-specific data (SRC_STRUCTURE, DEPENDENCIES)

Phase 2: Create Documents

For each document (requirements.md, architecture.md, tech_stack.md):

1. Check if file exists (idempotent)
2. If exists: skip with log
3. If not exists:

- Copy template from references/templates/ - Check LEGACYCONTENT for this document type: - For architecture.md: If LEGACYCONTENT.legacyarchitecture exists: - Use legacyarchitecture.layers[] for "## Building Block View" (Section 5) - Use legacyarchitecture.components[] for component descriptions - Use legacyarchitecture.diagrams[] for existing diagrams (preserve mermaid/images) - Use legacyarchitecture.dataflow for "## Runtime View" (Section 6) - Merge with auto-discovered SRCSTRUCTURE (legacy takes priority) - Mark: <!-- Migrated from legacy documentation --> at top of merged sections - For requirements.md: If LEGACYCONTENT.legacyrequirements exists: - Use legacyrequirements.functional[] as base for FR-XXX requirements - Use legacyrequirements.userstories[] if FR format not found - Augment with template structure (add MoSCoW labels if missing) - For techstack.md: If LEGACYCONTENT.legacytechstack exists: - Use legacytechstack.versions as base for technology versions - Merge with auto-discovered TECHSTACK (legacy versions take priority) - Use legacytechstack.rationale for decision explanations - Replace {{PLACEHOLDER}} with Context Store values - Generate C4 diagrams from SRCSTRUCTURE (for architecture.md, if no legacy diagrams) - Insert ADR links (for architecture.md Section 8) - Mark [TBD: X] for missing data

Phase 3: Self-Validate

For each created document:

1. Check SCOPE tag in first 10 lines
2. Check required sections (from questions_core.md)
3. Validate specific format requirements:

- requirements.md: FR-XXX identifiers, MoSCoW labels - architecture.md: 11 sections, C4 diagrams, ADR references - tech_stack.md: versions, rationale for each technology

1. Check Maintenance section
2. Auto-fix issues where possible

Phase 4: Return Status

Return to coordinator:

{
  "created": ["docs/project/requirements.md", ...],
  "skipped": [],
  "tbd_count": 5,
  "validation": "OK",
  "diagrams_generated": 3
}

Critical Notes

• Idempotent: Never overwrite existing files
• Heavy auto-discovery: architecture.md requires deep project analysis
• C4 diagrams: Generated from SRC_STRUCTURE in Mermaid format
• ADR integration: Section 8 links to docs/reference/adrs/
• arc42 compliance: ISO/IEC/IEEE 42010:2022 structure
• TBD markers: Use [TBD: X] for missing data

NOCODEEXAMPLES Rule (MANDATORY)

Documents describe contracts and decisions, NOT implementations:

• FORBIDDEN: Code blocks > 5 lines, function implementations, imports, DI configuration
• ALLOWED: Mermaid diagrams, component tables, method signatures (1 line), ADR links
• INSTEAD OF CODE: Reference source: "See src/Services/UserService.cs:45"
• TEMPLATE RULE: All templates include <!-- NOCODEEXAMPLES: ... --> tag - FOLLOW IT

Stack Adaptation Rule (MANDATORY)

• Links must reference stack-appropriate docs (Microsoft for .NET, MDN for JS)
• Never mix stack references (no Python examples in .NET project)

Format Priority (MANDATORY)

Tables > Mermaid/ASCII diagrams > Lists > Text

Definition of Done

• Context Store received and validated
• 3 core documents created (or skipped if exist)
• C4 diagrams generated (Context, Container, Component)
• ADR links populated
• Self-validation passed (SCOPE, sections, format)
• Status returned to coordinator

Reference Files

• Templates: references/templates/requirementstemplate.md, architecturetemplate.md, techstacktemplate.md
• Questions: references/questions_core.md (Q23-Q38)

Version: 2.2.0 (Added Stack Adaptation and Format Priority rules) Last Updated: 2025-01-12