Developer systems · C++ architecture · Verifiable change
A C++ workbench where every change carries proof.
Treechi is a desktop IDE for programs built as graphs of C++ reactors. It combines typed execution, fail-closed change gates, performance diagnostics and a provenance trail that connects each request to the code, evidence and release decision that followed.
Project snapshot
- Challenge
- Complex systems preserve code more reliably than they preserve why a change was requested, tested and accepted.
- Product decision
- Put executable graphs, typed schemas, performance diagnostics and change provenance in one visual C++ workbench.
- My role
- I set product direction and architecture, define the validation rules, review the measurements and make release decisions.
- Demonstrated
- Compile-to-apply gates, staged-index checks, deterministic export comparisons and measured performance paths run inside the system.
- Core stack
- C++20 · Dear ImGui · Direct3D 11 · MCP · CUDA
- Current stage
- Private Windows x64 build · version 0.1.0.
Evidence boundary: Figures are from a private repository as of 25 September 2026. Each result below identifies its test context and boundary.
The problem
Complex systems accumulate changes faster than teams can reconstruct why they exist. The hard questions come afterwards: who asked for this change, what evidence justified it, and did the passing test actually prove the intended behavior?
Usually the answers live in chat logs and in someone's memory. I wanted them in the tool itself, as records the platform keeps and checks, with an agent's account and the platform's own observation kept apart.
Treechi in Treechi
Treechi is developed this way, on itself. A source package lets Treechi read its own store as a graph, and a test places every tracked file of the repository inside or outside that graph.
Making change verifiable
Typed components reject invalid connections
Each graph node, called a reactor, is one C++ function with named, typed input and output ports. A connection is valid only when its schemas match; a failed execution publishes nothing.
Intent is versioned with implementation
Why a component exists is a revisioned field beside its body rather than a comment buried inside it. Apply records which intent revision the code implements, and review flags drift between the two.
Only the exact tested candidate can apply
Draft, compile, candidate, apply. The gate accepts only a passing candidate whose code, graph revision, schemas, fixtures and context still match the tested state.
Release criteria stay visible in the workflow
A threshold or stop condition appears beside the output it evaluates. The decision is visible while work runs instead of being reconstructed from a separate script afterwards.
A graph can export as a standalone C++ project. Treechi verifies that boundary rather than assuming it: the test runs the graph in the desktop engine, compiles and runs the export, compares every output, then changes one component to prove the comparison detects drift.
From request to evidence
Each step leaves a record for the next. A person can return to a component, ask why it exists and see the original request beside the evidence used to accept the change. The canvas also distinguishes changes made by a person from changes made by an agent.
- 01Capture the request in its original words
- 02Declare origin, files and checks
- 03Compile and test the exact candidate
- 04Prove checks can fail and pass
- 05Commit only after staged checks
- 06Reconstruct the decision later
A provenance query reads the chain back to the original request
How each step works
01
Asked
Treechi keeps requests in the requester's words and records where each one arrived. A request attributed to a person but received through an agent is marked attribution-unverified, and the caller cannot remove that label. Today requests arrive through the CLI or MCP rather than the desktop window.
02
Task
Every task names its origin: a person decided it, an agent proposed it, or a review finding raised it. Its record holds what was built, what was measured, how the proof was broken once, and what it does not claim.
03
Proof
To show that a regression check detects the intended change, Treechi alternates old and fixed code against one frozen fixture in isolated copies. A check must demonstrate both failure and success.
04
Commit
When a task reaches done, Treechi stages exactly the files it declared, runs its declared checks on that staged index, and commits only if they pass. On a refusal it unstages and names the failing check.
05
Message
The commit message keeps reported work separate from observed evidence. Everything above “Treechi saw:” is the agent's account; the sections below record what the platform verified and what remained outside its view.
06
Why
Later, a provenance query reconstructs why a component exists: its tasks, the original request, the command that changed it and the changes that followed.
One change, reconstructed
Reconstructed for this page
The quotation and identifiers below were written for this page; private requests and records are not shown. The feature, its measurement and its boundary are real, and the message follows Treechi's generated evidence structure.
- Askedreconstructed
- “The store keeps build leftovers nothing reads. Clear them, and show me the list before anything goes.”
- Changed
- store_compact removes build intermediates that nothing reads, with a dry run first and every file logged.
- Measured
- On a copy of a real 286 MB store it freed 103.6 MB of unused build artifacts.
- Falsified
- Each validation rule was deliberately violated once to prove its test can detect the failure.
- Boundary
- It has run on a copy of the store; no working store was altered.
Read the commit message · reconstructed
Remove build intermediates nothing reads, dry run first Asked for, verbatim: "The store keeps build leftovers nothing reads. Clear them, and show me the list before anything goes." store_compact removes build intermediates that nothing reads. A dry run comes first and lists every file; the real run logs every file it removes. Measured: on a copy of a real 286 MB store it freed 103.6 MB of build artifacts. Falsified: violated each declared rule once, and each rule's test failed as expected. Boundary: it ran on a copy; no working store was changed. Treechi saw: Checks: store_compact_dry_run and store_compact_logs_every_file passed (ctest -C Release, build), run with this task's files staged as tree 9c41e7a2d05b83f16e2a4c7d90b1f58e3a6c2d47. Treechi did not see: of the 5 files in this commit, 0 are carried by a reactor in this graph, so any change list above describes the graph and not these files. Everything above "Treechi saw:" is the acting agent's account, typed at 2026-09-25T15:02:11Z. The request request_7 was entered via mcp, so the platform did not see the user say it and the quotation above is attribution-unverified. No baseline observation exists for this task, so what follows "Treechi saw:" is the state at commit time rather than a difference.
The final section distinguishes the agent's account from what Treechi could verify directly.
Product evidence
The three results below connect directly to using the product: canvas response under stress, whole-system work on a real project and the cost of retaining project history. Lower-level implementation benchmarks remain available as drill-down.
Canvas frame, 5,000-node graph
Running build
3,775 ms to 29 ms
Caching and culling restored interactive canvas response in a synthetic stress case; vertices drawn fell from 1.7 M to 18 K. This is a limit test, not a typical workload or 60 FPS guarantee.
Whole-tick time, a real 33-node project
Running build
baseline to 43% less
Sending each component only the state bound to its inputs reduced request data per tick from 5.98 MB to 627 KB. Seventy-five of 76 outputs remained identical; the last reports wall-clock time.
A real project's history, on a copy
Validated build
167 MB to 14.3 MB
Content-addressed snapshots made a long local history substantially smaller without losing revisions: all 73 versions read equal before, after and after a restart. No working store was migrated.
Four implementation measurements and their test context
Diagnostics are switches with measured costs, and a setting is evaluated on the active graph by interleaving single executions and reporting a paired difference with its standard error.
A 60,000 × 16 table through a worker
Running build
189 ms as JSON to 48 ms as bytes
7.68 MB as bytes against 10.5 MB as JSON.
Dense GᵀG, 12,000 × 1,250, 8 threads
Validated build
plain loop to 33× faster
Hand-written SIMD kernels with bit-identical output; 37× with fused multiply-add. One benchmark on my machine. The kernels are not BLAS-class: OpenBLAS on one thread runs about 3.5× faster than the one-thread kernel.
The same call on CUDA
Validated build
4.12 s to 33.9 ms
121.6× the plain loop and about 3.3× the 8-thread CPU kernel, on one device, an RTX 4090. Near n = 300 the routed call was slower than the CPU.
store_compact, on a copy of a real 286 MB store
Validated build
— to 103.6 MB freed
The dry run lists every candidate and the real run logs every removal. Tested on a copy rather than a working store.
Current boundary
These product and trust constraints guide the first public release.
- The first release target is Windows x64 with MSVC; public packaging and signing are still in progress.
- Reactor bodies run with the user's permissions. File, network and process-access scans provide guidance rather than a security sandbox.
- The graph scheduler is sequential. Parallelism lives inside compute kernels, and exported C++ runs on one thread and still links Treechi's runtime libraries.
- Authoring and provenance queries currently run through the CLI or MCP. The desktop shows tasks read-only while the decision cockpit moves toward its first release.
Built with