API
- filter
- patch
- field mask

soft delete

gen
- TF
- CLI
- ios, android

dev
- data model explorer
- code explorer
- wire mock

telem
- metrics

deploy
- secrets
- cdn
- routing
- multi-team deploy model


features
- feature flags
- entitlements, plans, quotas, limits
- profile pic upload
- message inbox

meta
- style guide
- long running op

notify
- slack

ui
- tenant picker

static site
- docs

api validation v2


demo
- more cron
- third party api integration
- post request with new field demo backward compat

apps
- progress tracker (shipment)
- rfc
- forum
- blog
- issue tracker
- changelogs
- runbooks
- incident management
- status page


# nits

cli needs easy way to set request fields without writing a full, inline json body

cli needs to use double dash flag format?

it might be nice if tokens were just one big string with no special chars. currently:
key-06FXAC45VYNHSZRXQZXZKG-DYZW.fb3e41b3088bb112a817888ef59f1e95f616c5cd9517f538a40a907f75342f64

key prefix is best?

bots ui is confusing, listing bots and then a second section for api keys

numers in the ui need consistent, human-friendly format (see plan page, with 1000000)

why does creating a bot require a second click for creating a key

explore reorganizing from concern (store, api, lib) to domain (iam, todos, entitlements, etc)

revisit groups being identified by a core.Path

put access.Put... out of the provisioner. think about what the guidelines are for this kind of code.
- if access modification is buried in a middle layer library (or lower) then a call can accidentally
  have access they shouldn't more easily. push toward top level edges?

refactor store interface? Stores(tx).Users.Add()?

# membership

tenant_members(tenant, user, is_owner) — belonging + the one control-invariant (owner:
last-owner + bootstrap). capability tiers (e.g. "admin") are grants, not membership tiers.

use cases that would NOT be grants — orthogonal belonging axes, likely new columns
(is_guest / is_suspended / ...), not a wider role enum:
- guest / external collaborator: has access to specific resources but not a full member;
  doesn't count toward seat/member limits, not in directory, can't be promoted to owner
- suspended / deactivated: still belongs (keep seat, data, history to restore) but access
  frozen; not expressible as removing a grant
- billing / primary owner: single designated user, cardinality invariant (exactly one,
  must also be owner)


# ui composite views

some UI pages need a view that joins across tables — data that no single
table/endpoint owns. currently handled client-side: fetch two endpoints and merge
by id, because endpoints return their own namespace's table type and composite
view types are deferred.

example: the members page wants identity + membership tier together. it fetches
TenantMembers_ListByTenant (owner bit, user id only) AND Users_ListByTenant
(name/email) and joins by id in admin.js/dashboard.js. both queries hit
tenant_members.

fork: keep client-side join (convention-preserving, extra round-trip per page) vs
let the endpoint return a composite (e.g. Member = user ⋈ membership: User, Name,
Email, Owner) — which is the composite-view-type we currently defer.

expect this to become important as more pages need cross-table views. revisit
whether to support server-side composite/view types (and where they live — a
read/view layer separate from the one-struct-per-table stores) rather than
pushing every join into the client.