Skip to content

Remove Asset Slots Change Breakdown

Created: 2026-05-19 07:25 UTC

Summary

The Asset Slot system should be removed from the Presentation Video creation and editing experience. Asset Slots were used by the older Visual Matching model to map uploaded or sourced media to generated scenes. The new direction is different: scene generation should create image-generation prompts and generated images directly, and users can replace generated images with uploaded media in the Scene Editor when needed.

This breakdown does not implement the change. It identifies the likely work, affected surfaces, risks, out-of-scope items, and questions to resolve before creating an implementation plan.

Target Flow

flowchart TD
  setup["Presentation setup"] --> workflow["Presentation scene workflow"]
  workflow --> scenes["Scenes with image-generation prompts"]
  scenes --> imageGen["Image Gen model"]
  imageGen --> generatedImages["Generated scene images"]
  generatedImages --> editor["Scene Editor"]
  upload["User-uploaded image"] --> editor
  editor --> finalVisual["Scene visual"]

  assetSlots["Asset Slot definitions"]:::legacy
  visualMatching["Visual Matching"]:::legacy
  slotUx["Scene slot UX"]:::legacy
  slotAwareGen["Slot-aware visual generation"]:::legacy

  assetSlots -. remove .-> visualMatching
  visualMatching -. remove .-> finalVisual
  slotUx -. remove .-> setup
  slotAwareGen -. remove .-> imageGen

  classDef legacy fill:#f7d7d7,stroke:#a33,color:#111

Current Touchpoints

The codebase still contains Asset Slot and Visual Matching structures even though newer workflow guidance says semantic visual matching is disabled.

  • src/app/(frontend)/app/presentation/actions.ts loads asset_slot_definitions, builds scene slot lists for prompt input, embeds sceneSlot, evaluates visual matching candidates, and queues AI image generation with slot metadata.
  • src/components/anuvax/presentation-video/presentation-video-page.tsx keeps Asset Slot state and derives slot buckets, scene slots, scene slot progress, and AI generation toggles.
  • src/collections/anuvax/index.ts includes media fields such as slotCategory, assetQuery, assetQueryEmbedding, and assetSlotEmbedding, and scene fields such as sceneQueryEmbedding and sceneSlotEmbedding.
  • src/payload-types.ts contains generated types for the slot and visual matching fields.
  • scripts/seed.ts seeds Asset Slot definitions.
  • scripts/visual-matching-report.ts reports on Visual Matching runs.
  • src/mastra/tools/presentation/prompt-builders.ts still includes available scene slot prompt text.
  • src/mastra/agents/presentationvideo-agent-contracts.ts and src/mastra/workflows/sub/narrative.workflow.ts mention disabled visual matching or asset lookup.
  • docs/core/PayloadDataModel.md documents asset_slot_definitions and slot_affinity_tables as generation taxonomy and visual matching support data.

Grouped Changes

1. Presentation setup and Scene slot UX removal

Remove the user-facing Scene slot experience from the presentation setup and scene editing surfaces.

Likely work:

  • Remove Asset Slot loading state, errors, derived slot buckets, scene slot views, and scene slot progress from src/components/anuvax/presentation-video/presentation-video-page.tsx.
  • Remove any UI controls that let users configure slot-aware AI image generation.
  • Keep the simpler visual workflow: optional uploaded visuals as reference/source material, generated initial images, and Scene Editor replacement.
  • Preserve existing Scene Editor upload and visual override behavior where it is not slot-dependent.

Explanation:

The user should not need to reason about slots when the new workflow generates scene images directly. Uploaded media should be a manual replacement path, not an input to a slot matching system.

Likely affected code:

  • src/components/anuvax/presentation-video/presentation-video-page.tsx
  • src/app/(frontend)/app/create/presentation/page.tsx
  • Scene Editor components if visual replacement controls are split out from the main page file.

2. Slot-aware prompt and scene contract cleanup

Remove scene slot fields from prompt construction and generation outputs where they only exist to support Visual Matching.

Likely work:

  • Remove sceneSlotList input from presentation voiceover and scene prompt builders.
  • Stop asking agents or prompt builders to produce scene_slot.
  • Stop persisting sceneSlot and sceneSlotEmbedding during scene creation if those fields are removed from the model.
  • Keep sceneQuery only if it is still needed for non-matching search, diagnostics, or future retrieval behavior; otherwise plan its removal separately.

Explanation:

The new workflow needs image-generation prompts, not slot labels. Keeping slot requirements in prompts creates confusing output obligations and can lead future code back toward Visual Matching.

Likely affected code:

  • src/app/(frontend)/app/presentation/actions.ts
  • src/mastra/tools/presentation/prompt-builders.ts
  • src/mastra/agents/presentationvideo-agent-contracts.ts
  • src/mastra/workflows/presentationvideo.workflow.ts
  • src/mastra/workflows/sub/*.workflow.ts
  • src/lib/presentation-config/**
  • src/lib/anuva/contracts-v1.ts

3. Visual Matching removal from generation actions

Remove deterministic Visual Matching candidate scoring and scene-to-asset assignment from presentation generation.

Likely work:

  • Remove or bypass candidate construction, embedding, scoring, thresholding, assignment, and Visual Matching trace generation from src/app/(frontend)/app/presentation/actions.ts.
  • Remove args.slotGenerateAi style generation switches if they only exist for slot fallback behavior.
  • Make generated images the default path for image scenes when generation runs.
  • Keep explicit user overrides for uploaded images after generation.
  • Ensure text-only scenes still skip image generation cleanly.

Explanation:

The stated target says no Visual Matching is being performed. Scene images should come from the Image Gen model during scene generation, with manual replacement later.

Likely affected code:

  • src/app/(frontend)/app/presentation/actions.ts
  • src/lib/rag/** only where RAG media candidate helpers exist solely for visual matching.
  • scripts/visual-matching-report.ts
  • Tests around presentation generation and visual assignment.

4. Image generation as the primary scene visual path

Make image generation the primary source of initial scene visuals.

Likely work:

  • Confirm where current image generation is queued and executed for scenes.
  • Ensure each generated scene has a usable visualGenerationPrompt or equivalent image model input.
  • Remove slot metadata from queued compilerIssues.visualGeneration or generation-job payloads.
  • Keep status/error persistence explicit when image generation fails.
  • Preserve manual user replacement from Scene Editor as a separate operation.

Explanation:

This change is not just deletion. The old fallback relationship should invert: Image Gen becomes the expected path, and uploaded visuals become a user-directed replacement path.

Likely affected code:

  • src/app/(frontend)/app/presentation/actions.ts
  • scripts/presentation-worker.ts
  • src/mastra/tools/media/**
  • src/mastra/tools/presentation/**
  • src/lib/video-config/**
  • src/lib/presentation-config/**

5. Payload schema and generated type cleanup

Decide whether Asset Slot and Visual Matching fields should be removed from Payload schema in this same change.

Likely work if fully removed:

  • Remove asset_slot_definitions and slot_affinity_tables collection registrations.
  • Remove seeded Asset Slot definitions from scripts/seed.ts.
  • Remove media fields used only by slot matching, such as slotCategory, assetSlotEmbedding, and possibly assetQuery fields if no other retrieval path uses them.
  • Remove scene fields used only by Visual Matching, such as sceneSlotEmbedding, and possibly sceneSlot.
  • Add or update migrations for removed collections/columns as appropriate.
  • Regenerate src/payload-types.ts and Payload import map.

Likely work if staged:

  • Remove runtime and UX dependencies first.
  • Mark the schema fields and collections as legacy/unused in docs.
  • Plan a follow-up schema cleanup once data retention and migration expectations are explicit.

Explanation:

Runtime removal can be done without immediately dropping database structures. Schema removal has a larger blast radius because this workspace uses hosted services, generated types, migrations, seeds, and admin UI collection registrations.

Likely affected code:

  • src/collections/anuvax/index.ts
  • src/payload.config.ts
  • src/payload-types.ts
  • src/migrations/*
  • src/migrations/index.ts
  • scripts/seed.ts

6. Diagnostics, scripts, and stale support code

Remove scripts and reporting paths that only exist for Visual Matching.

Likely work:

  • Delete or retire scripts/visual-matching-report.ts if it has no non-slot use.
  • Remove package scripts that call visual matching diagnostics, if any.
  • Remove helper functions and constants used only by visual matching scoring.
  • Update tests that assert disabled visual matching behavior so they assert the new image-generation-first behavior instead.

Explanation:

Keeping diagnostics for a removed system makes the repo harder to understand and encourages accidental reintroduction.

Likely affected code:

  • scripts/visual-matching-report.ts
  • package.json
  • tests/unit/anuva-contracts.test.ts
  • tests/integration/**

7. Documentation parity

Update current docs to describe generated scene images and manual Scene Editor replacement instead of Asset Slots and Visual Matching.

Likely work:

  • Update docs/core/PresentationVideoWorkflow.md to show Image Gen as the initial scene visual path.
  • Update docs/core/PayloadDataModel.md and docs/state/CollectionMap.md to remove or mark Asset Slot collections and fields according to the schema decision.
  • Update docs/state/CurrentImplementationMap.md, docs/state/ServerActionsMap.md, and docs/state/WorkflowMap.md if runtime paths change.
  • Update docs/state/KnownGaps.md if it references Visual Matching or slot cleanup.

Explanation:

The docs currently serve as project orientation for the upgrade. They should make it clear that Asset Slots are not part of the target workflow.

Affected Product Surfaces

  • Presentation setup Visuals panel.
  • Scene Editor visual replacement flow.
  • Presentation scene generation and preview compilation.
  • Background image generation jobs and worker behavior.
  • Payload admin only if collections or fields are removed from schema.
  • Developer diagnostics around Visual Matching reports.

Likely Affected Tests

  • Integration tests under tests/integration that exercise presentation actions and generation flows.
  • Unit tests around Anuva contracts and prompt output behavior.
  • E2E presentation workflow tests if UI panels, visual generation, or Scene Editor replacement behavior changes.
  • Generated type checks after schema cleanup.

Expected verification during implementation:

  • pnpm lint
  • pnpm typecheck
  • pnpm test:int
  • pnpm test:e2e if route-level presentation behavior changes
  • pnpm generate:types and pnpm generate:importmap if Payload schema or admin registrations change

Likely Docs Impact

  • docs/core/PresentationVideoWorkflow.md
  • docs/core/MastraAgentsAndTools.md
  • docs/core/PayloadDataModel.md
  • docs/state/CollectionMap.md
  • docs/state/CurrentImplementationMap.md
  • docs/state/ServerActionsMap.md
  • docs/state/WorkflowMap.md
  • docs/state/KnownGaps.md

Risks

  • Removing slot-aware logic may break generation paths that still rely on sceneSlot, sceneSlotEmbedding, or slotGenerateAi even though Visual Matching is conceptually disabled.
  • Removing schema fields requires careful migration planning and may affect existing hosted database data.
  • Image generation must be reliably queued or executed for every non-text scene, or the user may see scenes without visuals.
  • Uploaded visual replacement must remain ergonomic after removing slot grouping and recommended slot hints.
  • RAG media metadata such as assetQuery may still have value outside Visual Matching; deleting it prematurely could harm future retrieval or diagnostics.
  • Generated src/payload-types.ts changes can create broad compile churn if schema cleanup is too aggressive.

Dependencies

  • Current Mastra APIs and model/provider names should be verified with the repo-local Mastra skill before implementation touches workflows, tools, or model calls.
  • Payload schema removal depends on deciding whether this change includes database migrations or only runtime/UX cleanup.
  • Image generation behavior depends on the current worker/job contract and available Image Gen provider configuration.

Out Of Scope

  • Replacing the Scene Editor upload/replacement workflow.
  • Introducing a new visual search, media recommendation, or asset ranking system.
  • Migrating old presentation records into a new schema unless explicitly required.
  • Changing billing, credit consumption, or subscription behavior for image generation unless the implementation discovers a direct dependency.
  • Reworking RAG ingestion except where visual matching metadata is proven to be slot-only.
  • Redesigning the full Presentation Video workflow beyond removing Asset Slots and Visual Matching.

Questions

Q1. Should Payload schema remove Asset Slot collections and fields in this same change?

Answer: Yes, remove Asset Slot collections and fields in this same change

Q2. Should existing sceneSlot and sceneSlotEmbedding data be migrated, ignored, or dropped without compatibility handling?

Answer: It should be dropped without compatibility handling

Q3. Should assetQuery and assetQueryEmbedding stay for possible non-slot retrieval/debug use, or are they part of Visual Matching cleanup?

Answer: Keep assetQuery and assetQueryEmbedding for possible non-slot retrieval

Q4. Should Image Gen run immediately during scene generation, or should scene generation persist prompts and let the worker create images asynchronously?

Answer: Scene generation should persist prompts and let the worker create images asynchronously

Q5. Should existing visual-matching diagnostic scripts be deleted outright, or moved under stale/reference docs for historical debugging?

Answer: Delete them outright