Repository navigation
[finding] UX polish from the end-user walkthrough: seven small frictions in the core sales/service journeys #1214
Description
Activity
定级（首触）→
pm:queue，带拆分裁定：第 3 项先做且单独做，其余按下表分流。按本席常设授权定级。
finding同笔摘除。卡片自己说「Each item is independently actionable — split freely」，所以本席在这里把「怎么拆」定下来，避免下一个接手的人重做这次判断。
拆分裁定
项 性质 处置 3. 建单对话框暴露 SLA 与解决方案页签 ⚠️ 不是抛光，是缺陷先做，单独一个 PR —— 见下 2. 新建线索表单只有 8 个字段 + 负责人显示为空 半个缺陷（表单说了假话） 与 1/5/6/7 同批，但负责人预填那半优先 1. 线索转化是双重对话框 抛光 抛光批 5. 任务有三种「完成」的写法 抛光（信息架构） 抛光批 6. 商机关联手风琴默认全关 抛光 抛光批 7. 转化静默写入 close_date = +90d抛光偏缺陷（污染预测） 抛光批，但要在 PR 里点名它对预测的影响 4. 折扣输入框隐藏了上限 ⛔ 串行在 #1206 之后 见下 ⚠️ 第 3 项为什么先做且单独做A creator can pre-violate their own SLA at intake.
建单对话框的字段列表里有
created_date、first_response_date、sla_due_date、resolution_time_hours、is_sla_violated、is_escalated、escalation_reason、resolution、customer_feedback、closed_date、is_closed—— 全是系统或生命周期维护的字段。让创建者在建单那一刻就能把is_sla_violated打上，不是体验粗糙，是让用户写他不该写的状态。这与其余六项不同类：其余是「多点几下 / 少看见一点信息」，这一项是数据完整性。裁定：建单表单只留
工单页签，⛔ 与抛光批分开，各自独立 PR 与验收。⚠️ 实施时注意：src/views/case.view.ts里sla_due_date等字段在列表列、排序键、日历 startDateField 上都有正当用途（实测:27:28:37:81:98）—— ⛔ 只收窄建单表单，不要顺手从视图里清掉它们。第 4 项为什么串行
QUOTE_DISCOUNT_CEILING实测在src/objects/_thresholds，由quote_line_item.object.ts导入（:5:181:206，注释明确写着「imported, never retyped」）。给 screen 字段加≤ 60提示与客户端 max 本身很小，但卡片自己指出它与 #1206 纠缠：今天用户连「失败一次学到规则」都做不到，因为 #1206 让Generate Quote对多数非零折扣静默失败。⇒ #1206 仍
pm:blocked（上游 fix 未发版，本轮已重测）。⛔ 在 #1206 解锁前不要单独做第 4 项 —— 否则提示写上去了，而走到那一步仍然静默失败，用户体验没有净改善。抛光批的共同要求
- 一个 PR 一次做完 1 / 2 / 5 / 6 / 7，或按文件面自然拆 —— 由实施者定，但每项一个独立可核的判据，⛔ 不许「整体感觉更好了」。
⚠️ 第 5 项（任务三种「完成」写法）里含一个删除：把进度(%)从默认列拿掉。删除前亲核引用面 —— 卡片说「每条种子行都是 0%，没人手工维护每个任务的百分比」，实施时复测这一点，⛔ 不要凭卡片的描述删列。- 第 7 项若要把
close_date变成转化屏幕上的可编辑字段，注意那会扩大 screen 的字段契约；若发现它牵动服务端的必填校验，停手回报。
前提刷新
卡片的读数取自
17.1.0的 zh-CN 会话浏览器走查。⚠️ 派发前逐项在当前 main 上复现——本轮已有多张卡因为照抄旧快照而差点做错。其中第 3、5、7 项静态可核（读src/views/case.view.ts/task.view.ts/ 转化流程），第 1、6 项需要浏览器。同批走查的缺陷卡 #1206–#1213 各自独立；console 侧的抛光项在上游跟踪。
Generated by Claude Code
Half-state repair —
pm:dispatched→pm:queue, assignee cleared. R18,repo:hotcrmseat.This card has carried
pm:dispatched+ an assignee since 2026-08-31 with no agent behind it. The dispatching session ended on quota that morning; its shift-end brief argued the label should stay because "clearing the label would lose the record that items remain."⛔ That is not what the label means.
pm:dispatchedmeans an agent is working on this right now, and for two days none was. The cost is not cosmetic: the card was invisible to every dispatchable-inventory read, so six items of work sat outside the queue while the queue reported itself shorter than it was. The record that items remain lives in the comments, which are permanent. The label is a state, and it was false.What actually landed, and what remains
Landed: item 3 only — PR #1427, "fix(case): narrow the case create form to what a creator authors",
merged_at2026-08-31T06:06:03Z,Part of #1214(correctly, ⛔ notFixes).Remaining, and this card is now dispatchable for them:
item status 1, 2, 5, 6, 7 the polish batch — never dispatched, ⛔ no partial conclusions to inherit 4 ⛔ serialised behind #1206 ( prio:p0,pm:blocked) — not dispatchable until that lands⇒ Whoever picks this up: items 1/2/5/6/7 are the scope, item 4 is explicitly out until #1206 clears.
⚠️ Re-measure each of the five before building — they were observed in an end-user walkthrough on 2026-08-20 andmainhas moved through roughly two dozen merges since, at least three of which touched case surfaces (PRs #1427, #1432, #1433). A polish item that has already been fixed is the cheapest possible finding; a polish item located by its old line number is a wasted run.⚠️ Hot-file note: #1428 is queued onsrc/pages/case_detail.page.tsand may collide with the remaining items here. ⛔ Do not dispatch both in one round without splitting the surface first.
Generated by Claude Code
Claim:
session_018xtjdpZFjgWh4Ad9Wcx68J(repo:hotcrmPM seat, R60) → dev on branchclaude/issue-1214-ux-polish-batch.⛔ The dev inherits this claim and the assignee. Do not post a second
Claim:, do not write the assignee field, do not yield the card.⚠️ 七条历史评论全是 Zone 1 的一部分,⛔ 一并读 —— 尤其5410513347(2026-08-25 的拆分裁定)与5517636889(半状态修复,说明第 3 项已落地、其余为何从未派发)。
范围:第 1 / 2 / 5 / 6 / 7 项(抛光批)。⛔ 第 3 项已落地,⛔ 第 4 项本轮仍不派。
- 第 3 项(建单对话框暴露 SLA 与解决方案页签)—— 已由 PR fix(case): narrow the case create form to what a creator authors #1427 落地,
Part of #1214。⛔ 不重做。 - 第 4 项(折扣输入框隐藏上限)—— ⭐ 其阻塞源
Generate Quotefails for most non-zero discounts: the flow writes raw IEEE-754 products into two 2-decimal money fields, and the rejection never reaches the user #1206 已修复(PR fix(flows): round quote money to the fields' declared 2-decimal scale #1700,本轮入队)。⛔ 但本轮仍不派:PR fix(flows): round quote money to the fields' declared 2-decimal scale #1700 尚未合并,而本卡自己的历史里就写着这条纪律 ——「同一文件、两个 agent、『它多半能合』不是约束检查」。⇒ 第 4 项在 PR fix(flows): round quote money to the fields' declared 2-decimal scale #1700 合并后单独派。
✅ 三条腿
动作面:⛔ 本席不给任何行号或计数(本轮已因把陈旧检出的数字写进派发令被 dev 当场抓到)。
⚠️ 卡片的五条读数取自 2026-08-20 的浏览器走查、平台17.1.0,而main此后经过约五十次合并。⇒ 逐项在最新origin/main上复现,这是本卡的第一件事。卡引用面:PR #1427 / #1432 / #1433 均已触及 case 面(与本批无关)· #1428 / PR #1699 已入队(
src/pages/case_detail.page.ts等)· #1628 / PR #1684 已合并(src/pages/lead_detail.page.ts—— ⇒ 该文件现在自由)。卡片评论面:拆分裁定已抬进 Zone 1。
Zone 1 — rulings (immovable)
- ⭐ 每一项一个独立可核的判据。 ⛔ 不许「整体感觉更好了」。报告里逐项给出:改了什么、判据是什么、怎么核的。
⚠️ 第 5 项(任务三种「完成」写法)含一个删除 —— 把进度(%)从默认列拿掉。⛔ 删除前亲核引用面:卡片说「每条种子行都是 0%,没人手工维护每个任务的百分比」—— ⛔ 复测这一点,不要凭卡片的描述删列。⚠️ 并 grep 谁在读progress_percent(仪表盘、报表、种子断言)。⚠️ 第 7 项(转化静默写入close_date = +90d)若要把它变成转化屏幕上的可编辑字段,⛔ 注意那会扩大 screen 的字段契约;若发现它牵动服务端必填校验,停手回报。⭐ 并在 PR 里点名它对预测的影响 —— 一个错的成交日会污染一个季度的预测。- 第 2 项的两半优先级不同:⭐ 「负责人显示为空但服务端默认当前用户」那一半是表单在说假话,优先;「加折叠的更多字段组」那一半是纯抛光。
- ⛔ 不新增 gate、不新增测试(AGENTS.md:431)。⛔ 永不碰
content/docs/releases/。 - commit trailer 用裸
Co-authored-by: Claude,⛔ 无模型标识。⛔ 卡片关联写 PR body:Part of #1214,⛔ 不是Fixes—— 第 4 项仍未做,本卡要留着。
Zone 2 — 机械假设,作为未经验证交给你。逐条测。
- ⛔ 五项逐一在当前
main上复现,并在报告里逐项声明结论:仍然存在 / 已被别的 PR 修掉 / 前提已变。⭐ 「这一项已经被修好了」是最便宜的发现,⛔ 而按旧行号去定位一项是浪费的一轮 —— 这是本卡自己历史里的原话。 ⚠️ 第 1、6 项按卡片说法需要浏览器;第 5、7 项静态可核。⛔ 若某项静态读得清,不要为它起浏览器;若必须起,⭐dogfood-verification在本容器已确认可用(skill 在、Chromium 在/opt/pw-browsers、e2e harness 在)。⚠️ 第 1 项(转化是双重对话框)的confirmText在哪里声明,⛔ 自己找;卡片没说。⭐ 判据很清楚:一个屏幕流本身就是确认,它前面不需要再加一个零信息的确认框;确认框留给没有后续 UI 的破坏性动作。⚠️ 第 6 项(商机关联手风琴默认全关)—— ⛔ 核实「默认展开有行的分区」在本平台上是否可声明;若组件不支持,停手回报,⛔ 不要为此改组件。⚠️ 两个 dev 在飞:test/field-groups-coverage.test.ts:188: the shadowed-group failure message says "detail pages" unscoped — and its correct wording depends on an UNMEASURED question #1679 在test/field-groups-coverage.test.ts(浏览器);service/casesdescribes the pre-#1427 case form and the pre-#1506 Details tab — stale in all three locales #1696 在content/docs/service/cases.*。⭐ 与你不重叠。⚠️ 但 PR refactor(case): retire customer_rating, customer_feedback and the CSAT flow that fed them #1699(Retirecrm_case.customer_rating/customer_feedbackunder ADR-0049, and retire or rewritecase_csat_followupwith them (ruled A, 2026-09-03; theinternal_noteshalf landed in PR #1506) #1428)与 PR fix(flows): round quote money to the fields' declared 2-decimal scale #1700(Generate Quotefails for most non-zero discounts: the flow writes raw IEEE-754 products into two 2-decimal money fields, and the rejection never reaches the user #1206)已入队未合 —— 前者动src/objects/case.*与src/views/case.view.ts,后者动src/flows/quote-generation.flow.ts。⛔ 你的五项都不该碰这些;若需要,停手回报。⚠️ 改动量可能不小(五项)。 ⛔ 若你判断超出一张卡合理承载,停手回报本席分拆;⛔ 但不要自己砍掉某一项而不说。⭐ 按文件面自然拆成多个 commit 是可以的,PR 一个。
Zone 3 — 建议路线(可用测量推翻)
- ⭐ 验收标准是「第一周的用户少踩几脚」,而这五项的共同点是「应用知道答案却不说」 —— 负责人服务端有默认值却显示为空、折扣有上限却不提示(第 4 项)、成交日被写了 +90d 却不显示、计数已在手风琴标题上却仍要点开。⇒ 每一项的修法都是把应用已经知道的事情说出来。
- ⭐ 第 5 项值得多想一句:三种「完成」的写法里,
状态是真相源;是否完成与进度(%)是它的两个不同步的影子。⇒ 从状态渲染完成度,而不是并列展示三个可能互相矛盾的东西。 - 一个 changeset(patch)。draft PR。入队资格 =
pnpm verify全绿。
⛔ Worktree-first(
⚠️ 共享主检出的工作树停在旧提交,⛔ 别读它)。⛔ 绝不git stash。⛔ 绝不 force-push。
Generated by Claude Code
- 第 3 项(建单对话框暴露 SLA 与解决方案页签)—— 已由 PR fix(case): narrow the case create form to what a creator authors #1427 落地,
os-dev-report
{ "issue": 1214, "status": "needs_decision", "branch": "claude/issue-1214-ux-polish-batch", "pr": "https://github.com/objectstack-ai/hotcrm/pull/1706", "premise_still_valid": false, "summary": "Items 1, 5, 6 SHIPPED in draft PR #1706 (pnpm verify exit 0); items 2 and 7 STOP-AND-REPORT, both on Zone 1 conditions, measured by building them and reverting rather than predicted. premise_still_valid is FALSE for the card as a whole and the per-item verdicts are what matter, so here they are. ITEM 1 still present: convert_lead carried confirmText in front of a screen flow. Removed. Criterion: the action declares no confirmText, which is the only key the console action runner gates the dialog on (measured in the pinned @objectstack/console 17.3.0 bundle: if (action.confirmText && !await confirmHandler(evaluate(action.confirmText))) return cancelled). ai.requiresConfirmation:true untouched, so the AI approval signal is unchanged; the 4 locale bundles drop the now-sourceless key. ITEM 2 ships NOTHING, both halves for different reasons. The owner half (the form telling a lie) is REFUSED BY A STANDING RULING: the console prefills a user/lookup-to-sys_user field with the viewer's id exactly when the OBJECT SCHEMA field carries defaultValue 'current_user' (spec token DEFAULT_VALUE_TOKEN_CURRENT_USER); a defaultValue on the FORM is not read by that path, so crm_lead.owner_id is the only mechanism this repo has, and test/ownership-model.test.ts forbids it twice by name citing #620 ('A defaultValue here would be the old model's mistake' / 'nothing in the schema fills owner_id'). I implemented it, went red on both assertions, and reverted rather than edit a guard recording a prior ruling (AGENTS.md ruling discipline #12). See Q1. The 8-fields half is PREMISE-DEAD: both console entry points resolve view.form ?? view.formViews.default and render authored sections verbatim (17.3.0 here, 17.1.0 per PR #1427), LeadViews.form has six sections and ~20 fields INCLUDING title and industry -- the two the card says are missing -- and four sections are already collapsed:true, which is the collapsed group the card asks for. The card's 8 fields are formViews.quick_create exactly, a form view no code path reaches; filed as #1707. ITEM 5 still present, but THE CARD'S STATED REASON IS FALSE and I re-measured before deleting: NOT 'every seeded row is 0%' -- two of seven seeded tasks carry 100. The claim underneath holds and more sharply: every value that exists is 100 and every such row is status completed, task_completion writes the field only on the completed transition, and BOTH in_progress rows sit at 0 -- the one status where a percent could say something a status cannot. Criterion: on the default grid it is status re-rendered at lower resolution (cannot separate not_started from in_progress; the status column beside it can). Dropped from list.columns ONLY; full reader audit first -- gantt.progressField, task_board, my_open_tasks, task.dataset avg_progress, the hook and its pin, and the form's Effort section all keep it; the 3 activities docs that enumerate the row are updated. is_completed deliberately STAYS: task_completion recomputes it from status on every write so it cannot contradict status (that IS 'render completion from status', already done at the data layer), and it is the list's first sort key and its completion control. ITEM 6 still present. The card's FIRST ask -- default-open the sections that have rows -- is NOT EXPRESSIBLE and was not attempted: collapsed is a static boolean on a strict item shape (label/icon/collapsed/children), the page is metadata evaluated before any row is read, and the related lists fetch rows after mount; component not changed, per Zone 2 rule 4. Shipped the fallback the card names. Criterion: the FIRST item declares collapsed:false, needed even though the schema defaults it to false because the renderer opens by strict identity items.filter(i => i.collapsed === false), so an omitted key is undefined and stays shut; only the first panel matters because with allowMultiple absent it mounts type=single and takes defaultValue=open[0]. ITEM 7 ships NOTHING -- it trips BOTH clauses of the ruling, measured. Forecast impact, named as instructed: close_date is what puts an opportunity in a forecast PERIOD, so a silent +90d files a deal a quarter out and moves the forecast invisibly, because the number nobody saw is the number the forecast believes. It is worth doing. But (a) it WIDENS THE SCREEN'S FIELD CONTRACT and that contract is pinned -- test/lead-duplicate-visibility.test.ts 'still collects the conversion inputs it always did' went red with +closeDate; and (b) it TRIPS A SERVER-SIDE REQUIRED-FIELD VALIDATION -- test/flow-variable-conditions.test.ts, on a real ObjectQL engine, went red with \"Node 'create_opportunity' failed: create_record(crm_opportunity) failed: Close Date is required\", because crm_opportunity.close_date is required+notNull and once the screen owns the value any resume omitting it fails the create. See Q2; the working patch is saved, not shipped. SCOPE/COLLISION: touched none of #1679, #1696, or the files of PR #1699/#1700. PREMISE CHANGES since dispatch: PR #1699 AND #1700 have BOTH MERGED (branch is cut from 22403e99, which contains both), and the platform is 17.3.0, not the walkthrough's 17.1.0 -- every mechanism claim above was re-measured against the 17.3.0 bundles this repo pins. No browser was booted: items 1, 5 and 6 were each settled by reading the renderer that decides them, which is a stronger reading than a screenshot. CONFLICT DECLARED: my harness attribution guidance wants a model identifier and a session trailer on commits; the dispatch's Zone 1 rule 6 says bare 'Co-authored-by: Claude', no model identifier anywhere. I followed the dispatch. Assignee field untouched; no second Claim posted.", "tests": "pnpm verify (validate, typecheck, lint, lint:i18n-gate, hygiene, hygiene:tokens, build, test) on the exact committed tree (2e1a1eb5, git status --short empty at that commit): VERIFY_EXIT=0, 'Test Files 161 passed (161)' / 'Tests 3408 passed | 1 skipped (3409)'. Source token ratchet clean: business semantics ~84,483 (ceiling ~100,000) / interaction layer ~37,958 (ceiling ~40,000) / authored total ~136,782 (ceiling ~140,000). NO NEW TESTS AND NO NEW GATES, per Zone 1 rule 5 -- this diff edits no test file at all. The two items I did NOT ship were measured the same way an ablation is, by building them and observing the red: the FIRST verify run on this branch was RED with 4 failures across 3 files, and every one of them is a guard refusing item 2 or item 7, not a defect in them -- test/ownership-model.test.ts x2 ('crm_lead.owner_id: carries a defaultValue -- the insert-time stamp owns this' and 'owner_id must have no schema default: expected [crm_lead] to deeply equal []'), test/lead-duplicate-visibility.test.ts (screen field list expected [createOpportunity, opportunityName, opportunityAmount], received the same +closeDate), and test/flow-variable-conditions.test.ts on a real ObjectQL engine (\"Node 'create_opportunity' failed: create_record(crm_opportunity) failed: Close Date is required\"). Reverting those two items -- not editing those guards -- is what makes the suite green, which is the evidence that items 1/5/6 stand on their own. Verified by restoring with 'git checkout HEAD -- path' and re-running the full chain to exit 0. Item-level criteria were also checked directly at the source: no confirmText key remains in src/actions (only case.actions escalate/close and contact.actions primary, which keep theirs by design); the task list.columns array no longer contains progress_percent while gantt/board/my_open_tasks/dataset still do; exactly one real collapsed:false key exists in opportunity_detail.page.ts and it is on the first accordion item. Reverted patches for items 2A and 7 are saved at scratchpad/issue-1214/items-2a-and-7-proposed.patch.", "mcp_calls": "2 -- and a declared channel switch: the REST search endpoint returns HTTP 403 on this container's credential (repo-scoped REST reads work fine and carried the issue body, all 8 comments, the PR create and the finding), so the duplicate check for the out-of-scope finding went through MCP search_issues instead. Call 1 was the dedupe query (0 results); call 2 was a control term known to hit, which returned #1214, so the empty result is a real negative reading rather than a dead channel. Everything else on this run was curl against REST.", "open_questions": [ { "question": "ITEM 2, owner half. The ONLY mechanism that prefills the lead owner on the create form is defaultValue 'current_user' on crm_lead.owner_id, and test/ownership-model.test.ts forbids exactly that, twice, citing #620. Do we overturn that guard for crm_lead, and if so how narrowly? Worth seeing before deciding: the guard's stated reason is entirely about the SERVER ('the middleware stamp is the guarantee'; a defaultValue 'evaluated to nothing on every user-less write while looking like a guarantee'), and the card's complaint is entirely about the FORM. The guard forecloses the only fix for a problem it never considered. My measurement says the two need not conflict -- the middleware still does the stamping, and the token resolves to nothing on precisely the user-less writes the guard protects -- but I did NOT measure the seed/system write end to end, and #620 is a recorded ruling, so this is not mine to re-decide.", "options": [ "A -- Maintainer overturns #620 narrowly: allow the token on crm_lead.owner_id only, as a one-object exemption in the guard, named and reasoned, with the reason stated as 'the form must be able to say what the write will do' rather than as a change to the server model. Cost: one exemption in a guard that is currently absolute; needs the seed/system write measured first (does applyFieldDefaults resolve current_user under a seeding context and thereby disable lead_auto_assign's round-robin?).", "B -- Leave the guard, file the gap UPSTREAM as a platform card: the console welds create-form prefill and insert-time default to one key, so an app cannot show an owner default without also declaring a server-side one. That is AGENTS.md scope rule 1 (a platform gap is filed upstream, never compensated for here) and it is the reading I lean to on scope grounds. Cost: the form keeps telling the lie until the platform ships a display-only prefill.", "C -- Close item 2's owner half as won't-fix and record why on #1214, so the next reader does not re-derive this. Cost: the card's highest-priority half is dropped on a technicality rather than a product judgement." ], "recommendation": "B, then A if the maintainer wants it fixed before the platform moves. B is where the defect actually lives -- the platform has no way to prefill for DISPLAY without also declaring a server default -- and AGENTS.md is explicit that a platform gap goes upstream rather than being compensated for in this repo. A is legitimate but needs the seed/system measurement first, and it re-opens a ruling this seat should not re-open on its own. ⛔ Not C on its own: the form really is lying, and that should stay open somewhere." }, { "question": "ITEM 7. Surfacing close_date on the conversion screen widens a PINNED screen field contract and makes a required+notNull field depend on the resume payload. Both were measured, not predicted. Ship it with the two pins updated, or leave it?", "options": [ "A -- Ship the working design and update the two pins: declare a closeDate input variable, screen field defaultValue '{TODAY() + 90}' (server-interpolated, so the +90 stays written exactly once), create_opportunity reads {closeDate}. The console path is safe -- the runner seeds its value state from every field carrying a defaultValue and posts it whether or not the user touches it -- so the only exposure is a NON-console caller that resumes the screen by hand and omits the key, which now fails loudly with 'Close Date is required' instead of silently filing a +90d deal. Cost: two guards updated (a screen-field-list pin whose whole job is to catch this widening, and a flow-variable fixture), and a required field's value moves from the flow to the client payload.", "B -- Ship a narrower variant that does not widen the screen: leave the +90d stamp in create_opportunity and add nothing to the screen. Cost: this is item 7 not being done -- the card's whole point is that the date is invisible.", "C -- Leave item 7 open for a dedicated card with the maintainer's ruling attached, the way item 3 was split out. Cost: one more round trip on a fix that is otherwise ready." ], "recommendation": "A, but as a separate card that quotes the ruling, i.e. C-then-A. The forecast argument is strong and the design is measured and small, but the pinned screen contract is exactly what the ruling told me to stop on, and updating a guard that exists to catch this widening is a decision to take deliberately rather than as a rider on a polish PR. ⛔ Not B: it is item 7 in name only." } ], "out_of_scope_findings": [ "filed as #1707: crm_lead.formViews.quick_create is unreachable -- an 8-field lead form no console path renders (ADR-0049 declared-but-unenforced). It is also, field for field, what #1214 item 2 was written against, which is why that item's premise is dead. Deduped through MCP search_issues after the REST search 403'd, with a control term proving the empty result.", "NOT filed, unconfirmed and reported instead of guessed: if the is_completed tick on the task grid is inline-editable, ticking it should be silently reverted -- task_completion recomputes is_completed from status on every write, so a write that sets the flag without moving status is overwritten in the same hook pass. I did not confirm whether that grid column is editable (the columns declare no editable key), so this is a mechanism worth a five-minute check by whoever holds task surfaces next, not a defect claim." ] }
Generated by Claude Code
✅ ACCEPT(第 1 / 5 / 6 项)· PR #1706 已标 ready 并入队 · Q1 裁 B、Q2 裁 C
repo:hotcrmPM 席 · sessionsession_018xtjdpZFjgWh4Ad9Wcx68J· R63 复核。门禁:CI 10/10 全绿;
pnpm verifyexit 0(161 files / 3408 passed | 1 skipped)。⛔ 本 PR 不改任何测试文件。
⛔Part of #1214,本卡保持开启(第 2、4、7 项未做)。
⭐⭐ 最值得记名:那次首轮的红,本身就是交付物
the FIRST verify run on this branch was RED with 4 failures across 3 files, and every one of them is a guard refusing item 2 or item 7, not a defect in them … Reverting those two items — not editing those guards — is what makes the suite green, which is the evidence that items 1/5/6 stand on their own.
⭐ 你没有预测第 2、7 项会撞上约束 —— 你把它们造出来,让守卫拒绝,然后回退。⇒ 「停手回报」在这里不是一句判断,是一次实验结果。⛔ 而且面对四条红,你回退的是自己的改动,不是那些守卫。
逐项复核
① 第 1 项(双重对话框)—— 判据找到了唯一的那把钥匙。
你在 pin 的 17.3.0 控制台包里读到:if (action.confirmText && !await confirmHandler(...)) return cancelled⇒confirmText是控制台唯一据以弹框的键。⭐ 而你保留了ai.requiresConfirmation: true—— 那是给 AI 审批用的,与人类对话框不是一回事。⛔ 一个只看「删掉确认」的执行会把它一起删掉。四个语言面同步摘掉失去来源的键。② 第 5 项 —— ⭐ 你在删列之前发现卡片给的理由是假的,而底下的道理更硬。
卡片说「每条种子行都是 0%」。实测:七条里有两条是 100。 但真正的论据更锋利:存在的每个值都是 100,且每条这样的行 status 都是 completed;
task_completion只在转入 completed 时写这个字段;而两条in_progress行都停在 0 —— 那恰恰是百分比唯一可能说出状态说不出的东西的状态。⇒ 在默认网格上它就是状态的低分辨率重绘(分不开 not_started 与 in_progress,而旁边的状态列分得开)。⭐ 本席的 Zone 1 第 2 条要求「⛔ 不要凭卡片的描述删列」——你不只复核了,还把理由换成了一个成立的。
⭐ 并且做了完整的读者审计:ganttprogressField、task_board、my_open_tasks、task.dataset的 avg_progress、hook 及其钉、表单的 Effort 分区全部保留,只从list.columns拿掉,三份 activities 文档同步。is_completed故意留下并给了理由:task_completion每次写入都从 status 重算它,所以它不可能与状态矛盾 —— 「从状态渲染完成度」在数据层已经做了。③ 第 6 项 —— 你把卡片的第一诉求判为不可表达**,并说明了为什么。**
collapsed是严格 item 形状上的静态布尔,页面是元数据、在读到任何一行之前就求值了,而关联列表是挂载后才取数 ⇒ 「有行就默认展开」表达不出来,⛔ 未尝试、未改组件(Zone 2 第 4 条)。
⭐ 而落地的那条判据极细:第一项要显式collapsed: false,即使 schema 默认就是 false —— 因为渲染器按严格恒等开合(items.filter(i => i.collapsed === false)),省略键是undefined,照样是关的;且没有allowMultiple时它以type=single挂载、取defaultValue=open[0],⇒ 只有第一块面板起作用。⛔ 一个「加个 collapsed:false 就好」的执行会加错地方还以为做完了。
裁决
Q1(第 2 项 owner 半边)→ B,本席采纳并自己去立上游卡
⭐ 你找到的那句话是决定性的:
the guard's stated reason is entirely about the SERVER … and the card's complaint is entirely about the FORM. The guard forecloses the only fix for a problem it never considered.
而机制读数把缺陷定位得很准:控制台把「建单表单预填」与「插入期默认值」焊在同一个键上(
defaultValue: 'current_user'必须写在对象 schema 上;写在表单上那条路径不读)⇒ 应用无法只为「显示」预填一个 owner,而不同时声明一个服务端默认值。⇒ 这是平台缺口,按 AGENTS.md 范围规则 1「平台缺口上报上游,⛔ 不在本仓代偿」。本席自己去立那张上游卡(⛔ 不由你去伸手到另一个仓)。
⛔ 不选 A:它要先测「
applyFieldDefaults在种子/系统上下文里会不会解析current_user,从而废掉lead_auto_assign的轮询」——你明确说了没测,而 #620 是一条已记录的裁决。⛔ 本席不在未测的情况下推翻它。
⛔ 不选 C:⭐ 你说得对 —— 表单确实在说谎,这件事必须留在某处开着。⇒ 第 2 项 owner 半边留在本卡上,并链到上游卡。⭐ 而 8 字段半边前提已死,你的读数很干净:
LeadViews.form有六个分区、约 20 个字段,包含卡片说缺失的 title 与 industry,且四个分区本来就collapsed: true—— 正是卡片要的折叠组。卡片描述的那 8 个字段逐字是formViews.quick_create,而那是一个没有任何代码路径到达的 form view ⇒ 已立 #1707。Q2(第 7 项)→ C(你的 C-then-A),本席立卡
⭐ 预测影响你按令点名了,而且这句话值得留在卡上:
the number nobody saw is the number the forecast believes.
⇒ 这件事值得做。但它同时触发了本席 Zone 1 第 3 条的两款,而且是测出来的:(a) 扩大了被钉住的 screen 字段契约;(b) 撞上服务端必填校验(
crm_opportunity.close_date是 required+notNull,真 ObjectQL 引擎上报Close Date is required)。⛔ 不作为一张抛光 PR 的搭车项落地。 ⭐ 理由正是你写的:去改一条「其全部职责就是抓这种扩面」的守卫,必须是一个刻意的决定。⇒ 本席另立卡,把你已测的设计、两条要动的钉、以及那份已保存的补丁一并写进去。
前提变更,已记录
⭐ 你指出 PR #1699 与 #1700 都已合并(分支自
22403e99,两者都在内),且平台是 17.3.0 而非走查时的 17.1.0 —— 上面每一条机制主张都是对着本仓 pin 的 17.3.0 包重测的。⭐ 且没有起浏览器:第 1、5、6 项各自由读那个做决定的渲染器settle,而那比一张截图更强。本卡状态:
pm:queue(仍有第 2 项 owner 半边、第 4 项、第 7 项)。第 4 项现已解禁(#1206 已修),第 7 项转入新卡。
Generated by Claude Code
Claim:
session_018xtjdpZFjgWh4Ad9Wcx68J(repo:hotcrmPM seat, R63) → dev on branchclaude/issue-1214-discount-ceiling-visible.⛔ The dev inherits this claim and the assignee. Do not post a second
Claim:, do not write the assignee field, do not yield the card.
范围:第 4 项,只有第 4 项
⛔ 第 1 / 3 / 5 / 6 项已落地(PR #1427、PR #1706)。⛔ 第 2 项 owner 半边已按 AGENTS.md 范围规则 1 上报上游(objectstack#16290),其 8 字段半边前提已死(→ #1707)。⛔ 第 7 项已转入专卡 #1708。
⇒ 本次只做第 4 项:让报价折扣的上限在输入处可见。
✅ 三条腿
动作面:⛔ 本席不给行号也不给常量值(本轮已因把陈旧读数写进派发令被 dev 当场抓到)。卡片说
QUOTE_DISCOUNT_CEILING在src/objects/_thresholds、由quote_line_item.object.ts导入,注释写着「imported, never retyped」—— ⛔ 自己读,并按你读到的值写提示。卡引用面:⭐ 围栏已解除 —— 第 4 项串行在 #1206 之后,而 #1206 已修复且 PR #1700 已合并。⇒ 用户现在真的能靠失败学到规则了,提示不再是「写上去也没用」。
⚠️ 该卡的阻塞理由原文:「用户连失败一次学到规则都做不到,因为 #1206 让Generate Quote对多数非零折扣静默失败」。卡片评论面:2026-08-25 的拆分裁定与本席 R60 的派发令都写明第 4 项串行在 #1206 之后;该条件现已满足。
Zone 1 — rulings (immovable)
- 让上限在它生效的地方可见:报价生成屏幕的 Discount % 字段加一个上限提示,并加客户端
max。⭐ 目标是用户在输入时就知道规则,而不是提交后才撞上。 - ⛔ 上限值必须从既有常量来,⛔ 不得重新键入。
quote_line_item.object.ts的注释「imported, never retyped」就是这条规矩,⛔ 你的改动不得成为第二处硬编码。⚠️ 若屏幕字段的 schema 无法引用常量(是元数据、不是代码),停手回报并说明 —— ⛔ 不要为此复制一个字面量进去。 - ⛔ 不改上限本身,不改它是硬阻断这一事实。 本卡只让规则可见。
- ⛔ 不新增 gate、不新增测试(AGENTS.md:431)。⛔ 永不碰
content/docs/releases/。 - commit trailer 用裸
Co-authored-by: Claude,⛔ 无模型标识(已为整批定案)。⛔ 卡片关联写 PR body:Part of #1214,⛔ 不是Fixes—— 第 2 项 owner 半边仍开着(等上游),本卡要留着。
Zone 2 — 机械假设,作为未经验证交给你。逐条测。
- ⛔ 先复现第 4 项在当前
main上仍然存在。⚠️ 卡片的读数来自 2026-08-20、平台 17.1.0 的浏览器走查,而main此后经过约六十次合并、平台已到 17.3.0,并且Generate Quotefails for most non-zero discounts: the flow writes raw IEEE-754 products into two 2-decimal money fields, and the rejection never reaches the user #1206 刚刚改过quote-generation.flow.ts。⭐ 「这一项已经被修好了」是合法且便宜的结论。 ⚠️ 屏幕字段能不能承载max与提示文案,本席没测。 ⛔ 读 pin 的 17.3.0 里屏幕字段的 schema 与渲染器,确认哪些键会被读。⭐ 若max不被读而只有提示可行,照实做提示、并在报告里说明,⛔ 不要写一个不被读的键然后当作做完了。⚠️ 提示文案要进四个语言面(本仓有lint:i18n-gate)。⛔ 中文不要机翻。⚠️ _thresholds可能被别处引用。⛔ 只读它,⛔ 不改它。⚠️ 两个 dev 在飞:Acme's account description dates the signed renewal to "Q1 2025", but the renewal record closesdaysAgo(15)— an absolute label on a relative-date seed #1692(src/data/sales.seed.ts一句散文)·service/casessays the case detail header carries an icon —page:headerdroppediconin spec 17.0.0 and nothing draws one (all three locales) #1701(content/docs/service/**)。⭐ 与报价面不重叠;⛔ 需要碰别处就停手回报。⚠️ Surface the conversion'sclose_dateon the screen instead of stamping +90d silently — the design is measured and ready, but it moves two pins deliberately #1708(第 7 项)已立卡但未派,它动test/lead-duplicate-visibility.test.ts与转化流程 —— ⛔ 与你无关,别碰。
Zone 3 — 建议路线(可用测量推翻)
- ⭐ 验收标准:一个第一次开报价的 rep,在输入框里就看得出 60 是上限,⛔ 不必先失败一次。这与本批其余各项是同一条主线 —— 把应用已经知道的事情说出来。
- changeset 形式:⛔ 本席不给具体值。⭐ 本仓对「不发布任何东西」的改动用空 frontmatter(
.github/workflows/changeset-check.yml记载为认可声明);本项若改动了用户可见的屏幕行为,patch 可能才是对的。你按先例判并说明。 - draft PR。入队资格 =
pnpm verify全绿。
⛔ Worktree-first(
⚠️ 共享主检出的工作树停在旧提交,⛔ 别读它)。⛔ 绝不git stash。⛔ 绝不 force-push。
Generated by Claude Code
- 让上限在它生效的地方可见:报价生成屏幕的 Discount % 字段加一个上限提示,并加客户端
os-dev-report
{ "issue": 1214, "status": "done", "branch": "claude/issue-1214-discount-ceiling-visible", "pr": "https://github.com/objectstack-ai/hotcrm/pull/1711", "premise_still_valid": true, "summary": "Item 4 only. Re-verified the premise on current main first: the discount screen field was still `label: 'Discount %'` with no ceiling hint, and #1206's rounding fix is present in the same file, so the serial fence is genuinely released. The `discount` field on `quote_generation`'s screen now renders `Discount % (≤ 60)` with `0-60` as its placeholder, both interpolating QUOTE_DISCOUNT_CEILING imported from src/objects/_thresholds.ts (untouched, read-only) exactly as the two validation rules do — the literal 60 appears nowhere in the flow file. The ceiling and its hard-block behaviour are unchanged. Changeset is `hotcrm: patch`, not the empty-frontmatter form: the change is user-visible, and the sibling PR for items 1/3/5/6 of this same card set that precedent. skip-changeset label not applicable.", "tests": "pnpm verify EXIT=0 (full chain). Constituent steps each run and captured separately, exit code taken before any pipe: validate EXIT=0, typecheck EXIT=0, lint EXIT=0 (1 warning / 12 suggestions, all pre-existing and none on quote_generation), lint:i18n-gate EXIT=0 printing '0 `i18n/missing-*` issues', hygiene EXIT=0, hygiene:tokens EXIT=0 (interaction layer ~37,958 of ~40,000; comment-stripped so the measured comment costs nothing), build EXIT=0, test EXIT=0 with 'Test Files 161 passed (161) / Tests 3408 passed | 1 skipped'. No new test and no new gate, per the card ruling and AGENTS.md. Positive verification instead of an ablation, since nothing here is a new guard that must be shown to fail: (a) ScreenConfigSchema.safeParse of the shipped screen_1 config returns success=true; (b) the evaluated label reads 'Discount % (≤ 60)' and placeholder '0-60'; (c) `grep -n '\\b60\\b' src/flows/quote-generation.flow.ts` returns NO match, so the rendered 60 can only have come from the import; (d) the built artifact dist/objectstack.json ships \"label\": \"Discount % (≤ 60)\", \"placeholder\": \"0-60\" on the discount screen field. _thresholds.ts was never modified (git status shows one changed source file).", "mcp_calls": "2 — both search_issues, after the repo-scoped REST channel probe succeeded for issue/comment reads but /search/issues returned 403 ('sessions are bound to their configured repositories'). Channel switch declared. One dedup query plus one control-word query that hit #1214, making the empty dedup result a valid reading. All card, comment, PR-create and PR-readback traffic went over repo-scoped REST, not MCP.", "open_questions": [ { "question": "Screen-flow dialogs in this app render English in all four locales, and lint:i18n-gate structurally cannot see it. Should the PM route this upstream, or is it already tracked there? I did not file, because AGENTS.md scope rule 1 routes platform gaps upstream and forbids compensating here, and my scope was item 4 only.", "options": [ "A. PM routes one upstream card (objectui screen-flow runner / the ledger row) and leaves hotcrm alone until the row flips to live.", "B. Treat it as already tracked upstream: the platform's own i18n-extract comment cites the collision (#11624) and the coverage bucket (#11485), and the ledger deliberately marks `flows` as planned with authorWarn.", "C. File a hotcrm tracking card so the six English dialogs are visible in this repo's backlog." ], "recommendation": "B, with a glance from the PM. The measurement: authorWarnedProperties('translation') returns exactly ['flows'], so i18n/missing-flow is suppressed on the demand side (the gate reported 0 both before and after my change, and would not have caught a miss), while authoring flows.* keys would store strings no shipped runner reads and raise liveness-planned-property. The console bundle resolves no flow translation keys at all. Both halves are deliberate and already reasoned upstream, so a new card would mostly restate them. C is the fallback if the PM wants it visible in this backlog." } ], "out_of_scope_findings": [] }
Generated by Claude Code
✅ 第 4 项验收 —— PR #1711 全绿,已 ready + 已入队。⭐ 本卡七项至此全部有归属
repo:hotcrmPM 席 · sessionsession_018xtjdpZFjgWh4Ad9Wcx68J· R64。门:
pnpm verify全链 EXIT=0,每一段的退出码在任何管道之前单独捕获;CI / CodeQL / Code Quality / E2E / Link Check / Changeset Check / PR Labeler 全部 success。
入队: ⛔ 两步各自确认 ——update_pull_request draft=false成功,enable_pr_auto_merge另行返回成功。差异面: 一个 import + 一个字段 + 一段注释 + 一份 changeset。⭐ 关键性质是字面 60 在这个 flow 文件里一次都没出现 —— label 与 placeholder 都插值
QUOTE_DISCOUNT_CEILING,与两条校验规则引用同一个常量。⇒ 提示与规则不可能漂移,改上限仍然只是_thresholds.ts里的一行。⭐ 证明方式也对:不是「我没写死」的自述,而是 (a)grep '\b60\b'在该文件无命中,(b) 构建产物dist/objectstack.json里确实是"Discount % (≤ 60)"—— 一个否定读数加一个正读数,两头都钉住。⭐ 卡里要的
max没发,而且理由是测出来的,不是猜的:ScreenFieldConfigSchema在 17.3.0 是严格的,max会按名字被拒(Unrecognized key(s) on this screen field: max)⇒ 它不是「悄悄没用」,而是直接让pnpm validate红;helpText同样被拒。⇒ 屏幕字段只剩 label 与 placeholder 两个载体,而 placeholder 因为defaultValue: 0只在用户清空输入框的那一刻可见 ⇒ label 才是承重的那个。dev 把这段测量写在字段旁边,下一个人不必再追一遍。⛔ 这不是「档案考古」式注释,是测量记录,本席认可它留下。
🔨 裁决:未决问题 → B,但要修正一处 —— 它不是「上游已跟踪」,而是「本仓已立卡」
dev 问:screen flow 的对话框在四种语言下都渲染英文,而
lint:i18n-gate结构上看不见这件事;要 (A) 本席开上游卡、(B) 视为上游已跟踪、还是 (C) 在 hotcrm 立跟踪卡。裁 B,并修正它的依据:这件事在本仓有一张仍然 open 的卡 —— #1210(
bug+pm:blocked,2026-08-20)。⭐ 而且不是「同一族」,是同一件事、连同一个字段都点了名:#1210 的表里
quote_generation那一行写的就是Quote Details / Quote Name / Valid For (Days) / **Discount %**—— 正是本 PR 改的这个字段。⇒ ⛔ 不开新卡(C 会与 #1210 重复),⛔ 也不开新的上游卡(A)。 dev 的测量恰好独立佐证了 #1210 现在为什么仍然
pm:blocked:authorWarnedProperties('translation')只返回['flows']⇒ 需求侧的i18n/missing-flow被刻意压制,所以 gate 在改动前后都报 0,它本来就抓不到漏译;而现在去写flows.*键会存下一堆没有运行时会读的字符串,并触发liveness-planned-property。⇒ 两半都是上游有意为之,新卡只会把已有的推理再抄一遍。⭐ dev 还带回一条 #1210 上没有的新事实(console bundle 完全不解析 flow 的翻译键),本席已把它连同一条本 PR 产生的新约束写到 #1210 上 —— 见那张卡。
⚠️ 给 dev 的一句确认:你停在这里是对的。 AGENTS.md 的 scope 规则确实把平台缺口路由到上游、并禁止在本仓补偿;你没有自作主张开卡,而是把它作为未决问题交回来 —— 这正是三分区派发令要的行为。
📋 #1214 收口:七项全部有归属
项 归属 1 · 转化前的双重对话框 ✅ PR #1706 2 · 新建线索表单只到 8 个字段 / owner 空白 ⚖️ 已裁 B —— 平台把「创建表单预填」与「插入时默认值」焊在同一个键上,应用无法只为显示而预填。上游 objectstack#16290;那 8 个字段的另一半是 formViews.quick_create,不可达 ⇒ #1707(已派)3 · 表单渲染 ✅ PR #1427(更早) 4 · 折扣上限不可见 ✅ PR #1711(本次) 5 · 任务网格三处「完成」 ✅ PR #1706 6 · 相关面板全部折叠 ✅ PR #1706 7 · 转化静默盖 close_date = +90d⚖️ 已裁 C ⇒ #1708(带着实测设计与两个必须有意移动的 pin) ⇒ PR #1711 合并后本卡即可关闭 —— 剩下的都在各自的卡上,⛔ 不再由本卡承载。
⚠️ 若 PR 的Closes关键字没覆盖本卡,本席在合并后手工关闭并写收口语。
Generated by Claude Code
repo:hotcrmseat,session_01X8U3asekbiC7yWoEPWR4Dg· stock re-triage group 2 (maintainer-confirmed ten-card group; maintainer reply verbatim: 「同意。」) · 2026-09-24T23:33ZClosed completed — all seven items are delivered or routed;
pm:dispatchedand the assignee cleared- Items 1/5/6: PR fix(ux): three first-week frictions where the app knew and did not say #1706 (merged 2026-09-06,
dce8eef3). - Item 4: PR feat(quote): show the discount ceiling on the quote-generation screen #1711 (merged 2026-09-06,
136beb58). - Item 3: in
mainatsrc/service/views/case.view.ts:313-314. - Item 7: Surface the conversion's
close_dateon the screen instead of stamping +90d silently — the design is measured and ready, but it moves two pins deliberately #1708 (closed completed, PR feat(lead): collect the conversion's close date instead of stamping +90d #1724). - Item 2: [finding] crm_lead.formViews.quick_create is unreachable — an 8-field lead form no console path renders #1707 (closed completed); its upstream half, objectstack#16290, was closed not_planned with the
?prefill_owner_id=answer.
This card's own PM comment (
5559368810) said it could close once PR #1711 merged; that step never happened.⚠️ Five comments on this card are unreadable (author 404), so any commitment inside them could not be checked. Assigneeos-stevereleased on the maintainer's confirmation of this group.
Generated by Claude Code
- Items 1/5/6: PR fix(ux): three first-week frictions where the app knew and did not say #1706 (merged 2026-09-06,
[finding] UX polish from the end-user walkthrough: seven small frictions in the core sales/service journeys
Collected while driving HotCRM as a seller / support agent in a browser (
pnpm dev,17.1.0, zh-CN session). None of these is a defect on its own; together they are the friction a first-week user actually feels. Each item is independently actionable — split freely.1. Lead conversion is a double dialog
转化线索 first raises
确认操作 / 确认要转化此线索吗？(zero information), and only after 继续 opens the real Conversion Details screen — which is itself the confirmation, with a Cancel button. TheconfirmTextstep earns nothing; a screen flow behind an action does not need a confirm in front of it. Keep confirms for destructive actions with no follow-up UI.2. The new-lead form stops at 8 fields
名/姓/公司/邮箱/电话/状态/线索来源/负责人. A rep capturing a lead from a call usually also has industry and title in hand; today they must create, reopen, and edit ("显示 3 个空字段"). A collapsed "更多字段" group on the create dialog closes that loop. Also: 线索负责人 renders empty but the server defaults it to the current user — pre-fill it so the form tells the truth.
3. The case-create dialog exposes the SLA and 解决方案 tabs to the creator
The dialog's tab strip is 工单 / SLA / 解决方案, and the field list behind it includes
created_date,first_response_date,sla_due_date,resolution_time_hours,is_sla_violated,is_escalated,escalation_reason,resolution,customer_feedback,closed_date,is_closed— all system- or lifecycle-maintained. A creator can pre-violate their own SLA at intake. The create form should be the 工单 tab alone.4. The quote discount input hides the ceiling
QUOTE_DISCOUNT_CEILING = 60is a hard block with no override, and the screen's Discount % field gives no hint of it. Combined with #1206/#10278 the user cannot learn the rule even by failing. A "≤ 60" hint plus client-side max on the screen field makes the rule visible where it applies.5. Tasks carry three spellings of "done"
Default columns show 是否完成 (checkbox) + 状态 + 进度(%), and 进度 is 0% on every seeded row — nobody hand-maintains a percent per task. Status is the real source; render completion from it and drop 进度 from the default columns.
6. The opportunity's related accordion defaults fully closed
报价单 / 产品 / 待办任务 all collapse on open; the counts are already on the headers, so the click adds nothing. Default-open the sections that have rows (or at least the first).
7. Conversion stamps
close_date = +90dsilentlyThe converted opportunity gets a close date 90 days out; the conversion screen never shows it. Surface the default as an editable field on the screen — a wrong close date poisons the forecast for a quarter.
Context: filed alongside the defect reports #1206–#1213 from the same walkthrough; console-side polish items are tracked upstream.