Skip to content

Repository Impact: Anuva Bento Integration

Summary

ANU-8 introduces a new private implementation repository and changes the presentation contract across CMS, Python, and Unity. Product Main owns the product invariants, staged handoffs, harness allowlist, and final acceptance; it does not own Bento, Web, Python, or Unity product implementation.

The first implementation child is deliberately Product Main-scoped because the current Anuva CLI and machine configuration cannot target a repository that does not yet exist. That child creates the durable repository boundary and extends the allowlisted harness. It does not implement the Bento product.

Ownership matrix

Repository Owned scope Explicit non-goals Inputs/dependencies Outputs/contracts Verification
anuva-main-video-creator Product plan and ADR; repository/Linear registry; CLI/config/docs-preview allowlist; staged issue manifest; cross-repository progress and completion Bento, CMS, Python, or Unity product code; arbitrary repository provisioning ANU-8 approval; Shoonya repository/Linear administration permission Registered anuva-bento boundary, approved handoffs, go/no-go and completion evidence Typecheck/tests for harness changes; strict docs/index validation; CLI dry runs; repository and label checks
anuva-bento Private downstream; upstream sync; contract package; schemas/validators; editor/player builds; templates; release artifacts; repository docs CMS persistence/workflows; Python orchestration; Unity host implementation; public Shoonya source Approved bootstrap; upstream Bento tag/SHA; spike approval Exact-version contract/editor/player/template artifacts and compatibility metadata Upstream and downstream builds/tests; offline/network checks; API tests; fixtures; license/notices; sync rehearsal
anuvax-cms PresentationConfig v2; persistence/revisions; multi-surface planning and compilation; authoritative timeline; editor/AI host; Web preview; asset/render packaging Player internals; Unity/Vuplex lifecycle; Python orchestration Stable Bento contract/player/editor artifacts; approved templates Composite presentation and immutable render package; Web editing and preview Lint/typecheck/unit/integration/Playwright; schemas/fixtures; conflict and security tests; Web-visible acceptance
anuva-unity-video-creator Three long-lived Vuplex players; host bridge; external clock; virtual-surface mapping; readiness; seek/reset; capture and performance Slide authoring/persistence; package assembly; Python job control Player artifact/API; CMS v2 fixture/package; timing and asset contract Deterministic three-surface playback and structured failures Compile/import health; Edit/Play Mode tests; seek/replay; transparency/assets; three-WebView profiling; representative capture
anuva-python-server Package receipt/staging; version/checksum validation; Unity invocation; retry identity; structured failure propagation Document transformation; editor/player implementation; virtual-screen behavior Final CMS package layout; Unity runtime expectations Verified immutable job-local package delivered unchanged to Unity Formatting/static/unit/integration; invalid-version/checksum paths; retry/staging tests; Unity handoff smoke
anuva-dev-docs No source changes; optional later canonical aggregate publication Product or implementation source records Explicit manual publication only Aggregate reviewed documentation Publication verification when separately approved

Contract changes

Repository and development-harness contract

Product Main must add anuva-bento to:

  • the canonical repository registry and architecture;
  • the Linear Repository label group;
  • Anuva CLI repository-key schemas and implementation-manifest validation;
  • machine development configuration and safe example configuration;
  • docs port/URL and aggregate-publisher mappings;
  • repository-context, issue, PR, docs, and launcher tests; and
  • the standard AGENTS, skill, prompt, template, and docs-preview workflow installed in the new repository.

The private GitHub repository and Linear label require explicit organization administration. No implementation child may target anuva-bento until both exist and the CLI recognizes them.

Presentation and timeline contract

CMS emits a versioned aggregate containing three surface documents and one ordered timeline. Bento owns the executable schemas and player. Unity consumes the documents/timeline without redefining them. Python stages and validates the package without transforming presentation content.

Stable identities are required for presentation, revision, surface, scene, surface item, slide, element, template family, runtime, and asset. Exact field names are finalized by the spike and downstream contract issue, subject to the Change Brief invariants.

Player host contract

The shared player must expose versioned commands for initialization, document load, state restore, reset, seek/external tick, activation, visibility, clear, fragment/state control, and diagnostics. It must emit ready, assets-ready, state-changed, animation-complete, and structured error events.

Web and Unity adapters may differ, but the renderer behavior and runtime version must not.

Asset and package contract

CMS owns asset resolution and package assembly. A render package records exact contract/runtime versions, immutable identities or checksums, surface documents, timeline, player assets, fonts, and supported media. Python verifies and stages it; Unity reads only the staged package. Expiring URLs and embedded credentials are forbidden in render inputs.

Sequencing and blockers

flowchart TD
    Plan["Approved Product Main plan"]
    Bootstrap["Product Main: register and bootstrap anuva-bento"]
    Spike["anuva-bento feasibility spike"]
    Gate{"Product Main go/no-go"}
    Contract["anuva-bento contract + deterministic player"]
    Editor["anuva-bento editor + templates"]
    CmsV2["CMS PresentationConfig v2 + package"]
    CmsEditor["CMS editor + AI + Web preview"]
    Unity["Unity three-player integration"]
    Python["Python package compatibility"]
    Review["Cross-repository completion review"]

    Plan --> Bootstrap --> Spike --> Gate
    Gate -->|"Go"| Contract
    Gate -->|"Revise or stop"| Plan
    Contract --> Editor
    Contract --> CmsV2
    CmsV2 --> Unity
    Editor --> CmsEditor
    CmsV2 --> CmsEditor
    CmsV2 --> Python
    Unity --> Python
    CmsEditor --> Review
    Unity --> Review
    Python --> Review

The CLI creates the bootstrap child from the initial manifest after the planning PR merges. The bootstrap child then updates the allowlist and expands the same manifest with the approved downstream children. Re-running the idempotent create operation reuses the existing bootstrap child and creates the remaining children.

Although production children may exist in Ready or blocked states, none may start after the spike until Product Main records an explicit “go” decision.

Repository Linear issue drafts

The complete issue bodies, dependencies, docs, verification, and staged manifest rules are in ImplementationIssues.md.

Cross-repository integration verification

  • Build the same representative documents with the contract package and validate them in CMS, Web player, Unity, and package-validation tests.
  • Prove Web preview and Unity report the same exact runtime version and asset identities.
  • Compare representative output across Web and Unity within an approved visual tolerance, including fonts, images, SVG, charts, transparency, fragments, transitions, and deterministic arbitrary seek.
  • Profile three concurrent Vuplex players at approved resolutions and record startup, memory, CPU/GPU, frame-time, and capture evidence.
  • Exercise generation, persistence, revision conflict, AI edits, template reapplication, preview, package assembly, Python staging, Unity playback, retry, capture, and final video delivery.
  • Verify production modes make no calls to Bento update or collaboration services and carry no credentials.
  • Search active code and docs for obsolete Reveal-specific Anuva contracts after cutover and record any intentionally retained Bento-internal Reveal dependency.

Product Main sync and completion

Every child CompletionReport must link its Linear issue, implementation plan/log, merged PR, exact checks, documentation previews, versions, limitations, and Product Main sync requirements.

Product Main will read every child, PR, report, and acceptance criterion; update Progress.md; create CompletionReview.md; record release impact; and request approval for the completion PR. ANU-8 remains In Progress until that PR merges and the guarded anuva linear change complete operation succeeds.