Skip to content

Project Atlas: [Project Name]

This template defines the format for a project atlas — the single page a team member opens to navigate everything a project produced: the tickets, the pull requests, the design documents, and the decisions, all cross-linked so any artifact can be reached from any starting point.

An atlas answers three questions without leaving the page:

  1. Where is the work? — every ticket and PR, its status, and how the PRs depend on each other.
  2. Why does the work look this way? — which design or product decision each increment implements.
  3. Where is the full story? — pointers to the design documents, decision logs, and any companion views (generated navigators, NotebookLM notebooks).

Create an atlas when a project has grown past the point where its landing page can carry the map — typically when:

  • The project spans 5+ tickets or a stacked-PR chain where merge order matters.
  • Implementation increments trace to named decisions (decision-log entries, design-topic rulings, fork/option rulings) that reviewers need to find from the code and vice versa.
  • Team members other than the original author need to navigate the project mid-flight.

For smaller projects, the Where this connects section of the project landing page (index.md) is sufficient.

  • The atlas lives in the project’s roadmap directory (next to goal.md, design.md, decisions.md) and is linked from the project index.md.
  • The atlas is the source of truth for the project map. Companion views (interactive navigators, notebooks) are generated from it and are regenerated when the map changes — never edited independently.
  • Update the atlas when a PR merges, a ticket changes phase, or a new decision lands. Stale rows are worse than missing rows: date-stamp the snapshot.
---
title: "Atlas: <!-- REPLACE: project name -->"
description: "<!-- REPLACE: one sentence — the navigable map of tickets, PRs, and decisions for <project>. 40–300 characters. -->"
tags: [roadmap, <!-- REPLACE: domain tags -->, traceability]
domain: roadmap
maturity: draft
author: "<!-- REPLACE: your name -->"
sidebar:
label: "Atlas"
order: <!-- REPLACE: next free order in the project directory -->
---
**Snapshot: <!-- REPLACE: YYYY-MM-DD -->.** <!-- REPLACE: one line on current overall state, e.g. "Design settled; implementation stack open awaiting merge." -->
<!-- 2-4 sentences: what this page is, and the reading order for someone new to the project. -->
## Phases at a glance
<!-- One row per phase or track. The umbrella tickets are the entry points into Linear. -->
| Phase | Umbrella ticket | Status | Scope |
| ----- | --------------- | ------ | ----- |
| <!-- REPLACE --> | [PDEV-XXX](https://linear.app/ardacards/issue/PDEV-XXX) | <!-- state --> | <!-- one line --> |
## The PR stack
<!-- 1-3 sentence summary of the dependency structure and the merge order, then the diagram.
Solid arrows = "is stacked on" (base-branch dependency); merge bottom-up. -->
```plantuml
@startuml
<!-- REPLACE: one rectangle per PR, solid arrow from each PR to its base;
group merged foundations and the open stack in packages; add a legend. -->
@enduml
```
## Increment traceability
<!-- The core table. One row per increment/work item. Design anchors name the
decision ids (DEC-NN, DT-NNN, fork/option ids) the increment implements. -->
| Increment | Ticket | PR | Status | Design anchors |
| --------- | ------ | -- | ------ | -------------- |
| <!-- REPLACE --> | [PDEV-XXX]() | [repo#NNN]() | <!-- merged/open/planned --> | <!-- DEC-NN, F-N, O-N… --> |
## Decisions and where they landed
<!-- Map each named decision to the increments/PRs that implement it and the
document that records it. Include product decisions, not only technical ones. -->
| Decision | Recorded in | Implemented by |
| -------- | ----------- | -------------- |
| <!-- REPLACE: DEC-NN — one-line statement --> | [Decisions](decisions.md) | <!-- ticket/PR links --> |
## Design sources
<!-- Where the full design story lives: the project docs in this directory,
working design records (workbooks/design topics), and any conventions
documents the implementation is bound to. Note access constraints. -->
## Related and parked
<!-- Tickets deliberately outside the current scope: follow-ups, parked forks,
adjacent audits. State WHY each is parked so the boundary is legible. -->
## Companion views
<!-- Generated navigation aids derived from this atlas, with access notes:
- Interactive navigator (Claude Artifact): <url> — regenerate on change
- NotebookLM notebook: <url> — re-sync sources on change
These are conveniences; this page is canonical. -->