mdflow v0.3.0: architecture that AI coding agents can act on

[yubinbin32-ops]

mdflow has evolved from a visual architecture graph into a context operating system for AI coding agents.

The project keeps a Git-tracked architecture graph beside the source, then uses MCP to turn it into task-scoped context. In v0.3.0, that context now reaches all the way into code execution:

• Ghost Blueprints → Solid Anchors: planned architecture can exist before code, then bind to real AST symbols as implementation lands.
• chain_code_stream: follows an execution path across files and returns only the participating functions, classes, and contracts.
• block_code_mutate: replaces a bound symbol atomically, runs verification, and restores the original file when verification fails.
• log_sanitize: removes terminal control noise and repeated success output while preserving useful failure context.
• Native macOS Context Console: explore dependencies, impact paths, code streams, plans, and Checkpoint evidence on one Canvas.

Reproducible measurements on the mdflow repository

Operation	Baseline	mdflow	Result
Task context	112,738 tokens	1,197 tokens	98.9% reduction
Four-module code chain	84,227 tokens	654 tokens	99.2% reduction
Build and test log	4,042 tokens	212 tokens	94.8% reduction

Run npm run benchmark to reproduce the measurements locally. Results will vary by repository and task.

Try it

cd your-project
npx -y github:yubinbin32-ops/Mdflow-Canvas init --scan
npx -y github:yubinbin32-ops/Mdflow-Canvas status
npx -y github:yubinbin32-ops/Mdflow-Canvas setup

• Website: https://dashend.cn
• v0.3.0 release: https://github.com/yubinbin32-ops/Mdflow-Canvas/releases/tag/v0.3.0
• Source and full benchmark notes: https://github.com/yubinbin32-ops/Mdflow-Canvas

I would especially value feedback from people using large repositories: which context boundary is hardest for your agent today, and what verification command would you want block_code_mutate to run before accepting a change?