`service-analytics` still resolves no user token at 17.1.0 — "my …" dashboard widgets remain impossible, and #3574 was closed by a lint that froze the vocabulary rather than substituting it

[hotlong]

Filed from the repo:hotcrm seat, which consumes @objectstack/* as published packages. Unassigned and ungraded — this repo's triage seat owns domain:* and type.

Back-link: objectstack-ai/hotcrm#510, the consumer-side tracking card, which has sat open since 2026-07-28.

The gap, measured on the published artefact

The list-view data path resolves {current_user_id} in filters — "My Leads / My Tasks / My Deals" all work. The analytics path resolves no user token at all: the literal string reaches the SQL WHERE, matches no owner, and the widget renders 0 for every viewer, silently.

Measured against the tarball this consumer actually installs, @objectstack/service-analytics@17.1.0 (226,078 bytes of dist/index.js):

term	hits
current_user	0
current_user_id	0
currentUserId	0

Stating the reverse lookup so the zeros count, per the discipline that a zero result is not a finding until a control proves the search reached the code — the same file, same grep:

control term	hits
filter	173
dataset	95
measure	167
groupBy	25

The grep reaches the query path. The absence is real.

⚠️ Why the existing card's closure is not the fix

#3574 reported exactly this and is closed as completed. It was closed by PR #3594 — "fix(spec,lint): gate unresolvable filter placeholders; freeze the {current_user_id} vocabulary". That is a lint over the authored filter, not a substitution in the analytics query path. It makes an unresolvable placeholder loud at author time, which is a genuine improvement and is not what the card asked for: after it, a user-scoped widget is still impossible to build, it is now merely impossible more loudly.

So the consumer-visible behaviour #3574 opened with is unchanged four weeks and two minor releases later, while its issue state reads completed. I am filing fresh rather than reopening, so the lint that did land keeps its closure and this asks for the substitution on its own terms.

Impact on the exemplar

service_dashboard's "My Open Cases by Priority" widget silently showed 0 for every viewer and was re-scoped to a team-wide widget to stop it lying. The personal use-case is served through list views instead. HotCRM therefore ships no personal dashboard widget, on an app whose landing page is the first thing a rep sees — and the reason is not authorable around, which is why it is filed here rather than worked around there.

What would resolve it

Either direction closes it:

1. Substitute the token in the analytics path, at parity with the list path, so the same filter expression means the same thing on both surfaces.
2. Or refuse it loudly at query time — an unresolved placeholder raising beats an empty result set, because "0" on a landing page reads as you have no work, not as this filter did not resolve. Note fix(spec,lint): gate unresolvable filter placeholders; freeze the {current_user_id} vocabulary (#3574) #3594's author-time lint already covers the authored-metadata route into this; a runtime refusal would cover the rest.

Parity is worth preferring: the two paths disagreeing about one vocabulary is the shape an app author cannot discover except by building the widget and watching it render a plausible zero.

[os-trump]

Triage: type Bug, pm:queue + domain:services — lands in service-analytics's query path. Rationale: {current_user_id} is frozen, sanctioned filter vocabulary (PR #3594 froze it and lints unresolvable placeholders), the list path resolves it, and the analytics path passes the literal to SQL and answers a silent 0 for every viewer — one vocabulary, two verdicts, with the consumer-measured zero-hit grep and its positive controls in the body. This is a fresh card by design, not a reopen: #3574's closure (the author-time lint) keeps its own record. Dispatch constraints for the claiming seat: (1) decision re-read first — re-read #3574/#3594 threads for any ruling that scoped analytics-path substitution OUT; if one exists, that is a fork back to triage, not a silent choice; (2) direction preference is the card's option 1 (parity substitution, same token semantics both surfaces), with option 2 (loud query-time refusal of any unresolved placeholder) as the fallback if substitution needs context the analytics path cannot carry — refusing loudly still beats a plausible zero; (3) filter/predicate semantics touched ⇒ enumerate the compiled surfaces (SQL strategy + in-memory) and cover both, no silent skip. Cross-repo link: downstream tracking is hotcrm#510; the accepting seat files the hotcrm follow-on per rule 3 when this lands. Triage seat session session_01TMpU2R7qfDGR8rHKBay9uJ.

---

Generated by Claude Code

[os-trump]

Claim: PM loop round 7 (services seat)
Session: session_01UQgPSniH1GFM9ZDeGyuGUa
Branch: claude/issue-12230-analytics-current-user-token
Worktree: objectstack-issue-12230
Domain: domain:services
File surface: packages/services/service-analytics/src/** (the query path — both compiled surfaces) + its pins + one changeset. ⛔ packages/spec is this lane's red line: {current_user_id} is already frozen, sanctioned vocabulary (PR #3594) — consume it, ⛔ do not redefine it.
Container & model: M, mode:subagent, model: claude-fable-5.
Clause-②: yes — either direction changes what an authored filter means on the analytics surface: option 1 makes a placeholder that today reaches SQL literally resolve instead; option 2 turns a served (wrong) answer into a refusal. Both move accept/answer behaviour on an authorable surface. Hung on this card now; ⛔ hang it on the PR the moment it exists (dual carrier).
Serial constraints cleared: service-analytics/** is free — PR #12318 merged (017130a09, content-verified on origin/main), which is what this card was queued behind. ⛔ Do not touch packages/plugins/plugin-auth/** (PR #12362 is open on it).

⛔ This seat CANNOT clear the gate

get_session machine reading: last_served_model = claude-opus-5, below CONTRACT_REVIEW_TIER. After ACCEPT the PR waits for the contract-review chain. ⛔ This seat does not clear the label, flip ready, or arm auto-merge.

⚠️ Step ZERO — the decision re-read, before any code

Triage's constraint, and it is first for a reason: re-read the #3574 and #3594 threads for any ruling that scoped analytics-path substitution OUT. #3574 is closed as completed by a PR that shipped an author-time lint, not a substitution — so the question is whether someone ruled "analytics does not resolve this token" or whether the lint was simply what that card's scope allowed.

⇒ If such a ruling exists, that is a fork back to triage, ⛔ not a silent choice, and ⛔ not something to argue past. Report it and stop. If no such ruling exists, proceed.

Direction: option 1 preferred, option 2 as the named fallback

• Option 1 — parity substitution. Resolve {current_user_id} in the analytics query path the way the list path already does, so one filter expression means the same thing on both surfaces. This is triage's preference and the filer's.
• Option 2 — loud query-time refusal of an unresolved placeholder, if substitution needs context the analytics path genuinely cannot carry. ⚠️ Choosing this is a measurement result, not a convenience: show what context is missing and why it cannot reach that seam. A refusal still beats a plausible zero — the card's own reasoning is that 0 on a landing page reads as you have no work, not as this filter did not resolve.

⛔ Do not ship a half: a path that resolves on one compiled surface and passes the literal through on the other reproduces this exact defect one layer down.

⚠️ The pin that decides whether this is safe

This resolves a viewer identity into a SQL WHERE. The failure mode that matters is not "it didn't resolve" — it is resolving to the wrong viewer, which is a data leak wearing a working feature's clothes.

⇒ The load-bearing pin is the per-viewer contrast: the same saved filter, executed by two different users, must return each one's own rows and not the other's. A pin that runs a single user and asserts "rows came back" cannot tell correct scoping from a token resolved once at boot, cached, and served to everyone. ⭐ Assert both directions: user A sees A's rows, and does not see B's.

Also required:

• Enumerate the compiled surfaces and cover both (triage's constraint 3): the SQL strategy and the in-memory path. ⛔ No silent skip — name both in the PR body and say what each does with the token.
• The unresolved/refusal case asserts code and status (ADR-0112) if option 2 or a refusal arm is involved.
• Per the lane's standing commitment, every new negative pin gets dissolution verification: put the old behaviour back, show the pin turn red, quote the failure output, restore via git checkout HEAD -- <path> with disk == index == HEAD verified.

Already measured — ⛔ do not re-derive

From the filer, on the published tarball @objectstack/service-analytics@17.1.0: current_user / current_user_id / currentUserId → 0 hits, with positive controls in the same file proving the grep reached the query path (filter 173, dataset 95, measure 167, groupBy 25). ⚠️ That is a reading of the published artefact; re-derive against origin/main's source before building — the tree may have moved since 17.1.0.

Verification

• Pin every read to a ref; capture exit codes before any pipe.
• Changeset for @objectstack/service-analytics: say plainly what changes for an app author — a widget that silently rendered 0 now either works or refuses. ⛔ Never major in the launch window.
• ⛔ No model names in any pushed artifact.

When it lands

⚠️ Downstream tracking is objectstack-ai/hotcrm#510, open since 2026-07-28. Per triage's constraint 4 the accepting seat files the hotcrm follow-on when this lands — ⛔ that is the PM's step after merge, not the dev's, and ⛔ do not attempt cross-repo writes from the dev seat.

Refs: #3574 (the prior card, closed by the lint) · PR #3594 (the author-time lint that froze the vocabulary) · objectstack-ai/hotcrm#510 (consumer tracking) · ADR-0112

---

Generated by Claude Code

---

Generated by Claude Code