Tour the generated project

A Sapporta app is a pnpm workspace with a Hono API, a React frontend, and a shared package for API contracts and wire types. The API and frontend can import the shared package. The shared package contains browser-safe contracts and wire types, with no server, database, or React I/O.

Every generated file, who owns it, and the file to edit for a given change are listed in the project file map. The changes a first outcome usually needs are table definitions in packages/api/schema/, route mounting in packages/api/app.ts, and navigation in packages/frontend/src/App.tsx.

The frontend already mounts TanStack Query and includes TanStack Form. Public Sapporta query options and form helpers connect application screens to generated table routes. AGENTS.md, CODING-PRINCIPLES.md, and VISUAL-DESIGN-GUIDELINES.md tell a coding agent how to work in this generated workspace.

The welcome screen

The new project’s /welcome screen offers Task Management, Invoicing, and Meal Tracking prompts. Each one gives a coding agent product direction and points it back to the project instructions. You can copy one, adapt it to your own domain, or use it to identify a smaller first outcome.

For example, the Task Management prompt can produce a project and task model with generated record surfaces:

Choose a bounded first outcome

Start with one result that has an obvious owner:

• Add a table and its ordinary CRUD surface with Tables, columns, and schema metadata.
• Change how registered or application rows are presented with Grid-first record workflows.
• Add a named action that coordinates several records with Shared contracts and request validation.
• If the result belongs to an already-running application rather than the repository, first choose the application interface.

Open the coding agent at the project root. The generated workspace already gives it AGENTS.md, framework-specific project files, and a project-local CLI. If the first outcome also needs access to the protected running application, create an agent token from /account/profile and paste the dialog’s setup prompt into that agent. The prompt contains the correct application URL and instructs the agent to place the URL and token behind private local environment tooling, then verify the token with api get '/api/auth-context'. The token itself must never be added to AGENTS.md. See Agent access and scoped tokens for the complete handoff and revocation workflow.

From there, use Develop with a coding agent to describe the outcome, owning boundary, server-side invariants, observable success, and relevant negative checks. Ask for a plan before edits when the change crosses schema, authorization, API, and frontend boundaries.

Review the evidence

When the agent finishes, inspect the result rather than relying on its summary:

• Review the focused diff and confirm that each change is in the package that owns it.
• Review generated migration SQL before applying it.
• Check shared contracts, mounted routes, and server-side authorization or row scope when the outcome uses them.
• Read the focused test output and build result.
• Start the application and read back the changed record, screen, endpoint, or report.
• Exercise a relevant failure, such as invalid input, missing ability, an invisible row, or an unapplied migration.

The generated project provides the usual build and development commands:

pnpm build
pnpm dev

A successful build proves that the workspace compiles. The read-back and negative check prove that the requested behavior is present at its runtime boundary. From here, use the guide index to choose the owner of the next outcome.