Sheet 06Adapter registryScale: NTS

Fourteen manifests, zero call sites

The adapter registry is a piece of recorded judgement rather than a piece of machinery. Each entry states what a tool is for, how mature it is, which platforms it runs on, and — unusually — how it is expected to fail. Nothing in the codebase executes any of it.

What an adapter manifest holds

AdapterManifest (types.ts:72–96) has eight required fields and seven optional ones. The required set is descriptive; the optional set is where the research work is stored.

id
Stable key. Deliberately qualified where a name is ambiguous — see autoloop-armgabrielyan below.
role
One of eight: executor, loop, optimizer, skill_evolution, prompt_optimizer, trace_eval, platform, benchmark_reference.
integrationType
One of six: cli, sdk, template, benchmark_reference, mcp, manifest_only. The mcp value is declared and used by no entry.
status
supported (4), optional (5), later (2), research_only (3).
capabilities
Free-form string tags. Not matched against anything.
source
Repository or documentation URL.
notes
A sentence of positioning — where this tool sits relative to Daedalus.
command?
The invocation string. Present on 7 of 14.
doctor?
Version-probe commands for a health check. Present on 5 of 14.
supportedPlatforms?
windows, wsl, macos, linux. Present on 7 of 14.
license? · maturity?
License present on 6 of 14; maturity on all 14.
failureModes?
How this integration is expected to break. Optional in the type, present on all 14.

The failureModes field is the unusual one. A registry that records “ambiguous package naming” and “model variance” alongside a command string is describing operational reality, not marketing a plugin catalogue.

Fig. 6.1 Adapter matrix — role against status

Matrix plotting the fourteen adapters by role and adoption status A grid with eight role rows — executor, loop, optimizer, platform, skill evolution, prompt optimizer, trace eval and benchmark reference — against four status columns: supported, optional, later and research only. Codex, OpenCode and bmalph sit in supported, as does Autoloop by armgabrielyan. Aider, pi-autoresearch, OpenEvolve, AgentEvals and OpenHands sit in optional. EvoSkill and GEPA sit in later. The Autoloop Claude plugin, PyPI Autoloop and AgencyBench sit in research only. Below the grid, a second panel shows the four integration levels described in the adapters document — manifest only, command, state bridge and API — with a marker showing that all fourteen adapters are currently at the manifest-only level, since no adapter is invoked by any code path. supported · 4 optional · 5 later · 2 research_only · 3 executor loop optimizer platform skill_evolution prompt_optimizer trace_eval benchmark_reference Codex CLI · codex exec OpenCode · opencode run Aider · aider bmalph · template Autoloop Claude plugin PyPI Autoloop Autoloop (armgabrielyan) pi-autoresearch OpenEvolve OpenHands · sdk EvoSkill · evoskill GEPA · sdk AgentEvals · sdk AgencyBench INTEGRATION LEVELS — docs/ADAPTERS.md:26–37 manifest-only Daedalus knows the tool command Daedalus invokes a CLI state-bridge writes the tool's native files api typed SDK calls all 14 adapters sit here — adapterRegistry is exported, returned by listAdapters(), and never read again
Fig. 6.1 — Four adapters are marked supported, which in this codebase means “judged ready to integrate”, not “integrated”. The ladder below is the honest reading: docs/ADAPTERS.md defines four escalating integration levels and every entry is at the first rung. The seven command strings and five doctor probe lists are the raw material for rung two, already written down.

The registry in full

adapterRegistry — packages/core/src/adapters.ts:3–197
id Role Integration Command Status Maturity Declared failure modes
codexexecutorcli codex exec supportedactive model/API credentials missing · noninteractive command contract changes · sandbox mismatch
opencodeexecutorcli opencode run supportedactive provider config missing · model variance · CLI behavior changes
aiderexecutorcli aider optionalstable less suited for browser/game debugging · requires model configuration
bmalphlooptemplate bmalph supportedearly Windows requires WSL/Git Bash · workflow files can drift from Daedalus state
autoloop-armgabrielyanoptimizercli autoloop supportedearly ambiguous package naming · requires stable scalar metric
autoloop-shengzhe-claude-pluginlooptemplate — research_onlyunknown not interchangeable with armgabrielyan/autoloop
autoloop-pypiloopmanifest_only — research_onlyunknown name collision · unverified runtime semantics
pi-autoresearchoptimizercli pi-autoresearch optionalearly requires Pi · requires stable benchmark command
evoskillskill_evolutioncli evoskill laterresearch needs benchmark splits · may optimize skills rather than product code
gepaprompt_optimizersdk — laterresearch needs rich feedback traces · can overfit rubrics
agentevalstrace_evalsdk — optionalactive requires OpenTelemetry traces · does not prove product behavior
openevolveoptimizercli — (cli, no command) optionalresearch bad fit for whole-product construction · requires strong evaluator
openhandsplatformsdk — optionalactive heavier deployment surface · workspace/server API setup required
agencybenchbenchmark_referencebenchmark_reference — research_onlyresearch benchmark scenarios are not product acceptance tests by themselves

openevolve declares integrationType: "cli" with no command, no doctor array and no supportedPlatforms. The manifest type permits this — command is optional on every integration type — so the registry can carry an entry that claims to be command-line integrable while providing nothing to invoke.

Fig. 6.2 Name-collision handling — “Autoloop”

How three unrelated projects named Autoloop are split into three distinct adapter entries A single ambiguous label, Autoloop, fans out into three separate manifests. The first, autoloop-armgabrielyan, is a GitHub project by armgabrielyan, an optimizer with the command autoloop, marked supported and early, whose capabilities are metric ratchet, keep-revert and agent-agnostic operation. The second, autoloop-shengzhe-claude-plugin, is a different GitHub project by yaoshengzhe, classified as a loop delivered as a template, research only, maturity unknown. The third, autoloop-pypi, is a PyPI package of the same name, manifest-only, research only, maturity unknown. Each carries a failure mode string that explicitly warns it is not interchangeable with the others. A note records that this split is the reason the smoke test asserts the presence of the qualified identifier. "Autoloop" one name, three unrelated projects autoloop-armgabrielyan role optimizer · integrationType cli · command "autoloop" capabilities metric_ratchet · keep_revert · agent_agnostic doctor autoloop --version · git --version platforms all 4 status supported · maturity early github.com/ armgabrielyan/ autoloop failure: ambiguous package naming autoloop-shengzhe-claude-plugin role loop · integrationType template · no command capabilities claude_code_plugin · independent_verification status research_only · maturity unknown github.com/ yaoshengzhe/ autoloop not interchangeable autoloop-pypi role loop · integrationType manifest_only · no command capabilities protocol_runtime status research_only · maturity unknown pypi.org/ project/ autoloop name collision 1 The split is load-bearing enough to be asserted in the smoke test: scripts/smoke.ts:40–41 checks that both "autoloop-armgabrielyan" and "agencybench" are present, and docs/TESTING.md lists the check as "ambiguous adapter entries were split".
Fig. 6.2 — A registry that resolves a naming collision by refusing to resolve it. Three entries, three sources, two of them explicitly quarantined as research_only until “command contract and license are verified”. This is the kind of detail that only exists because someone did the reading; it is also the only piece of the adapter registry the test suite touches.

Platform and licence coverage

Seven of fourteen entries declare supportedPlatforms. The gap matters because the project’s own runner is Windows-first — package.json ships an install-command script that shells out to PowerShell, and docs/TESTING.md is written entirely in PowerShell blocks.

Declared platform support and licences
AdapterwindowswslmacoslinuxLicencedoctor probe
codexyesyesyesyesApache-2.0codex --version
opencodeyesyesyesyesMITopencode --version
aideryesyesyesyesApache-2.0aider --version
autoloop-armgabrielyanyesyesyesyes—autoloop --version
pi-autoresearchyesyesyesyesMIT—
bmalphnoyesyesyes—node · git · bash --version
autoloop-shengzhe-claude-pluginnoyesyesyes——
7 further entriesno supportedPlatforms field2 of 7 licensed—

bmalph is the one entry whose platform list actively excludes Windows, and its failure modes say why: “Windows requires WSL/Git Bash”. The registry therefore contains a contradiction it is honest about — the primary loop adapter does not run natively on the platform the installer targets.

apps/cli/src/index.ts:78–80 — adapters
$ daedalus adapters
[
  {
    "id": "codex",
    "name": "Codex CLI",
    "role": "executor",
    "integrationType": "cli",
    "command": "codex exec",
    "capabilities": ["edit_repo", "run_commands", "noninteractive", "mcp_client"],
    "status": "supported",
    "source": "https://github.com/openai/codex",
    "notes": "Primary practical executor when OpenAI models are acceptable.",
    "doctor": ["codex --version", "git --version"],
    "supportedPlatforms": ["windows", "wsl", "macos", "linux"],
    "license": "Apache-2.0",
    "maturity": "active",
    "failureModes": [
      "model/API credentials missing",
      "noninteractive command contract changes",
      "sandbox mismatch"
    ]
  },
  … 13 more entries, verbatim from adapters.ts …
]
# the doctor array is data. Nothing spawns `codex --version`.

The judgement behind the list

docs/RESEARCH_MATRIX.md records a position on each tool in one sentence, and RESEARCH.md expands each into a short review with a verdict. The conclusions section is where the shape of Daedalus is actually argued for:

“A general system should not fuse these repos into one codebase… The durable core is goal/eval/state/scoring, not code editing… Metric optimizers are powerful only after Daedalus has a meaningful score command.”

docs/RESEARCH_MATRIX.md — Critical conclusions

That last clause is a precise diagnosis of the project’s own critical path. Four of the fourteen adapters — autoloop-armgabrielyan, pi-autoresearch, openevolve, and to a lesser extent evoskill — are all optimisers that need a trustworthy scalar to ratchet against. Until an evaluator actually runs and produces that number, none of them can be usefully connected, which is why they are marked optional and later rather than supported.

The registry also carries several entries the research explicitly declines to integrate. DGM, HyperAgents, Hermes and AgentFactory are reviewed in RESEARCH.md and deliberately not given manifests — the note on DGM is that it “expands mutation surface before eval discipline is strong enough”. Absence from the registry is itself a recorded decision.

Sheet notes

  1. research/repos.json holds twelve entries with a URL and a coarse role, for the PowerShell clone script scripts/clone-research-repos.ps1. The clones land in research/repos/, which .gitignore excludes — research inputs, explicitly not vendored dependencies.
  2. The two lists do not line up. repos.json covers eleven of the fourteen adapters and adds a twelfth entry, ralph, which has no manifest at all. Three adapters are absent from it: gepa, whose source is a documentation site rather than a repository, and the two quarantined Autoloop entries — repos.json carries a single unqualified autoloop id pointing at the armgabrielyan project, which is precisely the ambiguity adapters.ts was careful to split.
  3. capabilities strings are never compared against anything. An adapter claiming mcp_client and one claiming sandbox are treated identically by listAdapters(), which returns the array unfiltered.
  4. The integrationType union includes "mcp", anticipating adapters that are themselves MCP servers. No entry uses it.
Continued on sheet 07As-built survey — drawn vs. built Back to sheet 01General arrangement