Public Access
codex
7b2bcd3631
PR and Push Build/Test / build-and-test (push) Successful in 12m0s
Append successful offline recovery with a duplicate-warning marker and retain failed replay sources. Offer newly available microphones through confirmation notifications. Add project discovery metadata and blocking association approval, plus nonblocking workflow requests that start a separate settings-agent conversation. Include regression tests, OpenSpec changes, and verified local Release startup.
82 lines
2.2 KiB
Markdown
82 lines
2.2 KiB
Markdown
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:
|
|
|
|
Maintain its YAML `name` as the project's display name and `description` as a grounded description of its purpose in at most 256 characters. These fields help summarizers identify missing project associations. Preserve other frontmatter and body content when updating them.
|
|
|
|
```markdown
|
|
---
|
|
name: Project display name
|
|
description: Concise project purpose and distinguishing context.
|
|
---
|
|
|
|
# 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]]
|
|
```
|