[kvlonge]

Why

Renaming or moving a model or column by hand means editing refs, fixtures, headers, YAML and schemas, then adding migrate_from so warehouse data follows. sqb rename and sqb mv do it as one verified, all-or-nothing edit (CHI-392).

Changes

• sqb rename model:<old> <new>, sqb mv <model> <path>, sqb rename column:<model>.<col> <new> [--cascade]: rewrite every reference (SQL, tests, fixtures, headers, source/seed YAML, relationships, reusable schemas), compile the edited copy, then write. Refuse and change nothing when an edit is not mechanical. --dry-run, --json.
• Always add migrate_from for tables, views, incrementals and snapshots.
• --cascade renames through pass-through models; only the first set-operation branch names outputs.
• sqb mv moves scoped macros, enums, constants, schemas, audits and hooks to where the placement rules require; never duplicates.
• New target policy missing_migration_origin = allow | require_confirmation | deny (default allow: warning, build fresh), also on sqb dbt run/build. An origin built in this target but no longer visible stays an M102 error.
• The janitor keeps the origin of a pending migrate_from until the target has migrated it.
• sqb dbt run/build now read project/target config (previously built-in defaults), so settings such as retention-decrease policy, defer_sources_to, cursor and microbatch limits, old_name_views and BigQuery managed-retention planning now apply there too.
• Native column-reference analysis with rename spans.
• Docs, skill and plan hints.

Verification

• Unit, Rust and DuckDB E2E coverage for renames, moves, cascade (incl. set operations), declaration moves, refusals, reference rewriting, and the policy on build and dbt paths, janitor pending origins.
• make test (8289 passed), make check-ci.
• One independent review and a follow-up on its fixes.