Chaim
8e2cfd602c
When a chair's signed final decision is uploaded it is enrolled into the precedent library, but _enroll_final_in_library only set deterministic fields (citation, proceeding_type, date) and copied subject_tags from the case's subject_categories — which is usually empty. The Gemini metadata pass (subject_tags / summary / headnote / key_quote) was never triggered, so the row sat at metadata_extraction_status='pending' with no subject tags until a drain happened to pick it up. In practice a freshly-enrolled final showed an empty "תגיות נושא" in the precedent edit UI. Fix: after enrollment + citation, call the existing reextract_metadata path inline (G2 — one path, full status lifecycle). It runs on Gemini Flash over REST (GOOGLE_GEMINI_API_KEY, already in Coolify), so it is container-safe — unlike the halacha path (claude CLI, host-only). apply_to_record fills only empty fields, so the deterministic seeds and any chair-curated subject_categories are preserved. Result surfaced in the upload response (out["metadata"]); failures logged, upload still succeeds. Also corrects two now-stale comments: the "Gemini returns no_metadata for internal decisions" note in the enroll loop, and the "MCP-tool-only path" docstring on reextract_metadata (true for halacha, not for Gemini REST). Invariants: G1 (fill at source on enroll, not a read-time workaround), G2 (reuse reextract_metadata — no parallel extraction path). LLM call is Gemini REST, not claude_session, so the container LLM-call constraint holds. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>