experiment: map remaining apply proposal boundaries

2026-08-14 16:27:55 +01:00
parent 6cb91099c2
commit a5b71ad89a
2 changed files with 292 additions and 0 deletions
@@ -3455,3 +3455,15 @@ Key outcomes:
 Apparatus: Reused existing regression `60B.64 Test 1 — exact 60B.56 wording closes` (no new harness created).
 Post-refactor deterministic closure path verified as equivalent to pre-refactor baseline.

+
+---
+
+### Experiment 60B.70 — Remaining apply-proposal.js Boundary Map (2026-08-14)
+
+Read-only structural audit completed. `apply-proposal.js` is 4,480 lines with one ~992-line `applyValidatedProposal` function containing 15+ inline phases of orchestration logic. Responsibility map identifies eight clusters: proposal reconciliation (90L), compatibility validation (~130L inline + helpers exported at 902-1261), answer semantic validation (~297L), active unknown/target selection (~933L exported + ~215L inlined orchestration), resolution propagation (already extracted at 360L), final selectedQuestion lifecycle (~160L inline), graph mutation (via imported applyGraphUpdate), and supporting pure helpers (~530L). 
+
+**Finding:** Candidates A (reconciliation, 90L) and B (compatibility validation, ~130L inline) are equally clean extraction targets with STRONG test coverage and LOW semantic risk. Validation is prioritized first because it removes the largest single inline block that obscures the post-validation lifecycle. Strategy: two independent extractions in separate commits when a natural editing context arises.
+
+**Decision:** RETURN TO REASONING WORK FIRST — no implementation directive this session. Next extraction should happen when schema changes naturally touch the validation layer, avoiding forced refactoring without external pressure to ensure correctness.
+
+Medium-term target for apply-proposal.js: ~4,250-4,300 lines (clear orchestration file, not tiny wrapper-only).