ZERO GRAMS OF SUGAR✦100% GIT-BACKED✦NO VIBES-BASED QA✦WALLS REMAIN MOSTLY INTACT✦ZERO GRAMS OF SUGAR✦100% GIT-BACKED✦NO VIBES-BASED QA✦WALLS REMAIN MOSTLY INTACT
Kool.ad/e

A tour of the questionable amount of engineering inside

Under the hood.
Behind the punch.

Coding agents write code fast. Kool.ad/e is building the system that makes sure they write the right code, in the right place, with someone checking their homework.

Inspect the ingredients ↓See what's brewing ↓

CURRENT IMPLEMENTATION ≠ FUTURE ROADMAP. WE LABEL BOTH.

● ENGINEERING NUTRITION FACTS
YOU
“Build a thing”→MAN.AGER
“Which thing?”GIT + SPECS
Versioned intent→AGENT WORKERS
Scoped changesVERIFICATION
Actual evidence→HUMAN GATE
You decide

✓ THE FUN PART IS THE BORING PART

The architectural thesis

The model proposes.
The software enforces.

Give an agent a vague goal, a shell and a prayer, and it'll ship something. The missing control plane is durable intent, narrow permissions, explicit approvals, repeatable execution, independent verification and a Git history that remembers what everyone agreed to.

01 / Current implementation

Already in the glass.

Rust desktop app, Git-backed planning, task-focused board, isolated code clones, multiple coding CLI adapters and application-controlled MCP tooling. Linux repository command isolation still uses Bubblewrap.

Existing foundationTarget / not yet shipping

What runs today

CURRENT
Desktop UI + Man.agerBoard, conversations, work coordination
→
Planning storeSpecs, questions, state, Git history
→
Task cloneIsolated code + explicit branches
→
CLI + MCP bridgeBounded tools via Bubblewrap

The model doesn't own the repository just because it knows how to type git push.

Where the data lives

CURRENT FOUNDATION
Shared planning GitPer-record specs, decisions, task state
↔
Operator-local stateChats, telemetry, credentials, evidence
↔
Code repositoryTask clones, changes, PRs

Separating shared facts from private runtime state avoids the “everyone edited the same JSON file” party.

02 / Target architecture from GitHub issues

What's brewing.

A single, versioned workflow with explicit gates; Docker-only execution for local and remote targets; independent agent reviews and browser/desktop QA. These are planned outcomes, not present-day product claims.

From idea to verified PR

TARGET
Relentless clarifyAsync question cards
→
Approve + reviewHuman confirms, independent agent challenges
→
Task DAGParallel independent work
→
Build + QAIndependent review, interactive checks
→
PR + reconcileMerge evidence updates living spec

Man.ager owns triage and repair. Reviewers are independent. User intent is not silently renegotiated to make a failing test happy. Lifecycle epic ↗

Same security boundary, more places to run

TARGET
Man.ager + dispatcherPolicy, authorization, Git publication
→
Execution contractVersioned request, events, artifacts
→
Docker workerLocal or authenticated remote SSH
→
Evidence + verificationReplayable results, brokered dependencies

No Docker socket in containers, no arbitrary host shell fallback, no special superpowers for Pi. Docker contract ↗

Agents that actually test the product

TARGET
Completed buildApproved acceptance criteria
→
Independent QALinux desktop / browser interactions
→
EvidenceScreenshots, checks, failures
→
Repair + re-reviewMan.ager decides, then proves it

“The agent said it looked fine” is not a test report. Runtime QA ↗

03 / Why any of this?

Guardrails, not magic.

It's not architecture for architecture's sake. Every boundary exists because autonomous software development gets weird when an agent can make changes faster than humans can notice bad assumptions.

01 / TRUTH

Git is memory. Spec is contract.

Approved intent and verified implementation are separate. The spec changes when evidence says it should, not when the model feels optimistic.

02 / SAFETY

Capability is rented.

Agents receive scoped tools, brokered dependencies and isolated execution. No automatic master key to the host.

03 / SCALE

Parallel, not pandemonium.

Task clones, Git leases and dependency graphs let workers cooperate without writing over each other's changes.

04 / QUALITY

Homework checked by someone else.

Independent reviewers and runtime QA require real evidence before declaring victory.

05 / PORTABILITY

Your stack, not ours.

Build/test/start recipes describe the user's project. Rust powers Kool.ad/e, but your project doesn't have to use Rust.

06 / EVOLUTION

New tricks need permission.

Man.ager can propose improvements to itself, but execution still needs approval, isolation, review and a PR.

04 / The build order

The roadmap is a dependency chain.

Durable shared state first, standardized execution second, then progressively more autonomous agents within the same constraints.

01 / FOUNDATION

Persist the intent.

Planning repos, per-record state, isolated clones, multi-user coordination and PR linkage.

Planning design ↗
02 / EXECUTION

Make sandboxing boring.

Docker-only workers, CLI parity, brokers and remote execution.

Execution design ↗
03 / LIFECYCLE

Ask. Build. Verify.

Async clarification, approval gates, independent review, interactive QA and repairs.

Lifecycle epic ↗
04 / EVOLVE

Upgrade responsibly.

Propose missing capabilities, ask permission, implement in isolation and submit a reviewed PR.

Evolve design ↗

No imaginary features in the ingredients list. Code and issue status are the source of truth.

And MCP?

Kool.ad/e already has a private MCP bridge for controlled agent tooling. General-purpose external MCP brokering is a separate capability, not something we're pretending already ships.

05 / The main event

From “just build it” to actually built.

The task lifecycle, before and after the full issue backlog. One diagram shows the implemented foundation. The other links every proposed major step to its issue, because “coming soon” without receipts is just marketing with better posture.

GREEN = EXISTING PATH
BLUE = TARGET DESIGN
Each future card opens the issue defining that behavior.

Today: the working ingredients.

A user-driven, Git-backed flow with isolated task work and verification. Some steps are assisted or manually gated, rather than enforced as one autonomous state machine.

CURRENT / BUBBLEWRAP
01 / PLAN✎Discuss & specify

Capture intent, questions and project context in a durable spec.

02 / TRACK▦Make board tasks

Track scope, source and destination branches, state and ownership.

03 / ISOLATE◇Clone per task

Separate working trees and claims prevent destructive overlap.

04 / BUILD⌘Run an agent

Choose a CLI and mediate repository tools through MCP and Bubblewrap.

05 / VERIFY✓Check & publish

Run verification and follow explicit Git publication controls.

Today does NOT have the entire future clarification, adversarial review and interactive runtime QA pipeline enforced end to end.

Tomorrow: the fully mixed lifecycle.

The application drives the state transitions, permissions and review gates. Specialists can disagree, but they cannot silently approve themselves, rewrite user intent or publish unverified work.

TARGET / ISSUE-BACKED

01 / PLANNING & APPROVAL

Ask enough questions that the answer actually means something
01 / TARGET ↗Clarify intentRelentless asynchronous question cards. No guessing what the user meant.SPEC & IMPLEMENTATION ISSUE #159 ↗02 / TARGET ↗Confirm the planExplicit user sign-off against an immutable plan snapshot.SPEC & IMPLEMENTATION ISSUE #160 ↗03 / TARGET ↗Challenge the planIndependent adversarial review before tasks exist.SPEC & IMPLEMENTATION ISSUE #160 ↗04 / TARGET ↗Reconcile specsKeep approved target and verified current behavior separate.SPEC & IMPLEMENTATION ISSUE #161 ↗

02 / BUILD & COORDINATE

Parallel work, without fifty agents fighting over the same file
05 / TARGET ↗Decompose workStandalone tasks and dependency-aware subtasks. One parent PR.SPEC & IMPLEMENTATION ISSUE #162 ↗06 / TARGET ↗Schedule safelyConcurrency, per-task clones, Git claims and controlled branches.SPEC & IMPLEMENTATION ISSUE #138 ↗07 / TARGET ↗Execute in DockerProvider-neutral harness routing and policy-bound execution.SPEC & IMPLEMENTATION ISSUE #136 ↗08 / TARGET ↗Record the evidenceVersioned results, telemetry and authorized dependencies.SPEC & IMPLEMENTATION ISSUE #137 ↗

03 / REVIEW, QA & REPAIR

Trust is good. A screenshot and reproducible test are better.
09 / TARGET ↗Review codeIndependent quality review and bounded repair loops.SPEC & IMPLEMENTATION ISSUE #163 ↗10 / TARGET ↗Run the productInteractive Linux desktop and browser QA against real builds.SPEC & IMPLEMENTATION ISSUE #166 ↗11 / TARGET ↗Prove behaviorVisual and functional evidence mapped to acceptance criteria.SPEC & IMPLEMENTATION ISSUE #169 ↗12 / TARGET ↗Repair & recheckFindings route to Man.ager for fixes and fresh verification.SPEC & IMPLEMENTATION ISSUE #170 ↗

04 / PUBLISH & LEARN

The PR isn't the product. Merged isn't deployed, either.
13 / TARGET ↗Prepare the PRApp-controlled, scoped publication after review and approval.SPEC & IMPLEMENTATION ISSUE #164 ↗14 / TARGET ↗Sync realitySpec truth follows merge and deployment evidence, not vibes.SPEC & IMPLEMENTATION ISSUE #161 ↗15 / TARGET ↗Show the workBoard reflects questions, reviews, QA, PR state and blockers.SPEC & IMPLEMENTATION ISSUE #165 ↗16 / TARGET ↗Propose evolutionNew capability ideas require user opt-in and reviewed PRs.SPEC & IMPLEMENTATION ISSUE #174 ↗
HUMAN APPROVES INTENTINDEPENDENT REVIEWDOCKER POLICYREPRODUCIBLE QACONTROLLED PUBLICATION
Man.ager is the conductor, not the drummer playing every instrument.

Centralize decisions, distribute work, independently validate results and keep specs aligned with what actually landed.

FULL LIFECYCLE EPIC #172 ↗

06 / Follow the arrows. Question the arrows.

The lifecycle flowchart.

The full target workflow, including the part every optimistic diagram leaves out: what happens when review finds a problem. Every box opens its associated implementation issue.

01 · PLANNING ↗ #159Goal → questionsSurface ambiguity until readiness criteria pass. 02 · SPEC ↗ #161Reconcile intentWrite decisions and update target behavior without rewriting history. 03 · GATE ↗ #160User approves?No → revise plan and ask again. 04 · REVIEW ↗ #160Independent plan reviewBlocking finding → repair plan and renew approval if needed. 05 · DECOMPOSE ↗ #162Validated task DAGIndependent tasks and subtasks with explicit dependencies. 06 · EXECUTE ↗ #136Docker work sessionsScoped agents; local or remote policy-controlled workers. 07 · CODE REVIEW ↗ #163Independent reviewerInspect code against the accepted plan and test evidence. 08 · RUNTIME QA ↗ #166Run the actual appBrowser and desktop drivers verify real interactions. 09 · GATE ↗ #170All checks pass?No → Man.ager creates bounded repair work. 10 · CONDITIONAL ↗ #170Repair and re-reviewAfter any failed check, loop to verification; never self-approve. 11 · DELIVERY ↗ #164Controlled PRApproved and verified code is prepared for publication. 12 · TRUTH ↗ #161Merge → spec updateVerified merged and deployed state updates current implementation truth.
↺ RETURN PATHS:Unanswered question → planning · Material plan change → user approval · Code/QA failure → repair and fresh independent review · Merge/deploy evidence → spec reconciliation

These are conceptual edges, not a claim that the full orchestrator is currently deployed. The application state machine and issue acceptance criteria determine actual allowed transitions.

Want the whole packet? 36 architecture diagrams ↗Explore current vs future across 18 technical views. Mermaid source and GitHub issue receipts included.

Now with 73% fewer undocumented assumptions*

Drink it and get S*** done!

Build the right thing. Keep the receipts. Let the agents work, but don't give them the keys to the beverage factory.

Read the code ↗

* Statistic completely made up. We are not doing that with architecture claims.