Skip to content

skills/objectstack-ui teaches $currentUser as a filter value, contradicting its own "only two tokens resolve in a filter" contract #14139

Description

@claude

Found while funding the token budget for the Navigation Item Types rows (PR #14138); out of
scope there, filed unassigned for triage.

The contradiction, both halves inside one published file

skills/objectstack-ui/SKILL.md teaches $currentUser as a filter value in its
### Filtering section:

filter: [
  { field: 'status', operator: 'not_equals', value: 'closed' },
  { field: 'assigned_to', operator: 'equals', value: '$currentUser' },
]

followed by the note:

$currentUser is a runtime variable — the logged-in user's ID.

Roughly 1400 lines further down, the same file's ## Context Tokens section says the
opposite, and says it exhaustively:

Contract: CONTEXT_TOKENS in @objectstack/spec/data. These are the only two tokens
that resolve inside a filter value

naming {current_user_id} and {current_org_id}, resolved by resolveFilterPlaceholders
in @object-ui/core, and adding that os validate fails the build on an unresolvable
placeholder in any filter (rule filter-token-unknown) precisely because the runtime
failure is silent: an unresolved token reaches SQL as a literal, matches nothing, and the
surface renders empty.

Both claims cannot be true. One of the two sections is teaching a filter that does not work.

What the tree says

Repo-wide grep for the literal $currentUser (excluding node_modules):

  • skills/objectstack-ui/SKILL.md — the example and the note above (a third site, in
    Common Pitfalls, is deleted by PR docs(skills): document the action and component nav item types #14138 as ceiling funding);
  • packages/cli/src/commands/explain.ts — an { type: 'assignment', field: 'assigned_to', value: '$currentUser' } sample, i.e. a different surface (a default/assignment value,
    not a query filter);
  • docs/adr/0017-object-has-many-view.md — inside SQL-shaped prose, not a metadata example.

Nothing in packages/spec declares $currentUser as a filter token. The declared filter
vocabulary is CONTEXT_TOKENS (packages/spec/src/data/context-tokens.zod.ts), and its own
tests reject near-miss spellings.

Why it matters

This is a published, customer-loaded catalog. An AI author who reads ### Filtering — the
first place in the file that shows a "records assigned to me" filter — writes
value: '$currentUser' and gets either a red os validate (filter-token-unknown) or, if
the value slips past authoring, a list that silently renders nothing. The Context Tokens
section exists to prevent exactly that failure, and the Filtering section above it walks the
reader into it.

Decision the fix needs

Which half is wrong is not something this finding can settle from the docs alone:

  1. $currentUser is dead in filters — then the fix is to rewrite the ### Filtering
    example and its note to {current_user_id}, and the "only two tokens" claim stands.
  2. $currentUser really does resolve in some filter path (a legacy alias somewhere in
    the query layer) — then the Context Tokens section's "only two" is the false claim, and
    under contract-first the alias is what should go, with the declaration made to match.

Route 2 would be an ADR-0087 conversion-layer question rather than a docs edit, which is why
this is filed rather than fixed in passing. Note the file is at its token ceiling: any fix
here is size-neutral at best.

Generated by Claude Code


Generated by Claude Code

Metadata

Metadata

Assignees

Labels

bugSomething isn't workingdocumentationImprovements or additions to documentationdomain:skillspriority:p2Medium: important, M3

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions