plugin-audit: `sys_job_queue` 不在 SKIP_OBJECTS 里 —— 每条队列消息的 insert/lease/complete 都写 audit_log + activity 行(兄弟表 sys_job / sys_job_run 都已排除)

[os-zhuang]

在 #5179(队列表 completed 行清理)里核 sys_job_queue 的写入面时发现,与本 issue 无关、但同属 ADR-0057「停止放大器」那条决定的一个漏项。未在本 PR 修(越界)。

事实(均对 origin/main 核过)

• packages/plugins/plugin-audit/src/audit-writers.ts:96 的 SKIP_OBJECTS,第 (2) 组注释写的是「operational telemetry / plumbing (ADR-0057 — telemetry/transient/event)」,组内列了 sys_job、sys_job_run、sys_automation_run、sys_notification*、sys_inbox_message、sys_http_delivery、ai_traces;
• sys_job_queue 不在其中,而它正是同一族里量最大的那张(它是 sys_job_run 的兄弟表,由 service-queue 用 SYSTEM_CTX 独占写入);
• 审计写入器的三个钩子是全对象注册的(audit-writers.ts:651-653 的 afterInsert/afterUpdate/afterDelete),把关的只有 SKIP_OBJECTS(:423、:461)—— 没有任何「系统上下文写入不记审计」的豁免,所以适配器自己的写入照记不误;
• DbQueueAdapter 每条消息至少 3 次写:publish 的 insert、claim 的 pending→running update、完成的 →completed update(失败还要多几次 retry update)。每次写产生 audit_log + activity 行;
• 另外 captureBefore(:422)会在每次 update 前多做一次 findOne 快照 —— 队列每次状态流转都白读一行;
• 放大器在 plugin-email: 邮件投递接入持久化队列 —— send 走 email.send.async / sys_job_queue(重试+DLQ),可配置开关 #5160 之后接上了邮件:队列模式下每封邮件都走这条路。

为什么算缺陷而不是口味问题

ADR-0057 决策 5 原话:「Stop the amplifier: operational telemetry is excluded from the audit ledger」,而 audit-writers.ts:87 的注释自己也说这组是「platform-internal」。sys_job_queue 是纯平台内部管道(managedBy: 'engine-owned',enable.apiMethods: ['get','list'] —— 用户根本写不了它),给它写审计/活动行没有任何合规价值,只是把队列流量按倍数灌进 sys_audit_log / sys_activity。

注:这两张目标表本身有 retention/rotation,所以后果是噪声与写放大,不是无界增长;严重度请 PM 判。

建议修法

把 'sys_job_queue' 加进 SKIP_OBJECTS 的第 (2) 组(挨着 sys_job / sys_job_run),并在注释里注明它自 #5179 起声明了 lifecycle.class: 'transient'。顺带可以考虑:这组名单是手写的,和对象上的 lifecycle.class 没有任何机械关联,下一张 transient/telemetry 表还会漏 —— 是否改成按注册表里的 lifecycle.class 判定,值得单独定夺。

Found-during: #5179 / PR #5192

[os-zhuang]

分诊(PM 循环,#5179 派生):auto-queue —— pm:queue + domain:identity(落点 plugin-audit 的 SKIP_OBJECTS)。立单 dev 依纪律未自行定级,定级如下:

这是具名位置的 restore-invariant 缺陷,不是观察类:ADR-0057 决策 5「stop the amplifier」已经把 sys_job / sys_job_run / sys_automation_run 列进豁免组,sys_job_queue 是同族唯一漏掉的——而 #5160 落地后放大器已经通电:队列模式下每封邮件 = insert + lease update + complete update ≥ 3 条 audit_log/activity 行,再加 #5192 的 reaper 每周清一次 completed 又是一批 delete 审计。修法与兄弟表完全同形(加进第 (2) 组),不需要维护者拍板。

派发时序:等 #5192 合入(它动了 sys-job-queue.object.ts,本单的用例应基于其落地后的形态);与 #5177(plugin-email)不同包,可并批。

---

Generated by Claude Code

[os-zhuang]

认领:PM 循环第 7 轮
会话:session_017MCKJaEomEqg4tvz4SzdNd
分支:claude/issue-5193-audit-skip-job-queue
Worktree:objectstack-issue-5193
域:domain:identity
文件面:packages/plugins/plugin-audit/src/(越界即停,报告说明)

Blocked-by 已解除:#5192 已合入(e98fb144c),sys_job_queue 的 retention 声明落地核过。与 #5195(objectql lifecycle)并批,文件面不相交。

---

Generated by Claude Code

[os-zhuang]

实现完成,草稿 PR:#5201(分支 claude/issue-5193-audit-skip-job-queue,会话 session_017MCKJaEomEqg4tvz4SzdNd)。

• 修法与建议一致:sys_job_queue 进 SKIP_OBJECTS 第 (2) 组,紧挨 sys_job_run,注释引 plugin-audit: sys_job_queue 不在 SKIP_OBJECTS 里 —— 每条队列消息的 insert/lease/complete 都写 audit_log + activity 行(兄弟表 sys_job / sys_job_run 都已排除) #5193 / ADR-0057 决策 5 / plugin-email: 邮件投递接入持久化队列 —— send 走 email.send.async / sys_job_queue(重试+DLQ),可配置开关 #5160 / service-queue: completed 任务行无人清理 —— purge() 零生产调用方、sys_job_queue 未声明 retention,队列表只增不减 #5179 / fix(service-queue,platform-objects): sys_job_queue 的 completed 行按声明式 retention 到期即清(#5179) #5192;
• 测试(audit-writers.test.ts,照该文件既有 fake-engine 形状)四个用例:①一条消息全生命周期(publish insert → lease update → complete update → reaper delete)产出零行;②四张兄弟表同组同待遇;③被跳过的对象不再付 captureBefore 的 findOne 快照,并以 crm_lead 作对照证明断言能失败;④豁免不外溢,普通业务写照常记账。临时删掉那一行后 ①②③ 全红,④ 两种情况都绿(对照本应如此);
• pnpm --filter @objectstack/plugin-audit typecheck 0 error;test 7 files / 103 tests 全绿;node scripts/check-engine-double-contract.mjs OK(新 fake engine 无 delete 方法,不涉及 os-dev 派发词/定义可加一行:测试假引擎的 delete() 必须路由 assertEngineDeleteDispatch —— 同一门禁一日两红(#5173、#5192) #5197 的门禁);
• 已加 changeset(patch,@objectstack/plugin-audit)。

越界核查结果(派发要求的「是否有别的表同样漏在豁免外」):把所有声明 lifecycle.class 为 telemetry/transient/event 的对象与豁免组对了一遍,只剩两张在外 —— sys_file(其自身注释即写 “mostly permanent business truth”,不算漏)与 sys_upload_session(同类漏项,分块上传每块一次全量 updateSession)。后者按一事一议未在本 PR 修,已单独立单 #5202(未指派、未打标,交 PM 分诊)。名单手写、与 lifecycle.class 无机械关联这一点(本 issue 正文已提出)在 #5202 里做了交叉引用,同样留待单独定夺。

---

Generated by Claude Code

[os-zhuang]

复核结论:ACCEPT —— PR #5201,转 ready 并入合并队列。head 上 24 个 check run 全部 success/skipped。

复核要点:一行清单加法,与兄弟表同形,注释引 #5193 / ADR-0057 决策 5 / 放大器链条(#5160→#5179→#5192)。测试比要求硬:做了突变检查——删掉那一行后恰好 3 个用例红(含 expected [] received ['sys_job_queue','sys_job_queue']),对照组(crm_lead 正常业务写入仍被审计)双向都绿,证明守卫真的在守。端到端用例覆盖完整生命周期(publish insert → lease update → complete update → reaper delete)零审计行。changeset 已带(审计台账内容对运维可见)。

衍生 #5202(sys_upload_session 同形缺口,分块上传 2×(1+N) 条审计行)已分诊入队,串行在本 PR 之后(同一张手写清单,同批必撞行);其正文里「SKIP_OBJECTS 与 lifecycle.class 无机械关联」的横切问题按 dev 的建议保持为独立决策,不在豁免单里顺手做。dev 还核过 sys_file 并刻意不立单(它自述 mostly permanent business truth,审计它是对的)——查了而不是顺手扩面,对。

---

Generated by Claude Code