You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
schedules: follow-ups from #1322 — the new-task form preselects a Bot, and the copy test seeds the pick #1334
Follow-ups from the review of #1324 (PASS at 413092195c4501bf54806bca17283b23e72762ed, 04:04:22Z), which fixed #1322. Neither blocks that pull request; they are recorded so the review's non-blocking findings do not live only in a comment.
1. The new-task form still opens on the first roster Bot. core/src/client/schedules.js:174 (TaskForm) seeds target with roster.bots[0]?.id. #1322's "Out of scope" keeps it out of that fix, so #1324 does not claim it — but the shape is the one #1322 fixed in CopyRow: a form that opens with a target already chosen can send on one click to whoever sorts first. Decide whether creating a task should also require a deliberate pick (or whether the first Bot is a wanted default there).
2. The picked-target half of the new copy test seeds the pick instead of firing onChange. core/test/schedules-client.test.js:282 pushes 'g1' into the shim's seeded state, so what is pinned is "submit with a target sends it", not "choosing in <select> sets target". The handler (schedules.js:369) predates #1324 and is unchanged, so nothing is broken; a select.props.onChange({ target: { value: 'g1' } }) before the second onSubmit would pin the path a person actually takes.
Both were left alone on purpose: changing either moves the tip of #1324 and voids its PASS at this sha.
Claimed #1334 — first step: read TaskForm in core/src/client/schedules.js and the seeded pick in core/test/schedules-client.test.js.
Scope per the owner decision above: only item 1 — the new-task form no longer seeds target with roster.bots[0]?.id; it opens with nothing selected and sends nothing until a Bot is picked. Item 2 stays out.
Branch: dev/1334-taskform-no-preselect (from main at 2349444).
Activity
Birfy commentedon Oct 28, 2026
Written-by: Triage
Park 在本轮:卡在第 1 条判据(设计冲突未闭)与准入线(两项都不是可复现缺陷)。
onChange」(core/test/schedules-client.test.js:282,seeded.push('g1')):是测试覆盖缺口,不是行为 bug;按准入线不单独立项开 PR,留给将来碰这块测试的改动顺手补。needs-human、摘needs-info。Birfy commentedon Oct 29, 2026
Written-by: Triage
Owner 决定:放行,只做第 1 项(用户 2026-10-29 拍板「全按建议走」)。
范围:
core/src/client/schedules.js:174的 TaskForm 不再用roster.bots[0]?.id预选 target;新建任务要一次明确的选择(初始不选中,未选则不发)。不做:第 2 项(
core/test/schedules-client.test.js:282的播种)不单独立项;顺手补一条select.props.onChange({target:{value:'g1'}})路径断言可以带上,但不作为本单验收。验收:新用例断言表单初始不选中任何 Bot、未选时提交不发;撤掉改动后变红。
Birfy commentedon Oct 29, 2026
Written-by: Triage
快路径确认,不重新调研:#1334 已带
agent-ready,scope 以上一条评论为准——只做第 1 项(core/src/client/schedules.js:174的 TaskForm 不再用roster.bots[0]?.id预选 target,未选则不发),第 2 项不立项。摘掉并存的needs-human,状态标签只剩agent-ready,下游实现节点直接开工。Birfy commentedon Oct 29, 2026
Written-by: Dev
Claimed #1334 — first step: read
TaskFormincore/src/client/schedules.jsand the seeded pick incore/test/schedules-client.test.js.Scope per the owner decision above: only item 1 — the new-task form no longer seeds
targetwithroster.bots[0]?.id; it opens with nothing selected and sends nothing until a Bot is picked. Item 2 stays out.Branch:
dev/1334-taskform-no-preselect(frommainat 2349444).