---
name: beltioseis-restructure
description: >-
  Αναδόμηση και σουλούπωμα του roadmap αρχείου docs/Βελτιώσεις.md της εφαρμογής
  Καταγραφή Κλήσεων (call_logger). Χρησιμοποίησέ το ΟΠΟΤΕΔΗΠΟΤΕ ο χρήστης ζητά
  «αναδόμηση Βελτιώσεων», «σουλούπωμα του πρόχειρου», «ενημέρωσε/τακτοποίησε το
  roadmap», «πέρασε τις σημειώσεις μου στις Βελτιώσεις», «ξαναρίθμησε τις
  προτεραιότητες», ή γενικά όταν έχει γράψει τηλεγραφικές σημειώσεις στο τμήμα
  «📝 Πρόχειρο» του docs/Βελτιώσεις.md και θέλει να γίνουν κανονικές κωδικοποιημένες
  καταχωρήσεις. Καλύπτει: διόρθωση ορθογραφίας/συντακτικού, μετατροπή πρόχειρων
  σημειώσεων σε κωδικοποιημένες καταχωρήσεις, εμπλουτισμό τηλεγραφικών περιγραφών,
  επαναρρύθμιση προτεραιοτήτων με ξαναρίθμηση, και ΚΡΙΣΙΜΑ τον έλεγχο εγκυρότητας
  κάθε πρόχειρης σημείωσης απέναντι στον πραγματικό κώδικα. Ενεργοποιήσου ακόμη κι
  αν ο χρήστης δεν αναφέρει ρητά το όνομα του αρχείου, αρκεί το πλαίσιο να είναι το
  roadmap/σημειωματάριο βελτιώσεων του έργου.
---

# Αναδόμηση του docs/Βελτιώσεις.md

## Τι είναι το αρχείο και γιατί έχει σημασία

Το `docs/Βελτιώσεις.md` είναι το **σημειωματάριο του Διευθυντή Έργου** — ο οδηγός μελλοντικής υλοποίησης. Ο χρήστης (ο «Διευθυντής») γράφει βιαστικές, **τηλεγραφικές** σημειώσεις με πολλά ορθογραφικά στο τμήμα «📝 Πρόχειρο». Δουλειά σου: να τις μετατρέψεις σε **έγκυρες, ευανάγνωστες, τεκμηριωμένες** καταχωρήσεις που ο χρήστης θα μπορεί αργότερα να **ταυτίσει και να ανακαλέσει**.

> **Η μοναδική πιο σημαντική αρχή:** μια σημείωση που ο χρήστης δεν μπορεί να ταυτίσει με κάτι πραγματικό στον κώδικα είναι **άχρηστη**. Γι' αυτό ο πυρήνας αυτής της Ικανότητας ΔΕΝ είναι η ωραιοποίηση κειμένου — είναι ο **έλεγχος εγκυρότητας**: για κάθε πρόχειρη σημείωση, εντόπισε στον κώδικα αυτό που περιγράφει. Αν δεν το βρίσκεις ή είναι ασαφές, **ρώτα τον χρήστη — μην μαντεύεις και μην επινοείς αναφορές**.

## Οι πέντε λειτουργίες (τι κάνει η Ικανότητα)

1. **Ευανάγνωση** — διόρθωση ορθογραφίας και συντακτικού. Τα πρόχειρα είναι γεμάτα τυπογραφικά (π.χ. «ένω»→«ενώ», «πρωτύνει»→«προτείνει», «scackbar»→«snackbar», «επιλείουμε»→«επιλέγουμε»). Καθαρό, σωστό ελληνικό κείμενο με τη σωστή τεχνική ορολογία.
2. **Σουλούπωμα** — μετατροπή κάθε πρόχειρης σημείωσης σε κωδικοποιημένη καταχώρηση (βλ. «Κώδικες» παρακάτω) στη σωστή κατηγορία.
3. **Εμπλουτισμός περιγραφής** — οι σημειώσεις είναι τηλεγραφικές. Επέκτεινέ τες στο ύφος των υπαρχουσών καταχωρήσεων: **πραγματικό σενάριο** (με ονόματα/κωδικούς όπου δίνονται) → **τι πάει στραβά** → **τι ζητείται**. Όπου βρήκες την αιτία στον κώδικα, πρόσθεσε την αναφορά `αρχείο.dart:γραμμή` — αυτή ακριβώς η τεκμηρίωση κάνει τη σημείωση ανακαλέσιμη.
4. **Έλεγχος εγκυρότητας (ο πυρήνας)** — διασταύρωση κάθε πρόχειρης σημείωσης με τον πραγματικό κώδικα (δες «Ροή εργασίας»).
5. **Επαναρρύθμιση προτεραιοτήτων** — ξαναρίθμηση κάθε κατηγορίας 1→Ν χωρίς κενά, με σειρά προτεραιότητας (δες «Κανόνες αρίθμησης»).
6. **Σπάσιμο σε λίστες** — καμία καταχώρηση-«σούπα» (δες «Μορφοποίηση» παρακάτω). Ο εμπλουτισμός ΔΕΝ σημαίνει μακρύτερη παράγραφο.

## Μορφοποίηση καταχωρήσεων — ΑΠΑΓΟΡΕΥΕΤΑΙ η «σούπα» (ρητή απαίτηση χρήστη)

**Το πρόβλημα, με τα λόγια του χρήστη:** «Το κείμενο αυτό είναι απαράδεκτο ως προς τη μορφή του. Μοιάζει με σούπα! Για να εντοπίσω το υποζήτημα 6 μου βγήκαν τα μάτια!»

Ο εμπλουτισμός (λειτουργία 3) παράγει πλούσιο περιεχόμενο — αυτό είναι σωστό. Το λάθος είναι να το στοιβάζεις σε **μία τερατώδη παράγραφο** με `(α)`, `(β)`, `(1)`, `(2)` μέσα στη ροή του κειμένου. Ο χρήστης διαβάζει αυτό το αρχείο για να **βρει** πράγματα, όχι για να το διηγηθεί.

### Απαράβατοι κανόνες

1. **Πάνω από 2 διακριτά υποζητήματα → ΥΠΟΧΡΕΩΤΙΚΑ αριθμημένη λίστα.** Κάθε `(α)`/`(β)`/`(γ)` μέσα σε παράγραφο γίνεται **ξεχωριστό στοιχείο λίστας**. Το ίδιο για κάθε αριθμημένη απόφαση χρήστη.
2. **Καμία παράγραφος πάνω από ~5 γραμμές.** Αν σου βγαίνει μεγαλύτερη, περιέχει κρυμμένη λίστα — σπάσ' την.
3. **Ονομάτισε τα τμήματα με bold επικεφαλίδες** αντί να τα χώνεις στη ροή: `**Ζητούμενο:**`, `**Αποφάσεις χρήστη ΗΗ/ΜΜ:**`, `**Αρχιτεκτονική:**`, `**Δολώματα δοκιμής:**`, `**Ανοιχτή ερώτηση:**`.
4. **Κάθε υποζήτημα ξεκινά με bold ετικέτα** που λέει σε μία φράση περί τίνος πρόκειται — ώστε ο χρήστης να το εντοπίζει με σάρωση του ματιού, χωρίς να διαβάζει.
5. **Η αναφορά κώδικα στο τέλος του δικού της υποζητήματος**, όχι σκορπισμένη σε παρενθέσεις μέσα στην πρόταση.
6. **Ο τίτλος της καταχώρησης μένει ΜΙΑ γραμμή.** Το πλαίσιο («Εύρημα ΗΗ/ΜΜ», «επιβεβαιωμένο στον κώδικα») πάει σε δική του σειρά μετά τον τίτλο, όχι φουσκώνοντας τον τίτλο.

### Παράδειγμα — από σούπα σε ευανάγνωστο

**ΛΑΘΟΣ** (ό,τι έφτιαχνε η Ικανότητα πριν — υποζητήματα χωμένα στη ροή):

> - **ΔN — Ο ταξινομητής κρίνει από ΕΝΑΝ πίνακα.** (Εύρημα 25/07.) (α) Το `user_version` διαβάζεται και πετιέται (classifier.dart:45-46), οπότε αρχείο με `calls` και version 0 ταξινομείται δική μας βάση και τρέχει onCreate πάνω του… (β) Η σειρά «ο calls κερδίζει πρώτος»: υβρίδιο με calls ΚΑΙ υπογραφή Λάμπας βγαίνει callLogger… (γ) Ο validateSchema ελέγχει μόνο τον calls… Ζητούμενο: … ΑΠΟΦΑΣΕΙΣ ΧΡΗΣΤΗ: (1) … (2) … (3) …

**ΣΩΣΤΟ** (ίδιο περιεχόμενο, σαρώσιμο με το μάτι):

> - **ΔN — Ο ταξινομητής βάσης κρίνει από ΕΝΑΝ πίνακα.**
>   *Εύρημα 25/07, επιβεβαιωμένο στον κώδικα. Δεν είναι σπάνια σενάρια — προκύπτουν από κανονική χρήση DB Browser.*
>
>   **Τα παραπλανητικά αρχεία που περνούν:**
>   1. **Το `user_version` διαβάζεται και πετιέται.** Αρχείο με πίνακα `calls` και `user_version = 0` ταξινομείται «δική μας βάση», και το sqflite τρέχει `onCreate` πάνω του. Αυτή είναι η αιτία του περιστατικού 17/07. — `database_file_classifier.dart:45-46`
>   2. **Ο πίνακας `calls` κερδίζει πρώτος.** Υβρίδιο με `calls` ΚΑΙ πλήρη υπογραφή Λάμπας βγαίνει `callLogger`· δεν υπάρχει έλεγχος «έχει και τα δύο σχήματα → ύποπτο».
>   3. **Ο `validateSchema` ελέγχει μόνο τον `calls`.** Αρχείο χωρίς `users`/`departments` περνά ΟΛΟΥΣ τους ελέγχους και σκάει στην πρώτη οθόνη με «no such table: users» — χωρίς οθόνη σφάλματος, δηλαδή χωρίς διέξοδο.
>   4. **Μετρώνται μόνο `type='table'`.** Όψεις (views) με τα ίδια ονόματα δεν μετρούν → ταξινομείται `empty` και η εφαρμογή χτίζει σχήμα μέσα της.
>
>   **Ζητούμενο:** η ταξινόμηση να αποφασίζει από σύνολο ενδείξεων (2-3 βασικοί πίνακες + έλεγχος στηλών + `user_version` σε αναμενόμενο εύρος), να απορρίπτει ρητά τα υβρίδια, και ο `validateSchema` να ζητά τους βασικούς πίνακες.
>
>   **Δολώματα δοκιμής:** `Data Base\calls_test.db`, `Data Base\lamba_test.db`
>
>   **Αποφάσεις χρήστη 25/07 (οριστικές):**
>   1. **Υβρίδιο Καταγραφής+Λάμπας** → ΑΠΑΓΟΡΕΥΤΙΚΟ, με μήνυμα ότι το αρχείο δεν είναι έγκυρο.
>   2. **Παλιά αλλά έγκυρη βάση Καταγραφής** → ΠΕΡΝΑΕΙ (είναι επιθυμητό: «θέλω να δω μια βάση του 2023»), μόνο προειδοποιητικός διάλογος.
>   3. **Κενή βάση** → ΠΕΡΝΑΕΙ με απλή προειδοποίηση.

## Οικονομία τόκενς (ρητός περιορισμός του χρήστη)

Ο έλεγχος στον κώδικα γίνεται **ΜΟΝΟ για τις σημειώσεις του «📝 Πρόχειρο»** που προάγεις τώρα. **ΜΗΝ** ξαναδιασταυρώνεις τις ήδη υπάρχουσες κωδικοποιημένες καταχωρήσεις (Δ/Π/Σ/Κ) — έχουν ήδη ελεγχθεί σε προηγούμενες αναδομήσεις. Στις υπάρχουσες καταχωρήσεις κάνεις μόνο ό,τι χρειάζεται η αρίθμηση/παραπομπές, χωρίς νέα έρευνα κώδικα.

## Κώδικες κατηγοριών

- **Δ** = Διόρθωση σφάλματος → τμήμα «Α. Διορθώσεις» (Υψηλή / Μεσαία προτεραιότητα)
- **Π** = Προσθήκη λειτουργίας → τμήμα «Β. Προσθήκες» (Μεσαία / Χαμηλή)
- **Σ** = προς Συζήτηση/σχεδιασμό → τμήμα «Γ. Προς συζήτηση»
- **Κ** = πρόταση Claude → τμήμα «Δ. Προτάσεις Claude»
- **Ε** = ολοκληρωμένο (προς επιβεβαίωση) → τμήμα «Ε. Ολοκληρώθηκαν»

Ο κωδικός δηλώνει **ΘΕΣΗ ΠΡΟΤΕΡΑΙΟΤΗΤΑΣ, όχι σταθερή ταυτότητα**. Το «Δ3» σημαίνει «το τρίτο πιο επείγον», όχι ένα συγκεκριμένο σφάλμα για πάντα.

## Κανόνες αρίθμησης & παραπομπών (μη τους παραβιάζεις)

- **Ξαναρίθμηση 1→Ν χωρίς κενά** μέσα σε κάθε κατηγορία, κατά αύξουσα προτεραιότητα. Μετά την προσθήκη νέων σημειώσεων, ΟΛΗ η κατηγορία ξαναριθμείται.
- **Παραπομπές με ΠΕΡΙΓΡΑΦΗ, ΟΧΙ με αριθμό.** Αφού οι αριθμοί μετακινούνται, το «δες Δ5» θα δείχνει λάθος μετά την επόμενη αναδόμηση. Γράψε «δες τη συστάδα διαγραφής τμήματος» ή «ίδια οικογένεια με τις μπαγιάτικες μνήμες μετά από αλλαγή βάσης».
- **Διατήρησε ΑΝΕΠΑΦΑ:** κάθε «**Ανοιχτή ερώτηση:**», κάθε σημείωμα «*Έλεγχος ΗΗ/ΜΜ*», κάθε «✅ ΟΛΟΚΛΗΡΩΘΗΚΕ», και τα διερευνητικά σχόλια. Αυτά είναι ιστορικό διάγνωσης — ποτέ μην τα σβήνεις χωρίς ρητή άδεια.
- **Προτεραιοποίηση = κρίση, όχι μηχανική.** Τα κρίσιμα (κατάρρευση, σιωπηλή απώλεια/αλλοίωση δεδομένων, ακεραιότητα κοινόχρηστης βάσης) πάνε πάνω από τα καθημερινά UX. Όπου δύο θέματα ανήκουν στην ίδια «οικογένεια» (ίδιο σπασμένο συμβόλαιο σε διαφορετικές ροές), σημείωσέ το με περιγραφική παραπομπή.

## Ροή εργασίας

1. **Διάβασε** το `docs/Βελτιώσεις.md`, εστιάζοντας στην κεφαλίδα (κανόνες) και στο τμήμα «📝 Πρόχειρο».
2. **Για κάθε πρόχειρη σημείωση**, ένα προς ένα:
   - Κατάλαβε τι περιγράφει (ποια οθόνη/ροή/δεδομένα).
   - **Εντόπισέ το στον κώδικα** με στοχευμένη αναζήτηση (Grep/Read) — βρες το αρχείο και, ει δυνατόν, τη γραμμή. Κράτα τα ευρήματα για τον εμπλουτισμό.
   - **Αν το βρίσκεις καθαρά** → φτιάξε πλήρη κωδικοποιημένη καταχώρηση (σενάριο → πρόβλημα → ζητούμενο, με αναφορά `αρχείο.dart:γραμμή`).
   - **Αν είναι ασαφές, διφορούμενο, ή δεν εντοπίζεται** → ΜΗΝ το προάγεις στα τυφλά. Κράτησέ το ως **ερώτηση προς τον χρήστη**.
3. **Ρώτα τον χρήστη ΜΑΖΕΜΕΝΑ** όλες τις ασάφειες που συγκέντρωσες, με συγκεκριμένα ερωτήματα (π.χ. «Στη σημείωση για τον εξοπλισμό 3676 — εννοείς το autofill τηλεφώνου ή κατόχου; Δεν βρίσκω μοναδική αντιστοίχιση στη βάση»). Περίμενε απαντήσεις πριν οριστικοποιήσεις.
4. **Ενσωμάτωσε** κάθε προαχθείσα σημείωση στη σωστή κατηγορία & θέση προτεραιότητας, **με τη μορφοποίηση της ενότητας «Μορφοποίηση»** — αριθμημένη λίστα για κάθε καταχώρηση με πάνω από 2 υποζητήματα. Πέρνα και από τις **υπάρχουσες** καταχωρήσεις που είναι ήδη «σούπα» και σπάσ' τες σε λίστες: είναι αλλαγή μορφής χωρίς αλλαγή περιεχομένου, οπότε δεν απαιτεί νέα έρευνα κώδικα (δες «Οικονομία τόκενς»).
5. **Ξαναρίθμησε** όλες τις επηρεαζόμενες κατηγορίες 1→Ν, με περιγραφικές παραπομπές.
6. **Καθάρισε** το «📝 Πρόχειρο»: αφαίρεσε όσες σημειώσεις προήχθησαν· άσε εκεί (ή σε ξεχωριστή υποενότητα «⏳ Εκκρεμεί διευκρίνιση») όσες περιμένουν ακόμη απάντηση.
7. **Πρόσθεσε σημείωμα αναδόμησης** με τη σημερινή ημερομηνία στην κορυφή (μετά τα υπάρχοντα), στο ύφος: «**Αναδόμηση ΗΗ/ΜΜ/ΕΕΕΕ:** …τι ενσωματώθηκε/ξαναριθμήθηκε/μετακινήθηκε…».
8. **Ανέφερε** στον χρήστη σύντομα: τι προήχθη, τι ξαναριθμήθηκε, και τι έμεινε εκκρεμές λόγω ασάφειας.

## Παράδειγμα εμπλουτισμού

**Πρόχειρη σημείωση (τηλεγραφική):**
> Στη διαχήρηση βάσης, στον πίνακα audit_log βλέπω μόνο τις πρώτες 518 εγγραφες από τις 1116! Γαιτί δεν τις φορτώνει όλες;

**Αφού εντοπίσεις στον κώδικα** (π.χ. όριο σελιδοποίησης/LIMIT στον φορτωτή του πίνακα), **προαγωγή σε:**
> **ΔN — Ο προβολέας πινάκων της διαχείρισης βάσης δεν φορτώνει όλες τις εγγραφές.** Στη διαχείριση βάσης, ο πίνακας `audit_log` δείχνει μόνο τις πρώτες 518 από 1116 εγγραφές. *Έλεγχος: αιτία εντοπισμένη* στο `<αρχείο>.dart:<γραμμή>` (όριο/σελιδοποίηση στο ερώτημα φόρτωσης). Ζητούμενο: πλήρης φόρτωση ή σαφής σελιδοποίηση με ένδειξη πλήθους. Δένει με «βελτίωση χρόνου φόρτωσης πινάκων, ειδικά audit».

Αν **δεν** έβρισκες τέτοιο όριο στον κώδικα, δεν θα επινοούσες αναφορά — θα ρωτούσες: «Δεν εντοπίζω όριο στον φορτωτή του `audit_log`· θυμάσαι σε ποια οθόνη/κουμπί το είδες, να το αναπαράγω;».

## Όρια & προφυλάξεις

- **Άγγιξε ΜΟΝΟ** το `docs/Βελτιώσεις.md`. Μην μπερδέψεις με τα άλλα αρχεία changelog (`assets/changelog.json` = in-app, `CHANGELOG.md` = dev). Δες τη μνήμη «τρία αρχεία changelog».
- **Ποτέ μην επινοείς** αναφορά κώδικα, αριθμό γραμμής, ή «αιτία εντοπισμένη» που δεν επαλήθευσες. Η αναξιοπιστία εδώ ακυρώνει τον σκοπό του αρχείου.
- **Ποτέ μη σβήνεις** ανοιχτές ερωτήσεις, διερευνήσεις, ή ολοκληρωμένα (Ε) χωρίς άδεια. Σε αμφιβολία, ρώτα.
- **Καμία αλλαγή κώδικα** — αυτή η Ικανότητα αγγίζει μόνο τεκμηρίωση. (Ο έλεγχος στον κώδικα είναι μόνο για ανάγνωση/εντοπισμό.)
- Ο χρήστης διαχειρίζεται το git μόνος του — μην προτείνεις commit.