AnaxiGraph

Repository composition

Languages

Areas and their subsystems

Architecture map

Configured path groups are rolled up under parent areas. A fallback group is inferred only when repository policy does not match a file.

Immediate attention

Active findings

AnaxiIndex file intelligence

Module inventory

One row per file in the selected snapshot. Filter and sort deterministic facts, architecture placement, purpose, Git activity, coverage, and review signals. Expand a row for provenance and pattern-review context.

Fact Interpretation Review signal

Find module or purpose Area Subsystem Language Include docs, config & assets Rows

Attention is a 0–100 triage score from size, complexity, coupling, churn, and active findings—not a pattern-suitability score.

			Pattern / rewrite

Overlay Node size Find module External dependencies Architecture regions

Areas · all

Canvas height

Wheel to zoom · drag to pan · select a node to inspect

From signal to verified change

How the review workflow works

A finding is an inspection signal, not an automatic instruction to refactor. Review it, plan it when you want an agent to act, then let a later scan verify that the condition actually disappeared.

Persistent review workflow

Architecture findings

Status

Visual biography

Architecture over time

Human-approved context for coding agents

Use repository intelligence while you code

This page does not edit code. It calculates what an agent should read, what depends on the proposed change, which tests matter, and where extra review is required. AnaxiMCP gives Codex the same context directly from AnaxiIndex.

ANAXIGRAPH_FINDINGS(status="planned") → ANAXIGRAPH_FINDING_CONTEXT → ANAXIGRAPH_FILE / ANAXIGRAPH_IMPACT

Find the right coding context

Plan a coding task

Describe the outcome. AnaxiGraph finds likely implementation files, connected modules, tests, rules, and existing findings.

Check before editing shared code

Who depends on this?

Enter a file or unique symbol to see direct and indirect dependants, relevant tests, migrations, protected boundaries, and branch conflicts.

Task context, change impact, or a planned finding handoff will appear here.

Repository connections

How AnaxiGraph works with your code

Repositories stay read-only. A scan turns their files, Git history, relationships, findings, and optional coverage into AnaxiIndex records. The dashboard, REST API, and AnaxiMCP all read the same indexed snapshot.

Read-only repository→Scanner→ AnaxiIndex→Dashboard · REST · AnaxiMCP

Live service configuration

Connected repositories

Add another repository

Initialize it beside the code

Run one non-destructive command from the repository you want to understand. It detects obvious areas and writes an editable policy plus a dedicated, read-only Compose sidecar. Existing files are kept unless you explicitly use --force.

From the target repository

uvx --from git+https://github.com/hcekne/anaxigraph anaxigraph init .

Start its sidecar

docker compose -f compose.anaxigraph.yml up -d

Open its dashboard
```
http://127.0.0.1:8765
```

Docker guide →

Operating one dashboard across several allowlisted mounts? The Docker guide also covers the shared multi-repository registry mode.

Coding-agent access

Use the same intelligence while coding

Run the command below in a normal terminal on the machine where Codex runs—not inside a Codex chat. Connect Codex or another MCP client to . Use ANAXIGRAPH_REPOSITORIES to choose a repository, then query findings, file context, impact, or a task work envelope. AnaxiMCP reads AnaxiIndex; it does not grant the agent write access to the mounted repository.

Model-backed repository memory

Build and refresh AI understanding

With semantic.provider: agent, the connected coding agent can claim bounded evidence and write a validated interpretation to AnaxiIndex using its own model and tokens. Other providers use a separate worker. Every path is opt-in, and the mounted repository remains read-only.

Semantic setup →