[dnplkndll]

post-migration.py

Say which versions classified the person in a way 20.0 cannot hold.

19.0 had two fields: contract_type_id, which pre-migration renames to
employee_type_id because that is what 20.0 kept, and employee_type, a
required selection of Employee, Worker, Student, Trainee, Contractor and
Freelancer with Employee as its default.

The selection is not mapped onto an hr.employee.type. They classify
different things -- what the person is against what the contract is -- and
the records to map onto are 19.0's own contract types, so writing Student
into a version that never had a contract type would invent configuration
rather than carry it. Only the values someone chose are worth a line: the
default says nothing, and every version on the seed is on it.

---

CI: red until #118 lands

The test job fails on duplicate key value violates unique constraint "res_country_state_name_code_uniq" (Ladakh / Odisha). Not this branch:
base's pre-migration, which renames those two external ids, lives in #118 and
is not on 20.0 yet, so every branch cut from 20.0 alone hits it. Per the
fork's model the per-PR check is the lean one; the real migration gate is the
integration branch (#120), where all of this runs green over the full
585-module seed.

AI-assisted (Claude Code); every change reviewed, tested, and owned by the author.