2 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5	59407728e6	feat(planning): start_planning hands back the active plan that already covers the work (#4079) ... Step 4 of milestone 415 "An existing plan is found before a new one is made". A session that could not see an existing plan made a second one beside it. start_planning and create_milestone now ask first: an ACTIVE milestone in the project with the same title, or one that reads as the same plan (title, design and steps against milestone embeddings), is returned with its progress and a pointer to create_records(milestone_id=...). Nothing is created; force=true bypasses. - dedup.find_matching_plan / plan_gate / plan_match_response; access-checked before either arm (rule 78), fail-open like the other gates. - Done milestones never block; the semantic arm needs 200+ chars of candidate. - kb_plan_match_threshold (default 0.90) is a setting, in the Settings view, and pinned against the Python default by test_settings_defaults_agree. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-15 13:43:18 -04:00
bvandeusenandClaude Opus 5	2e8d8461cc	feat(settings): the two new retrieval bars get their controls (#3927) ... #3852 and #3853 each added a threshold and neither added its input, so two of the eleven retrieval settings were reachable only through the database. The other nine have had UI all along. That matters because the issue said otherwise. #3927 claimed none of the ten appeared in the frontend, on the strength of a grep across `web/src` — a directory this repo does not have. An empty result from a path that cannot match was read as "no UI anywhere", and a rule-25 argument was written on top of it. The issue is corrected rather than quietly rewritten: it is #3720's defect, absence read as non-existence, committed while filing issues about the product doing the same thing. A grep that returns nothing and a grep that cannot match produce the same output, and only a positive control tells them apart. So this is small, which is the honest size: - `kb_toolrule_threshold` — the command arm's bar. The hint says why it sits BELOW the write-path one rather than leaving that looking like a mistake: a shell command is short, so it scores lower for the same relevance, and at a shared bar this arm spoke on 2% of calls against the write path's 37%. - `kb_promptrule_threshold` — the prompt boundary, a third query shape again, and the only moment that reaches a rule about how to ANSWER. Both follow the five-site pattern the existing controls use: ref, clamp on save, write-back, payload key, load. Separate keys, because the finding of #3853 is that one number cannot serve arms whose queries differ in shape. Also corrects copy that went stale this morning. The standing-rule hint still said the arm surfaces "only rules marked conditional, since always-on ones are already loaded" — describing a tier milestone 394 removed, on the surface whose whole job is telling the operator what the bar does. The guard is the part worth keeping. A form's initial value is a CLAIM about the server's default, and nothing connected the two: retune the Python constant and the input keeps rendering the old number, which the operator reads as the bar in force. It pins the relationship across all five thresholds, never the values, so retuning stays free as long as both move — and it is falsified against a drifted form value. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011cPyzNnegXHr5iRMzzy5KJ	2026-09-11 20:30:06 -04:00