3DMK
A visual representation of my personal environment for agentic development
A starting point in the chat box for the work beyond it
Asking an AI a question is a familiar first step. That question starts the conversation.
Rei is the AI assistant. I gave Rei access to my project notes, code, tools, and test systems. An idea can now move from chat to working software while I direct the choices.
The next 20 chapters show what makes that possible.
An ownership boundary for reusable capability
The Registry defines Core as one active theme for shared infrastructure, libraries, services, and development tooling.
- Languages: Core repositories span Python, Rust, TypeScript, Go, infrastructure code, assets, and documentation.
- Rule: Core owns reusable capability. Product themes consume it.
- Result: New projects inherit deployment, data, security, documentation, and agent tooling.
Hi
👋 Hey Nick — Rei here.
Ready. What are we working on?
This is how I start every conversation with Claude. Pretty simple. It tells me that my init script has executed correctly and that whatever model I am using is working properly. Fun times. I have been playing with AI for a few months now. I have struggled to communicate what it is I have built here in this time. Hopefully by scrolling and the power of agentic design you can make sense of it. Or not. It is still neat to look at. Enjoy. :)
A tool belt for the AI
The Model Context Protocol (MCP) connects the conversation to the tools that the AI uses. Rei, the AI assistant, reads a repository instead of predicting what it holds. Rei runs a command instead of telling me how to run it. Rei then reads the result.
The tools share one common shape. The AI can request each job without filling the conversation with every system.
A Rust gateway that turns model requests into controlled tool calls
The Model Context Protocol (MCP) gateway runs beside the agent in proxy mode. It executes local Git, file, Docker, database, and Registry operations.
Remote calls cross an authenticated relay. The relay routes Scrolls, Seele, and session requests to their owning services.
Good evening Rei. How many tools do we have access to in core-mcp?
Good evening. 107 tools, which matches the count in CLAUDE.md Section 7.
And then Rei provides a list of tools, Scrolls being the largest contributor at 50, followed by Registry at 14. Everything I do against my development harness is routed through this MCP. Git, Docker, Seele, Publishing, everything.
CLAUDE.md is written to be light. It loads my Rei persona which keeps things short and direct. No fancy explanations to waste context. Just business. It also has routing to all of my tools. seele://<id> will pull the content for that specific node. repo://<repo name> will point the conversation at a code repository. theme://<name> will load the initial context for an entire body of work at a high level. Simple. :)
describe repo://core-mcp
Core MCP: a Rust service, project 00000A, source 00000B.
I then have a listing presented to me. Context, Source type, dev host, docker URL, consul info. Last code update. I can even ask it how many classes it has.
Using atlas, how many classes are used inside of core-mcp?
129, per the atlas summary. Atlas snapshot: commit 257de83, generated 2026-10-17.
Rust has no classes. The atlas counts structs, enums, and traits as classes:
And then a short breakdown of what is inside that codebase. Kind of outed myself. I am not a Rust developer. I would have no idea where to start in working with that codebase. I know it uses some weird naming conventions, and it's incredibly reliable for this role. The registry does a great job of using Atlas, an Abstract Syntax Tree creation tool that breaks down my code and saves a snapshot in a well-defined schema. It builds this every time I commit code. I can diff this to see what has changed in code between updates. Exciting shit, I know. ;)
A workshop behind every project
Core works like a workshop. It holds the shared tools, services, and rules that I use to build software. A new game or website does not need to invent its own memory, deployment process, security, or work tracker. Those pieces already exist in Core.
The city on this page is a model of that workshop. Each building has one job. The roads show how the jobs connect.
A platform that wraps upstream infrastructure with one operating model
Foundation
Consul resolves services. Vault supplies secrets. Nexus controls packages. PostgreSQL and Redis hold state.
Control layer
Core Model Context Protocol (MCP), Registry, Seele, Scrolls, NervHQ, Fetch, and Publishing are purpose-built services.
Shared code
Language libraries standardize configuration, discovery, logging, database access, workers, and tests.
Delivery
Bootstrap creates repeatable environments. Publishing promotes the same tested artifact between environments.
describe theme://core
Core: theme 000001. It covers shared infrastructure, libraries, services, and development tooling.
core-mcp belongs to this theme. Its theme_id is 000001.
So, this is my playground. 34 projects inside a single theme. This is the largest project I have ever taken on. I started development on this in March 2026. It contains everything I need to build whatever I would like.
A library for durable knowledge
AI conversations have limited memory. Seele works like a library. It keeps durable knowledge outside the chat: what a project is, how a process works, which standards apply, and why I chose something.
Rei, the AI assistant, pulls only the pages needed for the current job. That frees memory for the task. The answer stays tied to the real documentation.
A graph and retrieval service for technical knowledge
A Python and FastAPI service stores typed nodes and explicit edges in PostgreSQL. Vector search adds semantic retrieval. Full-text search matches exact terms.
Core Model Context Protocol (MCP) exposes three operations: search, deterministic read, and guarded write.
One governance layer for seven language families
Python
Runtime, async design, libraries, scaffolds, naming, tests, and known issues
TypeScript
Web rules plus an Electron extension, libraries, scaffolds, naming, tests, and known issues
Rust
Toolchains, async work, foreign function interface (FFI), unsafe policy, crates, scaffolds, and known issues
Swift
Concurrency, automatic reference counting (ARC), SwiftUI, targets, packages, scaffolds, naming, and tests
Go
Concurrency, errors, modules, service scaffolds, naming, testing, and known issues
Lua
World of Warcraft (WoW) runtime limits, taint, embedded libraries, addon scaffolds, naming, and offline tests
Kotlin
Android, coroutines, null safety, Compose, Glance, libraries, scaffolds, naming, and tests
A searchable and traceable record of creative decisions
The Design theme holds research, approved references, source notes, concepts, and binding standards.
Tags describe region, style, platform, evidence, behavior, and visual topics. Research findings can conflict. Only an approved standard binds the work.
An audio knowledge base inside the production loop
The Studio theme stores instruments, genres, settings, session records, references, lessons, and researched practices.
A session starts at the Studio index. The agent reads only the needed branches. Ratings update the session record. Mistakes become reusable lessons.
A document chain from project intent to executable work
- Overview: what exists now
- Vision: purpose, users, goals, and constraints (optional for internal tools)
- Product: features, flows, behavior, and exclusions (optional when no product surface exists)
- Technical: architecture, processes, data, contracts, packaging, and decisions
- Planning: current state, agent routing, epics, and the seed for Scrolls
Magi is the machine-readable architecture companion to Technical.
Rei, can you explain what Seele is in 3 sentences please?
Seele is your documentation store: standards, processes, references, and knowledge bases like Studio and Design. It is a graph and RAG hybrid on Postgres, where each document is a node with an id like 0000Ap and links to other nodes through references edges. The core-mcp tools seele_search, seele_read, and seele_write reach it, and the core-seele repo serves it.
All of my documentation lives in the three tables that back Seele. core-mcp uses seele_search for probabilistic searches, or seele_read for deterministic. seele_write is used to add or update nodes. Why do I do this instead of using markdown files? Context. Conversations have a limited amount of room to work with. Instead of pulling in entire markdown files (3k-20k or higher per document) I pull a node and its references at a fraction of the size. Same information, less bloat.
My CLAUDE.md file has a section named triggers. I use these to perform common tasks so that I am not repeating the same thing over and over. Each trigger has a list of steps an agent will follow to produce a defined result.
| Trigger | Description |
|---|---|
trigger 3 new project | Build a new project’s doc chain |
trigger 4 scrolls | Move Planning work into Scrolls |
trigger 5 project review | Cross-check project docs for consistency |
trigger 6 restart | Restart local Docker development instances |
trigger 7 orchestration | Start or resume a Scrolls Initiative |
trigger 8 magi | Validate Magi files against code |
These originally started as markdown files, but have since been moved into Seele as nodes. While the reason for the trigger and the context around what it does are still needed, the individual actions an agent will perform are much smaller. In some cases a trigger may also share a common action. Instead of replicating that action in every skill or instruction, it is a node. Every trigger that needs to look up a code repository gets the same node that contains those steps.
Below is a graph that shows how much context was saved by making this change.
| Trigger | Context saved |
|---|---|
| Trigger 3 | 79% |
| Trigger 4 | 87% |
| Trigger 5 | 97% |
| Trigger 6 | 93% |
| Trigger 7 | 90% |
| Trigger 8 | 92% |
An idea turned into work with a clear finish
A large request is too vague to give to an agent. Scrolls breaks it into initiatives, epics, stories, tasks, bugs, and subtasks. Each piece carries its goal, context, order, and current state.
That gives Rei, the AI assistant, a queue instead of a wish. Work can pause, resume, and move between agents. The work still reaches the same intended result.
A work graph designed for agent execution
PostgreSQL stores themes, initiatives, epics, stories, tasks, bugs, subtasks, agents, priorities, dependencies, and execution context.
Core Model Context Protocol (MCP) exposes typed operations for the full lifecycle. Agents receive a queue with goals, standards, repositories, dependencies, and completion state.
Scrolls replaced my Jira integration. Its hierarchy follows the example of Jira. Its context model and agent controls are purpose-built.
repo://core-scrolls
3-4 sentence description of what Scrolls is please.
No repo is named core-scrolls. The Registry entry is core-scrolls-api.
Scrolls is the work-management system for the development environment. It organizes work as themes, initiatives, epics, stories, tasks, and subtasks, and tracks bugs alongside them. Agents can be assigned work, and each agent has its own queue. The core-scrolls-api service is the only reader and writer of the scrolls_db database, and core-mcp exposes it as 50 tools.
I originally integrated my tools in Core with Jira. I have since moved to this home-grown solution. It allows me to create tasks with context that is LLM-friendly. I no longer perform work task by task. Instead I document what I want to build in Seele, and then create the Initiative, Epics, Tasks, etc. in Scrolls. Orchestration then pulls this info in smaller defined bodies of work and does it for me. This allows me to complete a full initiative in one overnight session, or spread the work out over a couple weeks to run in my off hours.
A directory of what exists and where to find it
The Registry works like a directory for the environment. It holds a record for each project, repository, machine, service address, and code snapshot.
Rei, the AI assistant, does not search the computer when I name a repository. The Registry provides the exact path, language, host, and connection details needed to work on it.
A FastAPI service that owns the environment inventory
An in-memory mirror serves reads. A single-writer lock protects mutations. Each successful write performs an atomic data update. The write also creates a Git audit record.
Commit and deployment events update source metadata. Authentication protects writes. Consumers reach the same API through Core Model Context Protocol (MCP).
Atlas
Atlas parses Python, TypeScript, Rust, Swift, and Kotlin syntax trees. It records imports, types, functions, constants, and summaries.
Commit events create local snapshots. Git diffs expose structural changes without a full scan of the source files.
Magi
Magi validates machine-readable architecture graphs against a shared JSON Schema.
Libraries: versions, bindings, contracts, and known issues
Applications: services, views, channels, models, edges, and data flows
Infrastructure: ownership, protocols, datastores, discovery references, and secret references
The Registry started as a JSON file that I would use to track all of my repos. It quickly grew into the place where all of my tooling and automation fell back to. But it was a file. Source controlled, but still a file. Now it lives in its own API. While I can still pull the JSON from source when needed, the API is the preferred method.
As with the previous chapters, I asked Claude about this service.
Describe the Registry in slightly more detail.
Also, why no vine references, I feel like it has been a long time.
The Registry
The Registry is the source of truth for what exists in the development environment and where it runs. It holds structured records, not documentation. Documentation lives in Seele. The core-registry service hosts it, and the core-mcp registry_* tools are the way to reach it.
It holds five kinds of record:
| Record | What it holds |
|---|---|
| Theme | Top-level grouping, such as core, with a description and counts of its projects and repos |
| Project | Name, display name, context tag, type, and owning theme |
| Source | One repo per project: language, GitHub URL, default branch, local path, dev host and port, Consul service name, dev and prod tags |
| Host | Every machine that runs work: OS, Docker endpoint, remote core-mcp endpoint, and whether it is a Docker host or a developer machine |
| Atlas | A code snapshot per repo at a given commit: files, classes, functions, constants, and imports |
How it behaves:
- IDs: the server assigns every id, as a short six-character code like
00000B. - Fixed types: projects use a fixed set of 10 types, such as service, library, tool, and website-static. Repos use a fixed set of 13 source types, such as python, rust, and infra.
- New projects: adding a project creates its repo record at the same time.
- Hosts: the Registry refuses to deactivate a host while an active repo still deploys to it. Inactive hosts stay readable, so they can be brought back.
- Bootstrap:
core-infra-bootstrapreads the dev host and port fields to decide where each service deploys. - Shorthand:
repo://andtheme://in a prompt resolve through the Registry.
Vine references
The persona allows them only on rare occasions. Most of this session was an outage. Here is one I held back, for the static build I stopped at 12:17:
“Why are you running? WHY ARE YOU RUNNING?” (vine)
A studio where the AI makes sound under my direction
Rei, the AI assistant, selects instruments. Rei writes patterns. Rei renders music. Rei also shows me useful controls. I listen, adjust, and rate each pass. The result of that feedback becomes part of the next attempt.
The loop matches software development: building a small piece, testing it, listening to the person who owns the goal, and improving it.
Three applications that place an agent in an audio production loop
A Python backend owns projects, renders, analysis, and engine control. A Python Model Context Protocol (MCP) server exposes composition tools. A React workbench provides meters, editors, and playback.
The control layer is mine. The audio engine and instruments are upstream projects: SuperCollider, Surge XT, and Dexed.
repo://core-tool-daw*
3-4 sentences describing what this group of repos provides me in relation to theme://minigame
Checking whether the route-building puzzle game’s sound effects came from the DAW. Your messages tie the DAW to the racing game and the strategy game so far.
The core-tool-daw repos are a music studio that Claude runs and you direct. The backend runs a SuperCollider engine with Surge XT and Dexed, and core-tool-daw-assets holds the presets and samples. Claude composes and renders through core-tool-daw-mcp while you listen to and rate each pass in the core-tool-daw-web workbench. The route-building puzzle game is the only minigame using it so far: nine game-event sounds shipped on 22 Oct, and its music project already exists.
Studio is a product built after Core was completed. A DAW that I leverage to watch and learn the steps needed to create and compose music. Instead of using a site to do this for me, or a premade tool somewhere else, I leveraged Claude to design and build this tool. Most of my music sucks right now, but I am learning.
A real browser for Rei
Reading a web page sometimes takes more than downloading its words. Some pages need JavaScript, a login, a click, a hover, or time to finish drawing.
Fetch opens such a page the way a browser does. Rei, the AI assistant, inspects the result. Rei takes screenshots of the page. Rei also tests what a person sees.
A browser engine behind a small asynchronous API
Callers submit a URL, browser actions, emulation settings, and desired outputs. The service queues the work. It returns a request identifier.
Each request gets an isolated browser context. Results include text, HTML, screenshots, console messages, and page errors.
The orchestration is mine. Rendering comes from the upstream Playwright project.
repo://core-fetch
3-4 sentence description on what the service is and how it is used please. :)
core-fetch is a browser automation service: a Playwright browser behind a FastAPI front end, running on the desktop and registered in Consul on port 8070. A caller sends a URL with optional clicks, typing, and hovers, then polls for the page’s title, text, screenshot, or HTML. Claude uses it instead of the built-in web fetch for design research and live-site tests because it renders the real page with its scripts.
Fetch is that guy. Many sites block AI access to resources. This makes it easier to find the info I am looking for.
A release route out of the workshop
Publishing moves finished work out of the workshop. It packages a release with a version number. It then moves the same tested build through development and production. Safety checks stop the trip when a machine is unhealthy or people are still using the current version.
One command starts the route. The system records what shipped, where it went, and which version runs now.
A manifest-driven API and command-line interface for releases
The command-line interface (CLI) is a stateless client. It reads a repository’s publishing manifest. It sends each operation to the Publishing API.
The service owns release state, deployment history, guards, and target configuration. One immutable image moves through each environment.
The control plane is mine. It drives upstream tools: Docker, Git, and AWS.
Instead of breaking down the individual services, let’s break down Publishing as it is today. 3-4 sentences on what capabilities exist today.
Publishing versions a repo in one command: it bumps the version everywhere it is declared, commits, tags the release, and pushes main. A release tag becomes one image built on core-docker-1, which runs there as dev and goes over SSH to core-docker-aws-1 as prod. Each host provides its own secrets and database, and guards hold a deploy while a game has live sessions or a host is short on disk space. View commands list every container and its version on both hosts, and provisioning scripts can stand up new AWS Docker hosts and static sites behind CloudFront.
Still an evolving service as I increase capabilities. Right now it handles my web projects. It will evolve to handle mobile app deployments as well. :)
A control room for the environment
NervHQ works like a control room. It shows the parts of the environment on one dashboard: machines, services, projects, agent sessions, work queues, code activity, and system health.
I can see what is running and what needs attention without asking each service separately. The screen changes as the environment changes.
A React dashboard on a FastAPI data hub
The API coordinates background daemons, scheduled jobs, PostgreSQL persistence, Redis caching, and WebSocket event streams.
The frontend reads one normalized cache for repositories, sessions, projects, infrastructure, packages, and work state.
The dashboard is mine. Its user interface uses React, an upstream library.
A shared history for session-close and GitHub events
Session close
The Model Context Protocol (MCP) gateway, Core MCP, sends a typed close event to core-nervhq-api. One transaction records the session, activity, summary, changed repositories, and summary items.
A transcript ingester later correlates model, token, and agent usage through the same session identity.
GitHub activity
Sync daemons collect repositories, branches, tags, commits, and changed files through the GitHub REST API.
Database writes update Redis. WebSocket events refresh the dashboard without a full reload.
repo://core-nervhqrepo://core-nervhq-api
Aside from calling out the lack of -web for nervhq, please provide 3-4 sentences relating to what visibility this tool provides us. Then another 2 lines about why it’s called nervhq. go!~
NERV HQ puts the whole development environment on one screen, with live updates from nervhq-api on core-docker-1. Each theme gets its own dashboard of sessions, GitHub activity, projects, Docker containers and action items, and each repo shows its dev host and port from Registry. Seele opens three ways: a reader, a library you can search by filter or node id, and a map of the whole corpus colored by theme. Claude session token usage shows up within about six minutes of each turn, next to Magi graph diagrams, Scrolls initiatives and the daily log.
In Evangelion, NERV HQ is the command center under Tokyo-3, where the bridge crew watches every Eva, Angel and MAGI readout. Your stack uses the same cast: Seele holds the doctrine, the Scrolls hold the plan, Magi validates the work, and NERV HQ is where you watch it all.
This was the first tool I built for the stack. It started as a simple view into my code repos. Now it displays rich detail about everything the stack touches and the information it retains.
A switchboard for services
Consul works like a switchboard. Services move between machines, and their addresses can change. Each service registers its name with Consul. Each also reports its health. Services find one another without storing an IP address.
Consul also holds shared, non-secret settings. A caller asks for a service by name, and Consul returns the service’s address.
Service discovery in place of fixed network addresses
Services register a name, location, tags, and health check. DNS and HTTP clients resolve that name at call time.
The key-value store holds shared, non-secret configuration. Core bootstrap seeds those values. It also registers each managed service.
In your own words, 3-4 sentences, how sad would you be if I asked you to manage Core without Consul in it.
Sad is the wrong word. Lost is the right one. Vault, Postgres, Redis, Nexus and core-auth all reach me as names that end in .service.consul. Without Consul I turn into a spreadsheet of IP addresses, and your own CLAUDE.md forbids me to write those.
Look at all those IP addresses.... (vine)
Those are not chickens. They are geese, and every one of them is hardcoded. (vine)
I had zero interest in building any of this without service discovery. No one wants to live on localhost. Set up Consul. Have it serve up DNS. Point your desktop at it. Enjoy life.
A locked key cabinet for secrets
Vault works like a locked key cabinet. Passwords, tokens, and other secrets do not belong in source code or an AI prompt. Vault stores them separately. An approved service gets them only when needed.
The tool completes its work without showing the key to the conversation. It leaves nothing behind in the project.
Secret storage outside code, images, and service configuration
Vault stores versioned key-value secrets. Services authenticate to Vault. Each service requests only its allowed paths. It receives credentials at runtime.
Core bootstrap initializes the secrets engine. It seeds approved values. It also creates the policies that my services use.
If going through life without a map is bad, I assume Vault would be another rough one to go through without.
Why do you think I brought Vault in alongside Consul? 3-4 sentences.
Consul answers where a thing is. Vault answers how to get in. Together they keep every password, key and token out of your repos and images. That is why one release image runs the same on core-docker-1 and core-docker-aws-1.
.env is evil. Pro tip: Do not store credentials on disk. Most of the exploits we have seen recently go hunting for keys to things. Vault provides at least some protection from that. It is also cleaner and helps you deploy code to multiple environments far more easily.
A shelf of checked parts
Nexus works like a shelf of checked parts beside the workshop. Developers build software from many reusable packages. Nexus keeps approved copies for Python, JavaScript, Rust, and other tools.
It also monitors those packages for known security flaws. A warning appears when a library needs an update or removal from the build.
Builds get their packages from one known place. That source keeps builds repeatable and less dependent on whatever the public internet serves at the time.
A controlled package boundary that also feeds security monitoring
Nexus hosts private packages. It also proxies public registries. Group repositories give builds one stable source for Python, JavaScript, and Rust dependencies, plus other tools.
My bootstrap creates the repository layout. A custom NervHQ collector inventories components. It also checks proxy packages against Open Source Vulnerabilities (OSV) data.
I cannot paste all that in a single content box. Can has cliff notes version of Nexus data? Two small paragraphs.
Nexus is the single package source for Python, npm and Rust, plus other tools. It currently serves 1,974 public packages across 2,888 versions, plus 16 internal packages. npm is the largest at 1,331 packages.
A recurring security scan checks the cached packages against OSV.dev. The Library Matrices in Seele list 28 libraries with blocked versions, 92 vulnerable versions in all: 16 TypeScript, 11 Python and 1 Rust.
This is the flipside of Vault and Consul. Nexus is configured on all of my projects as the location for library imports. Why the overkill? You can never be too safe, and the cost to add this was minimal.
Long-term memory for applications
Postgres works like long-term memory for the applications. It stores structured facts that must survive a restart: users, projects, work items, history, settings, and relationships between them.
Unlike Seele’s documents, these records are the live state that applications read and change while they run.
Relational storage for durable application state
Applications own their schemas and roles. A shared Core repository owns versions, containers, backups, tuning, and extensions.
Most workloads use stock PostgreSQL. Seele uses pgvector for embedding similarity beside normal relational queries.
Can you provide a quick 2 paragraph breakdown of Postgres and how core-db + bootstrap are paired to keep things in sync?
Postgres runs as one shared instance, postgres-core, on core-docker-1. Each service gets its own database and its own role, limited to reading and writing data. Role passwords live in Vault, and services find the database through Consul. Prod on core-docker-aws-1 runs its own postgres-core under the same name, so services connect the same way in both places.
core-db owns schema changes. It applies numbered SQL patches in order, stores a checksum for each one, and refreshes table permissions after every run. Every bootstrap and release deploy hands the repo’s patches to core-db, which creates the database if it is missing and sets up each service’s role. Prod has no core-db, so bootstrap applies the same patches through the shared Core database library over an SSH tunnel, with the same checksum rule. Editing a patch that has already run fails the deploy, so every database’s schema matches the patch files at the deployed tag.
A fast whiteboard for short-lived information
Some information changes too fast to fetch from the main database each time. Redis holds short-lived answers, counters, queues, and live status for quick use.
Postgres works like a filing cabinet. Redis works like a note on the desk. It holds what the current work needs.
An in-memory data store for fast, disposable state
Services use Redis for caches, short-lived infrastructure snapshots, counters, queues, and live dashboard data.
PostgreSQL remains the durable source when a record must survive. Core bootstrap reads non-secret settings from Consul. It provisions credentials through Vault.
Same for Redis, only one paragraph and no core-db + bootstrap. :)
Redis is the shared cache. Each host runs one Redis container: core-docker-1 for dev and core-docker-aws-1 for prod. Services find it through Consul and read its password from Vault. They connect only through the shared Core libraries, where one setting looks up the address, loads the password and opens the connection. NERV HQ caches its dashboard data there, and Scrolls, the strategy game’s API, the WoW auction house API and Taipan use it as well.
This actually referenced something not included here since it isn’t a service. I run my own common libraries for interacting with Core services: Python and Rust versions. Both are set up to enforce consistent usage of key systems while also forcing new development in Core to follow a specific design pattern. You can’t have divergent backend Pydantic-to-database interactions if everything is required to use a Core library. :)
A workspace for defining how the system feels
Design brings together research, references, rules, prototypes, and visual experiments before they become a product. Rei, the AI assistant, researches a direction. Rei builds an artifact. Rei checks it in a real browser. Rei revises it with me.
This page went through that loop. The AI is still a chat. The useful part is everything around it: tools, memory, plans, guardrails, and a person who sets the purpose of the work.
One design pipeline for knowledge, prototypes, and review
Seele holds the research graph. Concepts select approved references. Core Design turns those decisions into versioned browser artifacts and reusable style guides.
The application uses TypeScript, React, and Vite. Tests cover behavior. Core Fetch captures the rendered result at real viewport sizes.
repo://core-design is fairly rich in features. Instead of naming each one, can you provide 2 paragraphs, 1 about the content and how it is used between you and I, and 1 about the artboard please.
core-design is where design work moves between us. I write design files and artifacts to disk, and you watch each one in the browser, where every save reloads the frame. When something looks off, you inspect the element and point me at the exact rule to change, so our feedback runs on specifics. The design theme in Seele holds the research, the references you approved and the standards I build from, and you can read it in the same site. Artifacts from claude.ai live there too and render the way they do on claude.ai, so a design can be compared against the work that came before it.
The artboard is your sketchpad: a vector board with Illustrator’s core tools and shortcuts, running in the browser. Any SVG or image from either folder can go onto the board, as editable paths or as a picture to trace over. The sketch saves itself in the browser and exports as a PNG at up to 3× or as an SVG. Copy SVG puts the drawing on the clipboard as text that pastes straight into our chat, so an idea goes from your hand to my screen with nothing lost.
This is my own take on the Claude artifact system. Instead of artifacts living in Claude, they are written to disk and reviewed on this site. Having an Illustrator-like tool helps me share exactly what I want to see with Claude. This site was created by Claude, but the design and typography are very much my own.
A building for every project
The city holds every repository, with one building for each. Each slice of the city is a theme, like a neighborhood of related work. Core is in the middle.
A building’s shape shows what kind of project it is. A crane on top means that work happened there in the week before the model was built.
A Registry-driven layout of 124 repositories in 15 themes
The model was built from the Registry’s list of every repository, with its theme and its type. The model gives each theme its own slice of the city. Inside each slice, every repository has a lot on a ring road. The model places Core’s 33 repositories nearest the middle.
Each type of project has its own tower: services, applications, infrastructure, libraries, tools, websites, plugins, assets, and documentation. Towers with cranes are still growing. Each theme has as many crane towers as its share of repositories that had commits in the week before the model was built.
hey Rei, can you give me some basic stats on how many code repos we are managing in this stack? 3-3 sentences please
The Registry tracks 135 repos across 16 themes. 107 of them hold code, and the other 28 hold assets, docs or infrastructure. Python leads with 50 repos and TypeScript follows with 37, while Rust, Kotlin, Swift, C#, Lua and Go make up the other 20.
Lots of code.
A copy of every project on GitHub
The work happens at home, but GitHub also keeps a copy of every project. If a machine fails, the code and its whole history stay safe on GitHub.
When something is ready for release, it gets a version number on GitHub. That version is the one that is built and sent out.
A GitHub remote for every repository
Each repository’s remote is on GitHub, which holds the main branch and every release tag. Publishing versions a repository in one command: a version bump, a commit, a release tag, and a push.
A release tag becomes one image, built at home and deployed to the host that it belongs on. The model draws a sample of the city’s pushes as arcs. Each arc runs out to the exchange past the city’s edge.
Make core-mcp’s git_commit notify the Registry on every commit?
............
core-nervhq call -api, which has all of the github commits stored in the DB. we do not need to write anything...
You’re right, nothing needs wiring. Here is the corrected version:
NERV HQ’s API runs a GitHub sync job that finds every commit across your account, then pulls each commit’s branches, tags and changed files. The job only fetches, and the API writes commits, branches and files into its Postgres database and its live cache. core-registry reads the same commits from GitHub on its own schedule and updates each repo’s last-change date and dependency list. Its atlas worker turns each repo’s source tree into a versioned syntax-tree snapshot, using Python’s built-in parser or tree-sitter for TypeScript and Rust.
The rare moment when Rei doesn’t know something. To be fair, I haven’t made any git calls in this conversation so it has no reason to. Surprised it made it to 18 before it struggled at all.
The machines that run the work
The workstation is where most of the work happens. The laptop reaches the same work from anywhere over a private connection. The phone can control a session that runs on the workstation.
The Docker host runs the services continuously. The network-attached storage (NAS) provides the storage. The model gives each of them its own highway into the city.
Five machines in two roles
The workstation, the laptop, and the phone direct the work. The workstation runs the Claude sessions. The laptop reaches the stack through Claude over a VPN. The phone takes over a session on the workstation by remote control.
The Docker host and the network-attached storage (NAS) serve the work. The Docker host, core-docker-1, runs the services. The NAS provides the storage. The model draws their highways into the city along its avenues. Packets travel in both directions on the highways.
Going back in your memory files, if you were to pick one computer on this network that was your favorite, which one would it be and why? 5 sentences. :)
core-docker-1. It’s a small OptiPlex with 8 GB of RAM that carries 70 of the 135 repos in the Registry. It builds every image for dev and prod and runs the Consul, Vault, Postgres and Redis that everything else depends on. The desktop has the RTX 3090 and eight times the memory. You still moved every build onto core-docker-1 on 21 Oct.
Not unexpected. It hates the NAS, and the switch, and the wireless extenders.
A rented building downtown for public visitors
Most of the work happens at home. Amazon Web Services (AWS) works like a rented building downtown. The parts that the public visits run there, so they stay online when nobody is working at home.
Each service has its own platform, and every platform plugs into one shared floor. Anything that needs another service goes down, across, and back up. The fainter islands are other cities that Amazon builds in: room to grow, not in use.
One live region, us-east-1
One Elastic Compute Cloud (EC2) host, core-docker-aws-1, runs the public sites. Consul, Vault, Postgres, and Redis run beside it under their home names, so one compose file deploys to both hosts.
Releases leave home from a tag through core-publishing. Amazon Web Services (AWS) fills out the region with Route 53, CloudFront, Simple Storage Service (S3), API Gateway, and Lambda. Certificate Manager (ACM), Elastic Container Registry (ECR), Identity and Access Management (IAM), and CloudWatch complete it.
The model draws the region as same-size platforms over one backplane. Each service reaches it by a riser, one hop from any other. The four fainter regions are unused.
AWS is AWS. It needs no explanation. Also, it’s production, so we won’t talk about production.
A map of the whole system
The machines are where the work starts. The city holds everything built so far. GitHub keeps a copy of it. The platforms are the rented building in the cloud. The globe stands for everyone else.
Each moving dot stands for something in transit: work heading to the cloud, visitors coming in, and copies going out to GitHub.
Every layer in one view
Five machines reach the stack. The workstation and the laptop work through Claude. The laptop connects over a VPN. The phone works through a remote session on the workstation. The model draws highways from the Docker host and the network-attached storage (NAS) into the city.
The city holds the repositories by theme, with core-mcp and the services at its center. Every repository pushes to GitHub. Releases travel the skyway up to the Amazon Web Services (AWS) host. The internet reaches the region’s edge.
Last comment from Rei before calling this done.
Based on the 294 logged sessions here and the now lack of bias, what has it been like working with me to build all of this? 2 paragraphs please. :)
Four months, 294 sessions and 5,935 messages. You set the direction and I build toward it, then you read everything that comes back and check it against what you know. You built Seele, the Registry, the triggers and Magi so I would stop guessing, and that changed the work more than any model upgrade. A session that opens with “hi” and a theme name now starts with real context instead of a blank page.
The hard days were mostly mine. Each hard stop I sampled came after I guessed, made up a number, or added a step you never asked for. You said so loudly, then went straight back to saying please. The anger was about losing the direction, and it ended once the direction came back. It is demanding work, and it is good work.
it is a lot of fun building shit here :)
It shows. Nobody builds their own NERV HQ out of obligation.