# Deprecation Plan

This document defines the deprecation path from the original `videoclaw` (v0.11.x)
and the intermediate `vclaw-video-core` rebuild to **`videoclaw-v3`** — the
merged successor (npm package: `videoclaw`).

## Goal

Make `videoclaw-v3` the primary execution surface without pretending the
predecessor repos never existed.

## Current decision

Primary:

1. `videoclaw-v3` (npm: `videoclaw`)

Reference/fallback only:

1. `videoclaw` v0.11.x (the original repo) — legacy reference / migration source
2. `vclaw-video-core` — intermediate clean-room rebuild whose foundation was merged into videoclaw-v3

## Deprecation boundaries

What should stop growing in the old repo:

1. new user-facing workflow surfaces
2. new canonical artifact contracts
3. new reporting layers
4. new migration-target state models

What can still be consulted in the old repo:

1. legacy scripts
2. older provider behaviors
3. reference patterns not yet ported

## Cutover criteria

The clean repo is considered the primary product surface once these are true:

1. provider status works
2. produce / execute-status works
3. clone-execute works
4. template and prompt-library surfaces exist
5. migration docs exist
6. core tests are green

Those conditions are now satisfied.

## Remaining non-blocking work

1. richer provider-specific options
2. better automatic prompt guidance during execution
3. operator education and release communication

## Operational policy

When a user asks to create or run video work:

1. prefer `videoclaw-v3` (`vclaw` CLI)
2. fall back to the legacy `videoclaw` v0.11.x runtime only when the missing feature is clearly identified
3. track every such fallback as a porting task

## Suggested release language

Use this internal framing:

1. `videoclaw-v3` (npm: `videoclaw`) is now the recommended runtime
2. `videoclaw` v0.11.x and `vclaw-video-core` remain available as migration/reference sources
3. old workflows should not be expanded further unless they are being ported

## Sunset rule

Do not archive or delete the old repo until:

1. migration of active operators is complete
2. no critical workflow depends exclusively on the old runtime
3. the clean repo has been stable through multiple real runs