Skip to content

Token grant picker omits sharded Documents and Collections #188

Description

@brylie

Outcome

The token-management page lists every current Document and Collection, including content stored in per-resource shards, so a user can reliably grant access to anything visible elsewhere in the workspace.

Problem

src/routes/settings/tokens/+page.server.ts still reads listDocuments(doc) and listCollections(doc) from the default Y.Doc. Since #113/#120, service-created Documents and Collections live in their own shards and are discovered through the catalog plus shard-aware service queries. The token allowlist picker can therefore omit normal current content even though the sidebar and MCP listing surfaces see it.

The route also owns token mutation, validation, actor construction, and audit calls directly, outside the service manifest and request-context conventions.

Scope

  • Load Documents and Collections through the existing shard-aware service/query boundary rather than the default Y.Doc primitives.
  • Use locals.requestContext.caller / the canonical server actor instead of defining another CURRENT_USER literal.
  • Move create/revoke token business rules (Space validation, persistence, audit) behind a token service or equivalent application-use-case boundary; keep the SvelteKit actions as request/response adapters.
  • Preserve current Space, Document, and Collection grant behavior and one-time raw-token display.
  • Add a route-level regression test that creates a Document and Collection through their services (therefore in separate shards), loads /settings/tokens, and verifies both are available to grant.
  • Add service tests proving token creation/revocation audit exactly once with the canonical caller.

Non-goals

  • Multi-user authentication, OAuth, roles, or tenant administration.
  • Changing the token storage format or permission semantics.

Dependencies

None. This is the first item in the architecture-debt sequence because it fixes an existing correctness gap. The broader workspace read-repository consolidation can follow without delaying this repair.

Done when

Every Document and Collection returned by the workspace's shard-aware listing services is grantable from the token UI, token mutations have one application-layer owner, and the regression is covered without constructing content directly in the default Y.Doc.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions