Commit History
-
[NOTICKET] fix: add a fault-code label, measured; re-diagnose the Komatsu tables
Rifqi Hafizuddin +1: Claude Opus 5The Komatsu manual prints 27 service codes ([CA559], [CB2249]) in plain prose and the pipeline returned ZERO mentions for them. Not a parsing problem -- the codes are in `Chunk.text` verbatim. No label was asking: a code is not a component, a symptom, a check or an action, so neither `broad` nor the parked `diagnostic` set proposed one. GLiNER finds them readily once asked, 6 of 6 on the probe chunk at 0.54-0.69 against a 0.25 floor. `fault code` added to `diagnostic`, plus a `broad_codes` A/B arm. It is deliberately NOT in `broad`, because a label is not additive -- GLiNER runs flat NER and a new label competes for spans: mentions clusters code clusters E1c_strict BUMA 251 -> 200 86 -> 67 0 -> 0 0.8537 -> 0.7805 Komatsu 449 -> 548 93 -> 161 0 -> 17 -- Open Pit 787 -> 711 427 -> 377 0 -> 0 -- BUMA loses 51 mentions, 19 clusters and three gold terms; Open Pit loses 76 mentions…366697c -
[NOTICKET] feat: pull one linked partner chunk into the evidence window
Rifqi Hafizuddin +1: Claude Opus 50.4.0 pairs a table chunk with the prose that introduces it (`referenced_by`, both directions) and nothing consumed the pointer. Measured what it would buy, ranking only on the three v2 artifacts -- free, no GLiNER, no spend: clusters top-5 touches a pair BOTH sides only ONE BUMA 83 31 0 31 Komatsu 93 55 0 55 Open Pit 427 70 0 70 Zero of 603 clusters saw both sides. The ranker never co-selects a table and the prose that names it, so the partner is unseen content rather than a duplicate -- and for a bare grid that prose is often its only title ("Troubleshooting of engine (S-mode)" above "S-1 | 6"). Cost at the cap of 1: evidence read +14.5%/+24.5%/+9.9%, i.e. +1.6%/+4.1%/+4.2% of total prompt spend; Open Pit moves 71% -> ~74% of the 2M ceiling. The expansion lives in `top_k`, not `rank_evidence`, for two rea…5d51025 -
[NOTICKET] docs: sync for the open-queue pass, add the Step 8 and Step 7 proposals
Rifqi Hafizuddin +1: Claude Opus 5REPO_STATUS section 14 and DEV_PLAN section 0.8 get the 2026-09-11 delta, with per-item rows K17-K23. Three stale claims corrected while in there, all of which would have misled the next session: * REPO_STATUS gave `schema_version` as 0.3.3 in two places while the delta directly above it documented 0.4.0. * Its "Not yet done" paragraph still listed persistence, the HTTP surface, the full-document run and E3 as open. All four have landed. * KNOWLEDGE_PIPELINE_TODO rows X17, D2 and D4 read "not started" for four days after persistence and the 8 routes shipped on 2026-09-07, while DEV_PLAN recorded them done. Anyone reading that file first would have concluded the pipeline was still offline. It also records nothing of v2 or of this pass, so it now says outright that DEV_PLAN section 0.8 is canonical and the checklist covers the original build-out only. Two proposals, nothing built from either, both needing sign-off: * TABLE_BRANCH_PROPOSAL (Step 8). A shop manual is 74…7659cf0