docs: update web sentinel post-task guidance

.agents/skills/unidesk-monitor/SKILL.md

@@ -28,6 +28,7 @@ bun scripts/cli.ts web-probe sentinel validate --node D601 --lane v03 --sentinel
 bun scripts/cli.ts web-probe sentinel dashboard verify --node D601 --lane v03 --sentinel <id>
 bun scripts/cli.ts web-probe sentinel dashboard screenshot --node D601 --lane v03 --sentinel <id>
 bun scripts/cli.ts web-probe sentinel report --node D601 --lane v03 --sentinel <id> --latest --view summary
+bun scripts/web-probe-sentinel-scheduler.ts run --node D601 --lane v03 --sentinel <id> --stale-multiplier 1 --dry-run
 ```
 
 For long Workbench/user-path evidence, use the normal Web probe surface:

.agents/skills/unidesk-monitor/references/full.md

@@ -12,27 +12,32 @@ Known D601/v03 sentinel ids:
 
 - `workbench-dsflash-go-tool-call-10x`
 - `workbench-auth-session-switch-2users`
+- `mdtodo-visual-regression`
 
 Per-sentinel drill-down:
 
 ```bash
-bun scripts/cli.ts web-probe sentinel status --node D601 --lane v03 --sentinel workbench-dsflash-go-tool-call-10x
-bun scripts/cli.ts web-probe sentinel status --node D601 --lane v03 --sentinel workbench-auth-session-switch-2users
-bun scripts/cli.ts web-probe sentinel control-plane status --node D601 --lane v03 --sentinel workbench-dsflash-go-tool-call-10x
-bun scripts/cli.ts web-probe sentinel control-plane status --node D601 --lane v03 --sentinel workbench-auth-session-switch-2users
+bun scripts/cli.ts web-probe sentinel status --node D601 --lane v03 --sentinel <id>
+bun scripts/cli.ts web-probe sentinel control-plane status --node D601 --lane v03 --sentinel <id>
+```
+
+Freshness-only check:
+
+```bash
+bun scripts/web-probe-sentinel-scheduler.ts run --node D601 --lane v03 --sentinel <id> --stale-multiplier 1 --dry-run
 ```
 
 Dashboard render and screenshot verification:
 
 ```bash
-bun scripts/cli.ts web-probe sentinel dashboard verify --node D601 --lane v03 --sentinel workbench-dsflash-go-tool-call-10x
-bun scripts/cli.ts web-probe sentinel dashboard screenshot --node D601 --lane v03 --sentinel workbench-dsflash-go-tool-call-10x
-bun scripts/cli.ts web-probe sentinel dashboard verify --node D601 --lane v03 --sentinel workbench-auth-session-switch-2users
-bun scripts/cli.ts web-probe sentinel dashboard screenshot --node D601 --lane v03 --sentinel workbench-auth-session-switch-2users
+bun scripts/cli.ts web-probe sentinel dashboard verify --node D601 --lane v03 --sentinel <id>
+bun scripts/cli.ts web-probe sentinel dashboard screenshot --node D601 --lane v03 --sentinel <id>
 ```
 
 The screenshot command runs through the selected node/lane remote browser and downloads the PNG artifact to the caller's `/tmp` by default. Closeout evidence should cite `localPath`, `sha256`, page HTTP status, selected DOM summary fields and `layout.horizontalOverflow` / `overflowCount`; do not replace this with a local browser screenshot or ad-hoc `web-probe script` when the sentinel command can cover the page.
 
+Use the freshness-only `--dry-run` scheduler command when the question is only "how old is the latest run?". It reads cadence, latest age, due status and latest run id without starting a new browser observation. If an enabled sentinel is `due` or stale while other sentinels are fresh, treat it as a sentinel-specific cadence or runtime issue and record the sentinel id, cadence, latest age and run id before starting a repair loop.
+
 Report drill-down:
 
 ```bash
@@ -67,6 +72,7 @@ Per-sentinel management YAML:
 
 - `config/hwlab-web-probe-sentinels/d601-v03/workbench-dsflash-go-tool-call-10x.yaml#sentinel`
 - `config/hwlab-web-probe-sentinels/d601-v03/workbench-auth-session-switch-2users.yaml#sentinel`
+- `config/hwlab-web-probe-sentinels/d601-v03/mdtodo-visual-regression.yaml#sentinel`
 
 Typical config refs:
 
@@ -101,6 +107,8 @@ For a Web sentinel fix, closeout needs four independent evidence surfaces:
 
 Long `quick-verify` or CI/CD waits should be bounded by the YAML-declared budget and the operator's outer timeout. If a wait would exceed about two minutes during rollout, first inspect the visible stage and either optimize the slow path, defer the expensive quick verify to manual validation, or record it as a non-blocking timing warning; do not dead-wait without new evidence.
 
+If `origin/master` advances while rolling out a sentinel, first classify the new commits. For unrelated parallel changes, finish the current bounded check, wait briefly for the branch head to stabilize, then perform one final rollout/status pass against the stable head. Do not loop forever chasing every concurrent merge, but do not call a rollout complete while source truth, internal mirror and runtime image point at different commits.
+
 Source mirror readiness must be proven by the internal mirror object/read probe for the expected commit. A GitHub/source head check alone is not sufficient evidence to skip source sync, because it does not prove the k3s publish job can fetch the object from the node-local mirror.
 
 Dashboard aggregate counters may include historical runs. When they disagree with the latest selected run, closeout should name the latest `runId` and report hash as the acceptance source, and track the aggregate-labeling UI improvement separately instead of treating historical aggregate red counts as the latest run's blocker.