Roadmap — Planned & Not Yet Implemented

This page separates remaining planned platform work from shipped areas that used to appear on the roadmap. Several planned surfaces are partially plumbed through the schema but are not yet callable. Historical design notes were removed rather than kept as a second, stale contract.

The data engine is built in stages; A–F are shipped (private tables, resources, membership, mounts, link/unlink, federated queries, the access engine, the onMemberRemove lifecycle, object storage, and user profiles + identity resolution), and the functions MVP (Phase 2) is live — as-user execution with { role, via } provenance gating (see functions.md). The tallpond CLI ships the full self-serve loop (login, apps create, environment-scoped dev, confirmed production deploy with schema + functions/ + immutable source/static releases, clone of any promoted app, environment-only test sessions, env list / env reset, and typegen — see cli.md). Whole-file content addressing, source retention, and optional sanitized Git metadata are implemented in the repository contract; remote builds, platform-native forks, chunking, garbage collection, cryptographic signing, and verified exact-commit attestation remain open. What remains within Stage F is visitors (deliberately deprioritized); Phase 3+ (realtime, jobs) and the design-needed items below are still open.

Files & storage — shipped (Stage E)#

Object storage on both private and resource scopes: upload, download, url, list, metadata, updateMetadata, delete, move, copy, backed by a storage adapter (local dir in dev; S3 later). .url() is same-origin and cookie-authed. Uploads escrow a flat storage_write operation charge; downloads meter storage_egress to the fetcher; and the recurring sweep charges stored bytes pro-rata as storage_at_rest. Resource buckets are partitioned by rooms on the same rules as tables. See docs/api/files.md and docs/metering.md. Still pending: visitor-sponsored (signed-out) .url() reads.

Users & profiles — shipped (Stage F)#

user_profiles ({ userId, displayName, avatarUrl, handle }), tallpond.users(id).profile() / .profiles(), auth.getUser() = { id, profile } (email is never exposed), the reserved author(...) projection on mounted tables, and account deletion (onOwnerDelete: remove / tombstone / retain, with the reserved deleted-user profile). See docs/api/users.md. Still pending within Stage F: visitors (below).

Visitors & the app allowance#

Stage F — not implemented.

Sessionless (cookieless) reads for anonymous visitors on public resources that opt in with visitors({ read: true }), served at the resource's default role and metered to the app's allowance rather than a user wallet — with sponsor_exhausted when the allowance is spent. Backed by the app_allowance ledger (a bootstrap grant plus a rate × cumulative user spend), which also funds statics and cron, and enables true payer: "split" settlement.

• Schema today: visitors({ read }) is parsed and validated (a visitor-read resource must be public) but not enforced.
• Tracking: this page is the maintained status record; the removed historical design notes are not part of the contract.

Realtime — channels & presence#

Phase 3 — not implemented.

Publish/subscribe channels and presence scoped to the resource boundary (channel(name, { subscribe, publish }), presence({ read })).

• Schema today: channel(...) and presence(...) are parsed and stored so schemas are forward-compatible; nothing is enforced or served.
• Tracking: planned; no callable contract yet.

Billing: spend-threshold notifications#

Not implemented.

Notify a user as their spend on an app approaches its monthly cap (e.g. 50/80/100% thresholds), delivered by email. There is deliberately no global cross-app cap — the per-app cap plus this notification is the intended control surface. See billing.md.

Explicit custom migrations#

Design needed.

migration(async (db) => { … }) is sketched (see schema-and-deploy.md) and the 409 migration_blocked gate works, but the surrounding process is underspecified: where migration files live and how they're named/ordered, how the CLI bundles them into a /deploy payload, dry-run/preview before applying, and rollback on a failed migration. Needs a design pass before the first blocked deploy in anger.

Unified metering / rate card — shipped for current surfaces#

The shared rate card lives in docs/metering.md, enumerating every current surface as (payer, rate, mechanism). Recurring GB-month at-rest billing is live for both R2 blobs (storage_at_rest) and Neon row bytes (db_at_rest), while storage_write covers only the upload operation. Functions have their function_invoke dimension; realtime/jobs will add theirs if those surfaces land.

Functions — MVP shipped (Phase 2)#

App-defined server functions that always execute as the invoking user — no service role. functions/<name>.ts modules deploy to an environment with tallpond dev or to production with confirmed tallpond deploy (bundled into one Worker per deployment), invoke via POST /v1/functions/:name, and unlock { role, via: 'fnName' } access rules that make a function the mandatory write path. Every effect round-trips the gateway under a signed invocation token; the caller pays. See functions.md for the maintained reference and execution model.

Still pending: typed ctx.ai/ctx.files helpers (use the ctx.gateway escape hatch), nested invoke (a function calling a function), function entry gates, and the resource-/app-scoped functions/resource/ + functions/app/ directories.

Jobs#

Not implemented.

Scheduled and background work (cron, queues) sharing the resource/permission model.

• Tracking: planned; no callable contract yet.

Shipped-area caveats (recap)#

Even within the implemented surface, a few paths are deliberately simplified for now:

See README.md.