Two findings from the openchamber-bot review at 478f1e9c:
1. Pending selections silently swallowed the Open-in-Finder pick
(prev #4). handleOpenInFinder flows into the batch-first branch of
finalizeSelection, so with checkboxes ticked the OS pick was
ignored and the selections were added instead. Clear selectedPaths
before finalizeSelection so the Finder-sourced target is honored.
2. Within-batch dedup was missing in the VS Code branch (nit from
the previous review). A path repeated within one batch hit
addWorkspaceFolder twice. Mirror the non-VS Code contract with
a seen Set; add a regression test asserting the host is called
once per unique path.
Two non-blockers from the openchamber-bot review at b2ab4af15:
1. VS Code batch add reported a misleading failure. addProjects
returned [] unconditionally for the VS Code runtime because
addWorkspaceFolder is reached only by addProject. Iterate addProject
per path so valid selections succeed and the host is called once
per selection. addProjects is now async (returns Promise<ProjectEntry[]>);
the call site in DirectoryExplorerDialog awaits it; existing
tests in useProjectsStore.test.ts updated to await.
2. Turkish locale (tr.ts) was missing the two new keys that other
11 dictionaries received: actions.addSelected and browse.selectForAdd.
Add both with real Turkish translations: "Seçilenleri ekle" and
"Eklemek için seç".
Two blockers from the openchamber-bot review:
1. Space swallowed in the path input. The handler at
handleKeyDown was calling preventDefault on every Space,
turning paths with spaces into no-op strokes and toggling the
highlighted row instead. Gate the toggle on hasTrailingPathSeparator
(query) so Space is a literal character when the user is typing
a path or filter and only acts as a selection toggle when they
have navigated into a directory.
2. Batch path was unreachable when the filter had no exact match.
With checkboxes ticked and a typed filter that has no exact match,
shouldCreateTarget evaluated true and the primary action (Add
selected) called createDirectory for the typed text instead of
adding the selections. Move the batch branch above
shouldCreateSelection so explicit selections always win over the
single-target create path. Drop the trailing else-if (now
unreachable) which also lost { asProject: true }.
The variable was referenced at line 484 (the single-target create branch)
but never declared, so every non-clone add path (Add button, Cmd+Enter,
Open in Finder, mobile add) threw a ReferenceError that surfaced as a
'Failed to select directory' toast. Add the missing local declaration
matching the condition the original review intended: !isCloneMode &&
shouldCreateTarget && the target path equals the user-typed path.
The checkbox button calls togglePathSelection() on click but does not stop
event propagation, so the click bubbles to the parent row's onClick which
calls executeRow() -> browseToEntry(). With a mouse, every checkbox click
would (a) toggle the selection, (b) navigate into the directory, and (c)
the navigation effect would clear selectedPaths. The primary interaction
of the multi-select feature was unusable.
The existing handleQuickAdd helper avoids this exact bug by calling
event.stopPropagation() inside its onClick handler. Apply the same
pattern to the new togglePathSelection onClick.
Refs openchamber-bot review on #2877.
Add a multi-select mode to the "Add project directory" dialog: each
directory row gets a select toggle (checkbox icon, Space toggles the
highlighted row), and the primary action becomes "Add selected" and
registers every selected directory in one store update. Selections apply
to the currently browsed directory and reset on navigation, dialog open,
and clone-mode entry. Clone mode keeps its single-target flow.
Add addProjects() to useProjectsStore: validates, normalizes, and dedups
paths (already-added or duplicated), creates entries in a single state
update and single persist, activates the first newly added project, and
discovers icons for each entry. Mirrors addProject semantics for the
single entry.
Refs OPE-142
Canonical answer to 'is this reachable in VS Code': three webview hosts,
VSCodeLayout's three views, a 33-row surface table (mounted / partial /
not mounted with the mount chain or cut-off point), the dead-bridge
handler list, and which fs routes stay live. Reviews, changelog entries,
and parity claims consult this map; whoever mounts or unmounts a surface
updates it in the same change.
- changelog-authoring: a VS Code entry requires the surface to be
mounted from the VS Code entrypoint (consult the surface map in
packages/vscode/src/DOCUMENTATION.md when present); shared-but-unmounted
code earns no entry
- triage-prs: yulia-ivashko is a core maintainer with merge rights —
her review decisions carry maintainer weight in sweeps
A shared component importing a runtime API proves nothing about that
runtime; the runtime's own entrypoint must mount the path. Trace
top-down before claiming a bug or fix is user-visible in a runtime —
VS Code's layout mounts only a subset of the shared surfaces and bites
reviews constantly.
Either the manual check guards an irreversible path and the verdict
reads 'MERGE — after you verify X', or the verdict is a plain MERGE
with no checklist: residual cosmetic risk is absorbed by the verdict
(users surface it, a revert costs one commit). Post-merge homework
lists were the reviewer offloading uncertainty onto the maintainer.
A manual check either guards an irreversible path (data loss, upgrade
and restart flows, auth) and gates the merge, or it is low-risk visual
polish where merging first is fine and skipping the check is stated as
accepted risk — never a ritual list padded to feel thorough.
- PRs/issues with human thread activity run in pickup mode across all
three skills: the output opens with thread state (asked / answered /
resolved at HEAD / remaining) and continues the conversation instead
of restarting review — the sweep remembers the maintainer's own
comments for them
- every PR/issue reference in maintainer-facing output is a clickable
markdown link, never a bare number
- report entries are calibrated: 2-4 sentences each (what, why this
verdict, main risk), needs-your-hands lives inside the entry rather
than a number-repeating section
"Restart to Update" answered the renderer with null before the install was
attempted, so a rejected install only reached main.log and the button looked
dead. The apply-update path now keeps the IPC call open until the app quits or
autoUpdater reports the failure, rolls the quit/install flags back when the app
stays up, and the update dialog shows the real reason with a translated hint for
a rejected code signature.
Also settle the download promise on downloadUpdate() itself: an already cached
payload emits no 'update-downloaded', which left that promise pending with its
listeners attached on every retry.
A sweep verifies whether an earlier push-back or recorded product
decision was addressed at the current HEAD and reports that explicitly;
it never re-decides or re-asks. The generic rebase-request is never
posted over an existing substantive review comment.
Conversation-style entry points so the maintainer can start real work
without opening the GitHub UI: feature-work serves a menu of accepted
features (approved scope from the acceptance comment is binding);
bug-work serves verified bugs from the local fix backlog and the
root-cause:found label, severity-first, re-verifying anchors before
fixing. Both close the loop with fixes #N in the eventual commit.
A maintainer's answer on a FEATURE-DECISION now resolves mechanically:
wanted features get an acceptance comment plus the new accepted label
(never re-asked by later sweeps; label:accepted is the implementation
roadmap), declined ones get the drafted close; conditional answers are
recorded as the accepted scope.
triage-issues gains a silently-fixed detection ladder, strongest
evidence first: mechanism-anchor (git log -L on the root-cause:found
file:line since the issue date), repro re-run against current main, and
symptom search over commits/CHANGELOG/merged PR titles. CLOSE-FIXED
always names its evidence; an unverified hunch only asks the reporter
to retry.
pr-review's merge verdicts now search open issues for the symptom a bug
fix resolves and propose Closes #N, so fixes stop landing unlinked.
One issue now gets one comment instead of two posted minutes apart
(the old triage bot asked questions its reproduce sibling then answered
itself). The combined issue-intake agent, driven by an audit of recent
bot output:
- duplicate check before anything else — duplicates are closed, not
reproduced (the duplicate label had zero uses across 1,353 issues
while the bot found duplicates in prose)
- reproduction artifacts live in a collapsed block inside the comment;
the reproduce/issue-N branch convention is retired (382 stale branches
removed from origin)
- reproducible:true renamed to root-cause:found — it asserts a traced
mechanism, not reporter-confirmed causation; confirmed:reporter is the
human-set complement
- the bot no longer sets priority (maintainer-only flag), announces its
labels, opens with flattery, or interrogates feature reporters about
design decisions
- comment opens with a For-the-maintainer line (fix-ready /
needs-reporter / duplicate / likely-fixed / feature)
- label taxonomy cut from 65 to ~26: api:*, reproduction-steps:*,
priority:medium/low, 13 near-zero-use area labels, ios/android
platforms, and orphans removed
- runs on zai-coding-plan/glm-5.3-flash via ZHIPU_API_KEY
- new triage-issues skill mirrors the PR triage pipeline: mechanical
sweep, verdict fan-out, approved batch actions, fix backlog
Post-merge hardening of the session-to-worktree move (#2998), driven by
review findings on the follow-up pass:
- an ambiguous transport failure (relay abort, timeout) on the
change-carrying move no longer force-deletes the fresh worktree that
may hold the user's only copy of their changes; both intent kinds
surface honest guidance and refresh both directories
- assertSdkSuccess re-tags ambiguous transport errors when wrapping SDK
failures, so ambiguity classification survives the wrapper on every
path, matching the prompt-send precedent
- session liveness checks scan all child stores plus the global status
index, and report unknown (not idle) when no store covers the session
— an evicted background directory can no longer make a busy session
look movable
- incomplete-rollback errors carry the changes-may-be-in-destination
guidance instead of swallowing it
- move-message assembly shared across the three call sites; tests now
exercise the real ambiguity classifier (extracted to
send-failure-classification.ts) instead of a hand-mirrored mock
- i18n fallout from the merge train: Turkish gains the 21 worktree-move
keys, all 12 locales get the hedged ambiguous-failure toast; owning
DOCUMENTATION.md files record the new contracts
Comments and reviews from patrick-motard and mattv8 are strong human
signals during batch triage: their approval upgrades confidence, their
concerns become findings to verify. They write free-form; sweeps map
their conclusions onto the verdict ladder.
Re-enable the automated PR review (pull_request_target + /oc-review
comments) on zai-coding-plan/glm-5.3-flash via ZHIPU_API_KEY.
Recalibrate the output contract based on an audit of 69 past reviews
(22 PRs, Aug 15-18): 18 of 27 BLOCKED verdicts were template-policing,
3.1 reviews per PR, ~8.4K chars per comment.
- BLOCKED now means code/merge problems only; handoff/template gaps move
to a separate one-line Handoff flag that never changes the verdict
- re-reviews emit deltas (verdict + what changed) instead of full
re-emission; push-triggered re-reviews are throttled to one per 15
minutes (manual /oc-review always runs)
- hard length budgets by change class; the applied-guidance table is
gone (guidance is applied silently, named only when it produced a
finding); empty evidence/security sections are omitted
- evidence demands are single-shot and escapable, never raised for
dependency bumps, string edits, server code, or packaging
- the comment opens with a one-line maintainer verdict (merge / merge
after X / don't merge because Y), enforced by the workflow
- triage-prs skill treats review:* labels as a pre-sort for verdict
reviews
herjarsa