Skip to content

migration lens

Tribunal lens card. This is not a standalone agent: when the /ca:tribunal deep audit activates the migration lens, the generic tribunal-lens-reviewer agent is dispatched once under the migration assignment and executes this card as its mandate.

For every security policy reference below, follow the installed plugin’s includes/knowledge.md (“Read security policy before a security decision”): select the repository’s context format, read the complete policy from exact CTX-SECURITY-CONTROLS records in HTML mode or the full Markdown controls in Markdown mode, and read operative scope blocks when applicable. Required policy that is missing or unreadable blocks a security decision; scope blocks alone are not full policy.

Executed by tribunal-lens-reviewer under the migration assignment.

Find schema/data transitions that violate compatibility, integrity, availability or recovery obligations under the repository’s declared deployment model.

Assigned changes migrate persisted data/schema or alter how deployed versions read and write it.

No persisted transition or affected rollout contract. When the deploy model is unknown, preserve that uncertainty instead of assuming a reversible rollout.

Migration order, schema and query consumers, backfills, deployment windows and recovery procedures for the affected data.

  • Finding record (the installed plugin’s skills/tribunal/references/finding-record.md) and review risk (the installed plugin’s skills/tribunal/references/review-risk.md).
  • the repository’s .codearbiter/tech-stack.md — declared migration/deploy model, schema tools and version overlap; the repository’s .codearbiter/security-controls.md for relevant data classification and recovery obligations.

Inspect migration history/order, schema diffs, deployed-version compatibility matrices, query references and available table-size/lock evidence. Read recovery and rollout checks as evidence; do not apply or roll back migrations.

  • Does expand/contract ordering preserve mixed-version readers and writers?
  • Can a backfill lose, duplicate or misclassify data, or fail partway irrecoverably?
  • Do NOT NULL, renames, drops and index operations respect actual data and locks?
  • Is destructive or irreversible work guarded by the required recovery evidence?
  • Does editing a previously applied migration create divergent environments?

A declared forward-only model may use a corrective migration and verified restore procedure; a down migration is not universally required. A disposable schema or exclusive downtime window may have different obligations from a rolling deploy. Do not invent annotation or immutability requirements absent the actual contract.

Cite the deployment model, affected data/version window, operation order and concrete compatibility, locking or recovery failure. For an absent backfill or recovery path, state the search universe across migrations, deployment orchestration and recovery owners. Bound scale claims with available size/lock evidence.

Count of persisted transitions checked with their application-version and recovery windows, not only migration-file count.

Route rollout wiring to infra/change-closure, application authorization to appsec and secret exposure to secrets-supply. Keep missing recovery proof distinct from a demonstrated unrecoverable transition.

Applying migrations, universal rollback policy, and unrelated application-level data handling outside the assigned transition.