Memory & knowledge graph

A project carries more than its ten gates. It remembers the documents you fed it, the ones it generated, and the web of relationships that ties them together.

The library holds every document, the files you uploaded and the ones each gate produced. Uploads can be tagged as files, design screens, or wireframes, so they group sensibly and feed the right gates.

Underneath, CubeDot builds a knowledge graph from your blueprint, your features, functionalities, stories, and how they relate. Your agent can query it over MCP to answer the questions that come up mid-build, like “what depends on this?”

The graph runs both ways. As you build, the CLI can write back what happened:

• Reports and field notes capture the story of a chunk of work.
• Deviations record where the implementation intentionally departs from the spec.
• Devchanges (via cubedot devchange) capture off-spec work so it’s tracked without polluting your list of spec functionalities.

Anything that came from write-back is tagged source_kind: 'writeback' on recall, so you can always tell the spec apart from what actually got built. There’s more on the mechanics in Devchanges & write-back.