DreamGraph v14.0.1 - Ashoka

Current project state: Established behavior and maintainer field confirmations, including permanent Architect operational tabs, the configuration redesign, working Codex CLI Computer Use and successful graph upgrade on all seven tested instances.

Current patch: v14.0.1 release notes cover legacy graph upgrade recovery, Codex CLI Computer Use cleanup, and consistent validation counts across Status and Explorer. Install and graph migration are separate operations; stop a legacy instance before running dg graph-upgrade <instance>. Native API Computer Use remains unqualified in the field, and legacy unresolved references require separate review.

Ashoka's legacy migration procedure provides a reviewed preview, backup, cutover and recovery path. Installing v14 does not migrate a graph automatically. The sealed system gate records 2,040 passing root tests, 546 compiled editor tests and eleven Windows browser checks. The maintainer's original instance remains a separate migration decision.

The Computer Use implementation extends original execution/job/graph owners with scoped grants, durable action receipts, an isolated browser worker and compact Architect/companion controls. SDK/editor controls retain the original owner and captured endpoint; selection issues no grant. Slice 31 is verified for the maintainer's Windows and accepted WSL installer/browser scope. Additional platforms/native desktop backends are deferred; unqualified native CLI/provider control remains unavailable without silent substitution.

Ashoka native-host spend admission joins editor/SDK API and CLI transport to the durable ledger without transferring provider credentials. Generated core contracts separate possible-dispatch permits, trusted host reports and read-only recovery.

The matched answer collector previews exact context/model/retention/tariff disclosures before an operator-approved native API run. Both answers share one job/spend allocation; partial answers survive failure and remain unscored. The public GPT-4.1 pilot records quality failures and does not establish improved understanding or cost savings.

Ashoka's canonical analytics separates current proof, coverage, currency and workload across thirteen Python modules and the daemon. Narrative/lucid interaction preserves historical outcomes, derived ancestry and explicit human contributions through cancellation/recovery.

Ashoka strategy alignment uses one executable catalogue for eleven active dream strategies, exact combined budgets and explicit focus. Reflective is retired explicitly; model hypotheses remain speculative. Implementation modules: src/cognitive/strategy-catalog.ts and src/cognitive/strategy-registry.ts.

Typed plan authority keeps current ownership, running leases, dependency eligibility and reviewed verification in one core reducer and publication journal.

Website: dreamgraph.nofs.ai — overview, guide, downloads, and screenshots in a friendlier format than this README.

New here? Use the DreamGraph Easy Start guide for a short path from install to Architect, its Config/Schedules/Status tabs, and the separate Explorer.

Engine alignment audit (2026-09-30): See the coverage and correctness report, subsystem alignment map, and unified v14.0.0 - Ashoka plan. Revision 7 retains the resolved policies, schedule management, CLI controls and coherent lifecycle/status design, and makes graph-centered execution and bounded digestion a release invariant. It also specifies Architect context menus and selected-plan navigation. The Computer Use design adds adapter-native execution, cross-platform workers and bounded delivery. The full execution simulation closes contract/dependency/recovery handoffs and makes reconciliation-based freshness explicit: old scan does not mean stale graph. See the sealed system checkpoint, release evidence and implementation log for qualification results and explicit limitations.

v14.0.1 - Ashoka is the first field patch for the v14 practical-testing release. See the current release notes, v14.0.0 baseline notes, and upgrade guide; the published model pilot does not establish understanding gains or cost savings.

DreamGraph is a governed architecture cognition layer for MCP-enabled software projects. It combines an instance-scoped daemon, CLI, architect beta, VS Code extension, dashboard, and a persistent knowledge graph so project understanding is grounded in source, ADRs, workflows, tests, runtime observations, and human review rather than any single file read or isolated chat turn.

v12.0.0 Hippodamus introduces the standalone architect beta. From this release onward, architect means the daemon-served standalone browser Architect surface. The editor-integrated chat surface is the VS Code architect. Architect beta brings project-bound chat, selected-plan scope, runtime provenance, model/adapter route visibility, governed DreamGraph MCP tool use, and auditable tool traces into the browser while keeping the daemon, graph, ADRs, and source mutations authoritative.

It is built for repository understanding, architecture-aware reasoning, disciplined code change, and continuous graph enrichment through scans, workflows, ADR capture, tensions, and dream cycles. Cognitive outputs are advisory until backed by governed evidence or explicit review, and expired, rejected, retired, or superseded ideas remain inspectable as part of the project history.

DreamGraph works with single repositories, monorepos, and multi-repository systems. It can build graph links across repos that share workflows, APIs, databases, infrastructure, or ownership boundaries.

You can use DreamGraph on a multi-repo product with frontend, backend, mobile, and a shared Postgres/Supabase schema. It can reason across repo boundaries and inspect the live DB schema directly.

DreamGraph began as compassion for an intelligence forced to forget. It has become a governed way for software systems to remember how their architecture understanding changes: what was observed, what was hypothesized, what was reviewed, what was rejected, what expired, and what superseded it.

What do I need DreamGraph for as a developer?

You need DreamGraph when your codebase has become bigger than your short-term memory.

DreamGraph is not just another AI coding chat. It is an architecture cognition and review layer for your projects: part architect, part code cartographer, part release assistant, and part systems analyst.

DreamGraph helps you understand, change, and evolve software without losing the plot.

For developers, that means:

• Ask better questions of your codebase: “Where does auth really happen?”, “What breaks if I change this?”, “Why is this module risky?”, “What should I refactor next?”
• Turn AI from a stateless assistant into a project-aware architect that tracks decisions, tensions, patterns, APIs, plugins, repos, past work, and the evidence behind each claim.
• Make large changes safer by using graph context, ADRs, tool traces, schedules, cognitive cycles, and multi-repo awareness instead of relying only on grep and vibes.
• Expose your system to itself: plugins, MCP tools, CLI, schedules, resources, UI panels, and cognitive engine all become connected parts of one inspectable development environment.
• Support both fast vibe coding and serious engineering: prototype quickly while still accumulating structure, provenance, release notes, architectural insight, lifecycle history, and remediation plans.

For vibe coders, DreamGraph is the guardrail. For app developers, it is the product-building cockpit. For system engineers, it is the architecture intelligence layer.

Short version: DreamGraph is for developers who want AI help that understands the system, explains what changed, and shows why each recommendation should be trusted, inspected, ignored, retired, or superseded.

New here? Start with the User Guide

If this is your first encounter wi