---
name: <short human-readable title>
description: <one-line — what this memory is about, specific enough that a future search hit makes sense from this line alone>
type: project
created: YYYY-MM-DD          # the day you're writing this file
event_date: YYYY-MM-DD       # the day the thing being described happened (commit, decision, deploy)
# Optional relationships — delete the lines you don't use:
# updates: [older_project_file.md]    # this REPLACES older_project_file.md (will trigger archival)
# extends: [related_file.md]          # this REFINES related_file.md without replacing it
# derives: [source_observation.md]    # this was INFERRED from these source(s)
# related: [sibling_file.md]          # weak association, no directional claim
---

## What it is

One paragraph. What is this project / decision / state? Who/what does it
affect? Why does it matter enough to remember?

## State / decisions

Bullet the concrete facts that won't be obvious from reading the code later:

- Decision: X over Y because Z.
- Constraint: must support N because of M.
- Current status: shipped to staging / production / behind feature flag /
  paused / blocked on …
- Non-obvious gotcha: …

If the project has a file/path footprint, list the load-bearing files:

- `path/to/file.ex:L123` — what this does and why
- `path/to/template.html` — surface served at /foo

## Open threads

What's deferred, blocked, or pending. Each item one line. If they're truly
actionable, also surface them in the user's task list — memories are
durable context, not a TODO board.

- TODO: …
- BLOCKED on: …
- DEFERRED to next pass: …

## How to apply

One paragraph: when this memory matches a future request, what should you
*do* with it? Cite the file the next time the topic comes up? Use a
specific deploy command? Avoid a known pitfall?

This section is what makes a `project` memory useful on recall — without
it, the future agent has facts but no idea what to do with them.