Lambo Builder Documentation Rules

How to document every change during development

Documentation Rules for Lambo Builder

Context Independence Principle: Documentation must be complete enough that anyone can understand the project state without access to chat history or conversation context.

Every Phase Must Have

1. Phase Overview Document

2. Daily Progress Updates

3. Architecture Decisions

4. Completion Checklist

Every Session Must Update

1. Progress Tracking

2. Phase Documents

3. New Decisions

File Naming Convention

Phase Documents

Architecture Documents

Progress Documents

Reference Documents

Frontmatter Requirements

Required Fields

---
title: Clear Descriptive Title
description: What this document covers (1-2 sentences)
icon: 🎯  # Use relevant emoji
Date: November 1, 2025  # Creation date
Status: 🎯 ACTIVE | 📘 REFERENCE | ✅ COMPLETE | ⏳ NOT STARTED
Purpose: Why this document exists and what problem it solves
---

Optional Fields

---
order: 1  # For sorting in navigation
tags: [phase-0, cleanup, deprecated]
lastUpdated: November 2, 2025
author: Platform Team
---

Update Frequency

Daily Updates

Per Task Updates

On Decision Updates

Weekly Reviews

Documentation Best Practices

1. Be Specific

❌ "Updated the module system" ✅ "Replaced EditorModuleContract with BrowserModuleContract in user-management module, added ModuleParameterMetadata to 5 public actions"

2. Include Context

❌ "Fixed the bug" ✅ "Fixed infinite loop in navigation service caused by circular dependency between RouterService and ContextService. Solution: Used injection token pattern."

3. Link Related Documents

See [Module System Architecture](./module-system-architecture.md) for rationale.

4. Use Checkboxes for Tasks

- [x] Completed task
- [ ] Pending task
- 🎯 In progress task (use emoji)

5. Document Decisions

Always include:

6. Code Examples

Include code snippets for architectural decisions:

```typescript
// Example of BrowserModuleContract implementation
@ModuleDecorator({
  id: 'user-management',
  version: '1.0.0'
})
export class UserManagementModule implements BrowserModuleContract {
  // ...
}
```

Context Independence Rules

1. No Conversation References

❌ "As we discussed earlier..." ✅ "The decision was made to use BrowserModuleContract because..."

2. Complete Information

❌ "See previous notes" ✅ "See Phase 0 Cleanup for details"

3. Self-Contained Documents

4. Assume New Reader

Quality Checklist

Before committing documentation:

Examples

Good Documentation Example

---
title: Module System Architecture
description: Why we use BrowserModuleContract and hybrid routing
icon: 🧩
Date: November 1, 2025
Status: 📘 REFERENCE
Purpose: Document the chosen module system architecture
---

# Module System Architecture

## Decision: Hybrid Approach + BrowserModuleContract

### Rationale
We chose BrowserModuleContract over EditorModuleContract for three key reasons:

1. **Maturity:** BrowserModuleContract is more mature with the unified parameter system
2. **AI Training:** Single pattern makes AI training simpler
3. **Type Safety:** Better TypeScript support with readonly properties

### Alternatives Considered
- Keep both systems (rejected: too confusing)
- Create new unified system (rejected: too time-consuming)
- Use EditorModuleContract everywhere (rejected: less feature-complete)

### Impact
- All modules must implement BrowserModuleContract
- EditorModuleContract must be removed from codebase
- Migration path: user-management module first, then others

[Continue with full details...]

Bad Documentation Example

# Module System

We decided to use BrowserModuleContract.

See earlier for why.

Maintenance

Weekly Review

Phase Completion

Plan Updates

Reference: Following guidelines from docs/english/docs-angular-docs/add-docs/add-documentation.md

Last Updated: November 1, 2025