dsh-site-log-check
Checks supervision logs for cross-day continuity and for on-site supervision coverage, against GB/T 50319-2013 and other published documents. Reports gaps and coverage differences for a human to review.
Install
dsh plugin --profile web add dsh-site-log-check
Sandbox test results
| Stage | Result |
|---|---|
| 1 install | ✓ |
| 2 list | ✓ |
| 3 mount | ✓ |
| 4 boot | — |
Four stages run in an isolated sandbox: install (network on) → list → mount → boot (last three with no network).
README
dsh-site-log-check — Construction supervision log continuity and on-site supervision record coverage check
[English](README.md) · [简体中文](README-zh.md) · [Español](README-es.md) · [Português](README-pt.md) · [हिन्दी](README-hi.md)
<!-- topblock:v1 -->
What it is — Construction supervision log continuity and on-site supervision record coverage check. It returns a list of what is inconsistent, where, and what to fix.
Who it is for — supervising engineers; no command line required.
What you give it — the source material the check works on (a table, register or document); the original is never modified. Excel can be converted to JSON/YAML first, in chat if the platform supports it.
What it does not do — no compliance verdict, no liability finding, no replacement for the reviewer; differences only.
How to start — search "Professional Document Check Suite" in WorkBuddy / Coze (the full set; this check is one part of it; availability as listed); or:
dsh plugin --profile <name> add dsh-site-log-check
<!-- /topblock:v1 -->


dsh-site-log-check reads one construction project's supervision archive — the supervision service period, the daily supervision logs, the declared list of key works requiring on-site supervision, and the on-site supervision records — and checks that archive against the clauses its rule pack cites: whether one calendar day carries more than one log or a log dated outside the service period, which days of the period have no log, whether each log fills its content items and names a recorder, whether the declared key-work list exists and every declared key work has an on-site record, whether an on-site record carries start and end times in order, its key work, its contractor, what was found and the signatures, and whether on-site supervision claimed in a log is matched by an on-site record on the same date. Every difference it reports is literal and carries the clause it came from, and the report lists those differences for a human to review.
Install
dsh plugin --profile <name> add dsh-site-log-check dsh --profile <name> --dump-config | grep 'dsh-site-log-check'
What it looks like
Workflow overview: document → rule pack → findings. The examples below use the real command surface.
What it answers
Examples
The table below is the example set: the first row is the detailed walkthrough, the remaining rows are short cases.
Detailed output
Tool site_log_check
Input
~~~yaml
project:
serviceStart: "2026-03-01"
serviceEnd: "2026-03-05"
logs:
- date: "2026-03-01"
- date: "2026-03-05"
~~~
Output
~~~json
{
"id": "dsh-site-log-check.SL-002.378ce636",
"ruleId": "SL-002",
"severity": "info",
"locator": {
"cell": "2026-03-02"
},
"found": "2026-03-02 无监理日志记录",
"expected": "监理服务期 2026-03-01 ~ 2026-03-05 内应按日历日记录",
"fix": "核对是否因停工、节假日或日志未归档;确无施工活动的应有说明"
}
~~~
Observed from dsh-site-log-check/tests/fixtures/SL-002/SL-002-unsafe.yaml
You ask · What it answers
Two log entries carry the same calendar date — is that reported? · Yes. SL-001 applies params.maxPerDay (1) and reports every calendar day that carries more than one log; it also reports a log whose date falls outside the service period taken from project.serviceStart and project.serviceEnd. It compares dates and counts; it does not decide which of the two entries is that day's record, nor whether an entry added later was justified. If no log date in the material can be read, the rule reports itself in skipped instead of passing.
Three days in the middle of the service period have no log. What does the check do? · SL-002 counts the calendar days between project.serviceStart and project.serviceEnd that have no log. It is the pack's only info rule: the requirement that dates run consecutively comes from the Fujian standard DBJT 13-144-2019, not from GB/T 50319-2013, so it flags and never blocks. Below params.minCoverageRatio (0.9) it lists each missing day as a finding; at or above that ratio it reports itself in skipped and names the missing days there. Whether a gap was a stoppage, a holiday or a log that was never archived is left to a human.
A day's log leaves the problems column empty. · SL-006 reports that entry: every log must fill the column for the day's problems and how they were handled. It checks that the column is filled, not that the text is right, so an entry saying that nothing was found passes while a blank one does not. The pack records that the two available readings of 第7.2.2条第4款 differ in wording and that the official scan could not be re-read, so the rule deliberately stays silent on the wording and looks only at whether the column is filled.
Nothing in the material declares which key works require on-site supervision. Does that pass silently? · No. When the material shows on-site supervision was in play — an on-site record exists, or a log's supervision column mentions 旁站 — SL-008 reports the missing declared list. When nothing points to on-site supervision at all, the rule reports itself in skipped with that reason instead of inventing a requirement the project may not be subject to. The pack notes that the text of GB/T 50319-2013 does not itself list the key works and that the list comes from 建市〔2002〕189号第二条.
Our on-site record is signed only by the supervision engineer. Is that reported? · Yes. With params.requireContractorSignature on, SL-011 reports both a missing 旁站监理人员 signature and a missing 施工企业现场质检人员 signature. The p
…(truncated)
Rendered from the README published on npm. Formatted only, not edited.
Versions
Published on npm::11,最后更新 2026-10-30