docs(scheduling): referencias rotas a la documentación del solver

backend/scheduling-solver/AGENTS.md

@@ -199,8 +199,8 @@ matches, generic fallback.
 
 When an INFEASIBLE appears in production that the analyzer can't diagnose,
 **don't blindly patch here**: rebuild the real `SolverInput` for that month,
-identify the pattern, and then extend the analyzer with a
-new branch. One correct, specific message beats a thousand generic ones.
+identify the pattern, and then extend the analyzer with a new branch. One
+correct, specific message beats a thousand generic ones.
 
 ## Local setup
 
@@ -280,9 +280,8 @@ that drifts.
 - `docs/scheduling/constraints.md` — textual specification of the rules. Source
   of truth when code and constraints disagree.
 - `docs/scheduling/decisions.md` — decision log (why each constraint is
-  hard/soft, why the weights, what was tried and discarded).
-- `SCHEDULING-SOLVER-PLAN.md` (repo root) — original solver plan. Historical,
-  not updated; the code is the current truth.
+  hard/soft, why the weights, what was tried and discarded); the 2026-04-22
+  entry keeps the original phases.
 - `backend/services/scheduling/build-solver-input.ts` — the TS side that
   assembles `SolverInput`. Any new field here needs its counterpart there.
 - `backend/services/scheduling/solver-client.ts` — daemon process management,

backend/scheduling-solver/main.py

@@ -1,7 +1,7 @@
 """
 main.py — CLI entry point del solver.
 
-Protocolo (SCHEDULING-SOLVER-PLAN.md §3.4):
+Protocolo (docs/scheduling/solver.md, «Where it runs»):
   stdin  → JSON con SolverInput
   stdout → JSON con SolverOutput
   stderr → logs de debug

backend/scheduling-solver/schemas.py

@@ -1,6 +1,6 @@
 """
 schemas.py — Contratos de input/output entre Node y el solver Python.
-Corresponde a SCHEDULING-SOLVER-PLAN.md §3.1-§3.2.
+Corresponde a docs/scheduling/solver.md, «Input» y «Output».
 """
 
 from __future__ import annotations

backend/scheduling-solver/tests/test_benchmark.py

@@ -1,7 +1,7 @@
 """
 test_benchmark.py — Benchmark sintético: 30 empleados × 31 días.
 
-Criterio de cierre Fase 2 (SCHEDULING-SOLVER-PLAN.md):
+Criterio de cierre Fase 2 (docs/scheduling/decisions.md, entrada 2026-05-09):
   - 30 empleados × 31 días resueltos en < 30 segundos con horario factible.
   - Validación: no hard errors en validator (delegada a tests/scheduling/ TS, aquí
     sólo medimos status/tiempo del solver).

backend/scheduling-solver/tests/test_corpus.py

@@ -1,7 +1,7 @@
 """
 test_corpus.py — Corpus de fixtures del scheduler contra el solver Python.
 
-Objetivo (SCHEDULING-SOLVER-PLAN.md Fase 1):
+Objetivo (docs/scheduling/solver.md, «How it is tested»):
   - Ningún fixture produce status='error' (sin crashes internos).
   - Fixtures con parámetros claramente resolubles → status='ok'.
 

backend/services/scheduling/AGENTS.md

@@ -12,8 +12,8 @@ Manages monthly staff schedules through **manual cell-by-cell editing with
 real-time validation**, plus optional **auto-generation** via a CP-SAT solver
 (Python).
 
-**Month states:** `draft` (editable, validation surfaces warnings) ↔
-`published` (read-only for staff).
+**Month states:** `draft` (editable, validation surfaces warnings) ↔ `published`
+(read-only for staff).
 
 **Cell locking.** Assignments with `source_constraint_id` are **locked**: they
 come from approvals (vacations, IT, etc.) and can't be overwritten from the UI
@@ -471,8 +471,8 @@ git log.
 ## Historical Excel importer
 
 The one-off importer that loaded `PLANNING 2026.xlsx` (January-May) into
-`scheduling_*` in draft state was removed on 2026-10-04: it held the real
-names of the staff and had already run. The months stay in the database.
+`scheduling_*` in draft state was removed on 2026-10-04: it held the real names
+of the staff and had already run. The months stay in the database.
 
 ## Cross-month gotcha (H4/H5) — outstanding debt
 
@@ -496,8 +496,7 @@ logic in `consecutive-rest.constraint.ts` and
 - `docs/scheduling/constraints.md` — full textual specification. Source of
   truth.
 - `docs/scheduling/decisions.md` — decision log (why hard/soft, why the weights,
-  what was tried).
-- `SCHEDULING-SOLVER-PLAN.md` (root) — original plan. Historical.
-- `TODO.md` (root) — known module bugs (setSchedulableEmployees, H5 cross-month
+  what was tried); the 2026-04-22 entry keeps the original phases.
+- `docs/TODO.md` — known module bugs (setSchedulableEmployees, H5 cross-month
   debt, etc.).
-- `frontend/app/components/scheduling/CLAUDE.md` — the UI side of the module.
+- `frontend/app/components/scheduling/AGENTS.md` — the UI side of the module.

backend/tests/scheduling/solver-parity.test.ts

@@ -1,8 +1,7 @@
 // tests/scheduling/solver-parity.test.ts
 // Parity test: solver output must pass ScheduleValidator with 0 hard errors.
 //
-// SCHEDULING-SOLVER-PLAN.md Fase 1 criterion:
-//   "Output del solver pasa ScheduleValidator.validate() con 0 hard errors."
+// See docs/scheduling/solver.md, «How it is tested».
 //
 // Each test case: build SolverInput from a corpus fixture → run solver → validate matrix.