refactor(members): retire the dead acp_backend factory kwarg (#8166 item 1) - #9125
Conversation
…icit backend-select arm select_provider_backend's explicit precedence arm and the _acp factory closure's acp_backend kwarg that feeds it had zero non-test consumers: the one live caller (config/loader.py) never passes it, and no per-slot backend picker consumes it anywhere in src. Remove both so the seam does not sit unconsumed. The factory closure keeps **_kwargs, so a stray keyword is still absorbed harmlessly; the kiro construction path is unchanged (harness-parity H13) and the member-DM auto-route / configured-default arms are behaviorally identical. Refs #8166
Design Review (Fable 5) — ✅ PASSDesign-level review of All factory call sites pass only Design-Verdict: PASS Dead surface removed from the one backend-selection gate; no caller ever exercised the explicit arm, and the single-gate invariant gets strictly stronger. [DESIGN-REVIEWED] 7e096d2 |
First Principles Review (Fable 5) — ✅ PASSPremise-level review of All checks are complete. The change is a pure subtraction with verified zero live consumers of the removed surface, a declared and deferred sibling item, and no stale spec left behind. Final review: First-Principles-Verdict: PASS A pure subtraction of a zero-consumer seam, with the count verified in-repo and the deferred sibling declared — every item is the declared removal. What this change shipsIntent: stop carrying an unconsumed per-call backend-pick seam on the provider-construction path. FIX (subtractive cleanup recorded in issue #8166).
No spec goes stale: grepped Watch
[FIRST-PRINCIPLES-REVIEWED] 7e096d2 |
Opus 4.8 Review — ✅ no blocking findingsReviewed Verdict parsed from the review's SHA-scoped output markers for commit False positive or not applicable? A repository writer can comment: |
GPT 5.6 Review — ✅ no blocking findingsGPT 5.6 completed its review of This comment is updated in place on each push. Review detailsNo findings. False positive or not applicable? A repository writer can comment: |
iamwhatever
left a comment
There was a problem hiding this comment.
Tier 1 auto-approve: refactor (3 files). Criteria: no conflict, no requested changes, security path denylist clean, design-doc gate clean, SAST annotations clean, security checklist all-NO, AI reviewers green. Category: removes the dead acp_backend kwarg from the ACP provider factory and select_provider_backend, dropping an explicit-pick arm no caller used -- narrows the selection surface, no behaviour change, tests updated in step.
What is the problem?
Issue #8166 recorded two accepted follow-ups from PR #8153's review. This PR takes item 1 only:
create_provider_factory's_acp(acp_backend=...)kwarg and theexplicitprecedence arm ofmembers.select_provider_backendthat it feeds have no non-test consumers. They are an unconsumed seam sitting on the provider-construction path.Item 2 (session-key prefix normalization at one boundary) is deliberately out of scope - see the last section.
Why this issue matters to the user
An unconsumed seam on a construction path is a maintenance and review cost with no user benefit: it is one more parameter every reader of the factory has to account for, one more arm the harness-parity review has to reason about, and a false signal that a per-slot backend picker is imminent. The repo's boundary/harness-parity gate already pushes toward exactly one selection gate on the kiro construction path with no branching of its own; a dead precedence arm is friction against that direction. Removing it is behavior-preserving for every user.
How our fix solves it (symptom -> root cause)
select_provider_backendtakes a leadingexplicit: str | Noneand returnsresolve_selected_backend(explicit)when it is truthy;_acpdeclaresacp_backend: str | None = Noneand forwards it as thatexplicitargument.config/loader.py) never passesacp_backend, and no per-slot backend picker consumes it anywhere insrc/. I confirmed the absence with a control - the same grep method finds the live member-route caller (which passessession_key, notacp_backend) - so the instrument is not failing silent. The three tests that exercised the arm were its only exercisers, matching PR feat: crew member dispatch via per-session session_* mount on ACP backends #8153's review and dwu96's re-triage on the issue.explicitparam + its arm fromselect_provider_backend(precedence is now member-DM auto-route > configured default), and drop theacp_backendparam from the_acpclosure. The closure keeps**_kwargs, so a stray keyword is still absorbed harmlessly. The kiro construction path is unchanged (harness-parity H13: no conditional/argument/failure-mode added to it - a branch is removed), and the member/default arms are behaviorally identical.What tests we did
pytest -n0 test/test_member_dispatch_mount.py- 35 passed (deletedtest_explicit_pick_wins, which only exercised the removed arm; updated the 3 survivingselect_provider_backendcalls to the 3-arg signature).pytest -n0 test/test_config_loader.py -k "factory or provider or backend"- 18 passed, includingtest_factory_resolves_canonical_crew_identity(exercises the_acpclosure).black --check,isort --check-only,flake8,mypyon the three touched files - all clean. Brand-name gate clean on added prose.acp_backend=site and confirmed each is anAcpClient/AcpProvider/AcpRuntimeconstructor (the instance attribute), not the factory kwarg - untouched.Any other suggestions on the work
mcp_core.py'sstartswith("channel:")guard,dashboard/token_auth.py,mcp_gateway/claim.py/stub.py,session_allocation.py) with no agreed canonical-key contract;history_search.pyalready carries idempotent "collapse stackeddashboard_prefixes" logic andis_member_session_keyaccepts three spellings - both symptoms of keys travelling un-normalized. The issue text, CrysisDeu's triage, and dwu96's re-triage all call item 2 "larger than any one feature PR" / architecture. A mechanical sweep without that contract risks silently disarming a confinement check, so it wants its own design pass, not a rider on this cleanup.Refs #8166