diff --git a/.wolf/buglog.json b/.wolf/buglog.json
index 30608644..d86a10cc 100644
--- a/.wolf/buglog.json
+++ b/.wolf/buglog.json
@@ -17910,6 +17910,48 @@
       ],
       "occurrences": 1,
       "last_seen": "2026-08-20T15:57:00Z"
+    },
+    {
+      "id": "bug-1609",
+      "timestamp": "2026-08-20T21:10:00Z",
+      "error_message": "User-reported (live REPL session, xce_scheduler -i -s <replay>): after 'continue' with zero breakpoints set, output is just as verbose as single-stepping -- every decoded event still prints a '[sim] t=... session=...' + '[sim] event: ...' two-line block, defeating continue's documented purpose ('Run until next breakpoint hit or EOF').",
+      "file": "src/scheduler/src/repl_break.c",
+      "root_cause": "xce_repl_on_event() (repl_break.c:708-731) calls repl_print_event_summary() unconditionally before its breakpoint-match check, with no reference to sim->repl_state->mode (XCE_REPL_MODE_STEP vs XCE_REPL_MODE_CONTINUE). This was intentional for bug-1595 ('in each step, ... show the decisions/events that occur'), but the fix's implementation echoes on every xce_repl_check_event() call regardless of which command (step or continue) put the driver in motion -- the request was step-specific but the fix applies to both modes, so continue never actually reduces output versus stepping one session at a time.",
+      "fix": "Not yet fixed -- proposed: gate repl_print_event_summary()'s call in xce_repl_on_event() on rs->mode == XCE_REPL_MODE_STEP (or a new explicit 'set verbose on|off'), so continue only prints breakpoint-hit lines (and, optionally, one summary line per BEGIN_ROUND) while step keeps its current full per-event echo.",
+      "tags": [
+        "repl",
+        "sim",
+        "verbosity",
+        "continue",
+        "ux",
+        "scheduler-sim-diagnostics"
+      ],
+      "related_bugs": [
+        "bug-1595"
+      ],
+      "occurrences": 1,
+      "last_seen": "2026-08-20T21:10:00Z"
+    },
+    {
+      "id": "bug-1610",
+      "timestamp": "2026-08-20T21:10:00Z",
+      "error_message": "User-reported (same live REPL session): under 'continue', an unchanged PEND decision for the same jobid prints an identical '[sim] PEND jobid=...' line every scheduling round it remains pending -- e.g. jobs [22]-[29] (8 jobs) print their 8 byte-identical PEND lines 5+ times in a row across consecutive rounds with zero new information each time.",
+      "file": "src/scheduler/src/sim_loop.c",
+      "root_cause": "sim_print_decision() (sim_loop.c:388-411) unconditionally prints one DISPATCH/PEND/PREEMPT line per drained xce_decision_t with no de-duplication and no session/round context attached to the line itself -- called every round a job's allocation is (re-)attempted, so a job that stays PEND for N consecutive rounds produces N identical lines. xce_repl_on_decision() (repl_break.c:776-811), called alongside it, already tallies last_n_pend/last_n_dispatch/last_n_preempt per round for 'info session' -- that rollup exists but is never surfaced automatically, only on explicit 'info session'.",
+      "fix": "Not yet fixed -- proposed: either (a) only print a decision line the first time a given jobid enters PEND / when its pend reason changes, suppressing repeats of the identical reason, or (b) replace the unconditional per-decision echo with one per-round summary line at BEGIN_ROUND using the tally xce_repl_on_decision() already accumulates ('[sim] round N: X dispatch, Y pend, Z preempt'), reserving full per-decision detail for step mode or a matching breakpoint.",
+      "tags": [
+        "repl",
+        "sim",
+        "verbosity",
+        "duplicate-output",
+        "pend",
+        "scheduler-sim-diagnostics"
+      ],
+      "related_bugs": [
+        "bug-1609"
+      ],
+      "occurrences": 1,
+      "last_seen": "2026-08-20T21:10:00Z"
     }
   ]
 }