TazLab Repository Map

Scope

This page maps the main repositories in the TazLab workspace and the boundary each one owns.

Current Synthesis

The workspace is not a single application repository. It is a working directory that contains multiple independent repositories with distinct operational roles.

Main Repositories

AGENTS.ctx/

  • page: AGENTS.ctx
  • context governance system
  • active operational memory lives under AGENTS.ctx/memory/
  • defines how agents should behave across projects

tazpod/

  • page: tazpod
  • operator CLI and secrets-aware development environment
  • controls local container lifecycle, vault unlock/lock flow, S3-backed secret recovery, and operator tooling

ephemeral-castle/

  • page: ephemeral-castle
  • provider-specific infrastructure repository
  • provisions cluster base layers and hosts the Hetzner Vault runtime track

tazlab-k8s/

  • page: tazlab-k8s
  • provider-agnostic GitOps desired-state repository
  • Flux watches this repository and reconciles the cluster from it

mnemosyne-mcp-server/

  • page: mnemosyne-mcp-server
  • Go MCP server for semantic memory operations
  • deployed in cluster and backed by Postgres plus vector search

blog-src/

  • page: blog-src
  • Hugo blog source repository
  • publishes the external narrative and technical articles for TazLab

wiki.tazlab.net/

  • page: wiki.tazlab.net
  • dedicated documentation and synthesis repository
  • intended to hold the durable, organized wiki that future agents can consult directly

Boundary Rule

Each repository should keep owning its own executable truth, while the wiki should explain relationships and preserve structured documentation about those boundaries.

The wiki must not become a shadow implementation layer that drifts away from the actual repositories.

Supporting Pages

Open Questions

  • Which repository-specific hub pages should be created first under wiki/entities/?
  • Should the next pass create one page per major repository with entrypoints, key files, and common workflows?