ezer-mishpati/legal-ai
1
0
Fork 0
Code Issues 29 Pull Requests 1 Actions 1 Packages Projects Releases Wiki Activity

קטלוג עלון חודשי "עו"ד על נדל"ן" — פיצול ל-N רשומות digest (design-open) #436

New Issue
Open
opened 2026-08-05 11:01:11 +00:00 by chaim · 0 comments
chaim commented 2026-08-05 11:01:11 +00:00
Owner
Copy Link

What & Why

תכנון + מימוש פיצול העלון החודשי הרב-נושאי "עו"ד על נדל"ן" (פרסום נפרד מהיומונים היומיים "כל יום") ל-N רשומות digest שניתן לקטלג/לקשר. הוצא מ-#104.9 שבו מסלול ה-Gmail היומי כבר חי; חלק זה מוצהר design-open בקוד.

הקשר ופירוט

מצב נוכחי: /api/bulletins/upload (web/app.py:6774) הוא staging-only — שומר PDFים ל-data/bulletins/incoming עם dedup לפי hash, ללא DB. הערת-מחבר מפורשת (web/app.py:6766-6770): "their catalog/processing is not designed yet — download the whole back-archive first, then plan how to enrich the corpus." יש n8n backfill שמושך את הארכיון לתיקיית-ה-staging.

למה design-open ולא ביצוע מיידי: העלון החודשי הוא מסמך רב-נושאי; פיצולו ל-digest-records נכון דורש הכרעת מודל-קטלוג (האם כל נושא=digest? איך לקשר ל-precedent? האם זה שכבת-radar כמו היומונים או משהו אחר?). זו הכרעת-ארכיטקטורה (X12 digests-radar) + מוצר, לא משימה מכנית.

צעדים מוצעים (לכשיתוכנן): (1) לוודא שהארכיון נאסף ב-data/bulletins/incoming; (2) לנתח מבנה עלון (כותרות-נושא, גבולות); (3) להכריע מודל-קטלוג מול X12 (digest-per-topic? מצביע-מחקר?); (4) splitter דטרמיניסטי עלון→N digests דרך digest_library; (5) חיווט ל-n8n. לחקור ≥3 מקורות / לשאול חיים על מודל-הקטלוג לפני מימוש (feedback_research_architecture_decisions).

הקשר: docs/spec/X12-digests-radar.md · web/app.py:6766+ (/api/bulletins/upload) · זיכרון project_digests_radar · n8n workflow tWDhG8POD2UgrcBP (digests יומיים, נפרד).

Acceptance Criteria

העלון מפוצל ל-N רשומות digest תקינות (כל אחת עם נושא+מצביע-מקור), dedup חוצה-הרצות, ואינו מזהם את קורפוס-הפסיקה (INV-DIG1/2/3). מודל-הקטלוג מאושר מול X12 + חיים לפני מימוש.

הועבר מ-TaskMaster (tag legal-ai, id 124, status היה pending) ב-2026-08-05. הפניות (#124) בהודעות-commit ישנות מתייחסות למזהה ה-TaskMaster, לא למספר ה-issue הזה.

## What & Why תכנון + מימוש פיצול העלון החודשי הרב-נושאי "עו"ד על נדל"ן" (פרסום נפרד מהיומונים היומיים "כל יום") ל-N רשומות digest שניתן לקטלג/לקשר. הוצא מ-#104.9 שבו מסלול ה-Gmail היומי כבר חי; חלק זה מוצהר design-open בקוד. ## הקשר ופירוט **מצב נוכחי:** `/api/bulletins/upload` (web/app.py:6774) הוא **staging-only** — שומר PDFים ל-`data/bulletins/incoming` עם dedup לפי hash, **ללא DB**. הערת-מחבר מפורשת (web/app.py:6766-6770): "their catalog/processing is not designed yet — download the whole back-archive first, then plan how to enrich the corpus." יש n8n backfill שמושך את הארכיון לתיקיית-ה-staging. **למה design-open ולא ביצוע מיידי:** העלון החודשי הוא מסמך רב-נושאי; פיצולו ל-digest-records נכון דורש הכרעת מודל-קטלוג (האם כל נושא=digest? איך לקשר ל-precedent? האם זה שכבת-radar כמו היומונים או משהו אחר?). זו הכרעת-ארכיטקטורה (X12 digests-radar) + מוצר, לא משימה מכנית. **צעדים מוצעים (לכשיתוכנן):** (1) לוודא שהארכיון נאסף ב-data/bulletins/incoming; (2) לנתח מבנה עלון (כותרות-נושא, גבולות); (3) להכריע מודל-קטלוג מול X12 (digest-per-topic? מצביע-מחקר?); (4) splitter דטרמיניסטי עלון→N digests דרך digest_library; (5) חיווט ל-n8n. **לחקור ≥3 מקורות / לשאול חיים על מודל-הקטלוג לפני מימוש** (feedback_research_architecture_decisions). **הקשר:** docs/spec/X12-digests-radar.md · web/app.py:6766+ (/api/bulletins/upload) · זיכרון project_digests_radar · n8n workflow tWDhG8POD2UgrcBP (digests יומיים, נפרד). ## Acceptance Criteria העלון מפוצל ל-N רשומות digest תקינות (כל אחת עם נושא+מצביע-מקור), dedup חוצה-הרצות, ואינו מזהם את קורפוס-הפסיקה (INV-DIG1/2/3). מודל-הקטלוג מאושר מול X12 + חיים לפני מימוש. --- <sub>הועבר מ-TaskMaster (tag `legal-ai`, id **124**, status היה `pending`) ב-2026-08-05. הפניות `(#124)` בהודעות-commit ישנות מתייחסות למזהה ה-TaskMaster, לא למספר ה-issue הזה.</sub>
chaim added the area:retrievalstatus:readytype:featurepriority:p3-low labels 2026-08-05 11:01:11 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area:agents
סוכני Paperclip, תזמור, שער-הפלטפורמה (X15)
 area:backend
FastAPI web/, endpoints
 area:ci
Gitea Actions, שערי-CI
 area:docs
ספ-המערכת, תיעוד, תכנון
 area:extraction
קליטה, OCR, חילוץ הלכות/מטא/טענות/תכניות
 area:frontend
web-ui/ (Next.js), RTL
 area:infra
Deploy, Coolify, MinIO, אחסון, גיבויים
 area:mcp
שרת ה-MCP וחוזה-הכלים (X9)
 area:retrieval
RAG, חיפוש, קורפוס, גרף-ציטוטים, יומונים
 area:security
אבטחה, סודות, PII, audit
 area:writing
12 הבלוקים, סגנון דפנה, QA, רכישת-סגנון
 priority:p0-blocker
Blocks everything
 priority:p1-high
High priority
 priority:p2-normal
Normal priority
 priority:p3-low
Low priority / nice to have
 size:l
a week+ — consider splitting
 size:m
2-3 days
 size:s
~1 day
 size:xs
< half a day
 status:blocked
Waiting on another issue/decision
 status:deferred
Decided to defer — parked backlog; not auto-picked
 status:good-first-issue
Small, self-contained starting point
 status:in-progress
Being worked on (a branch/worktree exists)
 status:in-review
A PR is open for this issue
 status:needs-decision
Requires a call before proceeding
 status:ready
Scoped + pickable (has acceptance criteria + size)
 type:bug
Something works incorrectly
 type:chore
Infra, deps, refactor, CI, docs
 type:feature
New capability
 type:spike
Time-boxed investigation -> a decision/doc
No Label area:retrieval priority:p3-low status:ready type:feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
chaim
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: ezer-mishpati/legal-ai#436
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?