Reference

Three-repository audit

Recorded 2026-11-01.

Dev Guru (product and presentation), Ananke Plexus (harness and compute) and Dex Trove (reusable capability memory) are being built as three repositories. Before writing contracts, the plan requires recording what the existing code really exposes: pinned commits, interfaces, baseline tests, dependency direction and gaps. This page is that record. The planned names in the design bundle are targets; everything below was read from source or observed by running it.

How the three fit together

1. Ananke is the only harness. Dev Guru calls Ananke through one client port and never analyses code itself. Dex never imports Ananke or Dev Guru to publish or browse its catalog.
2. Dev Guru starts on Ananke’s existing Python facade (ananke.plexus.api.Ananke) over an in-process transport. It negotiates the supported range explicitly (ananke-plexus>=0.3.12,<0.4 since Dev Guru 0.1.0), plus the specific capabilities it calls. An isolated-process transport and a local gateway come later. Exactly one transport is used per run, and failures are reported, never retried on another transport.
3. The capability source port maps onto Ananke’s registry: learn, importers, sources, resolver and lockfile. It does not become a second authority. The registry stays the record of identity, versions, digests, trust and locks.
4. Dex stays optional everywhere. Ananke reaches Dex only through the ananke.troves entry point and the optional [dex] extra. Dev Guru declares dex as an optional extra and never imports dex_trove in its core (tested).

Pinned revisions

Neither ananke-plexus nor dex-trove ships a py.typed marker, so type checkers treat them as untyped. Dev Guru’s mypy follows them explicitly for now; adding py.typed to Ananke is a small follow-up.

What Ananke exposes today

Facade (ananke.plexus.api.Ananke)

Ananke.open(repository_root) returns a facade whose methods return CommandResult(ok: bool, summary: str, details: dict[str, Any]). The groups relevant to Dev Guru:

details is an untyped dict, so results are summaries rather than typed models. Dev Guru reads typed data directly from the owning service. For example, graph_summary calls graph_build() and then ananke.plexus.graph.service.load_graph, which returns a GraphSnapshot.

Graph model (ananke.plexus.graph.models)

GraphSnapshot(snapshot_id, provider, nodes: list[GraphNode], edges: list[GraphEdge]).

• GraphNode(node_id, kind, name, path, provider, metadata).
• GraphEdge(source, target, kind, origin, provider, confidence, source_location, snapshot_id).

origin is one of extracted | inferred | ambiguous | declared. Providers: native, plus optional graphifyy and code-review-graph adapters behind the GraphProvider protocol (build, impact).

At the audit, the native provider kept only top-level functions and classes, with owns and imports edges: no call edges, methods or notebooks. 0.3.12 adds methods, line, doc and signature metadata, and inferred calls and inherits edges (see Code graph). snapshot_id is still a UTC timestamp, so two builds of the same code differ. Dev Guru’s report manifest uses a content digest instead.

Registry (ananke.plexus.registry)

• Artifact kinds: skill, agent, tool, workflow, evaluator, prompt, policy, bundle, runtime-profile. There is no instruction kind; Dex maps instructions to prompt.
• Lifecycle active | deprecated | yanked | quarantined | archived; trust unknown | discovered | verified | approved | restricted | quarantined.
• Immutable versions in a content-addressed store, with digests, signatures (ed25519), channels, aliases and revisions. register, promote, yank, deprecate, quarantine, set_trust and alias_set are on Registry.
• Resolution: Resolver with locked, highest-compatible, highest-approved, lowest-compatible, stable-only and exact modes. Lockfile entries are LockEntry(id, version, digest, source, kind, dependencies, ...), checked by verify_lock.
• Sources: federation priority project → user → enterprise → public. Remote sources are pull-only, and pulled versions arrive as discovered (trust is never inherited).
• Ingestion: learn(registry, source) through importers (filesystem, framework, manifest, mcp, python_pkg, registry, rust_crate, vcs_archive), with a secret scanner and permission review. Installed libraries plug in through the ananke.troves entry point, selected per project by [troves.<name>].

Execution, events and evidence

• execution.plan.ExecutionPlan / ExecutionStep with approvals, checkpoints (save/load/resume_from_checkpoint), compensation and a scheduler (run_plan, with concurrent steps).
• workflows.Workflow / WorkflowStep are project-authored argv steps with their own runner, a second, simpler workflow notion.
• events.Event(event_id, event_type, run_id, timestamp, actor, payload, correlation_id, causation_id) goes over an in-process EventBus. Events have no sequence number and no persisted, replayable log.
• Evidence bundles, SARIF output and retention (evidence/).
• Interfaces: the ananke CLI (166 commands), apm, and an MCP server speaking JSON-RPC 2.0.
• Plugins: entry-point groups ananke.graph, ananke.backend, ananke.spec_provider, ananke.gate and ananke.lifecycle.

What Dex Trove exposes today

• CLI dex: sources, learn, validate, list, search, show, install, license, notices, catalog, ananke sync, docs export. This change adds facets list|show|build|doc, faceted search and Claude-safe install.
• Data: trove/catalog.json (every item’s dex.json), EXCLUDED.json, trove.lock.json, per-item ananke.yaml. This change adds trove/facets.json. Items keep upstream bytes verbatim, with a content_hash and a SemVer version.
• Integration: the ananke.troves entry point (dex_trove.paths:trove_root) and dex ananke sync, which stages items and runs ananke registry learn.
• Dependency direction: Dex imports Ananke in one place only. dex validate optionally imports Ananke’s ArtifactManifest for its strongest manifest check, and skips it when Ananke is absent. Catalog browsing and publishing don’t need Ananke.

Dependency direction (verified)

flowchart LR
  DG[Dev Guru] -->|in-process facade, version-negotiated| AN[Ananke Plexus]
  DEX[Dex Trove] -.->|ananke.troves entry point, optional extra| AN
  DG -.->|optional extra, never imported by the core| DEX

• Ananke never imports Dev Guru or Dex (Dex is found only through the entry point).
• Dev Guru’s tests assert that dex_trove is never imported and that no Node runtime is needed.
• Dev Guru’s acceptance suite runs from a built wheel in an environment without Dex.

Reuse map: planned task → existing code → gap

Dev Guru scaffold (DG-PACKAGE)

The repository is Neo-Pragnya/Dev-Guru. Package dev-guru, module dev_guru and command dev are provisional; the names are free on PyPI and TestPyPI, and nothing is reserved.

• dev_guru.client: the port (AnankeClient protocol, HarnessInfo, GraphSummary), connect(transport) and the in-process adapter. Negotiation checks the installed version against the supported range and probes six capabilities, two of them required (graph.build, graph.load).
• dev_guru.errors.GuruError with stable codes: HARNESS_MISSING, HARNESS_INCOMPATIBLE, CAPABILITY_MISSING, UNSUPPORTED_TRANSPORT, WORKSPACE_INVALID and HARNESS_FAILED.
• dev doctor [--json] reports the harness. graph_summary(workspace) runs real Ananke analysis; the tests use a fixture project, not a mock.
• The same tooling as Ananke and Dex: uv + hatchling, ruff, strict mypy, pytest, the capability-acceptance harness (byte-identical), scripts/scan_dist.py (byte-identical), and CI pinned to the same action SHAs.

Next, in backlog order: AN-SOURCE-PORT → AN-INTERNAL-SKILLS → AN-CAPABILITY-LOCKS → AN-APP-FACADE, then DG-CLIENT → DG-VIEW-MODELS → DG-CLI-SDK → DG-OFFLINE-HTML. That leads to the Dex-free acceptance path: an internal skill, a lock, a graph run and an offline HTML report.

Edit this page on GitHub ↗