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