Skip to content

Repository Registry

The repository registry is the handbook-level source of truth for Anuva repository ownership and routing.

Use this page to answer:

  • Which repositories belong to the Engineering Platform?
  • Which repositories coordinate products?
  • Which repositories implement product components?
  • Which repositories are future candidates?
  • Which documents should Codex read first when working in or across those repositories?
flowchart TD
  registry["Repository Registry"] --> platform["Engineering Platform repositories"]
  registry --> productMain["Product Management repositories"]
  registry --> implementation["Product implementation repositories"]
  registry --> future["Future repositories"]

  platform --> handbook["anuva-engineering-handbook"]
  platform --> devDocs["anuva-dev-docs"]

  productMain --> videoMain["anuva-main-video-creator"]
  productMain --> realtimeMain["future: anuva-main-realtime"]

  implementation --> web["anuvax-cms"]
  implementation --> python["anuva-python-server"]
  implementation --> unity["anuva-unity-video-creator"]

  future --> sharedSkills["anuva-shared-skills"]
  future --> sharedStandards["anuva-shared-standards"]
  future --> docsPortal["candidate: anuva-docs-portal"]
  future --> realtimeUnity["anuva-unity-realtime"]

Repository Status Model

Status Meaning
Active Repository exists and is part of current Anuva engineering or product work.
Planned Repository is expected, but not yet treated as an active dependency.
Candidate Repository concept is being evaluated.
Archived Repository is no longer part of active development.

Repository Type Model

Type Meaning
Engineering Platform Shared engineering process, standards, templates, prompts, registries, and portal structure.
Docs publishing Repository that aggregates and publishes documentation generated from multiple Anuva repositories.
Product Management Product or program coordination repository for a product.
Product implementation Repository that owns product code, local technical docs, tests, and verification.
Future Planned or candidate repository that should not be treated as an active dependency yet.

Engineering Platform Repositories

Repository Status Responsibility First Handbook Links
anuva-engineering-handbook Active Source of truth for engineering process, repository architecture, capability ownership, Codex workflows, templates, prompts, and handbook publishing structure. Organization Architecture, Repository Architecture, Capability Registry
anuva-dev-docs Active Aggregated development docs publisher. Builds MkDocs output from Anuva repositories, generates the GitHub Project status HTML page, and publishes the static site through Cloudflare Pages. Repository Architecture, GitHub Project Automation, Docs Parity Rules
anuva-shared-skills Planned Optional future home for reusable Codex skills if they need independent versioning or release cadence. Shared Skill Catalog
anuva-shared-standards Planned Optional future home for standards that should be versioned independently from the handbook. Repository Architecture
anuva-docs-portal Candidate Optional future publishing layer only if anuva-dev-docs outgrows static aggregation and needs a larger portal product. Repository Architecture

Product Management Repositories

Repository Product Status Responsibility First Handbook Links
anuva-main-video-creator Video Creator Active Product and program management for Video Creator: roadmap, product architecture, product capability map, GitHub issue/project task creation, cross-repository planning, product playbooks, product ADRs, release coordination, and product docs published through anuva-dev-docs when configured. Product Management Repositories, Product Main Repository Template, Bootstrap Product Main Repository, GitHub Project Automation
anuva-main-realtime Realtime Planned Future Product Management repository for Realtime when that product is ready to be defined. Product Management Repositories, Product Main Repository Template

Product Implementation Repositories

Repository Product Status Responsibility Product Management Repository
anuvax-cms Video Creator Active Web App implementation boundary and local implementation documentation. anuva-main-video-creator
anuva-python-server Video Creator Active Python server and render orchestration implementation boundary and local implementation documentation. anuva-main-video-creator
anuva-unity-video-creator Video Creator Active Unity Video Creator implementation boundary and local implementation documentation. anuva-main-video-creator
anuva-unity-realtime Realtime Planned Future Realtime Unity implementation boundary. anuva-main-realtime

Future Repository Candidates

Repository Type Status Extraction Trigger
anuva-shared-skills Engineering Platform Planned Skill definitions become numerous, reused across multiple products, or need independent versioning.
anuva-shared-standards Engineering Platform Planned Standards become broad enough that they should be versioned independently from the handbook.
anuva-docs-portal Engineering Platform Candidate The active anuva-dev-docs publisher grows into a larger portal product with its own UI, access model, search, or release lifecycle.
anuva-main-realtime Product Management Planned Realtime product planning becomes active enough to need durable roadmap, architecture, capability, and release coordination.
anuva-unity-realtime Product implementation Planned Realtime implementation begins and needs a dedicated Unity runtime repository.

Responsibility Map

flowchart LR
  handbook["anuva-engineering-handbook"] --> process["Engineering process"]
  handbook --> registries["Repository and capability registries"]
  handbook --> codex["Codex workflows"]
  handbook --> templates["Templates and prompts"]
  handbook --> publishingRules["Publishing rules"]

  devDocs["anuva-dev-docs"] --> aggregate["Aggregated static docs"]
  devDocs --> projectStatus["GitHub Project status page"]
  devDocs --> cloudflare["Cloudflare Pages"]

  videoMain["anuva-main-video-creator"] --> roadmap["Video Creator roadmap"]
  videoMain --> productArchitecture["Video Creator product architecture"]
  videoMain --> featurePlans["Cross-repository feature plans"]
  videoMain --> githubTasks["GitHub issues and project items"]

  web["anuvax-cms"] --> webBoundary["Web App implementation"]
  python["anuva-python-server"] --> pythonBoundary["Python render orchestration"]
  unity["anuva-unity-video-creator"] --> unityBoundary["Unity video rendering"]

  featurePlans --> web
  featurePlans --> python
  featurePlans --> unity
  githubTasks --> web
  githubTasks --> python
  githubTasks --> unity

Onboarding Requirements

Before a repository is considered fully onboarded to the handbook process, it should have:

  • A registry entry on this page.
  • Capability ownership recorded in the Capability Registry.
  • A repository-level AGENTS.md.
  • A repository-level change workflow or a clear pointer to the shared workflow.
  • Local documentation entry points.
  • Verification expectations documented for Codex.
  • A decision about whether and how its docs flow into anuva-dev-docs.

Product Management repositories should also have:

  • A product repository registry.
  • A product capability map.
  • Product-level cross-repository feature workflow.
  • GitHub issue and GitHub Project task creation workflow.
  • Product ADR, release, prompt, playbook, and template sections.
  • Links back to the Engineering Platform rather than duplicated engineering standards.

anuva-dev-docs should have:

  • A root index.html that links to each generated repository docs site.
  • A project-status.html page that summarizes the Anuva Video Creator GitHub Project grouped by repository.
  • A local batch file or script for building all docs.
  • A GitHub Actions publishing workflow when automation is enabled.
  • Clear behavior for repositories that do not yet have MkDocs configured.

Registry Maintenance Rules

  • Update this page when a repository is added, renamed, split, archived, or assigned a new handbook-level responsibility.
  • Update the capability registry in the same change when ownership changes.
  • Keep this registry at the responsibility level; do not turn it into an implementation guide.
  • Prefer repository names over informal labels once a repository name is known.
  • Mark future repositories as planned or candidate until they exist and are onboarded.