---
title: Registry
scope: 3dmk
type: documentation
subject: registry
group: Systems
status: current
version: "2.1.3"
source: https://3dmk.com/documentation#registry
author: Nick Olson
contact:
  email: 3dmk@3dmk.com
  site: https://3dmk.com
license: CC BY 4.0
license_url: https://creativecommons.org/licenses/by/4.0/
attribution: Nick Olson, 3dmk.com
---

# Registry

The Registry is the inventory of the development environment. It holds structured records for every theme, project, source repository, and host, plus a code snapshot of each repository. Agents read exact paths, hosts, and deployment details from it in place of a search. Documentation lives in Seele, not in the Registry.

## Role

The Registry answers what exists and where it runs. Agents reach it through Core Model Context Protocol (MCP) tools. A `repo://` or `theme://` reference in a prompt resolves through it. The `core-infra-bootstrap` tool reads each source’s development host and port fields to find where the service deploys. Commit and deployment events keep each source’s metadata current.

## Parts

The `core-registry` service is one Python and FastAPI process. Seven internal parts divide the work.

| Part | Job |
|---|---|
| Registry store | Holds every record in memory and serves every read |
| Write lock | Lets one change run at a time |
| ID minter | Issues 6-character base62 identifiers from a counter |
| Git client | Commits each change and pushes the history to GitHub |
| Reconciliation worker | Polls GitHub for the latest commit of each source |
| Library worker | Rebuilds a source’s dependency list when a manifest changes |
| Atlas runner | Parses a repository’s syntax trees into a structural snapshot |

Atlas reads Python, TypeScript, Rust, Swift, and Kotlin. Reconciliation runs hourly for a source with a commit in the last 24 hours, and daily otherwise.

## Data

The records live in one JavaScript Object Notation (JSON) file in a dedicated Git repository. Each change rewrites the file atomically. A local commit then records the change. A background loop pushes those commits to GitHub every 60 seconds, and the Git history serves as the audit log.

Six kinds of record make up the inventory.

| Record | What it holds |
|---|---|
| Theme | A top-level grouping such as `core`, with a description |
| Project | Name, display name, context tag, project type, and owning theme |
| Source | The one repository of a project: language, GitHub URL, default branch, development host and port, Consul service name, and release tags |
| Host | Operating system, Docker endpoint, remote Core MCP endpoint, and machine role |
| Libraries | The dependencies parsed from a source’s manifest files |
| Atlas snapshot | The modules and symbols of one repository at one commit |

Projects take one of 10 fixed types, and sources take one of 13. A deactivated host stays readable. The Registry refuses to deactivate a host that an active source still deploys to.

Atlas snapshots sit in a separate local-only Git repository with one file per source. Each new snapshot is one commit, so a Git diff shows the structural change between two commits.

## Connections

Five other systems exchange data with the Registry.

| System | What passes between them |
|---|---|
| Core MCP | Reads and writes through the `registry_*` tools, plus a commit event after each Git commit that it makes |
| Publishing command line | A deploy event that sets a source’s development or production tag |
| GitHub | Commit metadata for each source’s last code update |
| `core-auth` | Access tokens that authorize writes and events |
| Consul | Service registration and overrides for the reconciliation schedule |