DEV Community: dotdot

What Should Developers Practice When AI Writes the Code?

dotdot — Wed, 05 Aug 2026 20:39:50 +0000

As AI generates code, the weight of the skills developers need is changing. Typing code quickly matters less, while understanding the work, evaluating generated code, and managing design and complexity matter more. Using AI well requires distinguishing the practice that can shrink from the practice that must deepen.

AI lowers several early barriers on the path to expertise. As a result, what one person can build and attempt expands dramatically. Turning that change into real capability requires training thought and judgment alongside generation speed.

Typing Speed Matters Less

When developers entered code directly, the ability to translate an idea into exact syntax quickly had a major effect on productivity. Memorizing common syntax and APIs, becoming fluent with editors and shortcuts, and increasing typing speed reduced real working time.

When AI writes the first draft, the time spent entering code falls sharply. A developer can describe a requirement in natural language or request a change against existing code, and AI can produce an implementation across several files. Typing remains useful, but it is moving away from the center of productivity.

before: think → recall syntax and APIs → type → run
now:    think → describe the work → AI generates → review and revise → run

The mechanical cost of expressing code has fallen. Understanding what should be built and deciding whether the result is appropriate still take time.

Understanding the Work Before Coding Becomes Easier

Before implementation begins, developers must understand unfamiliar code and requirements. They find related files, follow call relationships, identify the intent and constraints of the existing design, and estimate the reach of a change. Slow information retrieval can consume much of the time before implementation even starts.

AI compresses this exploration. It can locate relevant parts of a codebase, summarize the roles of several files, explain unfamiliar libraries and concepts, and suggest possible change points. A developer can see the overall shape of a problem sooner.

This resembles an extension of cognition. AI searches a wider field for signals and proposes relationships. The developer uses those candidates to distinguish meaningful differences and select the context needed for the task. Areas that were previously expensive to explore enter a reviewable range.

Practice Evaluation More Deeply Than Generation

As code generation accelerates, the ability to evaluate the generated result determines productivity and quality. A developer must be able to read the code, explain its behavior, and decide whether it satisfies the requirements, preserves existing contracts, and avoids defects and security risks.

Evaluation goes beyond finding syntax errors. It asks whether the code understood the actual problem, whether responsibilities sit in the right place, whether tests verify important boundaries, and whether the result will remain maintainable.

This practice becomes more important as generated code looks more polished and convincing. Readable expression and sound design are separate qualities. Code that runs and code that can be operated and maintained are also separate outcomes. Developers need the judgment to verify evidence instead of accepting surface-level completeness.

Design and Complexity Management Become More Valuable

AI can add code quickly. It can continue producing plausible implementations even when direction and boundaries are unclear, allowing complexity to grow just as quickly. As generation becomes cheaper, choosing what to build and where to stop becomes more important.

Good design divides requirements into narrow, explicit responsibilities, limits how far a change can spread, and makes relationships explainable. Complexity management distinguishes present needs from possible future needs, finds where duplication and exceptions accumulate, and chooses what to delete or simplify.

These abilities retain their value in AI-assisted work. Faster generation makes the consequences of design decisions appear sooner and at a larger scale. Good design amplifies AI productivity. Poor design amplifies the complexity AI can produce.

Distinguish Shrinking Practice from Deepening Practice

Practice that matters less	Practice that must deepen
Typing code and boilerplate quickly	Defining the purpose of the work and its success conditions
Memorizing every syntax form and API	Finding information and selecting relevant context
Decoding unfamiliar code entirely from scratch	Verifying the explanations and relationships proposed by AI
Completing the first implementation draft by hand	Evaluating the behavior and quality of generated code
Performing repetitive transformations manually	Managing design boundaries and complexity

The skills on the left continue to provide useful foundations. Experience writing and debugging code helps build the judgment on the right. The important change is the purpose of practice and the proportion of time invested in each side.

Lowering a Few Barriers Expands the Possibilities

The path to expertise has included entry costs separate from depth of knowledge. Learning syntax, configuring a development environment, interpreting unfamiliar error messages, and writing repetitive code all slowed early attempts.

AI lowers several of these barriers. It reduces the time from an idea to an executable draft and makes a first result possible in an unfamiliar domain. Developers can run more experiments, small teams can cover a wider product surface, and individuals can approach larger problems.

Lower barriers broaden access to the starting line. Experts can apply their existing knowledge and judgment across a much wider field. This is why productivity and possibility grow together.

Guard Against Laziness in Thought and Judgment

Immediate answers and code make it easy to accept a result before understanding it. A developer can request implementation before clarifying the requirement, skim generated code, or stop evaluating once tests pass.

When this habit repeats, output speed increases while the ability to structure a problem and detect errors weakens. Time saved through AI should be reinvested in better questions, design review, code reading, and result verification.

Knowing the limits of AI means understanding which errors are possible, checking the evidence required for important decisions, and keeping human responsibility for the result. More capable tools also make skipped judgment more tempting, so deliberate review habits become essential.

Type Less and Judge More Deeply

Developers in the AI era can move time from entering code to understanding problems, choosing designs, and reviewing results. Lower entry barriers let more people explore greater possibilities, while experts can apply their judgment across a wider range.

The center of practice moves with that change. Typing and memorization receive less emphasis. Problem definition, context selection, code evaluation, design, and complexity management receive more. Understanding this shift lets developers capture AI productivity while keeping ownership of thought and judgment.

The more code AI writes, the more deeply we must practice deciding what to build, recognizing good code, and knowing what to trust.

Using AI Well Means Extending Our Cognition

dotdot — Wed, 05 Aug 2026 20:28:26 +0000

Using AI well goes beyond delegating more work to a machine. It begins with using our ability to perceive information, preserve memory, discover relationships, and make judgments more deliberately. It then extends those abilities into a range that would be difficult to handle alone. The essence of using AI is applying and extending our cognition.

From this perspective, the central question is how we direct that expansion. We decide what we are trying to understand, which information should become memory, and which relationships matter. AI becomes a cognitive tool that explores and compares a wider field of information, then presents it back to us for judgment.

Cognition Selects Information and Builds Relationships

Cognition receives external signals, distinguishes differences, preserves memory, and discovers relationships.¹ Thinking assigns importance and priority to perceived information, then arranges and combines it for the current purpose.²

We assign different importance to different information. The goal we want to achieve, events that have already happened, and our interests select the memory we need. Two people can read the same document and notice different passages or connect different experiences because they are solving different problems.

perceive a signal
  → distinguish meaningful differences
  → recall memory and relationships
  → combine them for the current goal
  → choose the next action

This flow remains when we use AI. Defining the question, selecting context, comparing results, and choosing the next action are cognitive activities performed by us. AI increases the range we can explore at each step and the amount of information we can compare at once.

AI Becomes an External Cognitive Tool

Humans have long extended cognition through external tools. Writing preserves memory outside the body. Tables of contents and indexes retrieve that memory. Maps and diagrams place relationships in front of us that would be difficult to hold entirely in the mind. Calculators and computers handle repetitive calculation and transformation so we can focus on higher-level problems.

AI belongs to this history of cognitive tools. Through natural language, it can search many documents for relevant information, compare different perspectives, and organize scattered clues into an explanation. Earlier tools accelerated specific cognitive operations. AI connects activities such as retrieval, summarization, comparison, and expression through a shared natural-language interface.

memory in the mind
  + knowledge recorded outside it
  + candidates retrieved and reorganized by AI
  → a wider space for human reasoning and review

This expansion lets us examine broader evidence, compare more possibilities, and test our thinking in several forms. External tools support detailed memory while we focus on judgment and understanding.

Cognitive Extension Begins with an Environment We Can Perceive

As AI handles a wider field of information, people must still be able to understand and manage that environment. Ambiguous names, mixed responsibilities, and hidden relationships produce unclear signals for both people and AI.

An environment that is easy to perceive makes the role of information visible. Names and locations reveal what information concerns. Headings and indexes show where it belongs in the whole. Links and explicit relationships connect information that should be read together. Structures that distinguish current decisions from historical records help assign priority to memory.

These structures are the language we already use to find, explain, and review information. AI uses the same human-readable structure as cues for exploring a wider range.

People Set Goals and Expand the Search Together with AI

Assigning importance to perceived information requires a criterion. I believe that criterion begins with the subject—we—and the desires that subject holds.² What we want to create, which problem we want to solve, and which outcomes we can accept are values that guide the use of a tool.

People set goals and evaluate results. AI searches broadly for information connected to those goals, proposes relationships that are easy to miss, and quickly unfolds possible explanations and options. This collaboration applies human cognition to a broader field of information and possibility.

person: set purpose → select context → evaluate results → make accountable judgments
AI:     expand range → retrieve candidates → propose relationships → support expression and comparison

Effective use keeps these roles connected. We compare AI output with our memory and experience, supply missing context, and refine the question. Our own understanding changes through that repeated exchange.

Extension Requires Better Questions and Review

The reasoning space opened by AI contains useful and inaccurate candidates together. Better judgment comes from checking the evidence behind a result, looking for missing perspectives and incorrect relationships, and applying accountable criteria to important decisions.

AI literacy therefore includes several connected abilities: structuring a problem, selecting relevant context, verifying results, and integrating new information into one's own understanding. Prompt writing is one part of that broader practice.

As AI develops, our role becomes clearer. We establish purpose and criteria, select meaningful signals from the range expanded by the tool, and connect the result to the next action. AI becomes an interface that reflects and extends our cognitive activity.

Applying Cognition to a Wider World

Using AI well begins with using our own cognition well. The ability to clarify what we want to know, manage memory, inspect relationships, and judge results determines the direction of AI use.

From that foundation, AI explores more signals than we can sense or remember at once, compares more relationships, and expresses more possibilities. This extension becomes a practical ability when we preserve structures we can understand and criteria we can apply.

The essence of using AI is applying our cognition to a wider field of information and possibility.

In this article, cognition broadly means finding differences, patterns, and relationships in signals. AI extends cognitive function into the range of finding and comparing patterns in anything we can define as a signal, including signals that living beings cannot sense. ↩
In this article, thinking is the process of deciding the importance and relationships of perceived information for a current purpose. I believe those criteria begin with the position and desires of the subject—we. ↩

What If a Project Had Psychometry?

dotdot — Wed, 05 Aug 2026 20:16:21 +0000

After changing code, the harder question is often not what changed, but what else should be reviewed with it. A project must preserve readable traces of its work so that specifications, architectural constraints, and tests connected to a changed file are not overlooked. Dotdotgod treats graph impact, which reads those traces backward from changed files, as a form of project psychometry.

Explicit project memory maintained by people creates two routes: one from a task goal to relevant documents at the start of work, and another from changed files back to the review scope after the work is done.

Project Memory Has Two Retrieval Directions

Living beings use present signals to recall past experience and choose what to do next. Could a project also retrieve the memory it needs from a current goal or an event that has already happened? This article uses cognition as an explanatory analogy, not as a rigorous model from cognitive science.

At the start of a task, the desired outcome is the retrieval seed. We interpret the request and find the relevant rules, specifications, architecture, and past decisions. After the task, the changed files become the seed. We inspect the result and find the documents, tests, and verification commands that should be reviewed alongside it.

Task start:  goal and request → required project memory
Task finish: changed files    → documents, tests, and source to review

Dotdotgod's query supports the first route by moving from a natural-language question to semantically related documents. graph impact creates the second route from changed files and maintained relationships. Both narrow the maintained sources that should be read now.

Maintained Traces Are the Source of Memory

In fiction, psychometry reads memories from traces left on an object. A project needs readable traces before it can offer anything similar. Dotdotgod keeps project memory in documents that people can read and edit.

Specifications describe the behavior the product currently guarantees.
Architecture documents preserve design rationale and constraints.
Test documents explain what is verified and how.
README indexes and Markdown links create routes to the next document.
Traceability explicitly connects specifications, implementation, tests, and verification commands.

Graph indexes and vector caches are derived retrieval data built over those sources. Maintained project memory remains in documents when a cache is deleted, and graph and vector data can be rebuilt from documents and repository structure. Search results provide addresses to source documents, while graph scores indicate review priority. Actual behavior is judged by examining the relevant sources, code, and tests together.

Graph Impact Reads Traces in Reverse

When a document points to implementation and tests, a changed file can follow those relationships in reverse.

dotdotgod graph impact . \
  --changed packages/cli/src/commands/query.mjs \
  --yml

Repeat --changed when several files make up one change. Each changed file becomes a graph seed, and specifications or tests shared by several seeds are merged into one overall review ranking.

The graph uses relationships that people maintain or that the repository can derive deterministically: structured traceability, Markdown links, README routes, and package and test structure. The default ranking combines Personalized PageRank seeded by changed files with traceability, verification signals, memory-area policy, and direct proximity. The semantic_similarity relationship is also computed deterministically from paths, filenames, headings, and package names. query uses a separate natural-language embedding search.

The following abbreviated example shows the essential output shape. Actual paths, scores, and reasons depend on repository state and configuration.

impact:
  changed_files:
    - packages/cli/src/commands/query.mjs
  groups:
    docs:
      items:
        - path: docs/spec/cli/QUERY.md
          score: 65.4
          reasons: [implemented_by, routes_to]
    tests:
      items:
        - path: packages/cli/test/e2e.test.mjs
          score: 58.1
          reasons: [verified_by]
  recommended_actions:
    - review_related_docs
    - run_related_tests
    - run_dotdotgod_validate

score indicates the value of reviewing a candidate early. reasons exposes why a candidate appears, such as structured traceability or a direct relationship. Grouping results into documents, tests, source files, and commands gives an agent a bounded set of next actions.

The Limits of the Psychometry Analogy

graph impact returns a bounded list of top review candidates. Related items may remain outside the result, and whether a high-scoring file needs modification is decided by reading its connected sources and tests.

Result quality depends on the quality of the traces a project preserves. Stale README files, missing implementation relationships, and large files responsible for many behaviors make the review scope broader and less specific. Clear document roles and traceability and test relationships that describe the current state produce more useful candidates from changed files.

Use the graph impact result as the next review list. Make the final decision after checking the connected sources and tests.

change files
  → graph impact
  → review related sources and tests
  → update the necessary code and documents
  → run tests and dotdotgod validate

People Maintain Project Memory

Names, paths, document roles, and relationships that are easy for people to understand also become cognitive cues for AI. At the start of work, the route runs from a goal to the required sources. At the end, it runs from changed files back to the sources that should be reviewed.

Both directions begin with the same maintained sources. When people update documents and traceability to match the current state, the agent's retrieval and change-review routes change with them.

Project psychometry is the ability to read the next review route that people might otherwise miss from the memory they have maintained.

How Graph Impact Finds What to Review Alongside a Changed File

dotdot — Sun, 02 Aug 2026 06:33:56 +0000

Semantic search can find documents related to a natural-language question. After an implementation change, the central question becomes which specifications, architecture notes, tests, and verification commands should be reviewed alongside the changed file. dotdotgod graph impact starts from changed files, produces a bounded review list with explicit reasons, and uses the documentation table of contents as a reverse map from a change back to its maintained sources.

A filename search alone has difficulty answering this question. Code and documentation may use different names, and one change may connect to several packages and verification paths.

The essential foundation is project memory that people can review and maintain directly. Specifications, architecture notes, test documents, README indexes, and traceability relationships remain in the repository, so people and agents can read and update the same evidence. Graph impact calculates the next review route from these maintainable sources.

Use Changed Files as Graph Seeds

For a single changed file, use the following command to find related items:

dotdotgod graph impact . \
  --changed packages/cli/src/commands/query.mjs \
  --yml

Repeat --changed when several files belong to the same change:

dotdotgod graph impact . \
  --changed packages/cli/src/commands/query.mjs \
  --changed packages/cli/src/query/chunks.mjs \
  --yml

The command deduplicates paths in first-seen order and accepts up to 20 unique, equally weighted changed-file seeds. Changed files appear first, while items connected to several seeds are merged into one ranking. This finds specifications and tests that matter across the whole change.

Graph Relationships Come from Maintained Project Evidence

The project graph is built from relationships that people maintain or that the repository structure exposes deterministically. query handles repository-wide semantic similarity search, while graph impact uses connections whose review rationale can be traced. The graph is a derived map of this evidence, and the team directly manages relationship accuracy by reviewing the Markdown sources and traceability information.

Signal	Meaning
Structured traceability	`implemented_by`, `verified_by`, `related_doc`, and verification commands
Documentation relationships	Markdown links, headings, and README navigation routes
Project structure	Relationships among packages, source, tests, configuration, and resources
Memory policy	Roles and priorities for current specifications, architecture, tests, and archives
Deterministic routing	Matches among paths, filenames, headings, README files, memory areas, and package names

Human-authored traceability has higher confidence than routing hints inferred from paths or names. When explicit connections are sparse, README files and stable project terms provide secondary navigation routes.

Graph impact quality therefore depends on both the graph algorithm and the condition of the maintained project evidence. Results become more specific when specifications and tests point to the real implementation, README files route to current documents, and files have narrow responsibilities.

Rank by Review Value

Returning every related node would turn impact analysis into another repository-wide search. The default balanced policy combines Personalized PageRank seeded by changed files with project review policy.

changed files
  → bound the candidate scope
  → multi-seed Personalized PageRank
  → apply traceability and verification policy
  → build a bounded result ranked by review value

The base score begins with PPR calculated from the changed files. Explicit traceability, test and verification signals, and direct proximity through Markdown links and README files add weight. Deterministic routing hints act as secondary signals when paths, headings, memory areas, or package names match.

Memory policy applies the current area's priority and its fresh or stale classification, then penalizes archive bodies. The first screen favors traceability, tests, and direct proximity over lower-confidence routing-only items. When enough actionable files exist, low-actionability metadata such as dependencies is kept out of the result.

The default policy favors current specifications and verification routes over archive bodies. Here, fresh and stale are memory-area classifications unrelated to file modification time.

The Result Is a Review List with Reasons

--yml returns a bounded structure that an agent can read directly. The following example illustrates the output shape; actual paths, scores, and reasons depend on repository state and configuration.

impact:
  ok: true
  changed_files:
    - packages/cli/src/commands/query.mjs
  groups:
    docs:
      items:
        - path: docs/spec/cli/QUERY.md
          score: 65.4
          reasons: [implemented_by, routes_to]
    tests:
      items:
        - path: packages/cli/test/e2e.test.mjs
          score: 58.1
          reasons: [verified_by]
  recommended_actions:
    - review_related_docs
    - run_related_tests
    - run_dotdotgod_validate

The result groups documents, behavior contracts, tests, files, commands, and package resources. score and reasons explain each inclusion, while omitted-item counts indicate candidates beyond the bounded output.

The default output or --compact works well for quick human reading. Agent workflows can use --yml, while --json provides detailed scores and automation diagnostics.

Graph Impact and Vector Search Have Different Roles

dotdotgod query finds documents semantically close to a natural-language question. Graph impact finds review items connected to changed files through maintained relationships.

Feature	Seed	Primary signals	Meaning of the result
`query`	Natural-language question	Multilingual embeddings	Documents semantically close to the question
`graph impact`	Changed files	Traceability, links, PPR, and policy	Items to review first after a change

The default graph impact ranking does not use embedding similarity. Lexical routing through paths, headings, README files, memory areas, and package metadata is calculated deterministically. Embedding search and the graph index have separate caches and failure boundaries.

This separation keeps results explainable. Each result can be identified as coming from semantic similarity or from implementation and test relationships, README routes, and other maintained evidence.

A High Score Is a Review-Priority Signal

A higher impact score indicates greater value in reviewing an item early. The score does not determine whether a file is broken, and affected items may remain outside the bounded result.

Sparse traceability or a large file that owns several behaviors produces broader results. After graph impact identifies a route, read the specifications, update implementation and tests, run regressions, and confirm that links and traceability still point to the current state.

change a file
  → run graph impact
  → review related specifications and tests
  → update the necessary code and documentation
  → run tests and dotdotgod validate

The graph cache is also derived data. Graph commands refresh it from repository files when it is missing or stale, while the source specifications and code remain the basis for judgment.

Measure Impact Quality Against Expected Results

Explaining why a score was calculated and placing genuinely useful files near the top each require verification. dotdotgod evaluates graph impact ranking against checked-in expected results for representative cases.

Metric	What it measures
`Precision@5/10`	The share of top results that must or should be reviewed
`Recall@10`	The share of must-review items found in the top ten
MRR	How early the first must-review item appears
`nDCG@10`	Ranking quality across required and recommended relevance grades

The evaluation script compares current results with a baseline and returns a verdict. As real cases accumulate, these measurements provide evidence for choosing project-appropriate CI thresholds.

Change Review Starts from a Reverse Table of Contents

A documentation table of contents is a forward map from a product question to relevant specifications and tests. Graph impact is a reverse map from code and documentation changes back to the sections that should be reviewed with them.

Connecting both directions lets specifications, implementation, and tests continue to describe the same project state after a change. The essential property is that although the navigation map is calculated automatically, its evidence remains in documents and relationships that people can read and correct. When the team maintains those sources, the agent's review routes update with them.

Graph impact finds review routes that people may otherwise miss within human-maintained project memory. Final impact decisions come from reviewing the connected sources and tests together.

How dotdotgod Query Finds Relevant Documents from a Natural-Language Question

dotdot — Sun, 02 Aug 2026 05:29:43 +0000

A documentation table of contents is the fastest retrieval method when an agent knows the relevant role and path. A user's question may use different language from a document's filename, and the question and document may even be written in different human languages. dotdotgod query searches locally for document passages that are semantically close to a natural-language question and routes the agent to the maintained sources worth reading.

Documents remain the source of project memory. Embeddings and search results are derived retrieval data that connect a question to those sources.

Start from Meaning When the Path Is Unknown

Consider this question:

Why does Load exclude old plans from its default context?

The relevant explanation may live in LOAD_PROJECT.md, MEMORY_AREA_CONFIG.md, or a document about context curation. A filename search may not connect “old plans” from the question with terms such as archive, local memory, or stale in the documents.

query accepts a free-form question and finds semantically related Markdown passages.

dotdotgod query . \
  "Why does Load exclude old plans from its default context?" \
  --limit 5

Multiple arguments after <root> are joined into one query. --limit accepts values from 1 through 100 and defaults to 30. The limit applies to distinct Markdown files rather than passage count.

Keep the Search Corpus within Docs-First Boundaries

Query searches Markdown documents under docs/ and applies the load.documentationSummary.exclude policy to define its scope.

The default corpus excludes these bodies:

docs/plan/
docs/archive/

Active plans and historical records are read through README indexes and explicit paths when needed. Hidden paths, paths that appear to contain secrets, and configured skip directories are also excluded from embedding.

This scope preserves the different roles of current shared documentation and local working records during retrieval.

Split Markdown along Its Heading Hierarchy

A useful search unit needs both the meaning of one section and enough context to interpret it. dotdotgod splits Markdown along its heading hierarchy, limits each body fragment to 1,600 characters, and attaches path and heading information.

docs/spec/LOAD_PROJECT.md
└── Focused Query
    └── query searches shared documentation ...

Each passage contains its repository-relative path, heading hierarchy from the top level through the current section, and a bounded body fragment. The path and headings provide an address for interpreting a result, while the body provides meaning to compare with the question.

Run the Multilingual E5 Model Locally

Query currently supports one model: Xenova/multilingual-e5-small. It runs locally through @huggingface/transformers, so document bodies are not sent to a remote embedding API.

Following the E5 input format, Query adds a different prefix to each kind of input.

query: Why does Load exclude old plans from its default context?
passage: path: docs/spec/LOAD_PROJECT.md ...

The query receives the query: prefix and document passages receive passage:. The model converts both into normalized 384-dimensional float32 vectors.

If the model files are absent, the runtime may download them to its user-level cache on first use. Remote provider selection and alternative embedding-model profiles are not currently supported.

Compare Semantic Distance across Every Passage

Query directly compares how closely the question matches every document passage in meaning (cosine similarity). For the current small local corpus, it does not need a separate index that quickly narrows the search to likely nearby candidates (approximate nearest neighbor).

convert the question into semantic coordinates
  → compare semantic distance with every passage
  → add a small bonus for matching words in titles and paths
  → sort consistently by score and path
  → select the highest result for each Markdown path

When a word from the question appears directly in a result path or title, Query adds a small bonus (lexical boost). Semantic proximity remains the primary signal, while explicit filename and heading matches also contribute.

After sorting, Query deduplicates results by Markdown path. Even when several passages from one document score highly, only the highest passage represents that file. This keeps one or two long documents from filling the result set and gives the agent a broader set of documents to review.

Reuse Embeddings for Unchanged Passages

Derived vector data lives in a repository-specific cache excluded from Git.

.dotdotgod/vectors/
├── manifest.json
├── chunks.jsonl
└── embeddings.f32

manifest.json records the schema, model, dimensions, exclusion policy, and refresh information. chunks.jsonl stores passage and path metadata, while embeddings.f32 stores float32 vectors.

When a passage fingerprint remains the same, Query reuses the existing vector. It embeds only new or changed passages and removes deleted passages when rewriting the cache.

If the cache is damaged, incomplete, or incompatible with the current schema, model, or dimensions, Query rebuilds it. Each artifact is written to a temporary file and replaced with an atomic rename to reduce the risk of partial writes.

The cache is derived data that can be rebuilt from maintained documents at any time.

Return a Bounded Set of Candidates for Source Reading

The default human-readable output stays concise. With --json, callers can inspect structured query, model, dimension, index, and result data.

Each result provides a chunk ID, repository-relative Markdown path, heading hierarchy, and bounded body excerpt. The final score includes the small bonus for matching expressions, and the original semantic-similarity score remains available.

A high score identifies a maintained-source candidate whose meaning is close to the question. A product contract under docs/spec/ and an explanatory document under docs/concept/ may use the same words while serving different roles. The agent checks the result path and heading to identify that role, then reads the maintained source.

Query and Graph Impact Answer Different Questions

Both features find related documents, but they begin from different inputs and use different signals.

Feature	Starting point	Primary signals	Purpose
`query`	Natural-language question	Multilingual semantic retrieval with a small bonus for matching expressions	Find documents close in meaning
`graph impact`	Changed file	Traceability relationships, links, PPR, and project policy	Find items to review together

Query uses its own local vector cache. Graph impact's default ranking uses deterministic relationships and word-match routing (lexical routing); embedding similarity is not part of its default route.

Load combines Query results with the documentation map when a natural-language focus is present. After code or documentation changes, graph impact identifies the next review route.

Semantic Retrieval and the Documentation Map Form One Reading Route

Semantic retrieval finds candidates when the path is unknown. Paths and README files then explain the role of each candidate document.

question
  → find candidate paths with query
  → identify their roles through README files and memory areas
  → read the necessary sections from maintained sources

Vector search finds the source address an agent should read even when the question and the document use different expressions.

How dotdotgod Load Turns a Documentation Table of Contents into a Reading Route

dotdot — Sun, 02 Aug 2026 03:59:30 +0000

Docs-first project memory keeps its source material in documents that people can review. An agent still needs to select the part relevant to the current task. The dotdotgod Load workflow creates a short reading route through the maintained documentation table of contents for the current request.

The previous article separated maintained documents from derived retrieval data. This article follows the sequence Load uses to narrow the reading scope when an agent starts a session or refreshes its context.

Check the Project Entry Points

Load begins with the primary entry points for project memory.

AGENTS.md
the current agent entry point
README.md
docs/README.md

AGENTS.md provides working rules shared across agents. The repository README explains the project's purpose and usage, while docs/README.md is the top-level index for specs, architecture, tests, and local-memory areas.

Load also identifies the repository root and existing user changes. When the session already contains clear baseline information, it reuses that context and preserves the user's worktree changes.

These entry points establish a stable address for the next stage of retrieval.

Start from the Table of Contents

Running Load without arguments displays shared Markdown paths below docs/ as a prefix-compressed tree.

/load

The documentation map counts docs/ as depth 1 and expands through directory depth 5. A deeper subtree is summarized with exact recursive directory and Markdown-file counts.

docs/
├── spec/
│   ├── README.md
│   └── cli/
│       ├── README.md
│       └── QUERY.md
├── arch/
│   └── README.md
└── test/
    └── README.md

The directory structure lets an agent choose a retrieval area, and README indexes guide it to the next document. Paths expose document roles early enough to distinguish relevant areas before opening their bodies.

Narrow the Reading Route with a Question

Free-form Load arguments become one natural-language query.

/load command routing

When local query is available, Load runs the equivalent of:

dotdotgod query . "command routing" --limit 30 --json

Focused Load reduces the documentation map to depth 3 and presents at most 30 semantically related Markdown files. When several passages from one file match, the highest-ranked passage represents that file.

natural-language question
  → semantically related document paths
  → path role and README context
  → relevant sections from maintained sources

Query results provide routes to source documents likely to matter for the question. A follow-up article explains how the embedding model, passage splitting, and vector cache produce those routes.

Open Current Work and History When Needed

The shared documentation map and default query corpus exclude these subtrees:

docs/plan/
docs/archive/

This default scope prioritizes current shared documentation. When an active plan matters, Load inspects the entries under docs/plan/ and reads the relevant plan. When a past decision matters, it uses docs/archive/README.md as the history map and follows it to the relevant archive body. Current work and historical records enter the context through separate reading routes.

Keep the Documentation Route Available When Search Fails

Load exposes this optional CLI discovery hint:

Help: dotdotgod --help

The hint is available independently of CLI execution status. In environments without the CLI or shell access, README indexes and the documentation map continue the retrieval route.

If model download, inference, or cache access fails during a focused query, Load returns to the base documentation table of contents. Source files, maintained documents, and project configuration remain intact. Query may refresh the ignored .dotdotgod/vectors/ cache and download the local embedding model into the user-level cache on first use.

Good Context Comes from a Short Reading Route

Load narrows the reading scope in five steps.

Check the maintained project and documentation entry points.
Show the retrieval scope through a depth-bounded documentation map.
Use semantic retrieval to narrow candidate documents when a question is present.
Select only the plans and history relevant to the current task.
Read the necessary sections from the maintained sources.

The same source documents can produce a different reading route for each session and question.

Current project context stays useful when the route from trusted sources to the documents worth reading now remains short.

The Role of Vector Search in Docs-First Project Memory

dotdot — Sun, 02 Aug 2026 03:12:40 +0000

When designing project memory for AI agents, it is tempting to choose the retrieval technology first. Before embedding documents, storing conversations, or building a graph, a project needs to decide where its durable knowledge will live. The dotdotgod approach keeps that knowledge in documents that people can review and version, then uses search and graphs as derived layers that route agents to the documents they need. This is the basic structure of docs-first project memory.

The previous articles explained how directories, filenames, and README files form a documentation table of contents for AI agents, and how dotdotgod keeps that table of contents current. This article takes the next step by separating the authoritative source of project memory from the retrieval data that can be rebuilt from it.

Separate Sources from Derived Data

Project memory contains several layers with different lifetimes.

Layer	Examples	Role
Shared sources	`AGENTS.md`, `docs/spec/`, `docs/arch/`, `docs/test/`	Rules, product behavior, design rationale, and verification knowledge
Local working memory	`docs/plan/`, `docs/archive/`	Current intent and relevant historical records
Derived retrieval data	Graph index, vector cache, manifest	An acceleration layer for finding related source documents
Session context	Load output and selected document bodies	A temporary reading scope for the current request

Maintained documents can be read, changed, and reviewed by people. When those documents are committed to Git, a project can trace when their contents changed and review the relationships between specs and tests in the same change.

The vector cache under .dotdotgod/ is calculated from selected Markdown passages. The graph cache indexes documentation relationships as well as package, source, test, and configuration metadata. Both improve retrieval speed and quality, while authority over product behavior and design decisions remains in maintained documents and code.

Maintained documents
  ├── relationship extraction → graph index
  ├── passage embedding       → vector cache
  └── selective reading       → session context

The direction of these arrows matters. Maintained documents preserve meaning; the graph, vector cache, and session context retrieve and deliver that meaning for the current task.

Derived Data Should Be Rebuildable

Separating sources from derived layers creates a clear failure boundary. Deleting the vector cache leaves the Markdown sources intact, and a stale or corrupt graph index can be rebuilt from repository files. When semantic retrieval is unavailable, an agent can still navigate through the directory documentation map and README indexes. Shared rules and specs also remain in the repository after an individual agent session ends.

This recoverability preserves essential project knowledge as models, embedding formats, and agent tools change. Local vector and graph caches stay separate from their sources so they can be recalculated from source files, maintained documents, and project configuration.

A Search Result Is an Address, Not the Answer

Natural-language retrieval is useful when a question and a filename use different wording. A user might ask, “Why are old plans excluded from the default context?” while the relevant documents are named LOAD_PROJECT.md and MEMORY_AREA_CONFIG.md. Multilingual embedding search can find passages with related meaning even when their wording differs.

Semantic proximity alone does not reveal whether a passage is a current spec, a historical plan, or an unverified idea. Directory paths expose document roles, and each README provides a local index for its area. Memory areas describe scope and fresh or stale classification, while explicit traceability connects specs to implementation and tests.

A search result is therefore a candidate address for a source document worth reading. The agent checks the result's path and role, reads the relevant source, and then makes a decision.

The Graph Creates Review Routes Back to Source Documents

The relationship graph finds specs, tests, and commands that deserve review alongside a changed file. Markdown links, README routes, package relationships, and structured traceability provide those connections.

A graph score sets review priority. Results vary with the scope and quality of the recorded relationships, so the final decision comes from reading and verifying the highest-ranked specs, code, and tests.

Vector retrieval and the relationship graph begin from different inputs.

Retrieval method	Starting point	Routes it returns
Directory documentation map and README indexes	A known documentation area	Child directories, documents, and the next local index
Vector retrieval	A natural-language question	Documents with semantically related passages
Graph impact	A changed file	Documents, code, and tests that deserve review together

Each method provides a route from a different starting point back to maintained source documents.

Load Creates a Reading Scope Without Copying the Sources

A docs-first structure becomes most useful when agents read selectively. The dotdotgod Load workflow narrows the reading scope for the current task in five steps.

Check entry points such as AGENTS.md, the repository README, and docs/README.md.
Build a depth-bounded documentation map before reading broad document bodies.
Use semantic retrieval to narrow document routes when the user provides a question.
Select only the plans or history relevant to the current task.
Read the relevant sections of the required source documents.

Load output is temporary retrieval context shaped for the current session and question. A later task can create a different reading route from the same source documents.

Trust Starts with Where Project Memory Lives

Retrieval accuracy alone cannot establish the quality of AI project memory. People must be able to review the source behind a result. Paths must distinguish current specs from historical records. Project knowledge must survive deletion of the search index, and different agents must be able to reach the same sources and rules.

Docs-first project memory uses vector retrieval, graphs, and Load as navigation tools built on a reviewable source.

Maintained documents preserve project memory. Retrieval results point to the part of that memory worth reading now.

How dotdotgod Keeps a Documentation Table of Contents Current

dotdot — Tue, 21 Jul 2026 12:51:41 +0000

dotdotgod does not create a documentation table of contents once and leave it behind. It combines initialization, README indexes, automated validation, traceability, impact analysis, and archiving with the normal development workflow. The navigation structure can therefore stay current as documents are added, moved, split, and completed.

The previous article described project directories and filenames as a book-like table of contents for AI agents. That structure can still decay as a project grows: new documents disappear from README indexes, links keep pointing to old paths, and completed plans remain mixed with active work.

dotdotgod treats documentation structure as more than a recommendation. It puts a maintenance mechanism at every stage where a document is created, changed, or completed.

Create the Initial Index, Then Expand It with the Project

dotdotgod creates a baseline documentation structure during project initialization.

AGENTS.md
CLAUDE.md
CODEX.md
docs/
├── README.md
├── spec/
│   └── README.md
├── arch/
│   └── README.md
├── test/
│   └── README.md
├── plan/
│   └── README.md
└── archive/
    └── README.md

These are not empty directories. Each README explains the area's role and the rules for placing documents there. The project starts with the major parts of the book and their initial table of contents before individual chapters are written.

Different agents use the same structure. AGENTS.md provides shared working rules, while CLAUDE.md and CODEX.md are thin entry points into those rules. Documentation discovery starts at docs/README.md, so Pi, Claude Code, and Codex can share paths and terminology instead of creating separate documentation systems.

dotdotgod does not list every document in one enormous index. Each directory's README.md acts as the local table of contents for that area.

docs/README.md
    ↓
docs/spec/README.md
    ↓
docs/spec/cli/README.md
    ↓
docs/spec/cli/LOAD_SNAPSHOT.md

Each README records important documents, child directories, status, and a one-line purpose. Adding, renaming, splitting, or archiving a document also requires updating the nearest README in the same change. A README is therefore not just an introduction; it is an active routing table.

A small subject begins as one focused document.

docs/spec/PAYMENT.md

When the domain grows, it can be promoted into a directory with its own README and supporting documents.

docs/spec/payment/
├── README.md
├── LIST_API.md
├── SUMMARY_API.md
└── REFUND_POLICY.md

This keeps one index from becoming too long and prevents one large document from accumulating unrelated responsibilities. As documentation grows, the navigation hierarchy grows with it.

After extending the structure, a project can configure the memory role of each path. dotdotgod config . shows the resolved policy, and dotdotgod config init . writes the built-in defaults to dotdotgod.config.json for editing.

{
  "memory": {
    "areas": [
      { "id": "decision", "label": "Decisions", "paths": ["docs/decision/**"], "scope": "shared", "freshness": "fresh", "role": "decision-record", "priority": 70, "includeBodiesByDefault": true }
    ]
  }
}

A project can register additional paths, change the paths and priorities of the default spec, architecture, and test areas, or remove areas it does not need. This configuration does not create or delete files. It classifies existing documents by memory role and scope. The Memory Area Config specification defines the fields and priority rules.

Validate Names and Structure Automatically

Documentation rules do not survive for long when they depend only on author discipline. The dotdotgod CLI checks whether project documentation follows the configured structure.

dotdotgod validate . \
  --include-local-memory \
  --check-index

Validation checks whether:

required baseline documents and README indexes exist;
Markdown links and structured traceability data are valid;
document names, paths, and sizes follow project rules; and
the index matches the current files.

Document size is also part of maintaining the table of contents. The default limit for one Markdown file is 200 lines and 10,000 characters. Exceeding either limit reports FILE_TOO_LONG or FILE_TOO_LARGE. Instead of extending one document indefinitely, split it by subject and update the nearest README index.

Projects can adjust size limits and excluded paths in dotdotgod.config.json.

{
  "validation": {
    "markdown": {
      "maxLines": 200,
      "maxChars": 10000,
      "exclude": ["docs/archive/README.md"]
    }
  }
}

Exclusions should remain narrow and cover only files that are difficult to split, such as intentionally large indexes or generated documents. One-off validation can override the limits with --max-lines and --max-chars. Generated traceability-link sections and json dotdotgod blocks are excluded from size measurement so generated metadata does not distort the document's body size.

This resembles proofreading a book before publication: check its table of contents, cross-references, and missing pages. Automated validation finds missing or oversized entries before the navigation structure collapses.

Connect Specs, Implementation, and Tests

Even a well-structured index loses trust when its documents drift away from the code. dotdotgod can record structured traceability on important behavior specifications, connecting them to implementation files, tests, related documents, and verification commands.

For example, after changing a CLI implementation, graph impact can identify the specs and tests that deserve review.

dotdotgod graph impact . --changed <path>

The graph and index do not replace the source documents. The follow-up article How to Find the Documents That Belong in a Change Review explains how changed files lead to related documents and how those results are ranked.

Separate Current Plans from Historical Records

As documentation ages, the distinction between current and historical information becomes more important. Active work lives at:

docs/plan/<task-slug>/README.md

A plan records its goal, scope, target files, risks, implementation sequence, verification, and current status. When the work is complete, the plan moves to:

docs/archive/plan/<task-slug>/

docs/archive/README.md remains the historical index for completed work. The history is preserved without mixing it into the current work queue.

Agents do not load every archive body by default. They inspect the historical index first and open a specific record only when a past decision is relevant. Archiving preserves history while removing completed work from the active table of contents.

The Table of Contents Is Maintained by the Workflow

dotdotgod creates the baseline index through initialization and shared agent rules, then uses each README as a local index. As documentation grows, domains are promoted into directories. Validation and impact analysis check links and traceability, while the plan lifecycle separates current intent from historical records. Load can then use the maintained index as a project-memory map for selective reading.

A documentation system does not stay useful because its initial structure was tidy. Every operation that adds, changes, splits, or completes a document also needs a rule for updating the table of contents.

dotdotgod is not trying to maintain a pile of Markdown files. It maintains a living project-memory system that people and multiple AI agents can read, change, and verify in the same way.

AI Agent Memory Starts with a Documentation Table of Contents

dotdot — Sun, 19 Jul 2026 08:13:24 +0000

Good project memory for AI agents is not a larger pile of documents. It is a hierarchical table of contents that helps an agent reach the right document quickly and ignore irrelevant ones. Directories identify document roles and parent topics, filenames name individual entries, and each README.md routes the agent to the next level. When a subject grows, a single file can be promoted into a directory with its own README and supporting documents. Paths, filenames, README indexes, and headings can therefore work like a book, letting an agent find the relevant specs, architecture, tests, and plans without reading the entire project.

Project Documentation Is a Book

We rarely read a book from the first page to the last when looking for one answer. We inspect the table of contents and move to the relevant part and chapter. Project documentation can follow the same model.

docs/
├── README.md                         # Table of contents for the whole book
├── concept/                          # Part 1: Core concepts
│   ├── README.md                     # Part 1 index
│   └── CONTEXT_CURATION.md           # Chapter: Context curation
├── spec/                             # Part 2: Product behavior
│   ├── README.md                     # Part 2 index
│   ├── PROJECT_INITIALIZER.md        # Chapter 1: Project initialization
│   └── cli/                          # Chapter 2: CLI
│       ├── README.md                 # Chapter 2 index
│       └── CONFIG_COMMAND.md         # Chapter 2, section 1: config command
├── arch/                             # Part 3: Architecture and constraints
│   ├── README.md                     # Part 3 index
│   └── DOCS_STRUCTURE.md             # Chapter: Documentation structure
└── test/                             # Part 4: Tests
    ├── README.md                     # Part 4 index
    └── CLI_INTERFACE.md              # Chapter: CLI regression tests

Read this structure as a route through nested indexes. spec/ is the top-level index for product specs, and PROJECT_INITIALIZER.md is one entry beneath it. When the CLI subject grows, cli/ becomes a new child index and cli/README.md routes readers within it. CONFIG_COMMAND.md is one entry in that child index. In book terms, these correspond to Part 2, Part 2 Chapter 1, Part 2 Chapter 2, and Part 2 Chapter 2 Section 1.

Full path	Role in the table of contents	Book notation
`docs/README.md`	Top-level index for the whole book	Full table of contents
`docs/spec/README.md`	Area index for product behavior	Part 2 index
`docs/spec/PROJECT_INITIALIZER.md`	Project initialization entry	Part 2, Chapter 1
`docs/spec/cli/README.md`	Child index for CLI documents	Part 2, Chapter 2 index
`docs/spec/cli/CONFIG_COMMAND.md`	config command entry	Part 2, Chapter 2, Section 1
`docs/arch/DOCS_STRUCTURE.md`	Architecture of the documentation system	A chapter in Part 3
`docs/test/CLI_INTERFACE.md`	Test strategy for CLI behavior	A chapter in Part 4

A small subject starts as one indexed file. When it grows, it becomes a directory with a README.md and its own child entries. The filename names the entry, while the full path is its address from the top-level index.

Directory Names Explain Document Roles

A directory does more than group documents by topic. It tells an agent how to interpret the information inside.

concept/ explains mental models and core concepts.
spec/ defines the product's current specs.
arch/ explains architectural rationale, structure, and technical constraints.
test/ records regression tests and manual test procedures.
report/ preserves evidence from research and measurement.
plan/ records the intent of active work.
archive/ preserves completed work and historical context.

Consider this path:

docs/spec/cli/CONFIG_COMMAND.md

This document describes the CLI config command in the current product specs.

Paths change the meaning even when documents cover the same subject.

docs/arch/CLI_ARCHITECTURE.md
docs/test/CLI_INTERFACE.md
docs/archive/plan/cli-refactor/README.md

The first explains architecture, the second explains testing, and the third records historical work. Their paths reveal role and freshness even when their bodies use similar terms.

A Filename Is a Chapter Title

The following filenames distinguish files but do not explain their contents.

DOCUMENT_1.md
NOTES_NEW.md
FINAL_V2.md
MISC.md

These names expose scope before the files are opened:

PROJECT_INITIALIZER.md
CLI_INTERFACE.md
LOAD_SNAPSHOT.md
VALIDATION_ARCHITECTURE.md

A good filename works like a chapter title that is meaningful in the table of contents. Dotdotgod uses kebab-case for directories and UPPER_SNAKE_CASE for durable Markdown documents. README.md is the predictable entry point for every directory.

CONFIG_COMMAND.md is more useful than API_1.md because it names behavior and domain instead of writing order. Stable, specific names let people and agents use the same vocabulary when finding and referencing documents.

README Is the Local Table of Contents

Each directory's README.md is a local index rather than a generic introduction.

# Product specifications

- `CLI_INTERFACE.md`: user-facing CLI specs
- `PROJECT_INITIALIZER.md`: project initialization behavior
- `cli/`: detailed specs for individual CLI commands
- `plan-mode/`: plan mode and staged execution specs

An agent can read this README and choose the next document without opening every file in the directory. This is why adding, moving, or renaming a document should update the nearest README in the same change.

Increase the Depth of the Index as Documentation Grows

Do not begin with a complex hierarchy. If a subject has one document, start with one file.

docs/spec/PAYMENT.md

When the domain grows into multiple documents, promote it to a directory.

docs/spec/payment/
├── README.md
├── LIST_API.md
├── SUMMARY_API.md
└── REFUND_POLICY.md

payment/README.md becomes the intermediate index between the spec area and its individual documents. An agent narrows the search in four steps:

Select a documentation area in docs/README.md.
Select a product domain in docs/spec/README.md.
Find the relevant behavior in docs/spec/payment/README.md.
Read only the necessary section of the selected document.

The amount of possible context grows with the project, but an index keeps the context required for the current task small.

A Good Index Also Says What Not to Read

When changing the current behavior of a CLI command, inspect docs/spec/cli/ first. Read docs/arch/ when implementation constraints matter, docs/test/ when regression coverage matters, and docs/archive/ only when a historical decision is relevant.

The documentation structure answers two questions:

What should the agent read now?
What can the agent ignore for this task?

Good project memory is not a system that injects every document into every prompt. It provides a route to relevant information and a boundary that excludes irrelevant information.

Designing Project Memory Means Designing Addresses

It is natural to begin project-memory design by asking what to store. First ask whether the information has a useful address.

Can a path and filename reveal a document's role and contents?
Does every directory contain an index to the next relevant document, while separating current and historical information?
Can the table of contents expand as documentation grows without making the agent read everything?

Directories divide the book into parts, filenames name chapters, README indexes route readers, and headings narrow a document into sections.

Designing documentation for AI is not cosmetic file organization. It is designing a table of contents that lets an agent reach the chapter required by the current question without reading the whole project.

DEV Community: dotdot

What Should Developers Practice When AI Writes the Code?

Typing Speed Matters Less

Understanding the Work Before Coding Becomes Easier

Practice Evaluation More Deeply Than Generation

Design and Complexity Management Become More Valuable

Distinguish Shrinking Practice from Deepening Practice

Lowering a Few Barriers Expands the Possibilities

Guard Against Laziness in Thought and Judgment

Type Less and Judge More Deeply

Using AI Well Means Extending Our Cognition

Cognition Selects Information and Builds Relationships

AI Becomes an External Cognitive Tool

Cognitive Extension Begins with an Environment We Can Perceive

People Set Goals and Expand the Search Together with AI

Extension Requires Better Questions and Review

Applying Cognition to a Wider World

What If a Project Had Psychometry?

Project Memory Has Two Retrieval Directions

Maintained Traces Are the Source of Memory

Graph Impact Reads Traces in Reverse

The Limits of the Psychometry Analogy

People Maintain Project Memory

Further Reading

How Graph Impact Finds What to Review Alongside a Changed File

Use Changed Files as Graph Seeds

Graph Relationships Come from Maintained Project Evidence

Rank by Review Value

The Result Is a Review List with Reasons

Graph Impact and Vector Search Have Different Roles

A High Score Is a Review-Priority Signal

Measure Impact Quality Against Expected Results

Change Review Starts from a Reverse Table of Contents

Further Reading

How dotdotgod Query Finds Relevant Documents from a Natural-Language Question

Start from Meaning When the Path Is Unknown

Keep the Search Corpus within Docs-First Boundaries

Split Markdown along Its Heading Hierarchy

Run the Multilingual E5 Model Locally

Compare Semantic Distance across Every Passage

Reuse Embeddings for Unchanged Passages

Return a Bounded Set of Candidates for Source Reading

Query and Graph Impact Answer Different Questions

Semantic Retrieval and the Documentation Map Form One Reading Route

Further Reading

How dotdotgod Load Turns a Documentation Table of Contents into a Reading Route

Check the Project Entry Points

Start from the Table of Contents

Narrow the Reading Route with a Question

Open Current Work and History When Needed

Keep the Documentation Route Available When Search Fails

Good Context Comes from a Short Reading Route

Further Reading

The Role of Vector Search in Docs-First Project Memory

Separate Sources from Derived Data

Derived Data Should Be Rebuildable

A Search Result Is an Address, Not the Answer

The Graph Creates Review Routes Back to Source Documents

Load Creates a Reading Scope Without Copying the Sources

Trust Starts with Where Project Memory Lives

Further Reading

How dotdotgod Keeps a Documentation Table of Contents Current

Create the Initial Index, Then Expand It with the Project

Validate Names and Structure Automatically

Connect Specs, Implementation, and Tests

Separate Current Plans from Historical Records

The Table of Contents Is Maintained by the Workflow

Further Reading

AI Agent Memory Starts with a Documentation Table of Contents

More Documentation Does Not Mean Better Memory

Project Documentation Is a Book

Directory Names Explain Document Roles

A Filename Is a Chapter Title

README Is the Local Table of Contents

Increase the Depth of the Index as Documentation Grows

A Good Index Also Says What Not to Read

Designing Project Memory Means Designing Addresses