docs(assistant): 兩個提醒數字不准在回報裡加回去

分流在資料層驗過了：那一輪的佇列八列全標成 builtin、逐筆點名零列，
工作階段開頭從印八行變成印一行。但同一輪的收尾回報拿到
reminders=0 與 reminders_builtin=8，寫出來的句子是「8 筆有提醒進了
佇列」——讀起來跟修之前一模一樣。

區別在資料層做出來了，在最後一步被攤平。技能檔本來只要求把
reminders_builtin= 記下來，記下來了，然後寫句子的時候丟掉；「要求
記錄」不等於「要求說出來」。

所以把措辭也釘死：兩個數字分開印、各自帶上它是哪一種，並寫進收尾
的完成條件。

plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "jsc-assist",
-  "version": "0.3.7",
+  "version": "0.3.8",
   "description": "助理：事件收攏、健康巡檢與待辦簿（MONITOR_{HASH} wiki 頁）",
   "skills": "./skills/",
   "jsc": {

skills/assistant/SKILL.md

@@ -412,7 +412,9 @@ One round: read five sources, record the result, then beat. Everything before th
 
    **The event numbers get their own line, and the unpaired starts get their own list.** Print `events_total=` and `events_bad=` as this round's event count and its non-`ok` count, then every non-`ok` event with its `kind`, `name`, `status`, `exit` and `detail`, then — separately, never folded into the same list — every start with no matching end, by `name` and `session`. A non-zero `events_unpaired=` is the round's most important finding: each row is a skill run that started and never reached its closing step. Say `events_rotated=` too when it is `rotated` or `failed`. When `item=D-11` failed, say the source could not be read rather than reporting zero events — zero read events and zero existing events look identical in a report and mean opposite things.
 
-   **Then report step 5 in its own block**, because it is the only place the task book's own work is accounted for: how many entries were due, how many ran, how many came back clean and how many failed, then every `failed=` row by name with the first line of its command's output, every `held=` row with what could not be given a target, and every `write_failed=` row as an entry that ran without being recorded. Say plainly that a held entry's history was left untouched. Close with the 待人處理 rows from the latest-round block, verbatim, and nothing else — the patrol names an entry point and stops there. Completion condition: all five items appear in the report, the event count, the non-`ok` count and the unpaired starts are stated, the heartbeat outcome is stated as written or not written, and no suggestion in 待人處理 was acted on.
+   **The two reminder counts are reported as two numbers and never merged into one.** Print `reminders=` as the entries a person can act on and `reminders_builtin=` as the delegation list's own items, each with the word that says which it is — a report saying "eight reminders queued" describes an eight-line problem for the reader when every one of the eight was waiting on plumbing nobody has wired. The queue writer splits the kinds and whatever prints the queue honours the split; a report that adds them back together throws that away at the last step, which is where the flattening happened in practice. Say what the built-in count is waiting on: an action of `remind` with no entry point yet, so it comes due again next round.
+
+   **Then report step 5 in its own block**, because it is the only place the task book's own work is accounted for: how many entries were due, how many ran, how many came back clean and how many failed, then every `failed=` row by name with the first line of its command's output, every `held=` row with what could not be given a target, and every `write_failed=` row as an entry that ran without being recorded. Say plainly that a held entry's history was left untouched. Close with the 待人處理 rows from the latest-round block, verbatim, and nothing else — the patrol names an entry point and stops there. Completion condition: all five items appear in the report, the event count, the non-`ok` count and the unpaired starts are stated, the two reminder counts appear as two separate numbers, the heartbeat outcome is stated as written or not written, and no suggestion in 待人處理 was acted on.
 
 ## status