Repo docs

Per-repo documentation — each repo's docs/ and README, ingested and associated with the repo. Rendered through the <<<RepoDocs>>> tag.

← source docs · code_pipeline/README.md

code_pipeline

The Conductor execution-provenance graph tracer — the "debug operator" (DO) from the Living Code-Graph spec (CM/DO/PS/GC), rebuilt clean.

Why this exists (not a fix — a replacement)

dz_debug is split-brained: three folders on disk all named dz_debug (a good 269-line DB-backed tracer, a weak 42-line RAM-only one, and stale vendored copies), plus a find_packages() + same-name-project-folder trap that makes import dz_debug resolve to an empty namespace shell. So from dz_debug import debug_decorator — stamped onto every function by codebean — resolves to nothing, and the calling class was never recorded.

We are not untangling that rot. code_pipeline is a new name, a new source tree, rebuilt from the spec, with a src-layout so the outer-name shadow is structurally impossible.

What it does (spec IDs)

- DO-1 call graph: nodes {handle, guid=uuid5(file:qualname:commit), file, commit}, real caller→callee edges (contextvars call-stack), variable snapshots, run/trace scoping. - DO-2 every branch point via sys.monitoring (loops aggregated by count — loops-above). - PS-1..5: a NEW, dedicated, auto-timestamped DB ($CODE_PIPELINE_DB, default ~/code/forge/code_pipeline.db); in-memory hot path → serialise on function stop; FULL collection with backpressure (never a silent drop); not grandfathered onto telemetry.db. - Node commit joins the wayback git lineage; the runtime trace is a traversal of the static graph.

Use

from code_pipeline import trace, new_run, edges, branches
new_run(task="my run")
@trace
def f(x): ...

Env

- CODE_PIPELINE_DB — trace DB path (default ~/code/forge/code_pipeline.db) - CODE_PIPELINE_REPR_LIMIT (2000) · CODE_PIPELINE_QUEUE_MAX (20000) · CODE_PIPELINE_BRANCHES (1)

Test

~/code/.venv/bin/python tests/test_graph.py     # standalone, or: python -m pytest tests/