f87ccccc4d72ec5eb6785c9f549814cc3424b827
address each point.
**Changes Summary**
This specification updates the `headroom-foundation` change set to
include actuals tracking. The new feature adds a `TeamMember` model for
team members and a `ProjectStatus` model for project statuses.
**Summary of Changes**
1. **Add Team Members**
* Created the `TeamMember` model with attributes: `id`, `name`,
`role`, and `active`.
* Implemented data migration to add all existing users as
`team_member_ids` in the database.
2. **Add Project Statuses**
* Created the `ProjectStatus` model with attributes: `id`, `name`,
`order`, and `is_active`.
* Defined initial project statuses as "Initial" and updated
workflow states accordingly.
3. **Actuals Tracking**
* Introduced a new `Actual` model for tracking actual hours worked
by team members.
* Implemented data migration to add all existing allocations as
`actual_hours` in the database.
* Added methods for updating and deleting actual records.
**Open Issues**
1. **Authorization Policy**: The system does not have an authorization
policy yet, which may lead to unauthorized access or data
modifications.
2. **Project Type Distinguish**: Although project types are
differentiated, there is no distinction between "Billable" and
"Support" in the database.
3. **Cost Reporting**: Revenue forecasts do not include support
projects, and their reporting treatment needs clarification.
**Implementation Roadmap**
1. **Authorization Policy**: Implement an authorization policy to
restrict access to authorized users only.
2. **Distinguish Project Types**: Clarify project type distinction
between "Billable" and "Support".
3. **Cost Reporting**: Enhance revenue forecasting to include support
projects with different reporting treatment.
**Task Assignments**
1. **Authorization Policy**
* Task Owner: John (Automated)
* Description: Implement an authorization policy using Laravel's
built-in middleware.
* Deadline: 2026-03-25
2. **Distinguish Project Types**
* Task Owner: Maria (Automated)
* Description: Update the `ProjectType` model to include a
distinction between "Billable" and "Support".
* Deadline: 2026-04-01
3. **Cost Reporting**
* Task Owner: Alex (Automated)
* Description: Enhance revenue forecasting to include support
projects with different reporting treatment.
* Deadline: 2026-04-15
Headroom Documentation
This directory contains comprehensive documentation for the Headroom project.
Documents
Core Documentation
-
headroom-project-charter.md
- Complete project charter and specifications
- Problem statement, solution overview, requirements
- Data validation rules, RBAC matrix
- Deferred features and out-of-scope items
- Success criteria
-
headroom-architecture.md
- Technical architecture with Mermaid diagrams
- System component diagram
- Data model (ER diagram)
- API architecture
- Authentication flow
- Deployment architecture
- Testing strategy
-
headroom-decision-log.md
- Complete conversation archive
- All decisions made and rationale
- Considerations and trade-offs
- Deferred features with reasoning
- Rejected options
- Timeline of discussions
-
headroom-executive-summary.md
- Condensed overview suitable for printing
- Executive summary
- Core features
- Quality standards
- Timeline and phases
- Success metrics
Converting to Word Format
Option 1: Using Pandoc (Recommended)
If you have Pandoc installed:
# Install Pandoc (if not already installed)
# macOS: brew install pandoc
# Windows: choco install pandoc
# Linux: sudo apt-get install pandoc
# Convert individual files
pandoc headroom-project-charter.md -o headroom-project-charter.docx
pandoc headroom-architecture.md -o headroom-architecture.docx
pandoc headroom-decision-log.md -o headroom-decision-log.docx
pandoc headroom-executive-summary.md -o headroom-executive-summary.docx
# Or convert all at once
for file in headroom-*.md; do
pandoc "$file" -o "${file%.md}.docx"
done
Option 2: Using Online Converters
If Pandoc is not available:
- Visit https://cloudconvert.com/md-to-docx
- Upload the .md file
- Download the .docx file
Alternatively:
- https://www.markdowntopdf.com/ (converts to PDF)
- https://dillinger.io/ (online Markdown editor with export)
Option 3: Copy-Paste Method
- Open the .md file in any Markdown viewer (VSCode, Typora, MacDown)
- Copy the rendered content
- Paste into Microsoft Word
- Format as needed
Mermaid Diagrams
The architecture document contains Mermaid diagrams. To render them:
In Markdown Viewers
- VSCode: Install "Markdown Preview Mermaid Support" extension
- Typora: Built-in Mermaid support
- MacDown: May require plugin
For Word Conversion
Mermaid diagrams don't convert directly to Word. Options:
-
Render to images first:
# Using mermaid-cli npm install -g @mermaid-js/mermaid-cli mmdc -i architecture.md -o architecture.docx -
Use online renderer:
- Visit https://mermaid.live/
- Paste Mermaid code
- Export as PNG/SVG
- Insert into Word document
-
Keep as code blocks:
- Diagrams will appear as text in Word
- Acceptable for technical documentation
Recommended Reading Order
For Project Owner (You)
- Start with headroom-executive-summary.md (overview)
- Read headroom-decision-log.md (verify all decisions captured)
- Review headroom-project-charter.md (detailed requirements)
- Study headroom-architecture.md (technical deep-dive)
For Associate
- headroom-executive-summary.md (context)
- headroom-architecture.md (technical implementation)
- headroom-project-charter.md (detailed requirements as needed)
For Hardcopy/Reference
- headroom-executive-summary.md → Print for quick reference
- headroom-architecture.md → Print for technical diagrams
Document Maintenance
When to Update
Project Charter:
- When requirements change
- When new features are added to scope
- When success metrics are revised
Architecture:
- When tech stack changes
- When new integrations are added
- When deployment approach changes
Decision Log:
- Add entries for major decisions
- Update when deferrals are implemented
- Record new trade-offs
Executive Summary:
- Update timeline when phases shift
- Revise success metrics based on learnings
- Update when project scope changes significantly
Version Control
All documents are in git. To track changes:
# View history of a document
git log -p docs/headroom-project-charter.md
# Compare versions
git diff HEAD~1 docs/headroom-architecture.md
# Tag major versions
git tag -a v1.0-docs -m "Initial documentation complete"
Quick Reference: Key Decisions
| Decision | Document | Section |
|---|---|---|
| Why SvelteKit? | Decision Log | Technical Stack Decisions → Frontend |
| Why Redis from day 1? | Decision Log | Architecture Decisions → Caching |
| What's deferred to Phase 2? | Project Charter | Deferred Features |
| What's the data model? | Architecture | Data Model |
| What are the success metrics? | Executive Summary | Success Metrics |
| What's the testing strategy? | Architecture | Quality Standards |
| UI Layout approach? | Decision Log | UI Layout Decisions |
| Sidebar + TopBar pattern? | Architecture | Frontend Layout Architecture |
Questions or Updates?
Contact: Santhosh J (Project Owner)
Last Updated: February 18, 2026
Documentation Version: 1.1
Description
Languages
Markdown
100%