Phase 3 Slice 2 Step B-2. UPDATE paliad.deadline_rules.priority
from the legacy (is_mandatory, is_optional) pair per DESIGN §2.3
(NOT msg 1746's inverted mapping — head clarified in msg 1750
that design §2.3 is the load-bearing spec).
Mapping:
T/F (153 rows) → 'mandatory' (statutory must, ☑ pre-checked)
T/T ( 1 row) → 'optional' (RoP.151 — opt-in deadline,
☐ pre-unchecked per mig 068)
F/T ( 0 rows) → 'recommended' (defensive; no live data)
F/F ( 18 rows) → 'recommended' (situational filings —
Berufungserwiderung, Replik,
Duplik, R.19 Preliminary
Objection, R.116 EPÜ, etc.)
Why NOT msg 1746's mapping:
- T/T → 'recommended' would PRE-CHECK RoP.151 in the save modal
and auto-create a Kostenentscheidung deadline the user didn't
ask for. That's the regression we'd ship.
- F/F → 'informational' would render 18 real filing deadlines
NEVER-SAVEABLE per design §2.3 ("informational … NEVER saves
as a deadline"). They'd disappear from save flows entirely.
T/F branch is intentionally skipped — mig 078 already defaults
priority='mandatory', so all 153 T/F rows are already correct.
Writing 153 needless audit rows would dilute the backfill trail.
Audit-reason cites design §2.3 — that's the persistent rationale
captured in paliad.deadline_rule_audit. Migration enforces NOT NULL
post-run via a DO block that RAISE EXCEPTION on stragglers.
