Devchanges & write-back
As you build, reality diverges from the spec, you fix a bug, add a helper, or make a call the blueprint didn’t anticipate. CubeDot captures that without letting it pollute your clean spec.
Devchanges
Section titled “Devchanges”Off-spec work is captured as a devchange (cubedot devchange). A devchange is tracked in the knowledge graph in its own devchange: namespace, so it’s recorded and queryable, but it is not treated as a spec Functionality. Your feature list stays the source of truth; your implementation history stays separate and honest.
Write-back
Section titled “Write-back”The CLI can write several kinds of implementation signal back to the project:
- Functionality transitions,
start/complete/done. - Reports, what happened during a chunk of work.
- Field notes, smaller observations.
- Deviations, where the build intentionally differs from the spec.
A recall that comes from write-back is tagged source_kind: 'writeback', so you can always tell spec from implementation.
Resilience
Section titled “Resilience”Write-back is designed to fail safe. If one operation can’t be applied (for example a devchange on a project where devchange is disabled), the CLI pre-checks capabilities and refuses just that operation, every other transition, report, note, and deviation keeps flushing and syncing. There’s no global stall.
Cleaning up
Section titled “Cleaning up”delete_writeback removes a devchange node, its edges, and its report chunk cleanly, no orphans left behind.