Bootstrap Context: anuva-unity-video-creator

This document is a product-main draft for the implementation repository anuva-unity-video-creator.

Expected destination after repository-owner review:

anuva-unity-video-creator/docs/bootstrap/BootstrapContext.md

It gives Codex agents, engineers, and reviewers enough product context to work inside the Unity repository without relying on chat history. It intentionally does not define implementation details that belong in the Unity repository.

Product Context

Anuva Video Creator is an AI-powered Virtual Studio for generating professional presentation videos from business knowledge, user intent, media, deterministic render configuration, and Unity-based virtual production.

The high-level product flow is:

flowchart LR
    User["User"]
    Web["anuvax-cms"]
    AI["AI Planning / RAG"]
    Config["PresentationConfig"]
    Python["anuva-python-server"]
    Unity["anuva-unity-video-creator"]
    Output["Final Video"]

    User --> Web
    Web --> AI
    AI --> Config
    Config --> Python
    Python --> Unity
    Unity --> Output

anuva-main-video-creator owns product planning, repository coordination, GitHub issue handoffs, progress sync, release readiness, and product docs. Implementation repositories own implementation decisions, code, tests, and local technical documentation.

Repository Role

anuva-unity-video-creator owns the Unity implementation boundary for virtual production and final video generation.

Product-level responsibility:

Virtual production scenes and staged presentation output.
Cameras and shot behavior required by presentation videos.
Bot Presenter behavior inside Unity scenes.
Virtual Screens rendering and playback inside Unity scenes.
Media playback needed for generated presentations.
Unity-side rendering of final video output.
Unity-local documentation, tests, and verification for the above behavior.

The repository should preserve a clear boundary between deterministic render instructions received from upstream systems and Unity-specific execution of those instructions.

This Repository Owns

The Unity repository is the primary owner for:

Capability	Unity-owned product responsibility
Virtual Screens	Stage and render screen content in virtual presentation scenes.
Bot Presenter	Present generated scripts through Unity scene behavior and presenter state.
Cameras	Execute camera framing, movement, shot behavior, and presentation staging.
Playback	Play media and timeline-like presentation events required by render jobs.
Rendering	Produce Unity-rendered video output for downstream delivery.
Brand Sets support	Apply brand presentation rules in Unity when the render contract provides them.

This Repository Supports But Does Not Own

The Unity repository supports these product capabilities, but they are primarily owned elsewhere:

Capability	Primary owner	Unity support boundary
AI-assisted presentation generation	`anuvax-cms`	Consume generated script, structure, and scene intent after they are compiled into render instructions.
RAG and Content Store	`anuvax-cms`	Use resulting presentation assets or media only after upstream selection and preparation.
PresentationConfig compilation	`anuvax-cms`	Consume the deterministic contract; do not own Web-side compilation logic.
Render orchestration	`anuva-python-server`	Execute Unity-side render work when the server starts or coordinates render jobs.
Render queue management	`anuvax-cms`, `anuva-python-server`	Report or expose Unity render state only through agreed server integration points.
Upload and publishing pipeline	`anuva-python-server`, `anuvax-cms`	Produce render output for downstream upload and delivery; do not own product delivery UX.
Product task coordination	`anuva-main-video-creator`	Link PRs, completion reports, verification, and local docs back to product-main issues.

Upstream Integration Points

Expected upstream inputs:

anuvax-cms provides product intent through PresentationConfig generation, script and narration structure, screen content decisions, brand data, and media references.
anuva-python-server owns render orchestration, Unity lifecycle, communication with Unity, render worker coordination, upload pipeline, and monitoring.
anuva-main-video-creator provides product feature context, repository impact analysis, GitHub issue handoffs, acceptance criteria, and release coordination.
anuva-engineering-handbook provides shared engineering standards, process, templates, and Codex workflow guidance.

Any contract change that affects PresentationConfig shape, render job lifecycle, server-to-Unity communication, media inputs, brand inputs, render outputs, or verification expectations should be planned through product-main before implementation work is split across repositories.

Downstream Integration Points

Expected downstream outputs:

Rendered video output consumed by anuva-python-server for upload, delivery, monitoring, and status reporting.
Unity-local logs, diagnostics, or completion signals needed by render orchestration.
PR completion reports that summarize implementation, docs, verification, integration notes, open questions, and follow-ups for product-main.
Unity-local docs that can be surfaced through anuva-dev-docs when publishing is configured.

Expected Local Docs Areas

Repository maintainers should confirm or create Unity-local documentation for:

docs/bootstrap/BootstrapContext.md for repository-specific Codex context.
Unity architecture and scene/runtime ownership.
PresentationConfig or render contract consumption.
Python-server communication and render lifecycle.
Virtual Screens behavior.
Bot Presenter behavior.
Camera and shot behavior.
Media playback behavior.
Brand Sets behavior where Unity has runtime responsibility.
Render verification and troubleshooting.
PR completion report expectations for product-main sync.

If the Unity repository uses a different documentation structure, keep the same content areas but adapt the paths locally.

Verification Expectations

Use Unity-local verification commands and workflows defined by the implementation repository. Product-main currently expects verification to cover these categories:

Unity project compiles without errors.
Relevant edit-mode or play-mode tests pass, if available.
Render workflow can execute the changed behavior locally or in the configured test environment.
PresentationConfig samples or fixtures for changed contracts are validated.
Server-to-Unity integration behavior is checked when render orchestration is affected.
Output video, frames, logs, or completion signals are inspected when rendering behavior changes.
Docs build or docs lint passes when Unity-local docs are changed.

When verification cannot be run, the PR completion report should explain what was skipped, why it was skipped, and what evidence remains.

GitHub Issue Expectations

Implementation work should start from a repository-scoped GitHub issue created or linked by anuva-main-video-creator.

Each Unity issue should include:

Product Feature ID.
Product change folder in anuva-main-video-creator.
Repository scope for anuva-unity-video-creator.
Explicit non-goals for Web, Python server, and product-main work.
Acceptance criteria.
Docs impact.
Verification expectations.
Product-main sync requirements.

Codex chat is not the durable record for cross-repository execution state. GitHub issues, project fields, PR completion reports, implementation docs, and product-main progress docs are the durable records.

PR Completion Expectations

Unity PRs that implement product work should include a completion report with:

Product Feature ID:
Product Change Folder:
GitHub Issue:
Repository:

Implementation Summary:

Docs Updated:

Verification Run:

Verification Skipped:

Integration Notes for anuva-main-video-creator:

Open Questions:

Follow-ups:

The PR should link the product-main issue or change folder and identify whether the work affects:

PresentationConfig expectations.
Server-to-Unity communication.
Render lifecycle or output.
Virtual Screens.
Bot Presenter.
Cameras or shots.
Brand behavior.
Local or published docs.

Product-Main Sync Requirements

After Unity work is implemented, keep product-main aligned by updating or reporting:

GitHub issue status and PR link.
Anuva Video Creator GitHub Project fields.
Verification state.
Docs impact.
Integration notes and product risks.
Any product-level acceptance criteria that changed.
Any required updates to Product Architecture, Product Capability Map, Product Repository Registry, product playbooks, or release notes.

When Unity work changes repository responsibility, capability ownership, or cross-repository contracts, anuva-main-video-creator should update its product docs in the same product change.

Docs Publishing Impact

anuva-dev-docs is the aggregated development docs publisher. When Unity-local docs change, the implementation PR or product-main progress note should state whether publishing refresh is required.

Expected docs impact values:

None: no docs changed and no publishing action needed.
Local: Unity-local docs changed.
Product: product-main docs or release notes changed.
Handbook: shared process, template, skill, or ownership guidance changed.
Publisher: aggregated docs output or publishing configuration needs refresh.

The publisher owns generated static output. Source docs remain in their owning repositories.

Open Questions For Unity Maintainers

What is the canonical Unity-local docs folder structure?
What commands should Codex run for compile, edit-mode tests, play-mode tests, and render smoke tests?
What sample PresentationConfig fixtures are safe and representative for local verification?
What is the canonical server-to-Unity communication entry point for render jobs?
What artifacts should be attached or summarized in PR completion reports for render changes?
Which Unity logs or diagnostics are expected by anuva-python-server?
How should failed render attempts be represented for orchestration and product progress reporting?
Which docs are currently published through anuva-dev-docs, and what refresh process should Unity PRs trigger?