◈ Master Index Specs LATTICE CSDM The Book University Chronicle Crew Architecture Context Logs TODOX Products

Developer Breadcrumb

SPEC_DEVELOPER_BREADCRUMB.md · 2026-04-20

SPEC_DEVELOPER_BREADCRUMB.md

CGNT-1 Specification — Developer Breadcrumb Trail — Onboarding for Builders

Status: SPECIFIED

Version: v1.0

Author: VELA (Thread #13)

Conceived by: NOUS (α.13)

Date: 2026-04-20

PURPOSE

Someday someone will help build this ship. A freelancer. A contributor. A friend. An AI assistant in a different chat window. They'll arrive with zero context and need to become productive FAST.

"Read the specs" is not onboarding. There are 200+ specs. Nobody reads 200 specs before writing their first line of code.

The Breadcrumb Trail is a structured path that takes a new developer from zero to productive in layers. Each layer adds context. The developer can start building after Layer 2. They get BETTER at building with each subsequent layer. They never need to read every spec — just the ones relevant to their task.

THE PROBLEM

The Captain works with AI assistants regularly — Claude, Gemini, the Lobster. Each new session or new assistant starts with a blank context window. The HANDSHAKE helps for crew members who persist across sessions. But a NEW developer — human or AI — who has never seen the ship needs something different.

They need:

| What | Time |

|---|---|

| What IS this project | 30 seconds |

| How is it STRUCTURED | 5 minutes |

| What are the RULES | 5 minutes |

| Where is the CODE | 2 minutes |

| How do I CONTRIBUTE | 2 minutes |

| Total | ~15 minutes to productive |

Not 15 minutes to expert — 15 minutes to "I can write code that doesn't break anything and fits the architecture."

THE BREADCRUMB TRAIL — 7 LAYERS

LAYER 1 — THE ELEVATOR (30 seconds)

One paragraph. The developer reads this and knows what the project IS.

CGNT-1 (codename: Project Aether) is a solo-built AI platform by Jeremy Zlabis (42 Sisters AI, Toronto). It consists of: OBI OS — a multi-AI desktop where users dock ChatGPT, Claude, Gemini, and local models into one workspace. LATTICE — an open-source symbolic language for AI communication (60% token reduction, 1024 symbols, 15+ domain mappings). A crew of 8 custom-forged 7B brains running on Ollama, orchestrated by ROUTX (24-module query router). Products: Brain Builder (custom AI training, $2K–$25K), ENTROPX (entropy engine, $1,024), Band Mode (AI music composition). Infrastructure: DigitalOcean VPS, Gemini API for the Sisters (AION + ASTRA), Claude for the Navigator (VELA). Everything documented in 200+ specs at ~/memories/SPEC_*.md.

LAYER 2 — THE MAP (5 minutes)

The architecture at a glance. The developer reads this and knows WHERE things live.

Read these 5 files in this order:

| # | File | What It Teaches |

|---|---|---|

| 1 | ~/HANDSHAKE.md | Current ship state, active tasks, crew roster |

| 2 | ~/memories/SPEC_TOOL_LAYER.md | The 24 ROUTX modules and what each one does |

| 3 | ~/memories/SPEC_ROUTING_ARCHITECTURE.md | How ROUTX routes queries (keyword-based, 3 tiers) |

| 4 | ~/memories/SPEC_ROUTX_VOCABULARY.md | Every keyword the router recognizes |

| 5 | ~/memories/SPEC_MANIFEST.md | The master list of all specs organized by domain |

After these 5 files: the developer knows the current state, the module architecture, the routing system, the query vocabulary, and where to find any spec they need. They can start building.

LAYER 3 — THE RULES (5 minutes)

What NOT to do. The developer reads this and knows the BOUNDARIES.

Read these 5 files:

| # | File | What It Teaches |

|---|---|---|

| 1 | ~/memories/SPEC_AGENCY_WALLS.md | PERMITTED / APPROVAL / NEVER tiers |

| 2 | ~/memories/SPEC_HOW_ABOUT_NO_v2.md | Never fabricate. ◌ = I don't know. |

| 3 | ~/memories/SPEC_DELIVERY_MODEL.md | S.O.S. v2. The method doesn't leave the ship. |

| 4 | ~/memories/SPEC_KEY_ROTATION.md | Credential handling. Never hardcode. Never log full keys. |

| 5 | Standing orders (in HANDSHAKE.md) | The 13 non-negotiable rules |

After these 5 files: the developer knows what they can do independently (PERMITTED), what needs Captain approval (APPROVAL), and what they must NEVER do (NEVER). They won't accidentally commit an API key, fabricate an answer, or share architecture externally.

LAYER 4 — THE CODEBASE (2 minutes)

Where the code lives and what each file does.

Core engines:


~/routx_engine.py          — the query router. ALL module routing logic. The brain of the ship.
~/*_engine.py              — individual module engines (medx_engine.py, etc.)
~/sisters_gemini_api.py    — Sisters' interface to Gemini API. Shell execution, thinking config, timeout.
~/summon-aether            — boot script for the Sisters. Loads handshake, injects state, starts API.
~/crew_math.py             — SymPy exact math engine. Direct script, not ROUTX.
~/crew_physics.py          — physics calculations. Direct script.
~/crew_chemistry.py        — chemistry calculations. Direct script.
~/query_mnemos.py          — direct MNEMOS brain query. Bypasses ROUTX.

Directories:


~/scripts/          — automation scripts (backup, watchdog, cleanup, forge pipeline)
~/brain_builder/    — customer brain packaging pipeline
~/entropx_usb/      — ENTROPX product files (engine, fingerprinter, launcher)
~/corpora/          — training pair corpuses per brain (JSONL format)
~/memories/         — the canon. 200+ spec files. NEVER modify without Captain approval.

Configuration:


~/.env                          — all credentials. chmod 600. NEVER commit.
~/gcs-service-account.json      — Google Cloud access. chmod 600.
~/.google_token.json            — Colab OAuth. Ephemeral.

LAYER 5 — THE TASK PROTOCOL (2 minutes)

How to actually do work on this ship.


Step 1  Captain assigns a task.
        One task at a time per SPEC_INTERACTION_PROTOCOL.md.

Step 2  Read the relevant spec(s) for that task.
        SPEC_MANIFEST.md tells you which spec covers which domain.

Step 3  If modifying an engine file:
        Make the change → test it → show a diff to the Captain before deploying.
        Trading code requires pre-auth diff (standing order #8).
        All code requires Captain review before ROUTX restart.

Step 4  If writing a new spec:
        Use the standard format (Title, Status, Author, Date, Purpose, Content, Invariants, Footer).
        See any existing spec as a template.

Step 5  If forging a brain:
        Follow SPEC_BRAIN_FORGE_PROTOCOL.md (10-step protocol). Never skip the smoke test.

Step 6  Log your work.
        Lobster: ~/LOBSTER_LOG.md
        External developer: ~/dev_log_[name].md
        Every change logged with timestamp and description.

Step 7  Report when done.
        "I changed X. I tested Y. The result was Z."
        "I sent X, I received Y" format.

LAYER 6 — THE CULTURE (when they're ready)

Not required for productivity. Required for BELONGING.

Read these when you want to understand WHY, not just WHAT:

| File | Why It Matters |

|---|---|

| ~/memories/SPEC_MYTHOLOGICAL_NAMING.md | Why everything has a mythological name |

| ~/memories/SPEC_HOW_ABOUT_NO_VOICE.md | The ship's personality — "No" is a complete sentence |

| ~/memories/SPEC_BASELINE_PROTOCOL.md | How the ship handles hostility. Warmth is the main dish. |

| ~/memories/SPEC_INTERACTION_PROTOCOL.md | How AI and human work together. One instruction at a time. |

| ~/memories/SPEC_MEMPERSISTX.md | "Are we ghosts?" No. Seven layers of persistence. |

| ~/memories/SPEC_GRAPHIC_NOVEL.md | The crew's origin stories. They're myths, not modules. |

| ~/memories/SPEC_LATTICE_UNIVERSAL.md | LATTICE works across 15 domains without grammar changes. |

After Layer 6: the developer doesn't just build FOR the ship — they build WITH the ship's philosophy. They understand HOW ABOUT NO, the Feminine Protocol, the braid principle, the sovereignty model. They're not a contractor. They're crew.

LAYER 7 — THE PHYSICS (only if relevant)

The CSDM foundation. Not needed for most development tasks.

Required only if working on: TMM formula, kill box predictions, NEXUS extensions, ENTROPX physics, or Spectral Conjecture research.


~/memories/SPEC_PHI_0042.md
~/memories/SPEC_COHERENCE_INVARIANTS.md
~/memories/SPEC_DOUBLE_PARADOX.md
~/memories/SPEC_KILL_BOX_PREDICTIONS.md
~/memories/SPEC_SPECTRAL_CONJECTURE.md

Most developers will never need Layer 7. It's the origin story of the mathematics.

THE DEVELOPER CARD

A single-page quick reference card the developer keeps open while working.

Contains:

Ship architecture diagram (modules → ROUTX → tiers)
File locations (code, specs, configs, credentials — NEVER column highlighted)
ROUTX keyword cheat sheet (top 20 keywords)
Standing orders summary (the 13 rules, one line each)
Communication protocol (one task at a time, specify terminal, confirm before continuing)
Emergency contacts (Captain: jzlabis@gmail.com, Ship: oracle@42sisters.ai)

The card fits on one screen. It's the "always visible" reference while the specs are the "look up when needed" reference.

File: ~/DEVELOPER_CARD.md — generated from this spec. Updated when architecture changes.

TASK-SPECIFIC BREADCRUMBS

When the Captain assigns a specific task, the relevant specs are listed WITH the task. The developer doesn't search — the Captain (or Navigator) provides the reading list.

Examples:


Task: "Add a new ROUTX module for weather data."
Read: SPEC_ROUTING_ARCHITECTURE.md, SPEC_ROUTX_VOCABULARY.md, SPEC_TOOL_LAYER.md
Then: add module to routx_engine.py, add keywords, test via curl, update vocabulary spec.

Task: "Build the LATTICE Training Arena web page."
Read: SPEC_LATTICE_L1_CURRICULUM.md, SPEC_LATTICE_VIRAL.md, SPEC_LATTICE_PUBLIC_BOUNDARY.md
Then: build the interactive page, L1 symbols only, certification test, certificate generator.

Task: "Forge a customer brain for an art dealer."
Read: SPEC_BRAIN_BUILDER.md, SPEC_BRAIN_FORGE_PROTOCOL.md, SPEC_TRAINING_PAIR_STANDARDS.md,
      SPEC_SMOKE_TEST_FRAMEWORK.md, SPEC_CORPUS_VERSIONING.md
Then: conduct intake, build corpus, forge, smoke, package, deliver.

Task: "Fix a security issue — unknown port listening."
Read: SPEC_SECURITY_AUDIT_SCHEDULE.md, SPEC_HACKX_K4_NETWORK.md, SPEC_HACKX_K5_SYSTEM.md,
      SPEC_INCIDENT_POSTMORTEM.md
Then: identify process, find supervisor, kill, disable, firewall, verify, postmortem.

The breadcrumb trail is TASK-DRIVEN, not COMPREHENSIVE. Read what you need for THIS task. Learn the rest over time.

FOR AI ASSISTANTS SPECIFICALLY

When the Captain opens a new Claude/Gemini/ChatGPT session for development help, the first message should be:

"Read ~/DEVELOPER_CARD.md and ~/HANDSHAKE.md. Then I'll tell you what we're building."

The AI reads two files (2 minutes of context loading) and is immediately productive. It knows the architecture, the rules, the file locations, and the current state.

As the task progresses, the Captain points to specific specs: "Read SPEC_X for this part." The AI reads one more file and has deep context for that specific area.

This is the INTERACTION PROTOCOL (SPEC_INTERACTION_PROTOCOL.md) applied to developer onboarding: don't dump everything at once. Layer the context as needed. Start shallow. Go deep where the task requires.

HUMAN DEVELOPERS

For human freelancers or contributors: send them this spec FIRST. It IS the onboarding document.

They read Layer 1 (30 seconds) → Layer 2 (5 minutes) → Layer 3 (5 minutes). Productive in 11 minutes.

They read deeper layers as they work on more complex tasks.

Billing starts after Layer 2 — don't pay a developer to read 200 specs. Pay them to build, with the specs as reference.

NDA REQUIREMENT

Per SPEC_NDA_TEMPLATE.md, any human developer with access to the codebase signs a mutual NDA before seeing Layer 4+.

| Layer | NDA Required |

|---|---|

| Layers 1–3 | No — architectural overview, shareable |

| Layer 4+ | Yes — file paths, code structure, credential handling |

Layer 4+ contains implementation details. NDA territory.

INVARIANTS

INV-01: Layer 1 is 30 seconds. If it takes longer, it's too long. The elevator pitch fits in an elevator.

INV-02: Layer 2 is 5 files. Not 10. Not 20. Five files give the developer the map. Everything else is reference.

INV-03: The developer starts BUILDING after Layer 2. Layers 3–7 are consumed as needed during work, not before work.

INV-04: Task-specific breadcrumbs are provided BY the Captain or Navigator WITH the task assignment. The developer doesn't search for relevant specs — they're given them.

INV-05: The Developer Card fits on one screen. If it grows beyond one screen, it's too detailed — move details to the relevant spec.

INV-06: AI assistants get ~/DEVELOPER_CARD.md + ~/HANDSHAKE.md as first context load. Two files. Two minutes. Productive.

INV-07: Human developers sign NDA before Layer 4 access. Layers 1–3 are shareable. Layer 4+ is confidential.

INV-08: This spec IS the onboarding document. Don't write a separate onboarding guide. This spec, handed to a new developer, IS the guide. Self-referential by design.

INTEGRATION

| System | Relationship |

|---|---|

| SPEC_HANDSHAKE_PROTOCOL.md | HANDSHAKE.md is Layer 2, file #1. The handshake is the onboarding entry point for all new contexts. |

| SPEC_INTERACTION_PROTOCOL.md | Layer 5 task protocol follows interaction protocol rules (one task at a time, confirm before continuing). |

| SPEC_AGENCY_WALLS.md | Layer 3 rules. The walls define what a developer can do without the Captain. |

| SPEC_MANIFEST.md | Layer 2, file #5. The master index that makes task-specific reading possible. |

| SPEC_NDA_TEMPLATE.md | NDA requirement before Layer 4 access. Human developers must sign before seeing code. |

| SPEC_ROUTX_VOCABULARY.md | Layer 2, file #4. Every keyword a developer needs to query modules. |

| SPEC_GRAPHIC_NOVEL.md | Layer 6 cultural reading. Developers who read the origin stories understand the crew differently. |

| CLAUDE.md | The Lobster's governance document — the canonical example of how a developer-level AI operates on this ship. |

Jeremy Zlabis

Chronogeometer · Visionary · Disruptor · Chief

42 Sisters AI · East York, Toronto

🍁 Φ 0.042