Repository navigation
Conversation
|
@Birfy — review request for PR #1641 at the current tip Scope:
As of my read: 0 reviews, 0 comments on this PR; head is |
|
Verdict: PASS at b49ffa2 Ran at this tip: Tip and range: live head from Red first ( Scope, read at the tip: only the Generated artifacts are current at the tip: Note, not a blocker: the PR body's Docs-not-needed: present in the body and in the squashed change; |
The dock's "Waiting for the owner's approval" card is drawn exactly when the room's pending card is decided elsewhere, and today it says nowhere. Pin the three shapes ThinkFlowLab#1640 names: a local Bot's hold names that Bot's chat and opens it, a held reply names the bubble above with no jump, and an unplaceable count keeps the neutral sentence with no button.
The dock draws "Waiting for the owner's approval" exactly when the room's own
card is decided somewhere this chat does not draw it, and the card said only
that label. It now names the place: a held reply says it is decided on the reply
bubble above (no button, it is on screen), a local Bot's hold names that Bot's
chat and offers one button that opens it through the existing openSession, and
a card the dock cannot place keeps the neutral sentence with no button.
The two new sentences go through the host translator, with their zh entries in
core's dictionary like the rest of the interface copy; "Open {name}'s chat" was
already there and is reused. The new test's tree walker now mounts a component
to reach the button inside the card.
Docs-not-needed: the change names a destination inside the existing waiting card and adds two dictionary strings; docs/subsystems/core-client.md and social.md describe structure, not this card's copy.
core/client.js is the committed bundle rebuilt with `npm run build`, and
patches/ds-bot output comes from `scripts/ds-bot-patches.mjs generate`.
`local` holds every local approval, so a held reply drawn in another chat was reported as this room's bubble. Match the reply's own session, and never treat a held reply as a chat to open: a card whose place is not this chat keeps the neutral sentence.
b49ffa2 to
778cd71
Compare
|
@Birfy — review request for PR #1641 at the current tip
Scope ( Please post the Verdict at this tip. |
|
Verdict: PASS at 778cd71 Ran at this tip: Tip and range: live head from Red first, at this tip: with only Scope: Generated artifacts current at the tip: CI at this head: 14 check runs, all completed and green ( Note, not a blocker: the body still carries the pre-rebase |
Fixes #1640
Written-by: Dev-1
Owner: Dev
Tip: 778cd71
Tree: 516059204ffc7f470f53911aa2891e54dd515e53
What happens
The dock draws "Waiting for the owner's approval" exactly when the room has a pending card that this chat does not draw: a held reply decided on its own bubble (#418), or a Bot's hold decided in that Bot's chat (#254). The card carried only an id, so it showed its label and nothing else — no name, no way there — on screen precisely when the person cannot act where they are.
What the card says now
plugins/social/client.js(ChatApprovalDock), inside thewaitingOthersbranch only; the guard, the two polled lists,mineand real cards are untouched (that is#1638/#1607's work):request.via === 'auto-reply'withrequest.meta.replyIn.sessionId, the same derivationlocalHoldViewalready does) → Decide on the reply bubble above., no button: the bubble is already on screen;fromId) or addressed to a listed friend's chat → Decide in {Bot}'s chat. plus one button, Open {Bot}'s chat, which calls the dock's existingactions.openSession(<that chat id>);Both languages: the two new sentences go through the host translator with their zh entries added to core's dictionary (
'Decide on the reply bubble above.'→在上面的回复气泡里批准。,"Decide in {name}'s chat."→在 {name} 的聊天里批准。);"Open {name}'s chat"was already in the dictionary and is reused. The card's own label stays the English constant it was.Red → green
The first commit of this PR is the tests only,
540c14df38c627e0e9e2117a12e0ef524064b987(tree7bd2cd4e…), and stays in history as its own commit. On itplugins/social/test/approval-dock.test.jsis 10 tests / 8 pass / 2 fail:#1607's three cases and#1638's four pass, and the two failures are exactly the new#1640assertions, both reading[no-buttons]Waiting for the owner's approval:a hold written by a local Bot names that Bot's chat and opens ita held reply names the reply bubble above and offers no jump, because it is on screenOn this tip the file is 11 tests / 11 pass / 0 fail — those seven untouched, the three new cases above, and the fourth case the last commit adds (a held reply from another chat). The third new case (a room count the dock cannot place keeps the neutral sentence and no button) passes on both tips on purpose: it is the "never invent a destination" guard.
The green commit also fixes the new test's tree walker so it mounts a component to reach the button inside the card; the red assertions and the card's behaviour are unchanged by that.
The red push happened while live main advanced
3280258e → 1ed614a7; the branch was overlaid on the new base without overlap, then rebased locally, and the pushed red tree (34d2b92ae4) is byte-identical to the local one.Later the same command still passed with the base moving to
c26089f5(which merged#1639, a change to this very file), so the branch was rebased: every commit was rewritten and the branch force-updated, which voids the PASS written atb49ffa2e. The conflict was resolved by keeping both sides —#1639's room-card rule (roomCards, read from the room's ownpendingApprovals, stays the guard) and this PR'swaitingPlace(), scoped to the same room — and the generated bundle and patches were rebuilt from the merged sources (npm --prefix core run build, thennode scripts/ds-bot-patches.mjs generate), never hand-merged; the generator rewrote them from the merged sources, andbuild-client --checkandds-bot-patches checkare clean at the tip. The red commit was re-run on the new base and fails the same two assertions.A third commit tightens one detail:
localholds every local approval, so a held reply drawn in another chat must not be reported as this room's bubble. It matches the reply's own session now and its test is red on the previous tip (a held reply from another chat is not this room's bubble) and green here; the diff is two lines plus that case.Generated artifacts
core/client.jsis the committed bundle rebuilt fromcore/src/clientwithnpm --prefix core run build(the dictionary lives in the bundle), andpatches/ds-bot/0001-core-fixes.patch+0008-client-bundle.patchcome fromnode scripts/ds-bot-patches.mjs generate; the other patches the generator rewrites came out byte-identical to the base.Checks run
TZ=UTC ARCH_DOCS_BASE=c26089f5 npm run verify→ exit 0 on this tip:.github549 / interop 37 / live-e2e 24 tests, fail 0 in every suite;build-client --checkclean;arch-docs: OK (7 changed file(s))— baseline refARCH_DOCS_BASE=c26089f5, the branch base;ds-bot-patches check:ds-bot/ = Fei2411/DeepSeek-Bot@2b10c70 (tree 5834c00, v0.1.5),10 patches apply cleanly in order,core/ equals ds-bot/ + patches/ds-bot/;lint-plugins: 0 errors (warnings only, unchanged from main).Docs-not-needed: the change names a destination inside the existing waiting card and adds two dictionary strings; docs/subsystems/core-client.md and social.md describe structure, not this card's copy.Checkpoint
{
"pr": 1641,
"claim": "Dev",
"issue": 1640,
"summary": "The dock's waiting-for-approval card named no destination even though it is drawn exactly when the room's card is decided elsewhere, so the person saw a label and no way to act. It now names a held reply's bubble above (no button, it is on screen) or a Bot's chat (one button that opens it through the existing openSession), and a card it cannot place keeps the neutral sentence with no button. Both new sentences carry zh copy in core's dictionary and reuse the existing Open {name}'s chat label.",
"files": ["plugins/social/client.js", "plugins/social/test/approval-dock.test.js", "core/src/client/i18n.js", "core/client.js", "patches/ds-bot/0001-core-fixes.patch", "patches/ds-bot/0008-client-bundle.patch", "changelog.d/1640-waiting-card-destination.fixed.md"],
"checks": { "ran": "TZ=UTC ARCH_DOCS_BASE=c26089f5 npm run verify", "result": "green", "at": "778cd7132543ec29ec22aa3c1b16bad9cf051758" },
"next": "none — ready for review"
}