What M1 ships

The data model and the MCP surface, over seeded data. There is no ingestion pipeline yet — and that is the point.

M1's claim is that the data model is the product. It ships the first CodiQ SDL — the language-neutral core of §4.4 — and lets gopgql do the rest: generate the vertex and edge tables, create theCREATE PROPERTY GRAPH view over them, and serve GraphQL/MCP. Rows come from a committed seed file, because no extractor exists yet. Anyone can insert rows directly; the value on offer is the vocabulary and the read surface, not the ingestion.

What is in the repository

schema/codiq.graphqlThe single source of truth. Three vertex types and the edges between them, annotated for gopgql.

schema/migrations/0001_core_tables.sql and 0002_core_graph.sql — generated from the SDL, committed and reviewed, applied with goose.

deploy/docker-compose.ymlPostgres 19, a one-shot migrate, a one-shot seed, and the long-running MCP server.

deploy/seed/seed.sqlA hand-extracted three-file Go package, shaped the way the M2 extractor will produce it.

docs/This site: landing, docs and the demo.

features/, test/integration/A godog feature and an integration test that starts the real containers and asserts a seeded descriptor comes back over MCP.

SPEC.md §11.1 says the compose pulls gopgql from ghcr. gopgql has not cut a tagged release yet, so deploy/gopgql.Dockerfile builds both binaries from a pinned commit instead — the escape hatch §14 M1 explicitly allows. Swapping back is deleting that file and giving the two services animage: line; nothing else in deploy/ changes.

The two migrations

gopgql emits the tables and the property graph as separate, consecutively numbered migrations, so no single file mixes DDL with the graph definition. That ordering matters later: editing the SDL produces a graph-down, tables, graph-up sequence, and one gopgql migrate applies it in order.

Applied by the migrate service, from the committed migrations

gopgql migrate --dir /migrations

Note the absence of --sdl. With it, gopgql regenerates the migration history from the SDL before applying it. Without it, the container applies exactly what is in the tree — so an SDL that has drifted from its migrations fails a review rather than silently reshaping a database. Regenerating is a deliberate, separate step:

gopgql generate --sdl schema/codiq.graphql --dir schema/migrations --name <slug>

What M1 does not ship

No extractor, no orchestration, no protobuf artifacts, no link pass. Every cross-file edge in the seed is written out by hand, in the place where the link pass will later compute it. That is deliberate: the derived edges are part of the model, and M1 is a claim about the model.

The milestones

Every milestone is a working, integration-tested, deployed vertical slice — never a shim. The product works from M1; later milestones optimise the ingestion internals in place without regressing it.

M1

SDL + database + MCP

The core SDL, the schema gopgql generates from it, and the GraphQL/MCP surface — over hand-written seed data.

shipped

M2

Go extractor, monolithic loader

Goroutines parse Go files with gotreesitter and insert into the M1 schema; a full link rebuild materialises the cross-file edges.

M3

Wrap in DBOS

The M2 loop becomes a durable workflow — same behaviour, crash-resumable. Adds the codiq_dbos database.

planned

M4

Map-reduce + batching

Per-file extract on a durable queue, one batched reduce per run. Poison files are skipped, not fatal.

planned

M5

Protobuf artifacts + disk offload

Extract writes a protobuf artifact to a shared volume and returns a key; reduce reads by key and deletes on success.

planned

M6–M7

TypeScript · Python

A language is one sub-package plus a query file plus a coordinate resolver. No core schema change.

planned

M8

Incremental link

Re-link only the affected neighbourhood; a scheduled full rebuild stays as the self-healing backstop.

planned

M9+

Additional languages

Rust, Java, C#, Ruby, PHP, C/C++, Kotlin, Swift — each an independent task, in any order.

planned

Next: the core model — the three vertex tables and the two kinds of edge between them.

The core model →