Overview

What Cadela Is

Cadela is a local-first AI harness — a command center for routing models, running agents, orchestrating workflows, managing project context, and producing clean-room documentation — all from your own hardware.

Why "harness"?

A harness connects, controls, and directs. Cadela is the layer between you and the models, between your project files and the agents that process them, between your local GPU and the API providers you choose to use. It is not another chat interface. It is a workspace designed for builders who need control over every part of the pipeline.

Design principles

• Local-first. Your data stays on your machine by default. External APIs are a deliberate escalation, not the only path.
• Project-aware. Skills, rules, and prompts are stored per repository — the harness adapts to the project, not the other way around.
• Modular. Model routing, agent roles, workflow pipelines, and documentation tools are independent systems that compose together.
• Private. No telemetry, no analytics, no "phone home" — unless you explicitly connect to a service you choose.

Getting started

Local Dev Setup

The public-facing site is a static Vite project. Here is how to run it locally and contribute.

Prerequisites

Node.js 18+ and npm.

Clone and install

git clone https://github.com/YOUR_ORG/cadela.dev.git
cd cadela.dev
npm install

Start the dev server

npm run dev

Serves at http://127.0.0.1:4173. Hot reload is enabled.

Build for production

npm run build

Output lands in dist/, ready for GitHub Pages or any static host.

Stop the server

npm run stop

Project structure

cadela.dev/
├── index.html              # Homepage
├── docs.html               # This documentation page
├── src/
│   ├── styles.css          # Design system and layout
│   ├── docs.css            # Documentation-specific styles
│   └── main.js             # Interactions and animations
├── assets/
│   └── cadela-mark.svg     # Logo mark
├── .claude/
│   ├── rules/              # Repo-specific rules
│   └── skills/             # Task-specific skills
├── docs/                   # Planning documents
├── prompts/                # Claude Code session prompts
└── package.json

Design

Planned Harness Architecture

Cadela is being designed as a modular system of independent layers that compose together.

Model routing layer

The routing system decides where each task executes based on configurable rules:

• Local providers: Ollama, llama.cpp, and directly-hosted models for privacy, speed, and offline work.
• API providers: DeepSeek, Claude, OpenAI, Gemini, and others for tasks that need stronger models beyond what local hardware can run.
• Routing policy: Task type, context size, privacy level, cost budget, and latency requirements determine where a request goes — automatically or by explicit override.

Agent system

Agents are specialized roles with their own system prompts, tool access, and execution rules:

• Code agent: Read, write, refactor, review, and test code within project rules.
• Reviewer agent: Adversarial pass on code, docs, and architecture decisions.
• Clean-room agent: Source understanding and original documentation production.
• Workflow agent: ComfyUI pipeline planning, prompt building, and media direction.
• Architect agent: High-level planning, dependency analysis, and implementation strategy.

Skills and rules system

Skills are composable, project-specific capabilities stored in .claude/skills/. Rules in .claude/rules/ define behavior constraints per repository. Together they let the harness adapt its behavior to each project without manual reconfiguration.

Workflow engine

The workflow engine sequences agent calls, tool executions, and user checkpoints into reproducible pipelines. Planned integrations include ComfyUI for media generation, UE5 tooling for game development, and automated clean-room documentation runs.

Methodology

Clean-Room Documentation Principles

Cadela's clean-room documentation workflow helps you understand code you are allowed to inspect — and produce original documentation — without reproducing proprietary content.

When to use it

You have purchased, licensed, or inherited source code that you need to understand, document, or plan a replacement for — but you cannot copy the code itself into your documentation.

The workflow

1. Source review. Inspect the codebase structure — file organization, module boundaries, dependency graph, and entry points.
2. Mirrored docs. Create a parallel documentation folder that mirrors the source layout. Each document captures purpose, behavior, and interface — not implementation.
3. Architecture map. Describe the high-level system: layers, data flow, key algorithms, protocol boundaries, and design patterns — in original terms.
4. Behavior notes. Document observable behavior: inputs, outputs, side effects, error states, and edge cases — without quoting source.
5. Implementation plan. Produce an original plan that could guide a clean reimplementation — architecture, data model, component responsibilities, and test strategy.

What is safe to produce

• Architecture summaries and dependency maps
• File-level purpose descriptions
• Behavior descriptions in original language
• Pseudocode that captures logic without reproducing protected expression
• Test plans, risk notes, and migration strategies

Boundaries

• Never copy proprietary code into documentation
• Never reproduce unique implementation details line-for-line
• Never suggest license bypass
• Never distribute derived source

Future

Roadmap

Cadela is in active early development. Here is what is being built and in what order.