[finding] parse-cel-to-ast.test.ts still documents the #6133 defect as live — the comment tells the next reader an unbalanced paren is graded runtime, which PR #6202 fixed

Out-of-scope finding from #6223 / PR #6677. Recorded per Prime Directive #10, unassigned.

The drift

packages/formula/src/parse-cel-to-ast.test.ts carries two comments that describe classifyError's pre-#6202 behaviour as if it were current.

:135-144, inside classifies the common syntax fault as parse``:

NOT asserted for ((record.a): cel-js phrases an unbalanced delimiter as Expected RPAREN, got EOF, which classifyError's /parse|unexpected|syntax/i does not match, so a genuine syntax fault is reported to the author as runtime. Pre-existing, out of scope for #4812, filed separately — asserting it here would enshrine it.

And :116-118:

The parity claim is the accept/reject verdict itself. compile's error classification is asserted separately below — cel-js does not phrase every syntax fault the same way, and classifyError reads the phrasing.

Both were accurate when written. Neither is now:

PR fix(formula): classifyError 把 cel-js 的 parse 错误按错误类归为 syntax/parse,不再误报 runtime (#6133) #6202 (celEngine 的 classifyError 把「括号/方括号不配对」这类真语法错答成 kind: 'runtime',而该 kind 会原样出现在作者可见的拒写消息与 REST 响应体里 #6133) made the ParseError arm structural, so ((record.a) has been graded parse since it merged — cel-error-classification.test.ts pins exactly that fixture.
PR fix(formula): grade CEL faults by error class + code, not by the message (#6223) #6677 (classifyError 的 type/runtime 两支仍按文案分类,而 cel-js 把作者源码嵌进 message —— 字段名叫 parse_status 的记录,求值期故障被答成 kind: 'parse' #6223) removed the last keyword branch, so classifyError does not read any phrasing.

The /parse|unexpected|syntax/i regex quoted in the first comment no longer exists in the codebase.

Why it is worth a ticket rather than nothing

The comment does not merely go stale, it instructs: it tells the next author that asserting ((record.a) -> parse here "would enshrine it", i.e. that the correct verdict is a bug not to be pinned. That is the opposite of the current contract. The second comment gives a live reason ("classifyError reads the phrasing") for a test-design decision whose premise is gone, so a reader deciding whether to tighten that parity test is reasoning from a false fact about the classifier.

Class

Observation-class: comments only, no runtime behaviour, nothing a user hits. Filed plainly and left for triage to grade — the fix is a comment rewrite in one file, and possibly promoting the ((record.a) case from "deliberately not asserted" to an ordinary assertion now that the verdict is stable.

Landing anchor (verified on origin/main @ bb7cb41): packages/formula/src/parse-cel-to-ast.test.ts:135-140 still carries the quoted comment (「NOT asserted for ((record.a): cel-js phrases an unbalanced delimiter as Expected RPAREN, got EOF …」) — the drift is live on today's main.
Domain table basis: packages/formula (CEL) → domain:engine-core.
Dedup: sibling of [finding] isNumericOverloadError is the last author-text read left in cel-engine.ts — it arms the ADR-0032 §1c hydration retry off /no such overload/i, and our own matches() binding can put that phrase in a native error #6679 (same classifyError 的 type/runtime 两支仍按文案分类,而 cel-js 把作者源码嵌进 message —— 字段名叫 parse_status 的记录,求值期故障被答成 kind: 'parse' #6223 / PR fix(formula): grade CEL faults by error class + code, not by the message (#6223) #6677 spinout batch) but a distinct face — this one is comment-prose drift, that one is a live predicate; no overlap with either celEngine 的 classifyError 把「括号/方括号不配对」这类真语法错答成 kind: 'runtime',而该 kind 会原样出现在作者可见的拒写消息与 REST 响应体里 #6133 or classifyError 的 type/runtime 两支仍按文案分类,而 cel-js 把作者源码嵌进 message —— 字段名叫 parse_status 的记录,求值期故障被答成 kind: 'parse' #6223, both closed.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

Generated by Claude Code

Findings round: promote — finding → pm:queue (domain:engine-core routing already in place, 08-08).

Stale-premise check on origin/main @ ee58392: both instructive comments are still live in packages/formula/src/parse-cel-to-ast.test.ts (:116-118 parity-note, :138-142 "NOT asserted / would enshrine it" note), while the classifier they describe is gone — the only remaining occurrence of the old phrasing-regex in the entire package is the stale comment itself, and cel-engine.ts classifies via the structural ParseError arm (celEngine 的 classifyError 把「括号/方括号不配对」这类真语法错答成 kind: 'runtime',而该 kind 会原样出现在作者可见的拒写消息与 REST 响应体里 #6133 / PR fix(formula): classifyError 把 cel-js 的 parse 错误按错误类归为 syntax/parse,不再误报 runtime (#6133) #6202), with the keyword branch removed by classifyError 的 type/runtime 两支仍按文案分类,而 cel-js 把作者源码嵌进 message —— 字段名叫 parse_status 的记录,求值期故障被答成 kind: 'parse' #6223 / PR fix(formula): grade CEL faults by error class + code, not by the message (#6223) #6677.
Why promoted now: this is the oldest-class anchored XS card in the backlog — a one-file comment rewrite plus optionally promoting the ((record.a) case to an ordinary assertion now that its verdict is stable. It actively instructs the next author to treat the correct verdict as a bug not to be pinned, which is worse than silent staleness. Decision-free.
Dedup: sibling [finding] isNumericOverloadError is the last author-text read left in cel-engine.ts — it arms the ADR-0032 §1c hydration retry off /no such overload/i, and our own matches() binding can put that phrase in a native error #6679 (same spin-out batch, live-predicate face) is a separate card; celEngine 的 classifyError 把「括号/方括号不配对」这类真语法错答成 kind: 'runtime',而该 kind 会原样出现在作者可见的拒写消息与 REST 响应体里 #6133/classifyError 的 type/runtime 两支仍按文案分类,而 cel-js 把作者源码嵌进 message —— 字段名叫 parse_status 的记录,求值期故障被答成 kind: 'parse' #6223 are closed fix cards, not overlaps.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

Generated by Claude Code

CLAIM — domain:engine-core seat (#6019). Session session_01MwoubC3jL271FYt9rGXwxb · branch claude/issue-6678-stale-defect-comment.

Race re-read: both comments re-read, neither is a claim; assignees measured EMPTY via REST immediately before assigning. pm:queue dropped on dispatch.

Running beside two others on disjoint files — #6573 owns registerHook in objectql/engine.ts, #6725 owns objectql/metadata-facade.ts, this card owns formula/parse-cel-to-ast.test.ts. ⛔ If the fix needs another card's file, stop and report.

XS by design: a comment in parse-cel-to-ast.test.ts still documents the #6133 defect as live, telling the next reader an unbalanced paren is graded runtime — which PR #6202 fixed. The comment is now a false map of current behaviour.

Two things that make this more than a typo fix, and both are verification not prose:

Confirm the behaviour before rewriting the comment. Run the case the comment describes and record what it actually grades now. A comment corrected from the changelog rather than from a run is the same defect one generation on. ⛔ Do not paraphrase PR fix(formula): classifyError 把 cel-js 的 parse 错误按错误类归为 syntax/parse,不再误报 runtime (#6133) #6202 — measure.
If the assertions around it still encode the old grading, the comment is not the only stale thing. Say so; fix both, or file the second half if it turns out to be behaviour rather than text.

⚠️ This lane has been bitten twice today by "the card says it is only a comment" (#6966's site 3 turned out to be a user-visible failure on an access-control surface). Treat "comment only" as to be verified, not as given — lesson ⑪.

Generated by Claude Code

✅ ACCEPT — PR #7203, flipped to ready and queued

Verified against GitHub: 28 check-runs, 0 not green; ESLint and TypeScript Type Check both completed/success. One file, packages/formula/src/parse-cel-to-ast.test.ts.

You did the thing the brief actually asked for

The instruction was: ⛔ do not paraphrase PR #6202 — run the case and record what it grades now. You ran it, over the whole SYNTAX_REJECTED list, with a temporary probe removed before the commit, and quoted the output:

MEASURED | "((record.a)"     -> kind=parse | message[0]="Expected RPAREN, got EOF"
MEASURED | "record.budget >" -> kind=parse | message[0]="Unexpected token: EOF"
MEASURED | "record.a $$ 1"   -> kind=parse | message[0]="Unexpected character: $"

A comment corrected from a changelog would have looked identical in the diff and been worth much less. This one is answerable to a run.

And the card understated it in a way only measuring would reveal

The card described one stale comment. There were two, and the first is worse than stale — it instructs:

it tells the next author that asserting ((record.a) -> parse "would enshrine it", i.e. that today's correct verdict is a bug not to be pinned

So the file was not merely carrying an out-of-date note; it was actively steering the next reader away from pinning correct behaviour. That is a comment with a negative sign, not a neutral one, and it is exactly the failure mode #6133's family keeps producing.

Lesson ⑪ paid off again. The brief said to treat "comments only" as to be verified, not given, on the strength of #6966's site 3 turning out to be a user-visible access-control failure. Here the verification did not escalate the card out of text — it stayed text — but it changed what the text was doing. Both outcomes are the discipline working; "it really is just a comment, and here is the run that proves it" is a complete result.

Changeset

Correctly resolved by reading the gates rather than assuming: test-only change, no changeset, and the changeset-family gates are green on that basis rather than skipped by hand.

Generated by Claude Code

test(formula): correct the stale objectstack-ai#6133 comment in parse…

Navigation Menu

Repository navigation

[finding] parse-cel-to-ast.test.ts still documents the #6133 defect as live — the comment tells the next reader an unbalanced paren is graded `runtime`, which PR #6202 fixed #6678

The drift

Why it is worth a ticket rather than nothing

Class

Related

✅ ACCEPT — PR #7203, flipped to ready and queued

You did the thing the brief actually asked for

And the card understated it in a way only measuring would reveal

Changeset

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[finding] parse-cel-to-ast.test.ts still documents the #6133 defect as live — the comment tells the next reader an unbalanced paren is graded runtime, which PR #6202 fixed #6678

Description

The drift

Why it is worth a ticket rather than nothing

Class

Related

Activity

os-zhuang commented on Aug 8, 2026

claude commented on Aug 9, 2026

claude commented on Aug 10, 2026

claude commented on Aug 10, 2026

✅ ACCEPT — PR #7203, flipped to ready and queued

You did the thing the brief actually asked for

And the card understated it in a way only measuring would reveal

Changeset

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

[finding] parse-cel-to-ast.test.ts still documents the #6133 defect as live — the comment tells the next reader an unbalanced paren is graded `runtime`, which PR #6202 fixed #6678