Repository navigation
design(id/atlas): where agent notes live — zettel vs repo vs publishing directly into the ID graph #6022
Description
Parent: #6018 (Atlas ingestion program). Statements S7–S10 of the 2026-11-04 brief.
Questions (Drew, in substance)
- Where do agent notes go? Agents produce notes constantly (working notes, research_notes, goal files, memory entries, scratch findings). There is no single placement rule today, and the answer decides what Atlas ingests and what future agents can find.
- What is the difference between the Zettelkasten and the repo as note homes? (Drew's dictation says "that tile cast" — read as the Zettelkasten, dezren39/zettel, the Emanote slip-box; interpretation recorded in the program inventory.) When does a note belong in the zettel graph vs committed to a code repo vs kept in agent memory/workspace?
- Publishing directly into the ID graph: some notes/objects should be published as ID-graph objects rather than files at all — which classes, and what changes (identity, writer-set, relations) when they are?
Tie-ins (do not reinvent)
- ID relation methods are already covered elsewhere: writer-set authority #5545, the capability/relation family under #5686, and tonight's worlds/licensing program (#5955). This design consumes those relation methods for notes rather than inventing a parallel model.
- Tonight's zettel brain-dump design already fixes part of the shape: every surface emits ONE
note_submissionenvelope; zettel notes are first-class Atlas corpus; the Turso submission DB is the system of record; mandatory metadata = content hash + provenance spans; nothing auto-commits (staging → human promotion). The placement design must compose with that pipeline, not bypass it. - The docs migration (#5981 + #5983) is moving the canonical home of fleet/architecture docs into code — placement rules for agent notes must agree with the migration's classification standard (sandbox-environment material stays in hatch-personal; everything else canonicalizes to code / zettel / ID).
- Atlas ingestion (parent program) is the downstream consumer: whatever homes are chosen, each needs an ingestion path with provenance marks (source system @ machine @ date).
Design must answer
- A placement decision table: note class (ephemeral working note, durable finding, design, research, daily log, user-facing doc) → home (workspace scratch / memory / repo doc / zettel / ID graph) → lifetime → Atlas-ingested? at which tier?
- The zettel-vs-repo distinction stated crisply enough that an agent mid-task can apply it in one step.
- The ID-graph publishing path: which note classes qualify, what an ID-native note's identity/provenance is, and how repo/zettel copies relate to it (canonical vs projection).
- Migration expectations for the existing sprawl (research_notes, goal workspaces, memory topics): swept, grandfathered, or left with pointers.
Done looks like
A placement design doc + the decision table, cross-linked from the zettel program and the ID epic (#2056), with any implementation split into follow-on issues.
Activity
developing-today commentedon Nov 5, 2026
CODE-1688
dezren39 commentedon Nov 5, 2026
Wave-2 child filed under this issue
wasRevisionOf/specializationOf/wasDerivedFrom/wasGeneratedBy/wasAttributedTo, per the research comment on #3125) mapped into the ID graph's relation vocabulary, reusing the relation-display methods from the design(id): client-side capability providers — one provider model for ESP32/MQTT, terminal, Bevy, smartphone, and web #5686 family. This issue decides which classes publish; design(id/atlas): ID-graph publication format — Atlas objects + provenance/lineage relations as ID-graph objects #6062 designs the format.— Wave-2 research fold-in, 2026-11-04 (prior-art doc:
~/workspace/scratch/atlas-ingestion-brief-2026-11-04/prior-art-research.md)dezren39 commentedon Nov 5, 2026
🤖 Agent note · done
Triage findings (verified 2026-11-05 against fresh GitHub state)
note_submissionenvelope returns nothing in this repo yet, so the design composes with that pipeline as specified in the issue body, not against landed code.