Learn from Notes and Tasks

The audited source checkout contains complete Notes and Tasks applications for the current package matrix. Use their reviewed files as a connected example, rather than assembling fragments from unrelated versions. Installation explains published consumption and how to prepare that exact example checkout.

Notes: one service, several entries

Start with the Notes assembly. It receives a selected database instance, session store, dialect queries and principals, then creates exact Auth and Notes instances. The shared service handles object ownership; CLI, raw Fetch and oRPC adapt the same business operations.

Read the files in this order:

1. contracts.ts and notes.ts: input validation, authenticated audience and object ownership.
2. application.ts, auth.ts, application-auth.ts: selected resources and verified service identity.
3. queries-sqlite.ts or queries-pg.ts: native dialect-specific data access.
4. operations.ts, router.ts, web.ts: explicit entry adapters.
5. server.ts and lenso.config.ts: local host assembly and runtime configuration.

The database guide explains migration ownership, including Auth sessions and legacy unowned rows. Auth covers login evidence and shared-service revalidation. Do not assign record ownership from request JSON or treat CLI access as an authorization bypass.

Current Notes management declarations select the existing sidecar service. CLI exports operations plus trusted operationBinding; MCP separately selects mcpOperations (list, read, remove) and supplies its own startup identity from NOTES_MCP_SESSION. Neither selection inherits the other entry's binding or authorizes an object by ID. The same shared service revalidates current session evidence and owner policy.

For a local SQLite walkthrough, use the app's declared configuration keys and scripts from its configuration guide. Inspect required key names and provide credentials through a private local environment or secret mechanism. No personal path or working credential is included in this documentation.

Tasks: producer and worker share a contract

The Tasks example uses a real PostgreSQL queue. Its producer accepts an authenticated report request; durable ownership associates the task with that principal. The worker consumes the shared validated contract and writes through the reviewed report service.

Read contracts.ts, task.ts, ownership.ts and authorized-service.ts before invoking producer or recovery operations. Then read resources.ts, producer.ts, worker.ts and mcp.ts. PostgreSQL provisioning and migrations are explicit. The worker does not turn an arbitrary JSON task into an authorized operation.

Tasks covers leases, retries, cooperative cancellation, retention and failure recovery. MCP and agents explains its independent operation allowlist. A retry can repeat a side effect; query durable state after an uncertain result before replaying.

The current Tasks config selects management operations for CLI and chooses a separate MCP subset: submit, query, cancel, retry, excluding report. Its binding reads trusted entry identity, independently of the validated business input. No global current actor or caller-supplied identity envelope is needed.

Workers: Notes on D1 and R2

The Workers Notes example uses platform bindings with request-owned application graphs. It does not run the Bun CLI Engine or PostgreSQL task worker in a Worker. Its greeting counter is per-request memory, not durable storage.

Use Workers, Files and deployment to select D1/R2 entries and local Wrangler checks. A successful dry-run bundle does not provision cloud resources or establish production readiness.

Make one change at a time

Choose a real operation, inspect its shared schema and identify its service policy. Change that service or contract, run the focused example tests, and only then verify each entry that uses it. Keep the exact plugin objects through assembly. Do not patch .lenso or dist outputs. Testing and troubleshooting gives checks for each boundary.