docs(todo): cerrar los puntos revisados y anotar las decisiones

docs/checklist/README.md

@@ -61,7 +61,8 @@ from `backend/`.
 - **`checklist_step_comments`** and **`checklist_step_attachments`**: comments
   and images per step.
 - **`checklist_event_log`**: every tick, untick and restart.
-- **`checklist_config`**: exists but is not used.
+- **`checklist_config`**: exists but is not used: the 06:30 reset and the
+  `Europe/Madrid` zone are written in the code. Left as is on 2026-10-12.
 
 ## What rules it follows
 

docs/conciliation/README.md

@@ -38,6 +38,8 @@ reconciliation or closes a month.
 - **Monthly summary**: totals for the month, which days are missing, and whether
   the month can be closed.
 - **Close the month**, only once every day of the month exists and is closed.
+  It exists only in the API (`PATCH /monthly-summary/:year/:month/status`): no
+  screen calls it.
 
 ## What data it handles
 
@@ -63,8 +65,12 @@ Four tables (`backend/db-mysql/aiven/09_conciliation.sql`):
 - **A closed day cannot be edited** — not its adjustments, not its totals —
   except by an `admin`. `confirmed` is not a locking state.
 - **A month closes only when every one of its days exists and is closed.**
-  Missing or still-open days block it and are listed by day number.
+  Missing or still-open days block it and are listed by day number. A closed
+  month does not lock its days: an `admin` can still reopen or delete them
+  (left as is on 2026-10-11, see `docs/TODO.md`).
 - **Deleting a day's reconciliation is only for `admin`.**
+- **`GET /api/conciliations` returns every day, without paging or filters**,
+  to any role with access. No screen uses it; left as is on 2026-10-12.
 
 ## How information flows
 

docs/general/database/README.md

@@ -70,10 +70,15 @@ Tables by module:
   `NOW()` or `CURDATE()` runs 1–2 hours behind Madrid; the backend calculates
   "today" in Madrid time on its own.
 - **Encrypted connection**: TLS with the Aiven certificate in
-  `backend/config/certs/`.
-
-**Migration status**: the 15 recorded in `INDEX.md` are applied on Aiven
-(verified on 2026-09-28).
+  `backend/config/certs/`. It is the project's public CA certificate (no
+  private key) and names the Aiven project by its id; it stays in the
+  repository because the backend and `apply-migration.sh` need it (decided on
+  2026-10-12).
+
+**Migration status**: the 26 recorded in `INDEX.md` are applied on Aiven
+(the last two, `20261011_keep_group_history_on_delete.sql` and
+`20261012_unique_invoice_supplier_number.sql`, applied and verified on
+2026-10-12).
 
 ## How information flows
 

docs/general/messages/README.md

@@ -41,7 +41,8 @@ conversation, and list them all.
 
 **The backend offers, but the interface does not use yet**: renaming a group,
 adding or removing participants after creation, searching in message text, the
-global unread counter and the view of all conversations for `admin`.
+global unread counter and the view of all conversations for `admin`. They are
+not planned (decided on 2026-10-12).
 
 ## What data it handles
 

docs/logbook/README.md

@@ -37,6 +37,11 @@ All roles **except `mantenimiento`**, which does not have access to the module.
 - **Edit and delete** own entries. Deleting does not remove: the entry goes to
   the trash.
 
+**The backend offers, but the module screen does not use**: the trash
+(`/trashed`) and the lists by author, department and priority (Reports uses
+`/all` with its own filters, deleted ones included). Nothing restores a deleted
+entry, not even the backend. Not planned (decided on 2026-10-12).
+
 ## What data it handles
 
 Four tables (`backend/db-mysql/aiven/03_logbook_tables.sql`):
@@ -58,6 +63,10 @@ Departments are the application's general ones (table `departments`).
   entries and comments, and also reading, unmarking, resolving and reopening.
   Each change and its history rows are written in one transaction: either
   both are saved or neither is.
+- **A comment leaves two history rows** (one of the comment, one of the entry),
+  and **each read or unmark adds one**, with no limit; all of them show in the
+  entry's history in Reports and in the recent activity. Left as is (decided
+  on 2026-10-12).
 - **Nothing is truly deleted**: entries and comments are only marked with
   `deleted_at`. There is no way to restore them from the interface.
 - **Only the author edits or deletes** their entry or comment.

docs/parking/README.md

@@ -58,6 +58,13 @@ Part of the logic lives **in the database**: the triggers in
 `05_parking_functions_triggers.sql` generate the booking code and keep the
 calendar up to date.
 
+The database also has 2 functions (`check_availability`,
+`get_total_availability`) and 5 procedures (`06_parking_procedures.sql`) that
+**nothing calls**, neither the code nor the triggers; only the local seeds run
+`generate_availability`, which the backend replaced with `extendAvailability`.
+`daily_parking_maintenance` would mark expired bookings as no-shows if someone
+ran it by hand. They stay in the database (decided on 2026-10-12).
+
 ## What rules it follows
 
 **Booking states**
@@ -126,6 +133,7 @@ BookingsListClient / BookingDetailClient ─────────────
 2. The status map requests spaces, bookings, expired ones and statistics with
    React Query. **It does not refresh on its own**: each action requests the
    data again, but changes made by another person do not appear until reloading.
+   Left as is (decided on 2026-10-12).
 3. Creating, moving, closing or cancelling a booking writes to
    `parking_bookings` within a transaction; the triggers update the calendar in
    the same operation.