🎁 福利专区全网大模型免费应用 + 新用户福利 + 注册活动入口,低成本玩转 AI

监理日志核对 PerryLink/dsh-site-log-check

DeepSeek Harness
PerryLink27 天前有提交已提供中文文档扫描:含敏感能力

比对监理日志与现场记录,逐条列出差异供人工复核

30/100
综合分
0
GitHub 星标
—
npm 周下载
—/5
用户评分

数据截至 2026/10/8 · 周下载取自 npm 全网(含 CI / 镜像),非本站安装数;综合分由星标、活跃度与兼容性检查合成。

安装命令 · 需先装 dsh CLI 引擎
dsh plugin --profile web add PerryLink/dsh-site-log-check
该包不可直接 npm 安装,改从 GitHub 源安装(明细见下方安装检查)

状态速览

判定依据:实装验证 · 静态安装检查 · 自动扫描 · 仓库维护状态
信任档位:需留意
是什么
dsh 原生插件 · tool
装得上吗
实装验证未通过(unknown),装前请到仓库确认最近更新与 issue
L4 · 真实安装等级说明 →
安全吗
本站尚未对该插件做风险分级
暂未覆盖,不等同于无风险
还在维护吗
活跃:最近一次提交在 27 天前
档位由哪些信号合成

本站实装验证(真实安装 L4 覆盖全站;L5 为运行时冒烟或实机截图,覆盖范围小于 L4) · 验证所用 dsh 版本 · 静态安装检查 · 风险分级 · 仓库维护状态。 下方各区块是它的证据明细。

验证判据与等级说明 →
⚠︎ 实装验证未通过(unknown · 2026/11/4) ——可能是验证环境差异,装前建议到 GitHub 仓库确认最近更新与 issue。
社区实装还没有人打卡 · 装过的第一个就是你
安全扫描自动 · 静态分析源码
v2.7.0
🔵 扫描:含敏感能力尚无人工评估
展开查看扫描说明与证据 ↓

静态扫描发现插件具备触达本地系统的能力:执行外部命令、读写/删除本地文件、读取剪贴板或密钥类环境变量(至少其一)。这是能力清单,不是危险判定——具体能力项与证据见下方,安装前请自行判断是否需要。

读写/删除本地文件
查看扫描证据(共 1 处,展示前 1 条)
  • 读取本地文件
    samples/quickstart/run.mjs:7
    const material = await readFile(join(here, 'input', "SL-001-unsafe.yaml"), 'utf8')
扫描于 2026/11/4(0 天前) · 范围 入口闭包 + 发布文件清单 · 来源 GitHub 仓库

静态扫描只反映源码中出现的调用,不构成安全背书;人工评估与自动扫描相互独立、互不覆盖。

依赖的 DSH / Cordis 模块
@deepseek-ai/cordis@deepseek-ai/dsh-package-manifest@deepseek-ai/dsh-tools@deepseek-ai/schemastery
给这个插件打分还没有人投票↓
用户评分
还没有人投票,来当第一个

功能亮点

  • 比对日志与现场记录
  • 逐条列出差异
  • 供人工复核

监理日志核对:依据《建设工程监理规范》《房屋建筑工程施工旁站监理管理办法(试行)》(GB/T 50319-2013、DBJT 13-144-2019)。仅提示差异,不作出定性结论。

README

由 DeepSeek 最新模型翻译生成
dsh-site-log-check — 施工监理日志连续性与现场监理记录覆盖检查 dsh-site-log-check 读取一个施工项目的监理档案——监理服务期、每日监理日志、申报的需现场监理的关键工序清单,以及现场监理记录——再拿这份档案对照规则包引用的条款做检查:同一日历日是否出现多份日志,或日志日期落在服务期之外;服务期内哪些天没有日志;每份日志是否填齐内容项、是否写明记录人;申报的关键工序清单是否存在、每项申报的关键工序是否都有现场记录;现场记录是否按顺序写明起止时间、关键工序、施工单位、发现的问题和签字;日志里声称做了现场监理的,同一天是否有对应的现场记录。它报告的每处差异都是字面差异,并带上出处条款,报告会把这些差异列出来供人工复核。 它能回答什么 | 你问 | 它答 | | 两条日志填了同一个日历日期——会报告吗? | 会。SL-001 套用 params.maxPerDay(1),报告每个出现多份日志的日历日;它还会报告日期落在服务期之外的日志,服务期取自 project.serviceStart 和 project.serviceEnd。它只比对日期和数量;不判断两条里哪条才是当天的记录,也不判断后补的那条是否合理。如果材料里没有任何日志日期能读出来,这条规则会在 skipped 里报告自己,而不是放行。 | | 服务期中间有三天没有日志,检查会怎么做?
展开完整文档(README 剩余 1 节)
dsh-site-log-check — 施工监理日志连续性与现场监理记录覆盖检查

dsh-site-log-check 读取一个施工项目的监理档案——监理服务期、每日监理日志、申报的需现场监理的关键工序清单,以及现场监理记录——再拿这份档案对照规则包引用的条款做检查:同一日历日是否出现多份日志,或日志日期落在服务期之外;服务期内哪些天没有日志;每份日志是否填齐内容项、是否写明记录人;申报的关键工序清单是否存在、每项申报的关键工序是否都有现场记录;现场记录是否按顺序写明起止时间、关键工序、施工单位、发现的问题和签字;日志里声称做了现场监理的,同一天是否有对应的现场记录。它报告的每处差异都是字面差异,并带上出处条款,报告会把这些差异列出来供人工复核。

它能回答什么

| 你问 | 它答 |
| 两条日志填了同一个日历日期——会报告吗? | 会。SL-001 套用 params.maxPerDay(1),报告每个出现多份日志的日历日;它还会报告日期落在服务期之外的日志,服务期取自 project.serviceStart 和 project.serviceEnd。它只比对日期和数量;不判断两条里哪条才是当天的记录,也不判断后补的那条是否合理。如果材料里没有任何日志日期能读出来,这条规则会在 skipped 里报告自己,而不是放行。 |
| 服务期中间有三天没有日志,检查会怎么做? | SL-002 统计 project.serviceStart 到 project.serviceEnd 之间没有日志的日历日。它是规则包里唯一的 info 规则:日期必须连续这条要求出自福建标准 DBJT 13-144-2019,不是 GB/T 50319-2013,所以它只提示、从不拦截。低于 params.minCoverageRatio(0.9)时,它把每个缺失的日期列为一条发现;达到或高于该比例时,它在 skipped 里报告自己,并在那里列出缺失的日期。至于某段空档是停工、放假还是日志压根没归档,交给人工判断。 |
| 某天的日志把问题栏留空了。 | SL-006 会报告这条记录:每份日志都必须填写当天的问题及处理情况栏。它只检查该栏是否填写,不检查文字对不对,所以写「未发现问题」的记录能过,空白的过不了。规则包记录道,第7.2.2条第4款现有的两种读法措辞不一致,官方扫描件又无法重新读取,所以这条规则有意不碰措辞,只看该栏是否填写。 |
| 材料里没有任何内容声明哪些关键工序需要旁站。这会静默通过吗? | 不会。当材料显示旁站确实发生过——存在旁站记录,或日志的旁站栏提到旁站——SL-008 会报告缺少已声明的清单。当完全没有迹象指向旁站时,规则会在 skipped 中报告自身并附上原因,而不是凭空捏造一项项目可能并不适用的要求。该包指出,GB/T 50319-2013 的正文本身并未列出关键工序,清单来自建市〔2002〕189号第二条。 |
| 我们的旁站记录只有监理工程师签字。这会被报告吗? | 会。开启 params.requireContractorSignature 后,SL-011 会同时报告缺少旁站监理人员签字和缺少施工企业现场质检人员签字。该包有意把两个依据分开:表 A.0.6 只有旁站监理人员(签字)一栏,第二个签字来自建市〔2002〕189号第七条,因此不能归到 GB/T 50319-2013 名下。规则检查的是签字是否记录在案,不检查签字是否真实。 |
| 日志说 5 月 12 日发生了旁站,但台账里那天没有记录。 | SL-013 会报告。它把旁站栏提到旁站的日志日期,与旁站记录开始的日期做比对。它只检查两者是否对得上;该包声明,GB/T 50319-2013 和建市〔2002〕189号都不要求两份文件互相引用对方的编号。如果没有旁站记录带开始时间,或没有日志声称发生旁站,规则会在 skipped 中报告自身,而不是通过。 |

遵循的标准

| 文件 | 编号 | 引用它的规则 |
| 《建设工程监理规范》 | GB/T 50319-2013 | SL-001, SL-002, SL-003, SL-004, SL-005, SL-006, SL-007, SL-008, SL-009, SL-010, SL-011, SL-013, SL-014 |
| 福建省《建设工程监理文件资料管理标准》 | DBJT 13-144-2019 | SL-002 |
| 《建设工程质量管理条例》 | 国务院令第279号 | SL-008 |
| 《房屋建筑工程施工旁站监理管理办法(试行)》 | 建市〔2002〕189号 | SL-011, SL-012 |

边界: 本插件检查建设项目的监理日志连续性,以及旁站记录的覆盖情况——即旁站监理领域(工程监理)。它不是 dsh-archive-check(检查项目记录归档是否完整),不是 dsh-hazplan-check(检查危大工程专项方案的章节),也不是现场安全检查器。它读取监理机构自身记录的机器可读导出,对照所引条款报告字面不符之处。

兼容性

| 层面 | 状态 |
| Harness | 对等范围 >=0.1.2-rc.1 <0.2.0 \|\| >=0.2.0-0 <0.3.0——已验证可接受 0.2.0-rc.2 和 0.2.1-alpha.1。刻意不声明 engines.dsh:它没有读取方,也无法拒绝宿主 |
| Node | ^22.19.0 || >=24.0.0 |
| 平台 | 全部(纯 ESM;无原生代码、无网络、无模型调用) |
| 工具模式 | 在 native、ptc 和 both 下都能用;如果是一整个文件夹的项目,用 ptc |

做什么

注册 site_log_check 工具。它读取某个项目的监理档案——服务期、每日日志、申报的关键工序清单,以及现场监理记录——套用带版本号的规则包,返回一份报告,每条发现都写明来自哪一条条款。

⚠️ 这里没有任何一项是 error,因为该标准是推荐性的

GB/T 50319-2013 是推荐性国家标准——住建部公告第 35 号批准其为「国家标准,编号为 GB/T 50319-2013」,其前言声明无任何章节为强制性。对比 GB 26860—2011,其前言直接写明「第5章和7.3.4为推荐性,其余为强制性」。这些条款里的「应」字表述是工程制图惯例,不是法律强制,所以每条规则最高只到 warn,本插件不拦截任何东西。

这并不是说这些要求不重要:监理日志和现场监理是《建设工程质量管理条例》规定的法定义务。但承载此处所检查的具体条款的标准是推荐性的,所以插件只提示,不拦截。

| 规则 | 检查内容 | 严重级别 |
| SL-001 | 每个自然日一篇日志,且在服务期内 | warn |
| SL-002 | 服务期内没有哪个自然日缺日志 | info |
| SL-003 | 日志记录天气和现场情况 | warn |
| SL-004 | 日志记录当天的施工进度 | warn |
| SL-005 | 日志记录当天的监理工作 | warn |
| SL-006 | 日志记录当天的问题以及处理方式 | warn |
| SL-007 | 日志写明编制人 | warn |
| SL-008 | 项目有申报的关键工序清单,需要现场监理 | warn |
| SL-009 | 现场记录带有开始和结束时间,且顺序正确 | warn |
| SL-010 | 现场记录写明发现了什么、如何处理 | warn |
| SL-011 | 现场记录有签字,监理方和施工方都要签 | warn |
| SL-012 | 每项申报的关键工序至少有一条现场记录 | warn |
| SL-013 | 日志中声称的现场监理与现场记录台账一致 | warn |
| SL-014 | 现场记录写明关键工序和施工单位 | warn |

安装

dsh plugin --profile <name> add dsh-site-log-check
dsh --profile <name> --dump-config | grep 'dsh-site-log-check'

配置

所有可调项都在 src/config.ts 的 Schemastery schema 里,所以可以直接从 cordis.yml 改,不用动代码。每条规则的阈值在 rules/site-log-check.yaml 里。

| 键 | 类型 | 默认值 | 说明 |
| rulesFile | string | rules/site-log-check.yaml | 规则包路径,相对于包根目录 |
| disabledRules | string[] | [] | 要停止运行的规则 id;每个都会出现在 skipped 里 |
| onlyRules | string[] | [] | 只运行这些规则 id;留空则运行全部规则 |
| skipNotes | string | "" | 追加到每条 skipped 原因后面的备注 |
| timeoutMs | number | 120000 | 协作式工具超时预算 |

值得了解的规则级参数:

- SL-002 的 minCoverageRatio(默认 0.9)和 ignoreWeekends——如果某个项目的覆盖率一直高于该比例,就通过 skipped 上报,并列出缺失的日期,而不是每缺一天报一条 finding。
- SL-011 的 requireContractorSignature(默认 true)——如果你的合同不适用双方签字规则,就设为 false。
- SL-012 的 keyWorks——关键工作目录。默认值逐字取自建市〔2002〕189号 第二条,但该条只覆盖房屋建筑工程;其他专业依据该办法第十二条引用它,应替换这份列表。

材料格式

工具接受 JSON 或 YAML。字段在读取层是可选的,由检查引擎校验,所以部分导出会产生关于缺失部分的 finding,而不是崩溃。

target: 某住宅楼工程 监理日志与旁站记录 project: name: 某住宅楼工程 serviceStart: "2026-03-01" serviceEnd: "2026-03-05" logs:
- date: "2026-03-01"
weather: 晴,具备施工条件 progress: 三层顶板钢筋绑扎完成 80% supervision: 巡视 2 次;旁站混凝土浇筑 1 次 issues: 个别箍筋间距偏大,已要求班组整改并复查 recorder: 张监理 keyWorks:
- name: 土方回填 contractor: 某基础工程公司 onsite:
- id: PZ-0001
keyWork: 混凝土浇筑 contractor: 某建筑公司 startedAt: "2026-03-04 08:00" endedAt: "2026-03-04 12:30" issues: 未发现问题;坍落度经检测符合要求 supervisorSignature: 张监理 contractorSignature: 李质检

规则来源

规则数据放在 rules/site-log-check.yaml。每条规则都带一份文件、一个文件编号、按来源自身编号体系给出的条款、一段逐字摘录,以及摘录读取自的 URL。加载器强制要求:摘录必须是至少八个字符的真实引文;如果某项检查的依据只是通用原则(kind: derived-from-principle,上限为 warn)或地方政策(kind: institutional-configuration,上限为 info),就永远不能声明为 error。

条款编号已对照《建设工程监理规范》GB/T 50319-2013 和《房屋建筑工程施工旁站监理管理办法(试行)》建市〔2002〕189号 的全文核对过。有三项发现塑造了这套规则包,记录在此,方便审阅者看清哪些是刻意没有主张的:

1. 「每日连续」没有国家条款。 GB/T 50319-2013 在监理日志的定义(第2.0.21条)里只说了每日。「日期应连续」这些字来自福建省 DBJT 13-144-2019,一份地方标准,所以 SL-002 的上限是 info。
2. 双方签字不是 50319 的要求。 表 A.0.6 只有一行签字栏,旁站监理人员(签字)。要求承包方质检员也签字,来自建市〔2002〕189号 第七条,SL-011 分别引用这两份文件,而不是合并它们。
3. 每日签名和总监理工程师审核是地方要求。 它们来自山东省 DB37/T 5009,不是国家标准,所以本包只检查是否指定了编制人(SL-007),不会凭空造出一条签字义务。

SL-012 里的关键工作目录也逐字对照过建市〔2002〕189号第二条。

故障排查

- 插件装上了,但工具始终不出现。 检查 main 是否指向 lib/index.mjs,以及 pnpm run build 是否生成了它;main 写错会让加载器静默跳过入口。
- dsh plugin add 以不兼容为由拒绝该包。 peer 范围覆盖 0.1.x 和 0.2.x;如果你的运行时不在其中,显式授予豁免: dsh plugin --profile <name> allow-version dsh-site-log-check@0.1.0 --dsh-version <runtime> --accept-risk
- 项目明明有缺口,覆盖检查却什么都没报。 只要覆盖率不低于 minCoverageRatio,SL-002 就通过 skipped 上报,把缺失日期列在那里。想让每个缺口单独成为一条发现,就调低该比值,或者去读 skipped 条目。
- check 报告 manifest-peers 失败。 静态检查器比对的是一个硬编码的 peer 范围,早于 0.2 系列。运行时会在安装时强制校验 peer 兼容性,所以声明的范围才是正确的;这是 dsh-plugin-dev 中已知的上游问题。
- 日期看起来偏移了。 所有运算都基于你提供的字符串做挂钟时间计算,不做时区转换。

开发

pnpm install
pnpm run typecheck # tsc --noEmit
pnpm test # vitest, paired fixtures per rule
pnpm run build # tsdown -> lib/index.mjs + lib/index.d.mts
node ../scripts/sync-shared.mjs dsh-site-log-check # refresh src/shared from ../_shared

许可证

Apache License 2.0 © 2026 dsh-site-log-check contributors。
预览分享卡片长什么样 ↓PerryLink/dsh-site-log-check
分享 · DeepSeek Harness Hub
PerryLink/dsh-site-log-check

比对监理日志与现场记录,逐条列出差异供人工复核

这是你的仓库?认领条目

回到顶部