mirrors/pikasTech-unidesk
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: clarify sentinel monitor run count contract

Browse Source
This commit is contained in:
Codex
2026-06-28 10:27:09 +00:00
parent efd544adbc
commit f4d97774cf
1 changed files with 3 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.agents/skills/unidesk-monitor/references/full.md
+3 -3
View File
@@ -46,7 +46,7 @@ bun scripts/cli.ts web-probe sentinel dashboard screenshot --node <node> --lane
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.
`dashboard verify` is the canonical monitor-web DOM contract. It should assert that trend latest-point counts match the latest `/api/runs?sort=updated` run, and that the monitor-web check panel is scoped to the selected run by default. For a selected run, check type count, alert type count, error samples, warning samples and alert samples must match `/api/runs/{id}.findings`; historical `/api/findings` aggregates may be available only behind an explicit time-window scope and must be labeled as historical.
`dashboard verify` is the canonical monitor-web DOM contract. It should assert that trend latest-point counts match the latest `/api/runs?sort=updated` run, and that the monitor-web check panel is scoped to the selected run by default. For a selected run, trend error/warning points, run-row tags and check table rows must all be derived from `/api/runs/{id}.findings` detail rows. Do not fall back to top-level sample counters such as `severityCounts` for user-visible run aggregates; historical `/api/findings` aggregates may be available only behind an explicit time-window scope and must be labeled as historical.
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.
@@ -106,7 +106,7 @@ Classify a monitor page issue in this order:
1. HTML shell loads: root status, asset links, `data-sentinel-id`, `data-base-path`, contract version.
2. API returns data: `/api/overview`, `/api/runs`, `/api/findings`, selected `/api/runs/{id}`.
3. Count scopes are coherent: trend latest point is latest-run sample count; selected run detail exposes type count and sample count separately; monitor-web checks default to selected-run scope and only show historical aggregates behind an explicit history/time-window selector.
3. Count scopes are coherent: trend latest point is the selected/latest run's check row count by severity, not a raw sample count; selected run detail exposes row count and sample count separately; monitor-web checks default to selected-run scope and only show historical aggregates behind an explicit history/time-window selector.
4. Browser render executes: page errors, console errors, DOM rows, status summary, check cards, scope labels and overflow state.
5. Runtime service health: `/api/health`, `/metrics`, scheduler heartbeat, SQLite/PVC write probe.
6. Control-plane health: source, registry image, git-mirror, GitOps, Argo, Deployment/Service/PVC.
@@ -123,7 +123,7 @@ For a Web sentinel fix, closeout needs four independent evidence surfaces:
2. `web-probe sentinel validate --node <node> --lane <lane> --sentinel <id>` must pass `/api/health`, `/metrics`, indexed recent report, public exposure and public dashboard probes.
3. `web-probe sentinel dashboard screenshot --node <node> --lane <lane> --sentinel <id>` must pass through the remote browser and save a verified PNG to the caller `/tmp`; record the local path, hash and layout overflow result.
4. `web-probe sentinel report --node <node> --lane <lane> --sentinel <id> --latest --view summary` must show the latest business run, report hash, samples and finding severity. Auth/login failures, submit failures, missing samples, absent recent reports and Code Agent multi-round continuity breaks are blockers. YAML elapsed-budget or total-turn timing alerts are non-blocking warnings unless they coincide with a failed turn, broken continuity, missing report or unavailable user path.
5. For monitor-web count fixes, `dashboard verify` must include the latest run id, trend sample counts, selected-run check counts and any targeted run filter evidence. A pass requires check samples to match the selected run detail, not just chart arithmetic.
5. For monitor-web count fixes, `dashboard verify` must include the latest run id, trend point row counts, selected-run check table counts, selected run-row red/yellow tags and any targeted run filter evidence. A pass requires all user-visible run aggregates to match `/api/runs/{id}.findings` detail rows, not just chart arithmetic.
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.