Skip to content

Remove V1 Upgrade Collections Change Breakdown

Created: 2026-05-19 13:34 UTC

Summary

Remove the Anuva V1 upgrade Payload collections from the active data model. The current upgrade API, CLI, and worker paths already store equivalent runtime state in the in-memory AnuvaRepository; if those paths need durable persistence later, they should use a repository-backed durable store instead of Payload collections created for the earlier V1 upgrade scaffolding.

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 the implementation plan.

Target Dependency Shape

flowchart TD
  api["Upgrade API route or caller"] --> service["Anuva orchestration service"]
  cli["scripts/anuva-cli.ts"] --> service
  worker["scripts/anuva-worker.ts"] --> service
  service --> repository["AnuvaRepository"]
  repository --> memory["Current in-memory store"]
  repository -. future option .-> durable["Future durable repository adapter"]

  payloadRegistry["Payload collection registry"] --> appCollections["App and CMS collections"]
  legacyV1["V1 upgrade collections"]:::remove
  payloadRegistry -. remove .-> legacyV1

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

Current Touchpoints

  • src/collections/anuvax/anuva-v1.ts defines the V1 upgrade collections.
  • src/collections/anuvax/index.ts imports AnuvaV1Collections and spreads them into the active Payload collection registry.
  • src/payload-types.ts contains generated collection keys, interfaces, relationship block variants, and select types for the V1 upgrade collections.
  • Current docs list the collections in docs/core/PayloadDataModel.md, docs/state/CollectionMap.md, docs/core/WorkersAndJobs.md, and docs/state/WorkflowMap.md.
  • Upgrade runtime state is handled through src/lib/anuva/repository.ts and consumed by src/lib/anuva/orchestration-service.ts, src/lib/anuva/source-adapters.ts, src/lib/anuva/retrieval.ts, src/lib/anuva/idempotency.ts, scripts/anuva-cli.ts, and scripts/anuva-worker.ts.

The active V1 collection slugs are:

  • conversation_states_v1
  • workflow_runs_v1
  • workflow_stage_gates_v1
  • source_documents_v1
  • scene_edit_history_v1
  • quality_metrics_v1
  • rss_feed_configs_v1
  • rss_ingest_runs_v1
  • rss_entries_v1

Grouped Changes

1. Payload registry cleanup

Remove the V1 upgrade collection definitions from the active Payload schema.

Likely work:

  • Remove AnuvaV1Collections from src/collections/anuvax/index.ts.
  • Delete or retire src/collections/anuvax/anuva-v1.ts once no active imports remain.
  • Confirm no payload.config.ts plugin or admin import map entry depends on those collection exports.

Explanation:

The collection definitions currently make these scaffolding entities part of the live admin/API schema. Removing them from the registry is the core product behavior change: Payload should no longer expose or manage this V1 upgrade state.

Likely affected code:

  • src/collections/anuvax/index.ts
  • src/collections/anuvax/anuva-v1.ts
  • src/payload.config.ts

2. Generated Payload type cleanup

Regenerate generated types after removing the collections.

Likely work:

  • Run pnpm generate:types after schema removal.
  • Verify src/payload-types.ts no longer includes V1 collection entries, interfaces, relationship variants, or select types.
  • Run pnpm generate:importmap only if the removal affects admin component registrations.

Explanation:

Payload collection removal is not complete until generated types reflect the active schema. Stale generated collection keys can hide dead references and make future code appear valid when the collection no longer exists.

Likely affected code:

  • src/payload-types.ts
  • src/app/(payload)/admin/importMap.js only if Payload reports import map changes.

3. Runtime reference verification

Confirm the API, CLI, and worker path does not rely on Payload V1 collections for persistence.

Likely work:

  • Search for all V1 collection slugs and exported collection names outside src/collections/anuvax/anuva-v1.ts and generated types.
  • Verify src/lib/anuva/orchestration-service.ts persists run, artifact, quality, source, and conversation state through AnuvaRepository.
  • Verify scripts/anuva-cli.ts and scripts/anuva-worker.ts use the orchestration/repository path rather than Payload collection CRUD for V1 state.
  • Update any tests that import or assert V1 collection availability.

Explanation:

The stated reason for removal depends on the repository already holding equivalent state. The implementation plan should prove this with code inspection before deleting schema.

Likely affected code:

  • src/lib/anuva/repository.ts
  • src/lib/anuva/orchestration-service.ts
  • src/lib/anuva/source-adapters.ts
  • src/lib/anuva/retrieval.ts
  • src/lib/anuva/idempotency.ts
  • scripts/anuva-cli.ts
  • scripts/anuva-worker.ts
  • tests/unit/anuva-orchestration-service.test.ts
  • tests/unit/anuva-source-adapters.test.ts

4. Database and deployment handling

Decide how to handle existing database tables or migration metadata for the removed collections.

Likely work:

  • Inspect current Payload migration conventions in this repo before choosing a migration strategy.
  • Decide whether to add an explicit migration that drops the V1 tables or only remove them from the active schema.
  • Check hosted database data-retention expectations before destructive table drops.
  • Confirm whether any production or staging environment has records in the V1 tables.

Explanation:

Removing a collection from Payload registration stops future schema/API exposure, but it may not automatically drop existing physical tables. Dropping tables is more destructive and should be planned only after confirming no retained data is needed.

Likely affected code:

  • src/migrations/**
  • src/migrations/index.ts
  • Deployment runbook or environment notes if a manual database cleanup is chosen.

5. Documentation parity

Update current docs so they no longer present V1 upgrade collections as active state.

Likely work:

  • Update docs/core/PayloadDataModel.md to remove the V1 upgrade collection section and clarify repository-owned upgrade state.
  • Update docs/state/CollectionMap.md to remove the V1 collection list.
  • Update docs/core/WorkersAndJobs.md where it names workflow_runs_v1 and workflow_stage_gates_v1.
  • Update docs/state/WorkflowMap.md where it references V1 workflow collections.
  • Update docs/state/KnownGaps.md if it lists V1 collections as an active implemented gap.

Explanation:

The docs are used as source-of-truth orientation for the upgrade. Leaving V1 collections in current docs after schema removal would mislead future work back toward Payload-backed V1 state.

Likely affected docs:

  • docs/core/PayloadDataModel.md
  • docs/state/CollectionMap.md
  • docs/core/WorkersAndJobs.md
  • docs/state/WorkflowMap.md
  • docs/state/KnownGaps.md

6. Tests and verification

Verify schema removal and repository-backed upgrade behavior.

Likely work:

  • Run pnpm typecheck after generated type cleanup.
  • Run pnpm lint for formatting/import cleanup.
  • Run pnpm test:int if any presentation or Payload action behavior is touched.
  • Run targeted unit tests for Anuva repository/orchestration behavior, likely tests/unit/anuva-orchestration-service.test.ts and tests/unit/anuva-source-adapters.test.ts.
  • Add a focused test only if existing tests do not cover the repository path named in the removal rationale.

Explanation:

The risk is less about UI behavior and more about hidden type/schema references and runtime state assumptions. Verification should prove both the schema is clean and the repository path still works.

Affected Product Surfaces

  • Payload admin collection list and Payload REST/GraphQL APIs for the removed slugs.
  • Upgrade API/CLI/worker state handling, through verification rather than expected behavior change.
  • Developer docs and generated Payload types.
  • Deployment/migration posture for hosted database environments.

Risks

  • Existing hosted database records in V1 tables may be lost if the implementation drops tables instead of only unregistering collections.
  • Payload generated types may have broad references to removed collection slugs, causing type errors in unrelated-looking files.
  • A hidden script, diagnostic, or test may still assume the V1 collections exist.
  • Removing admin-visible collections can affect operators who were using them for inspection, even if runtime no longer depends on them.
  • Future durable persistence still needs a clear repository adapter direction; removing Payload collections should not imply durable repository persistence already exists.

Out Of Scope

  • Implementing a new durable AnuvaRepository backend.
  • Migrating V1 collection data into a new durable repository store.
  • Redesigning Anuva contracts, stage gates, source adapters, or workflow state models.
  • Removing the in-memory AnuvaRepository.
  • Changing current Presentation Video generation UX or Mastra workflow behavior.
  • Dropping production database tables without an explicit data-retention decision.

Open Questions

Q1. Should implementation drop existing V1 database tables, or only unregister the collections from Payload?

Answer: Drop existing V1 database tables

Q2. Is any V1 collection data in hosted environments worth exporting before removal?

Answer: No

Q3. Should src/collections/anuvax/anuva-v1.ts be deleted outright, or moved to stale/reference docs for historical context?

Answer: Deleted outright

Q4. Should the implementation add a repository adapter interface now, or defer durable storage abstraction until a future persistence change?

Answer: Defer durable storage abstraction until a future persistence change but make a clear note of this in the Known Gaps doc (docs/state/KnownGaps.md)

Q5. Are Payload admin users relying on the V1 collections for debugging current upgrade runs?

Answer: No