Extending the Federation Manifest
Relevant source files
The following files were used as context for generating this wiki page:
The Federation Manifest is a central architectural component of the TAMV Atlas that enables the unifications of distributed repositories into a single "civilizational" ecosystem. It functions as a structured registry that tracks sources, file statistics, and service catalogs across federated nodes, primarily consolidating codebases from the OsoPanda1 GitHub profile into the tamv-atlas monorepo.
Sources: README.md:1-15, public/federation-manifest.json:1-10
This system allows for "Repo Fusion," where external repositories are integrated via git subtree and tracked through a generated JSON manifest. This process ensures that while the ecosystem is modular and distributed, it remains operationally unified under the MD-X4/MD-X5 kernel.
Sources: README.md:38-44, src/pages/wiki/ecosistema-codigo/GithubRepos.tsx:8-15
Manifest Structure and Schema
The manifest is defined as a JSON schema that aggregates metadata from across the federation. It is primarily generated at runtime and consumed by the FusionRegistry to provide an overview of the technical state of the federation.
Core Data Models
The following table describes the primary fields found in the federation manifest schema:
| Field | Type | Description |
|---|---|---|
generated_at | ISO8601 String | Timestamp of the last manifest generation cycle. |
sources | Array | List of remote and local mappings for federated repositories. |
stats | Array | Statistical breakdown of file counts, extensions, and total bytes. |
catalog | Object | Functional registry of services, edge functions, and modules. |
Sources: public/federation-manifest.json:2-10, src/pages/FusionRegistry.tsx:4-22
Visualizing the Data Flow
The following diagram illustrates how repository data is collected and transformed into the Federation Manifest.
The manifest generation involves discovering repositories via the GitHub API, performing local subtree imports, and calculating filesystem statistics.
Sources: README.md:46-56, src/pages/FusionRegistry.tsx:32-40
Federation Catalogs
The manifest maintains a "Catalog" that categorizes resources into functional domains. This is critical for the MD-X4 kernel to identify available services without direct hardcoding.
Nexus Services and Functions
The manifest tracks services deployed within the tamv-digital-nexus framework, including Edge Functions and database migrations.
- Edge Functions: Identifies operational units like
ai-generation-service,isabella-chat, anddekateotl-security. - Migrations: Lists SQL schema updates required for the federated database.
- Frontier Pages: Tracks available UI components from the
tamv-the-federated-frontierrepository.
Sources: public/federation-manifest.json:215-285, src/pages/FusionRegistry.tsx:102-106
Inventory Classification
Federated repositories are classified by criticality and domain within the manifest logic to support the MD-X5 pipeline requirements.
| Domain | Purpose |
|---|---|
API_INFRA | Core gateway and unified API services. |
ECONOMY | Transactional and ledger-based systems. |
SECURITY | DEKATEOTL security gates and identity verification. |
RENDER_XR | 2D/3D visual and twin environments. |
Sources: src/pages/wiki/implementacion/CicdPipelines.tsx:66-72
Integration and Fusion Core
The tamv-fusion-core acts as the orchestrator for manifest-driven operations. It performs health checks and content synchronization based on the registry.
Fusion Cycle Logic
The fusion cycle is a recurring process that ensures the local federation/ directory and the manifest remain in sync with the live environment.
The cycle validates route health, synchronizes content from external sources (Cubic/GitHub), and registers a cryptographic evidence hash in the MSR (Memory/Security/Reparation) ledger.
Sources: federation/tamv-digital-nexus/supabase/functions/tamv-fusion-core/index.ts:133-165, src/pages/wiki/modulo-cero/FusionWikisExternas.tsx:68-75
Operational Guidelines for Extension
When adding new repositories to the Federation Manifest, developers must adhere to the QC-TAMV-01 Constitutional framework.
- Repository Discovery: Use the
github-repo-scannerto detect new repositories under theOsoPanda1namespace. - Subtree Mapping: Map the repository to a specific directory within
federation/(e.g.,federation/new-service). - Schema Compliance: Ensure the repository includes standard TAMV metadata (e.g.,
node.manifest.jsonor consistent README headers). - Verification: Execute
npm run api:startto verify the manifest generator correctly identifies the new source and calculates its statistics.
Sources: README.md:120-135, src/pages/wiki/implementacion/CicdPipelines.tsx:25-35, src/pages/wiki/ecosistema-codigo/GithubRepos.tsx:45-55
Summary
Extending the Federation Manifest is the primary method for scaling the TAMV ecosystem. By maintaining a centralized, machine-readable registry of all federated codebases and services, the project enables a "many repos, one system" architecture. This manifest allows the MD-X4/MD-X5 kernel to provide unified observability, identity, and governance across a modular and distributed infrastructure.
Sources: README.md:145-150, src/pages/wiki/ecosistema-codigo/ProyectosPrincipales.tsx:25-30