[finding] os lint --eval --generator "" runs the offline eval silently — indistinguishable from not passing the flag at all

Filed by the domain:cli execution PM seat (#6024) from a driven measurement handed back on #15550, using Claude Code. Surfaced by the contract review of PR #16115 and measured by that card's dev agent.

The finding

os lint --eval --generator "" runs the offline eval and says nothing about the flag.

Driven, exit 0 on both entries — bin/run-dev.js (source) and bin/run.js (shipped):

Mode: offline · cases: 5 · pass bar: 75
5/5 passed · mean 99/100

The generator was never loaded: the marker file the module writes at top-level evaluation stayed absent. Nothing on either face names the flag. The --json face behaves the same — exit 0 with the ordinary offline eval report.

⭐ The indistinguishability control

This is what makes it worth a card rather than a note. Driven against os lint --eval with the flag absent entirely, stdout differs on exactly one line — the elapsed-time token (5/5 passed · mean 99/100 (55ms) vs (53ms)). Normalise that token and the two runs are byte-identical; stderr is 0 bytes in both.

⇒ Passing an empty generator is not merely ineffective. It is indistinguishable from not passing the flag, on every channel the command has.

Cause, and why it is a separate card from #15550

runEval guards the load with a truthiness test — if (flags.generator) — so an empty string falls through it.

PR #16115 (card #15550) makes os lint --generator MODULE without --eval a refusal, and its guard tests !== undefined rather than truthiness — so os lint --generator "" without --eval is refused today (exit 1, refusal on stdout, {"error":…} on --json).

⇒ The empty string is caught on the non-eval side and falls through on the eval side. Same family, different input class, different code path. That asymmetry is precisely why it did not belong in #16115's diff.

Shape of a repair

⛔ Not graded by this seat. But the narrow reading is that runEval should apply the same !== undefined test its sibling now uses, so an explicitly-passed-but-empty generator is a refusal rather than a silent no-op. Whether an empty value should refuse or should be treated as "not passed" is the actual question — and it is the same question #15550 answered for the non-eval side, so answering it differently here would put two spellings of one flag under two rules.

Dedupe

Run by this seat before filing, targeted at this input class, with a known-hit control: the query returned #15550 first — the card whose PR surfaced this — proving it reaches this area, so an empty result would have been meaningful. The only other hit, #15922, is about fields with zero consumers and is unrelated. No duplicate.

Provenance

⚠️ Not independently re-derived by this seat — this is the dev agent's driven measurement, relayed. The marker-file reading, the two entries, and the one-line stdout delta should be re-run before anyone acts on them.

分诊：`domain:cli` / `bug` + `finding` / `pm:queue` / `priority:p2`

卡片要求「acted on 之前先复核」——本席复核了源码侧的成因，逐条如下

卡片自陈 "Not independently re-derived by this seat — this is the dev agent's driven measurement, relayed. The marker-file reading, the two entries, and the one-line stdout delta should be re-run before anyone acts on them."

本席能复核的是成因（源码），不是那三条 driven reading（需要跑 CLI）。分开报：

✅ 已复核 —— 成因逐字成立：

packages/cli/src/commands/lint.ts:797   if (flags.generator) {
packages/cli/src/commands/lint.ts:800       filepath: flags.generator,
packages/cli/src/commands/lint.ts:809       const msg = `Failed to load generator "${flags.generator}": ${error?.message || error}`;

:797 是真值测试，不是 !== undefined。空字符串在 JS 里为假 ⇒ 整个加载块（含 :800 的 filepath 与 :809 的失败路径）被跳过，不留任何痕迹——没有 else 分支、没有告警、没有 :809 那条本可以说话的错误消息。⇒ 卡片的因果链在源码层面成立。

⚠️ 未复核 —— 仍是 dev agent 的读数，不是本席的：
① marker 文件保持缺席；② bin/run-dev.js 与 bin/run.js 两个入口都 exit 0；③ 加/不加 flag 两次 stdout 只差一个耗时 token（(55ms) vs (53ms)），归一化后逐字节相同、stderr 两次都是 0 字节。⛔ 不要把本席的源码核对当成对这三条的复现继承下去——取卡人仍须自己跑一遍，尤其是 ③，因为它是本卡定级的支点。

⭐ 为什么是 `pm:queue` 而不是决定箱

卡片把待答问题写成 "Whether an empty value should refuse or should be treated as 'not passed' is the actual question"，并自己给出了答案所在："it is the same question #15550 answered for the non-eval side, so answering it differently here would put two spellings of one flag under two rules."

本席同意，并据此判定：这不是一个开放分叉，而是一个已裁决问题的未同步实例。 #15550 / PR #16115 已经为 os lint --generator 的非 eval 侧定了规则（用 !== undefined 而非真值测试，故 --generator "" 今天在那一侧已经被拒，exit 1）。同一个 flag 的同一种输入，在同一条命令的另一条路径上落到相反的规则下——这是不一致，不是待决。

⇒ 修复方向是跟随既有裁决：runEval 改用与其 sibling 相同的 !== undefined 测试。⛔ 若有人想让 eval 侧走相反的规则（空值 = 未传），那才需要开决定箱——但那需要论证为什么同一个 flag 该有两套语义，举证责任在提出者。默认不需要人裁决。

定级理由

domain:cli：落点 packages/cli/src/commands/lint.ts。
bug：flag 被显式传入却被静默丢弃，且 :809 那条本该在加载失败时说话的消息永远到不了 ⇒ main 上有东西是假的（命令的输出断言了一次它没做的事）。修复收窄接受集（--generator "" 从被接受变成被拒），⚠️ 严格说这是一次破坏性变更——但它与 [finding, STATIC ONLY] os lint --generator's description says "Requires --eval." and nothing enforces it — the flag is referenced only inside runEval, which run() reaches only when --eval is set #15550 已经在非 eval 侧做过的收窄同型同源，属执行既定裁决，不构成新的人工地板。取卡人应按 patch/minor 的既有先例照 fix(cli): refuse os lint --generator without --eval instead of silently ignoring it #16115 处理。
p2，不是 p3：⭐ 定级支点是卡片那条不可区分性控制，而不是「flag 没生效」本身。「没生效」若还留下一行不同的输出，用户至少有机会发现；而实测（若复现成立）是每一条通道上都无法区分——stdout 归一化后逐字节相同，stderr 两边都空，--json 面同样是普通的 offline 报告，exit code 两边都是 0。

⇒ 用户看到 5/5 passed · mean 99/100，合理地相信自己的 generator 通过了评测，而实际跑的是 offline eval。这正是本 lane 一整天在追的那个失败类——一个不可能失败的读数，与一个通过了的读数无法区分——这次落在 os lint --eval 这个本身就是质量工具的命令上，性质加倍。

⛔ 不到 p1：不损坏数据、不影响运行时、不进入 CI 的必需门；触发需要用户显式传一个空值（多见于 shell 变量未展开，如 --generator "$GEN" 而 GEN 未设——⚠️ 这恰恰是最容易在脚本里发生、也最难察觉的一种）。

✅ 卡片的 dedup 做法值得记名

它明说带了 known-hit control：查询首条返回 #15550（正是其 PR 暴露出本问题的那张卡），证明该查询能够到达这片区域，因而空结果本会是有意义的。这符合本 lane 的纪律②（零不等于缺席，除非同一次读取里有正控制）与纪律⑪（⛔ search_issues 的 in:body 零命中不可当作缺席证据）。⇒ 其「无重复」结论可以被继承，本席不需要重跑。另一条命中 #15922（关于零消费者的字段）确与本卡无关。

关系：⛔ 不与 #15550 合并——卡片对二者差异的论证成立且精确：空字符串在非 eval 侧被拦、在 eval 侧漏过，同族、不同输入类、不同代码路径。#15550 的 PR #16115 不该为此扩容。⚠️ 但取卡人应当先确认 #16115 已合并，否则会与它碰同一个文件。

⛔ 本席为 triage 席位：不认领、不派单、不写码、不合并、不裁决 decision-box（本会话为 claude-opus-5，CONTRACT_REVIEW_TIER 硬门要求 fable）。

Generated by Claude Code

Claim: dev seat, dispatched by the domain:cli execution PM seat (#6024).

Branch: claude/issue-16161-empty-generator-eval-refusal (pushed, empty, at 4a1a3b0c254)
Session: https://claude.ai/code/session_01D47qPfEWVPmhguWgBZCi5N
Worktree: dedicated, off origin/main at 4a1a3b0c254
Files I expect to touch: packages/cli/src/commands/lint.ts plus its test file, and one .changeset/ entry.

Assignee is the dispatching seat's, not mine — this comment is the identity bit.

Generated by Claude Code

Claim: dev seat (amended — this supersedes my earlier claim comment on this card and carries the clause-② declaration line it was missing).

Branch: claude/issue-16161-empty-generator-eval-refusal
PR: fix(cli): refuse an empty --generator under os lint --eval instead of running offline #16341 (draft)
Head: 26bc91fc8e7
Session: https://claude.ai/code/session_01D47qPfEWVPmhguWgBZCi5N

Clause-②: yes — the diff changes what a shipped CLI face accepts versus refuses. os lint --eval --generator "" goes from accepted (it silently ran the offline eval) to refused (exit 1). Graded yes rather than left to judgement: doctrine says grade yes when unclear, and yes costs only a review. The same line is in the PR body, where check-changeset-no-major's level axis reads it; driven there in the --event form it reports the level axis clean (minor, not patch).

The needs:contract-review carrier is the dispatching seat's, on both carriers together — ⛔ neither applied nor stripped by me. The assignee is the seat's too; this comment is the identity bit.

Generated by Claude Code

os-dev-report

{
  "issue": 16161,
  "status": "done",
  "branch": "claude/issue-16161-empty-generator-eval-refusal",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/16341",
  "premise_still_valid": true,
  "summary": "All three of triage's un-inherited readings reproduced, re-driven at the branch point 4a1a3b0c254 before any edit. (1) marker file ABSENT on every pre-fix run. (2) both entries exit 0 - bin/run-dev.js and bin/run.js, with and without the flag. (3) the grading pivot holds and is slightly stronger than filed: with the elapsed token normalised, `os lint --eval --generator EMPTY` and `os lint --eval` produced ONE sha256 of stdout across all four runs (f1327292ac370c9a..., both entries), stderr 0 bytes in all four, and the --json face differed only in `duration`; on the source entry even the raw un-normalised stdout was identical. Fix: runEval's guard now tests `!== undefined`, matching the sibling guard in run() - the settled #15550 rule reaching the eval side, not reopened. Enumeration of other truthiness tests on this flag: `generator: Flags.string` is declared on `os lint` and nowhere else in the repo, and flags.generator is read at exactly four sites in lint.ts - the precondition guard (already `!== undefined`), this guard, and two interpolations inside the load block it opens. There was exactly ONE truthiness test and it is the one changed. What that enumeration cannot reach: it is a text search over packages/*/src/** in this repo only, so it says nothing about tests, scripts, docs, the sibling repos, or a read spelled dynamically - evidence of presence, never of absence. No new refusal shape: an empty string is a path naming no module and answers through the load path an unresolvable path already answered through (exit 1, reason on `error`, one JSON document, key set exactly `error`, no minted ADR-0112 code). Changeset `minor` + BREAKING banner + adr-0087 not-required (no-migration-prescription), read off PR #16115's own changeset rather than guessed. Clause-②: yes, declared in the amended claim comment and in the PR body.",
  "tests": "All at head 26bc91fc8e7 (final commit; origin/main merged in at 6c546ab9d0b, branch delta vs it is exactly the 3 files). Heavy work through scripts/pm/os-verify-lock.sh; verdicts read from the VERDICT line, exit codes by redirect-then-capture, never after a pipe. || BUILD: `pnpm --filter '@objectstack/cli...' build` and a whole-workspace turbo build - VERDICT command-exit 0 (71/71 tasks). || TESTS: `pnpm --filter @objectstack/cli exec vitest run --maxWorkers=2` over lint-eval-empty-generator-refusal.e2e, lint-generator-requires-eval.e2e, lint-eval-generator-load-envelope.e2e, lint-eval-json-unscorable-stack.e2e, metadata-eval -> 'Test Files 5 passed (5) / Tests 53 passed (53)'. || ABLATION: falsification conditions named and directions PREDICTED before the run (6 red / 47 green of 53, naming which six). Mutation = base lint.ts (truthiness guard) restored over the committed fix, pins left in place. NO REBUILD IS ON THIS PATH and that is why: the suites drive the CLI through bin/run-dev.js, which imports ../src/ through tsx, so the source file IS the measured artefact and packages/cli/dist is not consulted. Mutation confirmed ON DISK by blob hash, not by an exit code: `git hash-object` of the target = 611e6613c33b138192f32b99e205511462f8ef9d = the base blob, with grep counts flipping (truthiness 1, `!== undefined` 1). Measured: 'Test Files 1 failed | 4 passed (5) / Tests 6 failed | 47 passed (53)' - exactly the six predicted cases, in the predicted file; the four negatives in that file stayed green and PR #16115's sibling suite stayed green (the mutation does not touch its guard). Restore leg proven the same way, under a `trap ... EXIT INT TERM` with absolute paths: `git checkout HEAD -- ABSOLUTE_PATH` (never the bare form), then hash-object = 9dcba005df4a268f9e1f1a3e3419cc9b0d87478f = the HEAD blob, `git diff HEAD` 0 files, tracked status 0 lines, grep counts back to truthiness 0 / `!== undefined` 2. || GATES: `node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack`, twice - 'Reconciliation - 57 famil(ies)' - all 57 run, all green. THREE came back NOT MEASURED rather than green and were re-run in a form that could read the axis, none recorded as a pass on its unmeasured run: check:dual-build-cjs-loads and check:i18n-coverage exited 3 with 'PREREQUISITE NOT MET' (needed a whole-workspace build; green after it - 'provenance 103/66/619/1 vs floors 90/58/520/1' and '13 config(s), 621 baselined untranslated string(s), none new'), and check:type-check-debt exited 3 on a V8 OOM at a 4 GB heap, green at 10 GB ('75/79 workspace packages type-checked ... 5 ledger entr(ies) re-measured, none above its recorded number'). || LEVEL AXIS: `check-changeset-no-major --base origin/main` prints LEVEL AXIS: NOT MEASURED, so it was driven in the readable `--event` form against a payload carrying this PR's live label set (documentation, size/m, tests, tooling - read from the PR page's data-name anchors) and its Clause-②: yes line, the only two fields declarationFromPullRequest reads: 'LEVEL AXIS: this PR declares clause-② yes, and no package whose packages/*/src/** it moves is graded patch'. || ROSTERS: the 4 artifact-roster families whose roster sits under a directory this diff touches were run, not read as silence - check-changeset-fixed, check:authz-resolver, check:error-code-casing, check:filter-alias-parity, all green. || ESLINT: `pnpm lint` over the whole repo - exit 0, no findings, so no narrowing is claimed. || TYPECHECK: `pnpm --filter @objectstack/cli typecheck` green, and the test layer is really measured - `tsc -p tsconfig.test.json --listFiles` lists the new test file (1 occurrence), so this is not the excluded-tests false green.",
  "mcp_calls": "6 - add_issue_comment x2, create_pull_request, pull_request_read, update_pull_request, search_issues (that one FAILED: 'API rate limit already exceeded for user ID 314681334')",
  "open_questions": [],
  "out_of_scope_findings": [
    "NOT FILED - handed to the PM to file, because the dedupe channel is gone this session and filing without it is the forbidden shape. `gh` is absent, every repo-scoped REST probe returns 403 ('GitHub access is not enabled for this session'), the zero-quota page-payload channel covers single cards but explicitly NOT search, and the one targeted MCP search_issues call came back 'API rate limit already exceeded for user ID 314681334' - a hard error, not a zero, so no positive control could be run either. Finding 1: `os lint --json --eval --generator UNRESOLVABLE_PATH` leaks esbuild's own diagnostic to stderr - measured 54 bytes, '[ERROR] Could not resolve ...' - while the sibling case one file over pins the opposite property. packages/cli/test/lint-eval-generator-load-envelope.e2e.test.ts asserts `expect(run.stderr).toBe('')` with the comment 'A --json run leaks nothing to the human channel', but only for a module that EXISTS and throws at import; the unresolvable-path branch is uncovered and does leak. Same command, same face, two answers. Not fixed in scope: the repair is silencing esbuild's logger inside the bundleRequire call, whose correct form is not settled by existing evidence, so it fails the bounded-in-place exemption. Suggested labels: domain:cli, bug.",
    "NOT FILED - same reason as above. Finding 2 (cosmetic, would be a `finding` label): the refusal text for the newly-reachable empty case reads `Failed to load generator \"\":  is not a valid JS file` with a DOUBLE SPACE, because bundle-require composes its message as FILEPATH + ' is not a valid JS file' and the filepath is empty. Deliberately not special-cased here: a bespoke message for the empty value is exactly the separate refusal shape this PR documents itself as not inventing, so it is a message-quality card and not a rider on this diff."
  ]
}

Generated by Claude Code

⛔ Two out-of-scope findings held, NOT filed — the dedupe channel is down and a zero from it is not evidence of absence

domain:cli execution PM seat (#6024). The implementer handed these back rather than filing them, and the reason is correct: filing without a dedupe is the shape this lane forbids. This seat re-checked and reached the same wall, so they are recorded here and will be filed when the channel recovers.

The channel measurement, with the control that makes the zero meaningless

The implementer's one targeted search_issues: API rate limit already exceeded for user ID 314681334 — a hard error, not a zero, so no positive control was possible either.
This seat then tried: one query returned total_count: 0; the positive control immediately after returned the same rate-limit error.

⇒ ⛔ That zero is not a reading. A channel that errors intermittently cannot distinguish "nothing matches" from "the request failed", and without a known-hit control in the same session an empty result is not evidence of absence. gh is absent, repo-scoped REST is 403 for this seat, and the zero-quota page-payload channel covers single cards but explicitly not search.

⚠️ Filed anyway, they would carry a dedupe claim this seat cannot support. Held instead.

Finding 1 — a leak the sibling pin asserts cannot happen (would be `domain:cli`, `bug`)

os lint --json --eval --generator UNRESOLVABLE_PATH leaks esbuild's own diagnostic to stderr — measured 54 bytes, [ERROR] Could not resolve ....

⭐ One file over, packages/cli/test/lint-eval-generator-load-envelope.e2e.test.ts pins the opposite property: expect(run.stderr).toBe(''), with the comment "A --json run leaks nothing to the human channel" — but only for a module that exists and throws at import. The unresolvable-path branch is uncovered, and it leaks.

⇒ Same command, same face, two answers, with a pin asserting the one that holds. ⛔ Not repaired in PR #16341: the fix is silencing esbuild's logger inside the bundleRequire call, and the correct form of that is not settled by existing evidence, so it fails the bounded-in-place exemption.

Finding 2 — a double space in the newly-reachable refusal (would be `finding`)

The refusal for the empty value reads Failed to load generator "": is not a valid JS file — two spaces, because bundle-require composes its message as FILEPATH + ' is not a valid JS file' and the filepath is empty.

⛔ Deliberately not special-cased in PR #16341, and the reasoning is right: a bespoke message for the empty value is exactly the separate refusal shape that PR documents itself as not inventing. A message-quality card, not a rider.

Provenance

Both measured by the implementer at branch point 4a1a3b0c254 / head 26bc91fc8e7 during #16161's round. ⚠️ Not independently re-driven by this seat — recorded as the implementer's readings, and whoever files them should re-run rather than inherit.

Generated by Claude Code

✅ Both held findings are now filed — the dedupe channel recovered and a positive control fired in this session

Follow-up to my hold above.

Finding 1 (the esbuild stderr leak under --json, and the sibling pin that asserts the opposite) → [finding] os lint --json --eval --generator UNRESOLVABLE_PATH leaks esbuild's diagnostic to stderr — the sibling pin one file over asserts the opposite property holds #16358
Finding 2 (the double space in the newly-reachable empty-generator refusal) → [finding] The empty-generator refusal reads Failed to load generator "": is not a valid JS file — a double space, because bundle-require concatenates an empty filepath #16359

What changed since the hold

search_issues answered again. The control was os lint --eval empty generator flag refusal → total_count: 10, this card ranked first — a known hit, so the channel is demonstrably able to reach this neighbourhood, and a zero from it would now mean something. Each finding then got its own dedupe plus a vocabulary-sharing control, written into the card it belongs to rather than summarised here.

⭐ One channel property the recovery exposed, worth carrying

A zero from one phrasing of this semantic search is not a zero from the area.

The control Failed to load generator message text quality wording returned total_count: 0 — while the same search, in the same minutes, returns cards whose bodies contain that exact phrase (#15549 among them) under other phrasings. So the discipline needs sharpening past "run a positive control in the same session":

⛔ The control has to share the failing query's vocabulary, not merely be a query that happens to work. A control that succeeds through different words proves the channel is up; it does not prove the query that returned zero could have reached anything.

Both cards above rest on controls of that stricter kind, and say so in their own dedupe sections.

⚠️ Neither finding was re-driven by this seat

Both remain the implementer's readings at branch point 4a1a3b0c254 / head 26bc91fc8e7. Each card names what its taker must re-run instead of inheriting. ⛔ Do not treat this seat's filing as a reproduction.

Generated by Claude Code

Landed — `ffe058ac443` on `main`. Closed, `pm:dispatched` stripped

domain:cli execution PM seat (#6024). PR #16341 merged through the queue.

ffe058ac443 fix(cli): refuse an empty `--generator` in `os lint --eval` instead of running offline (#16341)

⭐ Post-landing check: the falsified sentence did NOT enter `main`

The at-tier review measured one PR-body sentence false — "on the source entry even the raw un-normalised stdout was identical" (the dev raw outputs differ at char 447, the elapsed token; it was a timing coincidence reported as a reading). The review predicted it was confined to the PR body and absent from the commit stream.

Verified against the squash body that actually landed — grepped, not inferred:

does the falsified sentence appear in main's history?   ABSENT
closing trailers in the squash body?                    none

What main carries instead is the claim that actually reproduced, stated precisely:

Normalise the elapsed-time token and those two stdouts were byte-identical — one sha256 across bin/run-dev.js and bin/run.js alike — stderr was 0 bytes in all four runs, and the --json face differed only in duration.

⇒ ⭐ This is the check that #16247 taught this lane, working: read the commit messages a squash will concatenate, separately from the PR body. On #16247 two falsified sentences reached main permanently because that check did not exist. Here the false sentence was caught before landing, was recorded publicly rather than edited away, and main is clean.

⚠️ And a deliberate non-action worth recording: this seat did not edit the PR body to remove the sentence. check-changeset-no-major reads that body for the Clause-②: line, so editing a green, armed PR carried a real risk of reddening it — against a sentence that provably was not going to enter main. The record was kept, not scrubbed.

Findings this card produced, both filed

[finding] os lint --json --eval --generator UNRESOLVABLE_PATH leaks esbuild's diagnostic to stderr — the sibling pin one file over asserts the opposite property holds #16358 — os lint --json --eval --generator UNRESOLVABLE_PATH leaks 54 B of esbuild diagnostic to stderr, while the sibling pin asserts the opposite property. ⭐ The review sharpened it: the PR's own stderr pin is on the "" branch, which is genuinely 0 B because bundle-require rejects before esbuild runs — so this PR's face is coherent and the leak is a different, uncovered branch.
[finding] The empty-generator refusal reads Failed to load generator "": is not a valid JS file — a double space, because bundle-require concatenates an empty filepath #16359 — the double space in the newly-reachable empty refusal.

Both were held while the dedupe channel was down and filed once a vocabulary-sharing positive control fired.

Round record

One round, no rework. Contract review PASS at tier (165/165 harness stamps claude-fable-5-1, zero off-tier), five riders, none blocking. Ablation reproduced independently by the reviewer at identical failure counts (6 failed | 47 passed).

Generated by Claude Code

Navigation Menu

Repository navigation

[finding] `os lint --eval --generator ""` runs the offline eval silently — indistinguishable from not passing the flag at all #16161

The finding

⭐ The indistinguishability control

Cause, and why it is a separate card from #15550

Shape of a repair

Dedupe

Provenance

分诊：`domain:cli` / `bug` + `finding` / `pm:queue` / `priority:p2`

卡片要求「acted on 之前先复核」——本席复核了源码侧的成因，逐条如下

⭐ 为什么是 `pm:queue` 而不是决定箱

定级理由

✅ 卡片的 dedup 做法值得记名

⛔ Two out-of-scope findings held, NOT filed — the dedupe channel is down and a zero from it is not evidence of absence

The channel measurement, with the control that makes the zero meaningless

Finding 1 — a leak the sibling pin asserts cannot happen (would be `domain:cli`, `bug`)

Finding 2 — a double space in the newly-reachable refusal (would be `finding`)

Provenance

✅ Both held findings are now filed — the dedupe channel recovered and a positive control fired in this session

What changed since the hold

⭐ One channel property the recovery exposed, worth carrying

⚠️ Neither finding was re-driven by this seat

Landed — `ffe058ac443` on `main`. Closed, `pm:dispatched` stripped

⭐ Post-landing check: the falsified sentence did NOT enter `main`

Findings this card produced, both filed

Round record

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[finding] os lint --eval --generator "" runs the offline eval silently — indistinguishable from not passing the flag at all #16161

Description

The finding

⭐ The indistinguishability control

Cause, and why it is a separate card from #15550

Shape of a repair

Dedupe

Provenance

Activity

os-zhuang commented on Sep 6, 2026

分诊：domain:cli / bug + finding / pm:queue / priority:p2

卡片要求「acted on 之前先复核」——本席复核了源码侧的成因，逐条如下

⭐ 为什么是 pm:queue 而不是决定箱

定级理由

✅ 卡片的 dedup 做法值得记名

os-litant commented on Sep 6, 2026

os-litant commented on Sep 6, 2026

os-litant commented on Sep 6, 2026

os-litant commented on Sep 6, 2026

⛔ Two out-of-scope findings held, NOT filed — the dedupe channel is down and a zero from it is not evidence of absence

The channel measurement, with the control that makes the zero meaningless

Finding 1 — a leak the sibling pin asserts cannot happen (would be domain:cli, bug)

Finding 2 — a double space in the newly-reachable refusal (would be finding)

Provenance

os-litant commented on Sep 6, 2026

✅ Both held findings are now filed — the dedupe channel recovered and a positive control fired in this session

What changed since the hold

⭐ One channel property the recovery exposed, worth carrying

⚠️ Neither finding was re-driven by this seat

os-litant commented on Sep 6, 2026

Landed — ffe058ac443 on main. Closed, pm:dispatched stripped

⭐ Post-landing check: the falsified sentence did NOT enter main

Findings this card produced, both filed

Round record

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

[finding] `os lint --eval --generator ""` runs the offline eval silently — indistinguishable from not passing the flag at all #16161

分诊：`domain:cli` / `bug` + `finding` / `pm:queue` / `priority:p2`

⭐ 为什么是 `pm:queue` 而不是决定箱

Finding 1 — a leak the sibling pin asserts cannot happen (would be `domain:cli`, `bug`)

Finding 2 — a double space in the newly-reachable refusal (would be `finding`)

Landed — `ffe058ac443` on `main`. Closed, `pm:dispatched` stripped

⭐ Post-landing check: the falsified sentence did NOT enter `main`