Dynetic

Goal in. An approved plan grows the right agent roles at runtime. Reviewed code out.

A local-first control plane for visible, editable, and recoverable multi-agent coding workflows across Claude, OpenAI Codex, and OpenCode.

简体中文 · Product spec · Architecture · M3 acceptance

Important

Dynetic has completed its M0–M3 engineering scope, but it is still a development preview. The macOS app is not signed or notarized, and the CLI has not been published to npm.

What is Dynetic?

Dynetic is an open-source, local-first control plane for dynamic AI coding workflows. You describe a software goal; Dynetic selects from six built-in role blueprints, proposes an inspectable plan, waits for approval, then instantiates the required agents in managed Git worktrees. If runtime evidence reveals more work, the graph can visibly grow fan-out workers, bounded repair agents, or conflict resolvers without silently rewriting the plan you approved.

The workflow engine—not an autonomous manager agent—owns state, budgets, verification, and side effects. The accepted plan and the actual runtime graph are persisted separately in local SQLite, so every generated instance has a role, provider binding, parent, reason, lifecycle, and audit trail.

Why Dynetic?

• One control plane for multiple coding agents. Use Claude Agent SDK, OpenAI Codex CLI, or OpenCode CLI through one runtime contract.
• Built-in roles, not cloned provider accounts. Explorer, Implementer, Test Engineer, Reviewer, Repair, and Conflict Resolver are versioned, provider-independent blueprints bound to your configured runtime profiles only when invoked.
• Plans you can inspect and change. Edit a versioned workflow as a step list or live DAG before approval and during replanning.
• A workflow that visibly evolves. Runtime fan-out, repair, and conflict nodes appear as dashed causal expansions of the accepted plan and survive restart/replay.
• Durable, local execution. SQLite events and node-level checkpoints survive control-plane restarts without treating chat transcripts as state.
• Safe Git isolation. Every writing task runs in an owned worktree with write-scope auditing, verification, review, rebase, and cleanup.
• Human attention only when needed. Typed gates cover plan approval, risky actions, questions, budgets, and final review.
• Failure-aware orchestration. Retry a node, repair only the failed frontier, then escalate to a human instead of looping forever.
• Private by default. No account is required. Telemetry and model-backed planning are both explicit opt-ins.

Core features

Area	Capabilities
Agent system	Six versioned role blueprints → user Agent Profile → per-run Agent Instance; provider-neutral routing and permission intersection
Agent runtimes	Claude Agent SDK, Codex CLI, OpenCode CLI; normalized streaming events, usage, interruption, and capability-aware resume
Dynamic workflows	Accepted Plan + append-only Runtime Graph, editable DAG, fan_out / join, repair/conflict expansion, verification, gates, and checkpoints
Planning	Deterministic offline planner by default; guarded model planner with read-only tools, repair attempts, cost estimates, and safe fallback
Git delivery	Managed worktrees, .worktreeinclude, setup scripts, manifests, diff review, inline feedback, conflict-repair agents, merge, push, and GitHub PR
Reliability	Durable event journal, stale-run recovery, idempotent transforms, global/per-agent queues, budget gates, replay export, and adaptive subgraph repair
Desktop	Tauri 2 shell, bundled Node runtime, single instance, tray pending count, native notifications, deep links, and opt-in autostart
Templates	Five seed workflows, parameterized reuse, offline character n-gram semantic search plus keyword ranking, and conservative auto-application

Built-in roles, created only when needed

Blueprint	Selected when	Default boundary
Explorer	The repository boundary or evidence is unclear	Read-only
Implementer	An approved product change is ready	Declared write scope
Test Engineer	Behavior needs independent regression coverage	Declared test scope
Reviewer	Verified evidence needs an independent risk pass	Read-only
Repair	A failed frontier has new evidence	Failed instance's workspace
Conflict Resolver	An integration has concrete conflicts	Conflicted workspace

These are role contracts, not six permanent bots. A simple change creates one Implementer. A broader change may create Explorer → Implementer + Test Engineer → Reviewer. Runtime fan-out can create several fresh instances from one blueprint; each instance records its bound Agent Profile, parent, spawn reason, cost, and result.

How it works

flowchart LR
    Goal["Software goal"] --> Planner["Planner selects built-in blueprints"]
    Planner --> Plan["Accepted Plan<br/>logical contract"]
    Plan --> Approval{"Human approval"}
    Approval -->|edit| Plan
    Approval -->|approve| Engine["Durable engine"]
    Engine --> Bind["Blueprint × Agent Profile"]
    Bind --> Instance["Agent Instance<br/>isolated worktree"]
    Instance --> Evidence["Artifacts + verification"]
    Evidence --> Decision{"Enough evidence?"}
    Decision -->|runtime fan-out / failure / conflict| Expansion["Dynamic runtime nodes<br/>visible + append-only"]
    Expansion --> Bind
    Decision -->|yes| Review{"Human review"}
    Review -->|approve| Deliver["Merge · push · pull request"]

Loading

1. Register a real Git repository and one or more provider-backed Agent Profiles.
2. Press ⌘N and describe the outcome you want.
3. Review the role-aware plan—simple work gets one Implementer; broader work can assign Explorer, Implementer, Test Engineer, and Reviewer—and approve it from the attention inbox.
4. Watch the live DAG. Dashed nodes show agents created at runtime and why they appeared.
5. Inspect the manifest, verification evidence, artifacts, and diff.
6. Comment on diff lines to send structured feedback back to the agent.
7. Approve local merge—or explicitly authorize a branch push or GitHub pull request.

Quick start

Requirements

• Node.js 24 or newer
• pnpm 10
• Git
• At least one configured runtime:
  • Claude Agent SDK credentials
  • authenticated codex CLI
  • authenticated opencode CLI

Run from source

git clone https://github.com/gumlau/dynetic.git
cd dynetic
pnpm install
pnpm build
node packages/cli/dist/index.js

Dynetic opens http://127.0.0.1:4317 and stores local data in ~/.dynetic/. If the port is busy, the CLI tries the next available port. Use --no-open to keep the browser closed.

For development:

pnpm dev

Before submitting a change:

pnpm verify

Desktop app

The desktop build stages the production CLI deployment, web UI, and the current platform's Node executable inside Tauri resources. An installed app therefore does not require a separate Node installation.

# Validate desktop structure and configuration
pnpm --filter @dynetic/desktop check

# Compile a debug Tauri app without creating an installer
pnpm --filter @dynetic/desktop desktop:check

# Build a macOS .app and .dmg
pnpm --filter @dynetic/desktop desktop:build

Apple Developer signing and notarization are still required before public distribution.

Optional configuration

Environment variable	Effect
DYNETIC_AI_PLANNER=1	Enables model-backed workflow planning. The planner receives read-only tools, gets at most two repair attempts after its first candidate, and falls back to a deterministic valid plan.
DYNETIC_TELEMETRY=1	Enables telemetry only when DYNETIC_TELEMETRY_ENDPOINT is also set. Event names are allowlisted and identifiers are hashed locally. Prompts, filenames, diffs, and agent messages are excluded.
DYNETIC_TELEMETRY_ENDPOINT	Destination for explicitly enabled minimal telemetry. No endpoint means no outbound telemetry.
DYNETIC_NODE_BIN	Overrides the Node executable used by the desktop shell for development.
DYNETIC_SERVER_ENTRY	Overrides the bundled control-plane entry point for desktop debugging.

Architecture

Dynetic is a pnpm monorepo with strict TypeScript boundaries:

apps/server             Fastify HTTP/WebSocket composition root and orchestration
apps/desktop            Tauri shell and portable control-plane resources
packages/core           Task state machine, scheduler, workflow engine, gates, budgets
packages/dsl            Versioned workflow schema, built-in role catalog, validation, topology, plan diff
packages/adapters       Claude, Codex, and OpenCode runtime adapters
packages/store-sqlite   SQLite events, projections, plans, artifacts, gates, templates
packages/git            Repository checks, worktrees, diff, rebase, merge, cleanup
packages/ui             Inbox, board, runs, DAG, review, templates, and settings
packages/cli            Local server launch, port fallback, and browser integration

Read the engineering architecture and architecture decision records for state ownership, recovery, security, and clean-room boundaries.

Project status

M0–M3 engineering acceptance is complete and covered by automated tests. See the acceptance record for evidence and implementation tradeoffs.

The next release-focused work is:

• choose a stable version and publish release notes;
• sign and notarize the macOS app;
• validate installers on clean machines;
• publish the CLI to npm and test cold npx startup;
• maintain a real-provider compatibility matrix for Claude, Codex, and OpenCode.

Documentation

• Research findings
• Product requirements
• Epics and milestones
• Engineering architecture
• Agent blueprints and runtime graph
• Dynamic agent blueprint research
• M3 acceptance record
• Clean-room competitor boundary

Contributing and security

Contributions are welcome. Read CONTRIBUTING.md, use the issue templates, and run pnpm verify before opening a pull request.

Please do not disclose vulnerabilities in public issues. Follow SECURITY.md to report them privately.

License

Dynetic is licensed under the Apache License 2.0. Competitor research informs product behavior only; implementation follows the documented clean-room boundary. See THIRD_PARTY_NOTICES.md.