24 lines
1.5 KiB
Markdown
24 lines
1.5 KiB
Markdown
# Promotion Plans
|
|
|
|
Approval establishes permission to propose a change. It does not activate anything.
|
|
|
|
`LifecyclePromotionPlan` binds the approval and subject to the exact candidate, desired state,
|
|
rollback target, project consumers, affected embedding/pipeline/runtime/storage identities,
|
|
migration class, canary/drain strategy, health gates and abort conditions. Its impact projection
|
|
lists projects, clients, indexes, retrieval pipelines, runtime deployments, artifacts and scheduler
|
|
envelope. Approval freezes these fields; changed intent requires a new plan.
|
|
|
|
The supported classes are `transparent`, `behavioral`, `requires_reindex` and `schema_breaking`.
|
|
Behavioral changes require evaluation/canary evidence. `requires_reindex` requires a ready isolated
|
|
migration and shadow/dual-read/evaluation-only route; M12 records but does not automatically execute
|
|
the cutover. Schema-breaking plans require a manual runbook and are likewise not auto-executed.
|
|
|
|
Execution creates a `LifecycleOperation` journal and immutable rollback snapshot transactionally.
|
|
Stages are `PREPARING`, `ACTIVATING`, `VERIFYING`, `COMMITTED`, `ROLLING_BACK`, `ROLLED_BACK` and
|
|
`FAILED`. Requester, approver and executor are stored separately. A repeated idempotency key returns
|
|
the original operation.
|
|
|
|
For M13 production reindex, the migration plan references this exact approved promotion plan and
|
|
approval fingerprint. M12 still refuses to execute reindex as a direct deployment swap; the typed
|
|
migration cutover journal is the only supported execution path.
|