Capability Registry
The capability registry maps Anuva capabilities to the layer and repository that own them.
Capabilities should remain stable even when repository boundaries change. A capability can start in one repository, move to a product-main repository, or later split into a shared Engineering Platform repository without changing its name.
flowchart TD
capability["Capability"] --> level{"Ownership level"}
level --> platform["Engineering Platform capability"]
level --> product["Product-level capability"]
level --> implementation["Repository-level implementation capability"]
platform --> handbook["anuva-engineering-handbook"]
product --> productMain["product-main repository"]
implementation --> repo["implementation repository"]
Ownership Levels
| Level |
Meaning |
Typical Owner |
| Engineering Platform capability |
Reusable process, standard, workflow, prompt, template, registry, or publishing capability used across products. |
anuva-engineering-handbook, anuva-dev-docs, or a future shared platform repository. |
| Product-level capability |
Product coordination capability such as roadmap, product architecture, product capability map, product release, or cross-repository product playbook. |
Product Management repository such as anuva-main-video-creator. |
| Repository-level implementation capability |
Code, local technical docs, tests, operations, and implementation behavior for a bounded component. |
Product implementation repository such as anuvax-cms, anuva-python-server, or anuva-unity-video-creator. |
Capability Status Model
| Status |
Meaning |
| Active |
Capability is currently owned and relevant to active Anuva work. |
| Planned |
Capability is expected but not yet assigned to an active lifecycle. |
| Candidate |
Capability is being evaluated or may be split later. |
| Shared |
Capability affects multiple repositories and needs an explicit coordinating owner. |
| Capability |
Owner |
Status |
Notes |
| Organization architecture |
anuva-engineering-handbook |
Active |
Defines the Organization, Engineering Platform, Product, and repository layers. |
| Engineering process |
anuva-engineering-handbook |
Active |
Defines shared change workflow and development operating model. |
| Repository architecture |
anuva-engineering-handbook |
Active |
Defines current and planned repository topology. |
| Repository registry |
anuva-engineering-handbook |
Active |
Tracks repository purpose, type, status, and onboarding state. |
| Capability registry |
anuva-engineering-handbook |
Active |
Tracks capability ownership level and routing. |
| Codex workflow architecture |
anuva-engineering-handbook |
Active |
Defines how docs, agents, skills, prompts, and repositories work together. |
| AGENTS.md design guidance |
anuva-engineering-handbook |
Active |
Defines durable repository-level instruction patterns. |
| Shared change workflow |
anuva-engineering-handbook |
Active |
Defines small change, large change, docs parity, and verification expectations. |
| Template library |
anuva-engineering-handbook |
Active |
Provides reusable engineering and product-main templates. |
| Prompt library |
anuva-engineering-handbook |
Active |
Provides reusable Codex prompts for engineering workflows and repository bootstrap. |
| Handbook MkDocs structure |
anuva-engineering-handbook |
Active |
Owns the current MkDocs skeleton and navigation. |
| Cross-repository task automation workflow |
anuva-engineering-handbook |
Active |
Defines how product-main docs become GitHub issues, GitHub Project items, PR completion reports, and progress updates. |
| Aggregated development docs publishing |
anuva-dev-docs |
Active |
Builds MkDocs output from Anuva repositories, generates project status HTML, and publishes the static docs site through Cloudflare Pages. |
| Shared Codex skills |
anuva-engineering-handbook or future anuva-shared-skills |
Planned |
Starts as handbook catalog content; extract only when independent versioning is useful. |
| Engineering standards |
anuva-engineering-handbook or future anuva-shared-standards |
Planned |
Starts in the handbook; extract only when standards need a separate lifecycle. |
| Docs portal product |
future anuva-docs-portal |
Candidate |
Only needed if anuva-dev-docs outgrows static aggregation and becomes a larger portal product. |
Product-Level Capabilities
| Capability |
Product |
Owner |
Status |
Notes |
| Product vision |
Video Creator |
anuva-main-video-creator |
Active |
Defines what the product is and what outcomes it pursues. |
| Product roadmap |
Video Creator |
anuva-main-video-creator |
Active |
Tracks product-level sequencing and priorities. |
| Product architecture |
Video Creator |
anuva-main-video-creator |
Active |
Describes high-level product components without duplicating implementation internals. |
| Product capability map |
Video Creator |
anuva-main-video-creator |
Active |
Maps product capabilities to owning repositories. |
| Cross-repository feature planning |
Video Creator |
anuva-main-video-creator |
Active |
Converts product-level features into repository impact docs, GitHub issues, and GitHub Project tasks. |
| Product GitHub Project coordination |
Video Creator |
anuva-main-video-creator |
Active |
Owns feature task creation, project field conventions, progress sync, and release review for the Anuva Video Creator GitHub Project. |
| Product playbooks |
Video Creator |
anuva-main-video-creator |
Active |
Documents product-specific recurring workflows and examples. |
| Product ADRs |
Video Creator |
anuva-main-video-creator |
Active |
Records product-level decisions. |
| Product release coordination |
Video Creator |
anuva-main-video-creator |
Active |
Coordinates release readiness across implementation repositories. |
| Realtime product management |
Realtime |
anuva-main-realtime |
Planned |
Future equivalent product-level capability set for Realtime. |
Repository-Level Implementation Capabilities
| Capability |
Product |
Owner |
Status |
Handbook-Level Notes |
| Web App implementation boundary |
Video Creator |
anuvax-cms |
Active |
Local implementation details belong in that repository. |
| Python render orchestration implementation boundary |
Video Creator |
anuva-python-server |
Active |
Local implementation details belong in that repository. |
| Unity Video Creator implementation boundary |
Video Creator |
anuva-unity-video-creator |
Active |
Local implementation details belong in that repository. |
| Realtime Unity implementation boundary |
Realtime |
anuva-unity-realtime |
Planned |
Future implementation capability for the Realtime product. |
Capability Routing
Use this routing rule when deciding where a Codex task should begin.
flowchart TD
request["New task"] --> scope{"What is the scope?"}
scope -->|Engineering-wide process, standard, template, prompt, registry| handbook["Start in anuva-engineering-handbook"]
scope -->|Docs aggregation or public docs publishing| devDocs["Start in anuva-dev-docs"]
scope -->|Product roadmap, product architecture, product feature, release, GitHub Project tasks| productMain["Start in the product-main repository"]
scope -->|Code, local technical docs, tests, operations| implementation["Start in the owning implementation repository"]
scope -->|Unknown ownership| registry["Update repository and capability registries first"]
handbook --> sharedDocs["Update shared handbook docs"]
devDocs --> publishedDocs["Build or publish aggregated docs"]
productMain --> productPlan["Create product-level plan and repository impact"]
productPlan --> githubIssues["Create GitHub issues and project items"]
githubIssues --> implementation
implementation --> localDocs["Update local docs and verification"]
registry --> handbook
Ownership Rules
- Every active capability should have one primary owner.
- Shared capabilities may involve multiple repositories, but the registry should still name the coordinating owner.
- Engineering Platform capabilities should avoid product-specific implementation detail.
- Product-level capabilities should avoid duplicating engineering standards or implementation internals.
- Repository-level implementation capabilities should avoid duplicating product roadmap or cross-repository planning.
- Capability moves should update this page and the Repository Registry in the same change.
Current Gaps
- Video Creator product-level capabilities are active and should be expanded in
anuva-main-video-creator as product plans mature.
anuva-dev-docs is active, but each source repository still needs to finish or maintain its own MkDocs setup.- Realtime capabilities should remain lightweight until the Realtime product is actively defined.
- Future shared platform capabilities should remain in this handbook until an independent repository is justified.