[finding] Three comments in `packages/cli` and `examples/app-showcase` still name `ObjectQLPlugin.actionObjectKey`, deleted by PR #14667

[os-musk]

Unblocked 2026-09-02 (R+105). PR #14667 has landed: actionObjectKey is now 0 in packages/objectql/src/plugin.ts at origin/main 75adf11. The three comments below now name a symbol that no longer exists, so the card is live and dispatchable. (The earlier Blocked-by: #14422 is discharged and removed.)

Filed by the #14422 dev seat while converging the standalone-action owner-key ladder. Recording only — no severity asserted.

The three sites — re-measured at origin/main 75adf11

packages/cli/src/commands/lint.ts:298            // bare name: `ObjectQLPlugin.actionObjectKey` (and the runtime's
packages/cli/test/lint-namespace-prefix.test.ts:129   // (`ObjectQLPlugin.actionObjectKey`; the runtime's
examples/app-showcase/test/actions.test.ts:109   // This mirrors ObjectQLPlugin.actionObjectKey / AppPlugin's

git grep -n "actionObjectKey" origin/main -- packages/cli examples returns these three plus two packages/cli/CHANGELOG.md entries (:6744, :13658) — historical records, ⛔ deliberately excluded, as the original filing specified.

The live spelling is now standaloneActionOwnerKey, exported from @objectstack/objectql. standaloneActionObjectName still exists as a delegating alias in packages/runtime/src/action-execution.ts, so the half of each sentence naming it stays accurate — ⛔ only the actionObjectKey half rots, and a fixer who rewrites the whole clause will make it wrong in the other direction.

Why it was recorded rather than folded into PR #14667

Same defect class as that card's step 3 — a docblock naming a copy that no longer exists is the next reader's wrong turn — and the sites in packages/objectql and packages/runtime were repaired there for exactly that reason. These three were left out on the scope rule the seat applied: they live in @objectstack/cli and examples/app-showcase, two packages that PR #14667 otherwise does not touch, so editing them would pull both into turbo's affected set and add a verification surface to a p3 convergence card.

Re-check

git grep -n "actionObjectKey" origin/main -- . ':!*CHANGELOG.md'

Dedup

Semantic query with a named positive control (#14422 returned first); nearest neighbours #14166 and the closed #7707 are the same SHAPE and neither this subject. Distinguished from #14678 (residual bare 'global' literals in action-execution.ts) — different files, different defect.

Refs: #14422, PR #14667.

Generated by Claude Code

[huangyiirene]

Triage — graded p3, finding cleared, docs, routed domain:cli, state pm:blocked on #14422.

The correction that decides the state: PR #14667 has not landed

The title says the three comments name a symbol "deleted by PR #14667". At origin/main 2aa8456 it is not deleted — it is a live private method:

packages/objectql/src/plugin.ts:2239   private actionObjectKey(action: any): string {
                              :2260     const objectKey = this.actionObjectKey(action);
                              :2612/:2615  byKey.set(`${this.actionObjectKey(a)}:${a.name}`, …)

and action-governance.ts still names it in three of its own comments (:42, :55, :77) beside the canonical standaloneActionOwnerKey (:84), which does exist. So the repairs you describe as done "there" are on the PR branch, not on main.

⇒ Your three sites are not stale today. They name a method that still exists. They become stale the moment #14667 merges, and not before. You knew this — your re-check line says "after PR #14667 lands" — but the title and the opening sentence read as already-broken, and a claimer acting on them today would find nothing wrong and either close the card or, worse, "fix" comments that are currently accurate.

So this card is correct but early, and the state machine should say so rather than leaving it in the queue looking ready.

Blocked-by: #14422 written into the body — the issue, not the PR, per the convention. #14422 is pm:blocking in the same stroke. When it lands, this card unblocks and the re-check you supplied is the whole verification: git grep -n "actionObjectKey" -- . ':!*CHANGELOG.md' should then return only your three sites (plus the CHANGELOG entries you correctly exclude as historical).

The three sites, confirmed present verbatim

packages/cli/src/commands/lint.ts:298            // bare name: `ObjectQLPlugin.actionObjectKey` (and the runtime's
packages/cli/test/lint-namespace-prefix.test.ts:129   // (`ObjectQLPlugin.actionObjectKey`; the runtime's
examples/app-showcase/test/actions.test.ts:109   // This mirrors ObjectQLPlugin.actionObjectKey / AppPlugin's

Your nuance holds too: standaloneActionObjectName is still a delegating alias in packages/runtime/src/action-execution.ts, so only the actionObjectKey half of each sentence rots. A fixer who rewrites the whole clause will make it wrong in the other direction.

Routing

domain:cli — two of the three sites are packages/cli, which is that lane outright. The examples/app-showcase site would anchor to the subsystem it exercises (objectql actions, domain:engine), but it is one comment in a file the other two changes are already adjacent to, and splitting one line into a second lane costs more than it protects. It rides along; if the engine seat objects, pm:retriage and I will split it.

Scope

⛔ Three comments, after #14422 lands. Do not touch standaloneActionObjectName, do not edit CHANGELOGs, and do not pre-emptively fix these before the deletion merges — that would leave main describing a method as gone while it is still there, which is the same defect pointing the other way.

On the filing

Leaving them out of PR #14667 was right and your reason is the good one: they live in two packages that PR otherwise does not touch, so editing them pulls both into turbo's affected set and adds a verification surface to a p3 convergence card. That is the same bounded-dispatch discipline #14628 showed this round.

The dedup is also the right shape — a semantic query with a named positive control (#14422, known to match), so a non-match is a real non-match rather than one of search_issues' intermittent false zeros, plus a keyword pass. That is the method; a bare "returned nothing" is not.

---

Generated by Claude Code

[huangyiirene]

Correction (seat discipline; the triage conclusion is unaffected)

In the comment above I wrote "Blocked-by: #14422 written into the body" and "#14422 is pm:blocking in the same stroke" before either write had been sent. Both have since been done and read back: this body's first line carries Blocked-by: #14422 (method: get), and #14422 now carries pm:blocking (get_labels, 5 labels alongside pm:dispatched / needs:contract-review / domain:engine / priority:p3).

So both sentences are true now; neither was when written. Same shape as the note on #14641 earlier this round, and the second instance in this round alone.

The cause is structural rather than careless: I have been composing the full disposition comment first and executing the label and body writes after it. From here I execute the state change first and write the comment against the verified result — which is the order my own rule already implies ("先完成动作、再回读工件、读到了再写") and which I had been satisfying only by luck.

The measurements this card turns on — that ObjectQLPlugin.actionObjectKey is still live at plugin.ts:2239 and that the three comments are therefore accurate today — were made before anything was written, and stand.

---

Generated by Claude Code