The project is split in 3 important files:
PROJECT.md
DECISIONS.md
JOURNAL.md

The idea is a hierarchical summary:

Meeting Summary -> detailed (what was discussed)
then Journal Entry -> compressed (why should I care this event happened?)
then PROJECT.md -> distilled (what do I absolutely have to know about this project EVERY TIME I work on it. This is an onboarding document that every agent should read.)

The journal should always be appended and read using tail or searched.

Example journal entry:

```markdown
## 2026-05-30
### Team Daily

New Blocker: HLS delayed

Impact: Release likely delayed, team implements Z-Levels in the meantime.

[[20260529-093030-6187486-summary|Summary]]

### Refinement

Calendar-Feature is refined, Golem feature needs more work.

[[20260529-103030-3465634-summary|Summary]]
```

PROJECT.md should use this structure:

```markdown
# Executive Summary

<Elevator Pitch>

## Business Goals

## Priorities and High Level Constraints

## Current Phase & Status

## Next Milestones

## Open Risks

## Important Stakeholders

## Key Documents

Links to: Architecture Overview, Technical Onboarding, etc.

[[JOURNAL.md]]
[[DECISIONS.md]]
```

DECISIONS.md logs decisions in the same compressed way that JOURNAL.md logs meetings, with links to ADRs and/or meeting summaries for details.
Only include important decisions: architecture decisions that are expensive to change, and project decisions about timeline, goals, governance, team, or process.
Do not log small implementation details such as how UI elements are aligned.

Example decision entries:

```markdown
## How do we handle project delays?
Communicate to <Stakeholder> first, let them decide further actions.
[[20260529-093030-6187486-summary|Source]]

## How will authentication be handled?
Company SSO with provided UI package.
[[ADR-0027-use-sso-and-ui-package-for-auth|Source]]
```