Repository navigation
feat(bridge): run installed Show Me and Retro with session or item scope - #78
Conversation
timeleft--
left a comment
There was a problem hiding this comment.
Reviewed exact head 6a96e31 against #71 and the Show Me/Retro contract in #55. Availability uses the installed command list, missing commands send nothing, invocation preserves session/item scope, and the atomic pending slot suppresses repeats until settlement. The current navigation and explanation remain intact; no prompt, subagent or cross-session API was added.
Independent validation: 54 real mod tests pass with the integrity-checked Claude Code 2.1.296 and with the minimum 2.1.293, and both call reports remain within #55's allowlist. The repository version check passes for 0.8.0 to 0.9.0; all six protected source checks are green on this exact head. The selected-item seam is prepared for #69 integration; that integration must retain public-pane scope and refresh discovery coverage. Installed-host acceptance remains #73.
No material defect or unmet acceptance was found in this slice.
Closes #71. Part of #55.
What this does
Show Me and Retro in the Claude Captain's Bridge pane now run only the Captain's own installed commands, in this exact session, with an explicit scope.
$.command.list()when the Bridge opens and on each refresh. It accepts the configuredshowMeCommand/retroCommandname or<plugin>:<name>.command.list, returns to this state.$.command.run({command, args}).argsisthis session, or the selected item's title with its evidence refs and the timestamps of the records they cite. The scope is read from the skeletonviewstate, so this slice works before the overview/detail slice lands and adds no dependency on it.prompt.submit/prompt.fill, starts no subagent and sends nothing cross-session. Retro asks for suggestions and applies none.pendingis claimed atomically; repeat presses (including the other action) are ignored until settlement, which clears it on success or error. A non-unknown failure shows a retryable notice. Navigation and the explanation are untouched.CI allowlist parser
claude plugin validate2.1.296 annotates calls made inside helper functions as$.command.run (via runAction). The existing parser rejected that. It now accepts only that exact annotation and still checks every call name against the #55 allowlist (a forbidden call behind a(via ...)is still rejected; malformed annotations still fail closed). Tests added.Evidence
claude plugin test(pinned 2.1.296, empty HOME): 54 pass, 0 fail acrosshooks/register.test.tsxand the newhooks/actions.test.tsx. The new tests cover unqualified, namespaced and configured availability; missing disabled state with zero sends; whole-session and selected-item scope with refs and timestamps; one queued call during delayed settlement; repeat suppression; error recovery; unknown-name rejection; and bothterminalanddesktoptrees.claude plugin validatecall list is within the allowlist:$.command.list, $.command.register, $.command.run, $.session.id, $.session.version, $.state.get, $.state.set, $.ui.open, $.ui.resolve.scripts/verify.shpasses (jj 0.45.1, fava-trails pin).scripts/mw-version.py; the Python package and both plugin manifests are synchronized.Not claimed
This is CI/stand-in evidence only, not installed-host acceptance. The
$.command.list()result shape is not exposed by the test kit's$, so the mod accepts either an array or{commands: [...]}of{name}/string entries; confirm against a real host during release acceptance. Existing selected-item tests should be re-run through the public pane seam after the overview/detail slice (#69/PR #76) lands.All fixtures are synthetic. No private paths, sessions or toolkit dependencies.