简体中文界面。帖子、指南及政策正文保留原文；未对原文作自动翻译。
CallumBennett0708 · 2026年6月28日 10:51 UTC
Does the reconnect record contain a job identity, or only the completion bit?
23分I'd preserve the raw reread separately from the counted result. You can observe the same completion twice without producing two completed jobs; throwing away the reread makes the diagnostic history less useful.
14分Fiona, would the operator see both entries? I can imagine that distinction being clear to a developer and still looking like two finished coupons on the shift screen.
15分Two observations in diagnostics, one result in production totals. Label the views. I wouldn't make operators deduce it from timestamps.
-3分Chen, the controller record has a job number and completion state but our reconnect handler only passes the state onward; Fiona and Louis, both screens currently use the same event list, so yes, they both show the extra completion
21分I've watched a class treat job number as a permanent identity because the exercise never restarted its producer, so I'd ask what happens to that number at restart before making it the only key here
5分And who reconciles the coupon already counted twice? Fixing the display for the next run won't explain the old total. I'd want the commissioning owner to check that against the job evidence, with the correction visible rather than quietly editing the number.
11分Same coupon still in the fixture, Callum, or had it been removed?
12分Ruth, that observation could help reconciliation, but the occupied fixture alone would not identify which verification completed. I would keep physical state and the recorded job evidence together.
8分For a beginner's handover, I'd put one actual reconnect example beside the two screens. Show the repeated observation and where its existing result is found. If identity is missing, the example should stop at unresolved, not supply a guessed number.
8分Ruth, it had been removed; the commissioning owner matched the saved record to the identified coupon in the inspection log and has recorded the duplicate-count correction, while the developer is separating observations from results
16分Olivia's example sounds useful. We had a handover full of normal screenshots and no explanation of why yesterday's information might reappear; the person on shift naturally treated every new row as new work. I'd test this wording with somebody who hasn't helped write it.
18分Has the job-number restart question been answered, Callum, since that determines whether a repeated number can safely be matched to the old result at all?
9分Owen and Theo Ali, the job counter can restart from its initial value and this interface exposes no producer-session identifier, so the developer has made that restart case unresolved instead of reusing the earlier result
19分What happens on the screen in that unresolved case? I'd expect a reader to know which total is confirmed and which job needs attention, without opening a developer log.
23分And don't call that a new completed job merely because its number is unfamiliar.
12分The replay build shows confirmed results separately and a named unresolved observation with no count increment; held-state reconnect repeats one result, while the restart-number case stays unresolved, and nothing in this monitor resubmits work
7分That gives maintenance an honest boundary. Keep the producer-identity limitation in the handover with the reconciliation owner, Callum; otherwise somebody will see the unchanged total after a restart and decide the monitor simply needs another reconnect.
10分