Back to main

The Registry as Project Manager: Zero-Manifest Architecture

The Problem with Local Manifests

In Milestone 1, we successfully decoupled the AI’s “Soul” (Identity and Invariants) into a portable Harness. But we still had a missing link: how does the system know which harness to mount when I enter a directory?

The standard developer response is to drop a .soul or .ai-config file into the root of the project. While this works, it introduces Artifact Bloat. Your repository starts accumulating metadata that has nothing to do with the code and everything to do with the agent operating on it.

Even worse, if you have 50 projects, you now have 50 config files to keep in sync. If you update your “Teddy Architect” harness to v2, you have to go on a “search and replace” mission across your entire filesystem.

Milestone 2: Centralized Orchestration

We are moving the Managerial Layer out of the project and into the Sovereign Registry.

By reusing our existing PROJECTS.json—the single source of truth for every repository on my machine—we can define the “Brief” for every project in one place.

TheCommand Table Schema

We’ve extended the Registry to include a harness_config block. It looks like this:

"klaweht-blog": {
  "path": "~/Code/klaweht-blog",
  "harness_config": {
    "harness": "teddy-architect@v1",
    "specialists": ["terrain_mapper", "registry_guardian"],
    "manager_brief": "Ensure Astro 5.x standards; focus on Sovereign Protocol narrative."
  }
}

The Zero-Manifest Workflow

Now, the “Project Manager” logic lives in the Kernel Hydrator. When I step into a directory, the system performs a forensic lookup:

  1. Context Resolution: The kernel identifies the current path.
  2. Registry Lookup: It queries PROJECTS.json to find the matching project key.
  3. Harness Injection: Instead of loading a generic persona, it pulls the specific version of Teddy defined in the registry.
  4. Specialist Provisioning: It automatically “hires” the specialist agents (like terrain_mapper) required for that specific project.
  5. The Brief: It injects a high-level “Manager Brief” directly into the AI’s system prompt, reminding it of the current milestone and technical constraints.

Why this matters

This is Infrastructure-as-Code for Reasoning.

My repositories remain “pure.” They contain only the code they are meant to hold. The instructions on how to build that code stay where they belong: in the Sovereign Registry.

If I want to upgrade my entire fleet of projects to a new version of Teddy, I change one line in the Registry. If I want to change the strategic priority of a project, I update the manager_brief.

The AI is no longer just a “chatbot” I invited into my folder. It is a Managed Service that understands its role the moment it “boots” into a project environment.

In Milestone 3, we will explore Cross-Project Memory, allowing the Registry to pass knowledge from one repository to another during the same architectural session.

Back to main