projectdocs

projectdocs are the project memory of an exploration: plans, decisions, bug reports, reviews and notes as Markdown files, grouped in phases and anchored to code symbols. Source code shows what the program does. projectdocs record why it was built that way, what was tried before and what is still open.

projectdocs are optional. Tracemoor works without them, and you can start them at any point in a project.

Where the files live

projectdocs live in the exploration, not in the source repository:

<exploration>/projectdocs/<project>/
  _project.md                 masterplan
  progress.md                 current state (optional)
  phases/
    08-polish-amp-open-issues/
      _phase.md               phase marker: title, order, status
      2026-06-17_bugreport_tile-cache-not-invalidated-….md
      09-subphase/            a subphase lives inside its parent
  decisions/NNN_*.md          architecture decision records (optional)

Every entry is a plain Markdown file with a YAML frontmatter. You can read and edit the files in any editor and version them with git. See Share an exploration.

Phases

A phase is a named section of the work, for example "Git integration" or "Polish & Open Issues". It has a title, an order number and a status. A phase can contain subphases. A subphase is a folder inside its parent's folder.

Status	Meaning
`planned`	Not started.
`in-progress`	Work is under way.
`completed`	Done.
`open-issues`	Done, but bug reports in it are still open. Set automatically, see Bug reports.
`verified`	Checked and accepted by a person. The AI does not set this status.

Entries

An entry is one Markdown file in a phase. Its type says what kind of knowledge it holds:

Type	Holds
`plan`	What is going to be built.
`summary`	What was built, in a session or a milestone.
`decision`	A decision and its reasons.
`design`	A design or UI note.
`research`	Research results and sources.
`review`	A code or quality review.
`log`	Running notes.
`bugreport`	A bug from report to fix, in one file.
`featurerequest`	A wish or an idea.
`ticket`	A ticket, usually imported from Jira or GitHub. See Tickets.

bugreport, featurerequest and ticket entries have a lifecycle status (open, in progress, closed or finished). It is stored as a reserved tag in the frontmatter, next to free tags such as ui or regression.

The file name is created from the date, the type and the title: 2026-06-17_bugreport_tile-cache-not-invalidated.md.

Anchors

An anchor links an entry to a code symbol, for example a bug report to the function that caused the bug. From the code, the editor gutter shows that an entry is anchored there. From the entry, the anchor leads to the current position of the symbol. Entries can also be anchored to git commits. See Anchors.

flowchart LR
    E["projectdocs entry"] -- "anchor" --> S["code symbol"]
    E -- "commit anchor" --> C["git commit"]
    S -. "gutter mark, peek" .-> E

projectdocs and specs

Specs (URS, FS, test cases) use the same anchor mechanism but add a status workflow, signatures and traceability. projectdocs have none of this. Use projectdocs for working knowledge and specs for requirements that must be verified. See Specifications.

projectdocs and the AI

The AI reads and writes projectdocs with the projectdocs_* tools. Before it changes a symbol, it looks up the entries anchored to it. After a fix, it appends the result to the bug report and anchors the changed symbols. See projectdocs and the AI.