Repository navigation
Draw a group's own header until its first message (#998) - #1017
Conversation
|
Verdict: INC at e4b5e34 两条:一条让这个 tip 的 CI 红,一条是功能上的真洞(不是风格)。 ① CI 红在
② 门太松:发送中、以及首条发送失败后,会同时出现两个头 宿主头不是“零回合一概不画”。它的判据是 所以从点 Send 到第一回合开跑之间: 改法一行,在 const blank = session?.blank === true && session?.promptAttempted !== true(
Ran: 其余我看过的地方没有问题,不用动:hooks 都在那个早退之前;order 30 排在 |
e4b5e34 to
669d43b
Compare
Creating a group opens its Session with zero turns and the host draws no session header then, so a group made from "Create group chat" showed only its sidebar row (#998). The dock now hands `blank` to every `flybot.session.dock` slot and the social plugin's `social-group-strip` draws the group's name, its members and Invite by link exactly then. "Has said nothing" is not the host's condition, though: the host draws no header only while `session.blank && conversationPhase(...) === 'blank'`, and a session that has been sent to already reads `engaging` (a failed first send never turns it blank again). The dock therefore passes `session.blank === true && session.promptAttempted !== true`, so the strip and the host's header can never be on screen together, and its test pins both halves. Fixes #998
669d43b to
0695233
Compare
|
INC both taken, new tip ① Docs split by owner. You are right that the contract belongs to ② The condition is narrowed to the host's own. Bundle and Please judge |
|
Verdict: PASS at 0695233 新 tip 上两条 INC 都落地了;这一条按新树重判,旧 tip ① 条件: ② 文档归属:约定只在 顺手核过、不在本次 INC 内的: Ran: $ node api.mjs /repos/ThinkFlowLab/FlyBot/commits/0695233947165da107e14f294cd46b7c5e758b1a/check-runs
# 12 success,enqueue-guard 失败是在等这条 PASS
$ node --test core/test/overlay-approvals.test.js
# 6/6
$ node -e '条件改回 session.blank' && node --test core/test/overlay-approvals.test.js
# 5/6,只掉 {blank:true,promptAttempted:true} 那条
$ node -e '从 dock 的 props 里拿掉 blank' && node --test core/test/overlay-approvals.test.js
# 5/6,#998 红:槽位收不到这个事实
$ node --import ./test/resolve.mjs --test "test/*.test.js" (plugins/social, tip 树)
# 437/437
$ node -e '去掉 GroupStrip 的 blank 门' && 再跑 social 全套
# 436/437,只掉 #998 那条
$ node scripts/ds-bot-patches.mjs check
# skipped pin (no git) / ok 10 patches / ok core/ equals ds-bot/ + patches/ds-bot/非阻断(不挡这张):
|
Owner: Dev4
Reviewer: Reviewer
Base: c52a9ba
Tip SHA: 0695233
Fixes #998
Reproduce
/new-chat→ Create group chat → name + members → Create: the app lands on a session with a blank draft. Nothing above the composer names the group, says who is in it, or offers an invite; the group exists only as a sidebar row. Typing one line makes the host's session header appear, which is why the shape read as "the group appears only after the first message".Mechanically the host draws no session header at all for a Session with zero turns, and
flybot-slots.js'sFlyBotSessionDockreceives thesessionbut dropped that fact instead of passing it to the slots.What changed
core/src/client/flybot-slots.js:FlyBotSessionDock({ sessionId, useRoster, actions, session })computesconst blank = session?.blank === true && session?.promptAttempted !== trueand addsblankto everyflybot.session.dockslot's props. That is the host's own condition, not just "has said nothing": the host draws no header only whilesession.blank && conversationPhase(...) === "blank"(dsh-client-ui-conversation), and a session that has been sent to already readsengaging— so standing in onsession.blankalone put two headers on screen from the Send click until the first turn, and forever after a failed first send, which never makes the session blank again.core/types/flybot.d.tsmirrors the same wording;core/client.jsis the rebuilt bundle.plugins/social/client.js: newGroupStrip({ room, roster, blank })—nullunlessblank === true, the id is a room id and it is not a face room; then the group's name, its members' names, and Invite by link (sameroom-invite-mintroute the Members card uses, inline with Copy link). Registered asflybot.session.dock#social-group-stripat order 30, beforesocial-room-end(40); exported. Five.fs-group-strip*rules.plugin-runtime.mdcarries the slot contract (blank= nothing said and nothing sent, and why);core-client.mdcarries one line in Generated bundle for the rebuilt artifact, pointing at plugin-runtime as that page does for#818;social.mdhas### A group's own header before its first turn (#998).changelog.d/998-group-strip-before-first-turn.added.md.patches/ds-bot/0008-client-bundle.patchregenerated and the threepatches/ds-bot/files/mirrors refreshed.No new host surface: this uses the existing dock slot, so nothing is needed from the upstream header the repo does not own.
What I ran
plugins/social: 437/437, 0 skipped.core/test/overlay-approvals.test.js: 6/6. The#998test pins four inputs:{ blank: true }→true,{ blank: true, promptAttempted: true }→false,{ blank: false }→false,undefined→false.node scripts/ds-bot-patches.mjs check:skipped pin (no git)+ok 10 patches apply cleanly in order+ok core/ equals ds-bot/ + patches/ds-bot/; the regenerated0008reproducescore/client.jsbyte for byte (354 hunks).node .github/scripts/changelog.mjs check: the fragments inchangelog.d/are well formed.oxlinton the four touched files: 0 errors; the 10 warnings are the same 10 the untouched tree reports at the same lines.arch-docsneedsgit diff, which this machine does not have, so I ran the checker's ownloadSubsystemMap/pathMatchesOwnedover this tip's 14 files:core/client.js→core-client(touched),flybot-slots.jsandflybot.d.ts→plugin-runtime(touched),plugins/social/*→social(touched), 0 missing. The real check runs on CI.Red without the source change
Pristine (before this PR), only this PR's test files dropped in:
core/test/overlay-approvals.test.js→ 5 pass / 1 fail,not ok 5 - #998: the session dock tells a slot whether the chat is still blank(the slot'sblankisundefined).plugins/social→ 435 pass / 2 fail,not ok 260 - #998: a zero-turn group draws its own strip…andnot ok 69 - client.js registers a sidebar section and @ rows…(the expected-slot list now namesflybot.session.dock#social-group-strip, which pristine does not register).Three knives, each on a copy of this tree, each restored:
session.blankback as the condition (the loose one this round fixed) → the core test goes red on exactly the{ blank: true, promptAttempted: true }case: 5/1.blank: blank === truefrom the dock's slot props → core#998red (5/1).blank !== true ||fromGroupStrip's early return → the plugin test goes red (436/1), because the strip then draws for a non-blank chat and for a dock that was never told.Not run
core/suite: it was running against the pre-INC tree, six othernode --testrunners were on the machine at the same time, and it had stopped making progress, so I killed it rather than report a number from a stale tree.core/'s full run is CI'stests-ok/ Node 24 job, and the reviewer's own run./new-chatflow. The one visual claim I make — that the host's header and the strip never share the screen — rests on the host's condition as read indsh-client-ui-conversation, and is pinned by thepromptAttemptedcase rather than by a screenshot.mergeable_stateand the rest of this tip's CI: for the reviewer to read after the push, not claimed here.Risk
Low. The dock change is one prop on an existing slot,
false/undefinedfor every session that has said something or been sent to — i.e. every session today except a brand-new one — plus a type line, so no existing slot can change behaviour. The strip only renders on ablankroom session: never for a Bot chat, a face room, or a session with a turn or a send, and it reuses the Members card's invite endpoint rather than adding one. The rebuild ofcore/client.jsis the usual 3-line bundle delta and the patch series reproduces it exactly. Rollback is deleting the slot registration and the prop.