code-work

Graph-Native Code

Treat the graph as the source tree. A generated .py, .ts, .json, or test file is a disposable projection used for execution; never patch it directly.

Represent the project

• Use one document root per generated file. Give it the intended filename and fileType.
• Use ordered child nodes for meaningful code units: imports, types, functions, classes, helpers, implementation blocks, exports, fixtures, and tests.
• A leaf should have one coherent responsibility and reason to change. Make it addressable when you may need to understand, test, revise, move, reuse, or remove it independently. Do not create a node for every line.
• When behavior is duplicated, put the shared function/class in the appropriate module node, update callers/imports, and remove the copies. The graph does not replace ordinary modular design; it makes that design movable and inspectable.
• Represent configuration, package manifests, and tests as document roots too.
• Connect durable design concepts to the concrete nodes they implement.

For code file types, generation concatenates root content and descendants as raw code in document order. Node titles are graph metadata, not emitted code.

Enter the work

If guided navigation would help at a real implementation choice, ask the graph for several concrete possibilities:

graph_suggest_next({
  task: "Build or change this graph-native software project and verify it",
  workflow: "coding"
})

Consider higher-weighted routes seriously, then choose, combine, modify, or reject them according to the actual task. The suggestions are provocations, not a state machine or exhaustive menu. In direct mode, choose these moves yourself and use the graph tools immediately; no coding capability is lost. If the useful route requires prior context, follow it with graph_understand, carrying the suggested stance and focus. If the task is already locally clear, make the next coherent graph-native code move instead.