strata:graphify

strata:graphify

Orchestration wrapper. Doesn't bundle Graphify, shells out to whatever graphify is on PATH (install separately: pip install graphifyy).

What it does

The orchestrator runs two steps in sequence:

1. Build the graph. Runs graphify update . (AST-only, no LLM, no network) which produces graphify-out/graph.json with nodes and edges for every function / class / module Graphify can see.

2. Wire it into the vault. Reads the freshly-produced graph.json and writes one markdown note per node into <vault>/<repo>/graphify/, with [[wikilinks]] for each edge. This step is local and mechanical, no LLM, no API key, no network. It's Strata's own implementation of Graphify's --obsidian flag, designed to work without an LLM key.

After both steps, Obsidian's graph view shows one continuous knowledge graph: a decision note that wikilinks [[MedicationService]] visually connects to the Graphify-generated note for that class.

How

# Default — incremental graphify update + vault wiring
"${CLAUDE_PLUGIN_ROOT}/bin/strata" graphify

# Skip the vault wiring (graph.json still produced)
"${CLAUDE_PLUGIN_ROOT}/bin/strata" graphify --no-obsidian

# Full rebuild instead of incremental (slower, deterministic)
"${CLAUDE_PLUGIN_ROOT}/bin/strata" graphify --rebuild

# Status only — print graph age + size, no build
"${CLAUDE_PLUGIN_ROOT}/bin/strata" graphify --status

# Semantic-edge mode (uses Graphify's LLM path).
# Costs tokens AND sends file content to an external LLM API.
# DO NOT use for regulated content.
"${CLAUDE_PLUGIN_ROOT}/bin/strata" graphify --deep

Resulting vault layout

~/StrataVault/<repo>/
├── decisions/                  # ADRs (Strata-managed)
├── domain/                     # vocabulary (Strata-managed)
├── pr-context/                 # per-branch notes (Strata-managed)
├── lessons/                    # retrospectives (Strata-managed)
├── procedural/                 # recipes (Strata-managed)
└── graphify/                   # per-function / class / module nodes
                                 (regenerated by /strata:graphify)

The graphify/ subfolder is regenerable from graph.json on demand, treat it as build output. Point Obsidian at the vault root and use path:graphify (filter to code nodes only) or -path:graphify (hide them) when navigating the graph.

Role tagging

Each generated note carries a graphify/<role> tag in addition to the generic graphify/code umbrella tag. Roles are derived from path + filename conventions:

Tag	Matches
graphify/test	tests/, __tests__/, *Tests.cs, *.test.ts, *.spec.ts, *_test.py, …
graphify/route	routes/, pages/ files (TanStack, Next.js, SvelteKit, Astro)
graphify/component	components/ or PascalCase .tsx/.jsx/.vue/.svelte
graphify/hook	useFoo.ts(x) React-hook convention
graphify/service	*Service.cs/.ts or under services/
graphify/controller	*Controller.cs/.ts or under controllers/
graphify/repository	*Repository.cs/.ts, *Repo.cs, *Dao.cs
graphify/model	models/, entities/, types/, *Types.cs, *.types.ts, …
graphify/util	utils/, lib/, helpers/, *Utils.cs, *.utils.ts
graphify/code	everything else (umbrella + fallback)

Open Obsidian's graph view → Groups → add a search for each tag (e.g. tag:#graphify/service) with its own colour. The result is a visually distinct dependency map instead of a uniform blob.

Monorepo package tagging

On monorepo layouts, each note also carries a graphify/pkg/<name> tag and a package: frontmatter field. The package is detected from the file's path: if it lives under <category>/<pkg>/... where <category> is one of apps, packages, services, web, libs, gateways, integrations, clients, or servers, then <pkg> is its package.

Examples:

• web/billing/src/routes/index.tsx → pkg: billing
• integrations/legacy-crm/src/Client/Foo.cs → pkg: legacy-crm
• gateways/checkout/tests/Bar.cs → pkg: checkout

Files outside that structure (root-level scripts, shared utilities) get no package tag. In Obsidian's graph view, add one Group per major package (tag:#graphify/pkg/billing, etc.) to colour each package's cluster distinctly. Combined with role tagging, this gives you a two-axis view of the codebase: which package something belongs to, and what shape of thing it is within that package.

When to invoke

• First time: bootstrap the graph for the repo.
• After major refactors (new modules, renames).
• When /strata:review flags the graph as stale.
• Before a session that needs code-structure context (god nodes etc.).

Result

After running, Strata's SessionStart primer shows updated node + edge counts and the top god nodes. The code_graph_status MCP tool returns the fresh summary. The wikilink-to-code bridge (internal, surfaced via recall at layer 2) cross-links decisions referencing code symbols back to their graphify nodes: even via unresolved wikilinks, it resolves [[MedicationService]] to graphify:MedicationService against graph.json.