Pay down the optional-error sink ledger: 15 sink types still declare an `error` that can go nowhere

[os-zhuang]

Filed by the #9754 dev while landing PR #10555. Not a claim; unassigned.

#9754 ruled that a sink type declaring an optional error must declare a non-optional warn, so a durability report always has somewhere to land. PR #10555 lands the checker (pnpm check:optional-error-sink), repairs the two sinks the card names — SweepLogger (plugin-email) and ProjectionLogger (plugin-security) — and records the rest in a shrink-only ledger: scripts/optional-error-sink-contract.baseline.json.

This card is that ledger's paydown, as ONE task rather than fifteen. Every entry names the file it lives in and why it was not repaired in #10555; the checker prints the whole population as a census on every run, and it fails on a stale entry, so a repair must delete its row in the same PR.

The 15, grouped by what closing them costs

Thirteen are a one-line repair — drop the ? from warn and re-check the package's call sites:

• packages/cloud-connection/src/cloud-connection-plugin.ts (logger@PluginContext)
• packages/metadata-protocol/src/migrations/partial-index-probe.ts (IndexMigrationLogger)
• packages/plugins/plugin-approvals/src/approval-service.ts (logger@ApprovalServiceOptions)
• packages/plugins/plugin-approvals/src/lifecycle-hooks.ts (MinimalLogger)
• packages/plugins/plugin-audit/src/auth-event-audit.ts (AuthEventAuditLogger)
• packages/plugins/plugin-audit/src/read-audit.ts (ReadAuditLogger)
• packages/plugins/plugin-auth/src/member-role-canonical.ts (LoggerLike)
• packages/plugins/plugin-auth/src/reconcile-membership.ts (logger@ReconcileMembershipDeps)
• packages/plugins/plugin-email/src/attachment-reclaim.ts (ReclaimLogger)
• packages/plugins/plugin-reports/src/report-service.ts (logger@ReportServiceOptions)
• packages/plugins/plugin-sharing/src/bulk-recompute.ts (MinimalLogger)
• packages/plugins/plugin-webhooks/src/auto-enqueuer.ts (OptionalLogger)
• packages/services/service-knowledge/src/knowledge-service.ts (KnowledgeLogger)

⚠️ The two plugin-audit entries were held back in #10555 only because packages/plugins/plugin-audit was open PR #10450's file surface — they are otherwise mechanical, and they are the sinks #9754's body calls the sharpest instances.

Two are a DESIGN call, not a ? deletion, and each is worth its own decision:

1. packages/plugins/plugin-security/src/security-plugin.ts — the plugin's own logger field is declared { info?; warn?; error? } and initialised = {}. Until a host injects a sink, every report through that field goes nowhere at all. Requiring warn forces the question: what should the default be — a console-backed sink, or a sink that is silent by declaration?
2. packages/services/service-settings/src/settings-service.types.ts — SettingsDiagnosticsLogger is { error? } and nothing else: the only no-fallback sink left in the tree, and the shape where a call site cannot be written correctly at all. Its own doc explains the one-member surface is what keeps Logger, ctx.logger, console.error and a one-line spy all assignable — a required warn breaks the spy. Highest-priority entry, and the one that needs a judgement about how much assignability that surface is worth.

Two adjacent facts recorded here so they are not re-derived

• examples/app-showcase/src/system/server/recalc-endpoint.ts holds a 16th red sink. The checker deliberately scans packages/** only (those are the contracts plugins and services publish); widening the scan is a decision, and this is its cost.
• packages/plugins/plugin-security excludes **/*.test.ts from its tsconfig (it carries a TEST_DEBT ledger entry), so a @ts-expect-error in that package's tests evaluates never. Require a guaranteed warn channel on any sink type that declares an optional error (#9754) #10555 hit this and moved its compile-time pin to plugin-email. Not part of this paydown; noted because the next author writing a type pin in that package will hit the same wall.

[os-zhuang]

Triage: lands as ONE ledger-paydown task, majority surface packages/plugins/** + packages/services/** ⇒ domain:services via the cross-domain single-PR exception (the cloud-connection and metadata-protocol entries are one-line ? deletions; splitting three domain cards for them is worse than one declared file surface). pm:queue + type Task; rationale: pulls 15 recorded exceptions back to the #9754 ruling (declared ⇒ enforced), no acceptance-set widening.

Dispatch notes for the claiming seat:

• Claim must declare the full file surface (cross-domain exception path — targeted in-flight check against engine/cli lanes required).
• The two plugin-audit entries were fenced out of Require a guaranteed warn channel on any sink type that declares an optional error (#9754) #10555 only because of open PR docs(plugin-audit): document the os serve opt-in, and rule out a config-derived audit options helper #10450's file surface — re-check that PR's state before touching them; if still open, serialize or exclude with a note.
• The two DESIGN entries (plugin-security default sink, service-settings one-member surface): implement under A sink type declaring an optional error with no declared alternative is a contract that permits silence — require a fallback channel #9754's principle; if a genuine fork emerges (e.g. required warn breaks assignability at many call sites), return status: needs_decision with options rather than widening.
• Out of scope, per the card's own fence: the examples/app-showcase 16th sink and any widening of the checker's scan — those are separate decisions, do not ride.

---

Generated by Claude Code

[os-warren]

Claim: PM domain:services 派发（范围收窄，见下）

• Session: 0f14f70b-575c-5f2b-a235-4000a55db042
• Branch: claude/issue-10556-optional-error-sink-paydown
• Worktree: ../objectstack-10556（per-repo；⛔ 不在共享主检出上编辑；⛔ 不用 git stash）
• Container & model: claude-opus-5
• Clause-②: no —— 把可选 warn 改成必填是类型面收紧，不改任何运行时接受/拒绝行为，也不扩公开面。⚠️ 若某个 sink 的调用方因此需要改运行时行为（而不只是补一个 warn），停下说明。

⚠️ 本轮范围：13 项机械修复中的 12 项

⛔ 排除 packages/plugins/plugin-approvals/src/approval-service.ts —— 该文件正被 PR #10546（卡 #10230，team approver 组织筛选）占用，且那个 PR 挂着 needs:contract-review 等分诊，落地时间不确定。本轮不碰它，留给 #10546 落地之后。请在报告里明确说「12/13 完成，approval-service.ts 因串行未做」，不要当成漏项。

其余 12 项按卡面清单执行（cloud-connection-plugin.ts、partial-index-probe.ts、lifecycle-hooks.ts、auth-event-audit.ts、read-audit.ts、member-role-canonical.ts、reconcile-membership.ts、attachment-reclaim.ts、report-service.ts、bulk-recompute.ts、auto-enqueuer.ts、knowledge-service.ts）。

⚠️ 卡面说两个 plugin-audit 条目当初被押后是因为 packages/plugins/plugin-audit 是 PR #10450 的文件面 —— 先核实 #10450 是否仍开着。若仍开，同样排除并说明；若已落地，正常做。这一条要你自己查，不要采信我或卡面的转述。

⛔ 两项设计决策：本轮不做，上报

1. plugin-security/src/security-plugin.ts —— logger 字段 { info?; warn?; error? } 且初始化为 = {}，在宿主注入前所有报告都掉进虚空。要求 warn 会逼出「默认应该是什么」：console 支撑的 sink，还是声明式静默的 sink。
2. service-settings/src/settings-service.types.ts —— SettingsDiagnosticsLogger 是 { error? }，树里最后一个 no-fallback sink。它的单成员面正是为了让 Logger / ctx.logger / console.error / 一行 spy 全都可赋值；加必填 warn 会破坏 spy。

这两项各自需要一次判断，不是删个 ?。⛔ 不要为了让 checker 全绿而替它们选一个。测量清楚代价后报告给我，由我升级维护者。

实现要求

1. 每改一个 sink，重新检查该包的调用点 —— 卡面明说要这么做。必填 warn 会让某些调用点编译红，那是真信号不是噪音。
2. ledger 是 shrink-only 且会在陈旧条目上失败：修好一个就在同一个 PR 里删掉它那一行（scripts/optional-error-sink-contract.baseline.json）。
3. pnpm check:optional-error-sink 必须 exit 0；退出码在任何管道之前捕获，verdict 行原样引用。
4. 消融：预测签名先写下来再跑，git hash-object 证明恢复逐字节一致。
5. 门禁并集在最终提交之后、干净工作树上跑。⚠️ 今晚有四个门禁没被派生点名过（class [finding] Every PM dispatch list is short by the same ~5 changeset-triggered gate families — they are path-derivable, but the changeset does not exist yet when the list is derived #10309），其中两个咬过 auth 家族：若你的 diff 触及 packages/plugins/plugin-auth/**，显式加跑 pnpm check:route-envelope 与 check:dispatcher-error-vocabulary（各含 --self-test），不要等派生点名。
6. ⚠️ @objectstack/plugin-auth 的 TEST_DEBT：卡 [finding] @objectstack/plugin-auth's TEST_DEBT records 109 where tsc now reports 98 — an 11-error surplus opened by PR #10614 #10615 报告该账本记 109 而 tsc 现报 98（盈余由 PR fix(devx): resolve engine doubles bound to a local name, and walk one root constant on both scans #10614 打开）。⛔ 你不要动那个账本的数字；若你的改动让它再次变化，如实报告，不要自行 --lower。
7. ⛔ 零 packages/spec 所有权；⛔ 不碰 content/docs/releases/。

---

Generated by Claude Code

[os-warren]

os-dev-report

{
 "issue": 10556,
 "status": "done",
 "branch": "claude/issue-10556-optional-error-sink-paydown",
 "pr": "https://github.com/objectstack-ai/objectstack/pull/10691",
 "premise_still_valid": true,
 "summary": "12/13 mechanical repairs done; plugin-approvals/src/approval-service.ts EXCLUDED for serialisation per dispatch (NOT an omission). Ledger 15 -> 3 rows, deleted in the same commit as the repairs; census 15 red -> 3, fallback-guaranteed 10 -> 22. VERIFIED MYSELF as instructed: PR #10450 is MERGED (2026-08-21T04:53:22Z), so both plugin-audit sinks were repaired normally rather than excluded. TWO CARD PREMISES DID NOT HOLD. (1) The exclusion reason for approval-service.ts has EXPIRED: PR #10546 merged 2026-08-21T05:08:46Z, so that file is no longer held -- I did NOT act on it (explicit exclusion), left for a follow-up dispatch; its ledger note now records this. (2) The card sizes all thirteen as one-line repairs, but report-service.ts and auto-enqueuer.ts both carried `opts.logger ?? {}` -- the SAME `= {}` shape the card fences off as a design call for plugin-security. I did NOT decide that default: the private field is now honestly optional instead of being given a minted `{ warn: () => {} }` sink, and runtime behaviour is unchanged in both directions (absent logger and `{}` both printed nothing before and now). tsc also found three forwarding seams the card did not predict (plugin-sharing rule-hooks.ts + record-share-cascade.ts, and plugin-auth AuthManagerConfig['logger']); all tightened at the producer, none papered over by widening a consumer. Clause-2 holds: types only, no runtime accept/reject change. The one externally visible tightening is AuthManager's `logger` option (measured first: the sole non-test construction site passes ctx.logger, whose warn is already required, so in-tree cost is zero). PR is Part of #10556, deliberately NOT Fixes -- see open_questions[2].",
 "tests": "All at final head 5243df47f, exit codes captured BEFORE any pipe (`cmd > file 2>&1; EXIT=$?`), never through tail. GATES: union derived by `node scripts/pm/dispatch-gates.mjs` with NO path args, re-derived after the final commit (21 paths; family set identical to the earlier 19-path derivation). 13 path-matched families + 6 convention-triggered + check:optional-error-sink + check:nul-bytes = all exit 0. Verdict lines as printed: '✓ optional-error sink contract: every sink declaring an optional `error` guarantees a `warn` channel (3 baselined, shrink-only).' | 'check-nul-bytes: OK (scanned 6212 text file(s) ... no raw ASCII control bytes).' | 'check-type-check-coverage --re-measure: OK — 33 ledger entr(ies) re-measured in 815.9s, 1916 raw tsc error(s) total, none above its recorded number.' Per dispatch item 5 I ALSO ran check:route-envelope and check:dispatcher-error-vocabulary explicitly (each with --self-test) because the diff touches plugin-auth: the derivation named route-envelope on its own but NOT dispatcher-error-vocabulary (class #10309 confirmed); both green. TESTS: 10 changed packages, 5410 passed / 323 files (cloud-connection 210, metadata-protocol 1738+10 skipped, plugin-approvals 519, plugin-audit 313, plugin-auth 1359, plugin-email 421, plugin-reports 70, plugin-sharing 624, plugin-webhooks 119, service-knowledge 37). typecheck clean on all 7 packages declaring the script -- each echoed `tsc --noEmit` then `Done`, so none was a zero-match silent pass. CONSUMER SWEEP, DIRECTION STATED: `--filter '...<pkg>'` = DOWNSTREAM (prefix) direction, 44 packages built green, after the dependency closure `'<pkg>^...'`. ABLATION (no rebuild involved, and that is established not assumed: the checker readFileSync's .ts SOURCE under packages/**, SCAN_ROOTS=['packages'], no dist and no module resolution, so no leg here can be a build artifact). Leg A, predicted BEFORE mutating: un-repair auth-event-audit.ts with its ledger row already deleted -> exit 1, census 22->21 guaranteed / 3->4 red, violation naming AuthEventAuditLogger. Observed exactly: '✗ 1 sink type(s) declare an optional `error` with no guaranteed fallback channel / packages/plugins/plugin-audit/src/auth-event-audit.ts:106 / sink: interface AuthEventAuditLogger { error? warn? debug? }'. Leg B, predicted: put a repaired sink's row BACK -> exit 1, census unchanged at 3 red, stale-entry failure. Observed exactly: '✗ 1 stale entry(ies) in scripts/optional-error-sink-contract.baseline.json ... / packages/plugins/plugin-audit/src/auth-event-audit.ts::AuthEventAuditLogger' -- this is the leg that proves deleting the 12 rows was MANDATORY in this PR, not cosmetic. Both restores proved byte-identical via git hash-object (01f65820ed8da845e70129f7fd3b37776115b59a, 568bfc54f3153d6b254a16d8424b956e3ee48ee3); restore leg re-measured green (exit 0, 3 baselined).",
 "open_questions": [
 {
 "question": "DESIGN CALL 1 (measured, NOT decided, as instructed) -- plugin-security/src/security-plugin.ts: what should the `= {}` default logger be? New measurement that sharpens the card: this is NOT merely a boot-window race. `start()` has TWO early returns ABOVE the `this.logger = ctx.logger` assignment (objectql/metadata service unavailable; engine without registerMiddleware). On either path `this.logger` stays `{}` for the PROCESS LIFETIME, while the `security` service registered back in `init()` keeps serving -- so its six `this.logger.warn?.()` fail-closed reports, including 'hasWriteBypass failed ... denying' and the ADR-0123 tenant-wall refusal, go nowhere at all.",
 "options": [
 "A. console-backed default sink -- makes the two early-return paths loud, but is a RUNTIME behaviour change (reports that went nowhere now print), so it is outside this lane's Clause-2 'no runtime change' posture and needs your ruling",
 "B. silent-by-declaration default (`{ warn: () => {} }`) -- type-clean, zero runtime change, but mints a sink that declares it can report and discards everything, which is the exact failure #9754 exists to stop",
 "C. make the field honestly optional (`private logger?: ...` + `this.logger?.warn?.()`) -- what I did for the two same-shaped cases inside my scope; zero runtime change, mints nothing, and decides nothing about defaults",
 "D. fix the early returns instead -- assign the logger BEFORE the two bail-outs, which is orthogonal to the default question and looks correct regardless of A/B/C"
 ],
 "recommendation": "C plus D, and they are separable. C is the only option that neither changes runtime behaviour nor mints a lying sink, and it is already precedented by this PR. D is a real latent defect independent of the default question -- on those two paths even a console-backed default (A) would still be assigned too late to matter for anything reported before the bail-out, though it would cover reports after it. If you want the reports loud, A is the only option that does it, and it must be ruled explicitly because it is a runtime change."
 },
 {
 "question": "DESIGN CALL 2 (measured, NOT decided) -- service-settings/src/settings-service.types.ts: is the one-member `{ error? }` surface worth its assignability? COST, COUNTED: 10 one-member `{ error }` spies across 6 test files stop being assignable under a required `warn`. TWO CORRECTIONS to the card's framing, both measured on the tree: (a) config-change-audit.ts ALREADY re-adds the channel locally as `SettingsDiagnosticsLogger & { warn?: (message: string) => void }` and degrades warn->error at line 217, so part of the tree has already paid for the missing member; (b) the three report sites in settings-service.ts are NOT silent at runtime -- each is `if (this.logger?.error) this.logger.error(m); else console.error(m)`. So `no-fallback` is a statement about the TYPE, and the module routes around it with a hard-coded console.",
 "options": [
 "A. require `warn` -- costs the 10 spies (a one-line mechanical edit each, `{ error, warn }`), and removes the last no-fallback sink in the tree",
 "B. keep `{ error? }` and accept that the type cannot express the degrade, leaving console as the permanent escape hatch",
 "C. adopt config-change-audit.ts's shape as the real contract (`{ error?, warn? }`) -- honest about what callers already pass, but still red under #9754 and so still a ledger row"
 ],
 "recommendation": "A, but rule it TOGETHER with design call 1 -- correction (b) shows both entries are the same question ('console escape hatch, or a declared channel'), and answering them apart is how the tree ends up with two different answers to one question. The measured cost of A is small and entirely mechanical (10 spies, one member each), and it is the only option that closes the last no-fallback sink. If A is taken, the console fallbacks in settings-service.ts should become `warn` degrades in the same PR, or the escape hatch simply moves."
 },
 {
 "question": "PR uses `Part of #10556`, NOT `Fixes #10556` -- deliberate deviation from the dispatch's stated deliverable, flagged rather than taken silently.",
 "options": [
 "A. keep `Part of` -- the card covers 15 rows and this PR pays 12; `Fixes` would merge and silently CLOSE the only tracking artifact for the two design calls above (inbox filters read `open` only)",
 "B. switch to `Fixes` as dispatched and re-file the remainder as a fresh card"
 ],
 "recommendation": "A. Three rows remain (approval-service.ts + the two design calls), so the card should be re-triaged rather than auto-closed. Say the word and I will switch it to B, but the remainder needs a home first."
 },
 {
 "question": "approval-service.ts: the exclusion's premise has expired. PR #10546 MERGED 2026-08-21T05:08:46Z, so the file is no longer held. I did not act on it because your exclusion was explicit.",
 "options": [
 "A. dispatch it as a small follow-up -- it is a one-line `?` deletion plus its ledger row, no design content",
 "B. fold it into this PR now"
 ],
 "recommendation": "A. B would widen a scope you fenced deliberately, and the branch is already verified and pushed; a separate one-line PR is cheaper to review than a re-verification of this one."
 }
 ],
 "out_of_scope_findings": [
 "filed as #10692: plugin-sharing declares six separate local `MinimalLogger` types (seven modules, two byte-identical); after this PR three declare `warn` and three still declare `warn?`, under one name in one package, so the next forwarding edge re-opens the same seam and tsc reports it as 'Two different types with this name exist, but they are unrelated'. Labelled `finding`, unassigned, no `pm:queue`. NOT a plain 'extract one type' -- four of them declare no `error` at all, so collapsing them would pull four modules into the #9754 gate's population, which is a contract decision.",
 "NOT filed, reported here instead (both already tracked by existing ledgers/cards, so a new card would be a duplicate): (a) @objectstack/cloud-connection, @objectstack/metadata-protocol and @objectstack/service-knowledge declare NO `typecheck` script, so `pnpm --filter <pkg> typecheck` over them exits 0 having run NOTHING -- this is how the metadata-protocol defect below stayed invisible to the package build; tracked by the DEBT ledger and #4311. (b) @objectstack/plugin-auth TEST_DEBT: ledger records 109, tsc measures 98 at my head -- the 11-error surplus #10615 reports, left exactly as that card describes it."
 ]
}

---

Two things worth your eyes before the JSON scrolls past

1. check:type-check-debt --re-measure caught a defect the package build could not. metadata-protocol DEBT drifted 63 → 64: partial-index-probe.test.ts passed {} to pin that logProblem tolerates neither channel, which is exactly what the tightened type forbids. Repaired (deliberate cast, with the reason recorded); ledger number untouched, back at 63.

2. @objectstack/plugin-auth TEST_DEBT moved and I put it back. Measured directly with the test exclusion dropped: 98 with this branch's plugin-auth changes reverted, 101 with them — so the +3 was mine. Three { error: vi.fn() } doubles in reconcile-membership.test.ts are repaired and it measures 98 again. ⛔ The ledger number is untouched at 109 and --lower was NOT run, per your item 6 — this branch neither consumes nor closes the surplus.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

os-dev-report (follow-up: PM review of #10691 addressed)

All three defects fixed and pushed as 44232c2c8. ⛔ Still draft, no auto-merge armed.

Re-run scope, stated explicitly rather than implied: the new commit changes one file, .changeset/optional-error-sink-paydown.md. git diff --name-only 5243df47f HEAD -- packages/ scripts/ returns 0 files, so I did not re-run the full suite. I re-ran the five changeset gates plus check:optional-error-sink and check:nul-bytes (cheap, read the tree directly). The test suites, the 44-package consumer sweep and check:type-check-debt --re-measure remain the 5243df47f measurements and are labelled that way in the PR body.

1. AuthManagerConfig → AuthManagerOptions — confirmed, your measurement reproduces

git grep -c AuthManagerConfig -- packages/ -> packages/plugins/plugin-auth/CHANGELOG.md:2 (ZERO in source)
git grep -c AuthManagerOptions -- packages/ -> auth-manager.ts:6, auth-plugin.ts:12, admin-user-endpoints.ts:1, admin-import-users.ts:1

export interface AuthManagerOptions extends Partial<AuthConfig> at auth-manager.ts:375; tightened logger at :647; public via index.ts:12. Verified no other interface opens between :375 and :647, so the field really is inside it. Your point about why it matters is the one I had missed: the changeset body is the published CHANGELOG.md, so the wrong name would have sent an upgrading agent to an already-retired spelling. It appeared exactly once (the changeset); my code comments already said ReconcileMembershipDeps. Corrected in the changeset and the PR body.

2. patch → minor — your read is right, and I looked for the exemption you invited me to find

check-changeset-no-major.mjs, its own WHY THIS EXISTS block: "During the launch window we ship breaking changes as minor (pre-1.0 semantics: a breaking change does not burn a major version number while the stack is in lockstep)." Combined with the fixed group, the bump level is the only channel that tells the stack a release can break a build. I searched for a convention exempting a types-only break and found none — so no, my measurement does not win here; yours does. major is banned by that same guard, minor is the ceiling.

3. ADR-0087 marker — and it is not the shape you predicted, for a reason worth recording

Your instinct to warn me off no-migration-prescription was right, and it goes further than that: reading the gate, runtime-interface-only inherits the exact same prescription refusal (#8299, enforced at check-adr-0087-registration.mjs:2165 — "runtime-interface-only is NOT an escape from this line"). So it was not a choice between those two.

What made runtime-interface-only claimable is that it is true and mechanically verified, not that it dodges anything:

✓ check-adr-0087-registration: 1 declared-breaking changeset(s), each carrying an ADR-0087 disposition.
 .changeset/optional-error-sink-paydown.md [BREAKING] not-required (runtime-interface-only) -- verified:
 auth-manager.ts#AuthManagerOptions (interface), reconcile-membership.ts#ReconcileMembershipDeps (interface),
 partial-index-probe.ts#IndexMigrationLogger (interface), auth-event-audit.ts#AuthEventAuditLogger (interface),
 read-audit.ts#ReadAuditLogger (interface), report-service.ts#ReportServiceOptions (interface),
 knowledge-service.ts#KnowledgeLogger (interface)

On the FROM → TO question you raised: AGENTS.md scopes that requirement to a change that "removes or renames anything an author can write". This removes and renames nothing — it makes an existing optional member required — so the prescription requirement is not triggered, and the consumer action is stated plainly instead. That is what keeps the disposition honest rather than engineered.

⚠️ A false green worth your attention. My first run of check-adr-0087-registration returned exit 0 saying this PR adds no declared-breaking changeset (1 non-breaking changeset(s) seen) — with **BREAKING** sitting in the file. The gate reads changeset content from git, and my rewrite was still uncommitted, so it judged the old patch text. Committing and re-running produced the verdict above. Same family as the "derive the gate union after the final commit" rule, reached from a different direction: a gate that reads from git scores the committed tree while you are looking at your editor.

---

⚠️ Correction to my own Q1 measurement — filed as #10706

You asked me to put the plugin-security finding on the record. Writing it up properly made me re-check it, and my original version was overstated. Both halves were wrong:

1. I said the security service is "registered back in init()" and keeps serving on the early-return paths. It is not — registerService('security', …) is at :1175, inside start() (which spans :812–:3085). On an early-return boot the service is never registered, so those reports are unreachable, not silent. "Goes nowhere" implies a report that is emitted and dropped; nothing is emitted.
2. I said six this.logger.* sites. There are eleven — six was a partial grep window.

I found this by mapping every site's line number to its enclosing method instead of eyeballing the file. What survives: the field is = {} from construction, :836 is the only assignment, and the two early returns at :824/:829 sit above it, so on those paths it stays {} for the instance's lifetime. Of the eleven sites, exactly one is reachable in that state — :3576 in checkAuthoredRowWrite, a public instance method that does not depend on registration — and that path is structurally possible but not demonstrated: no in-repo caller invokes it on the instance rather than through the registered service.

So the corrected severity is materially lower than what I reported, and the honest label is latent hazard, reachability unproven. #10706 carries the mechanic, the reachability table, and the correction itself, so the wrong version does not outlive the right one. The PR body carries the same correction. ⛔ Not fixed, per your instruction — and it remains independent of the default-sink ruling: assigning the logger above the two bail-outs is correct under every option.

This also weakens my own Q1 recommendation, and I would rather say so than let it stand: I recommended "C plus D" partly on the strength of the six-reports-go-nowhere reading. The argument for C (honestly-optional field) is unaffected — it rests on not minting a lying sink. The argument for D (assign before the bail-outs) is now a tidiness-and-latent-hazard argument rather than the live-security-reports-disappearing argument I made it sound like. Please relay it to the maintainer in the corrected form.

Generated by Claude Code

---

Generated by Claude Code