Skip to main content

lofi developer documentation

These guides are for developers building an application from the @nzip/lofi generated template. They describe the checked-out package version and its generated project—not the older prototype sketches under docs/spikes/.

Start here

Work through the guides in order; each builds on the project state the previous one leaves behind.

StepGuideWhat you do
1Getting startedScaffold an app, verify local persistence, and identify the files you are expected to change.
2Data and UIConnect a Jazz table to a typed Preact hook and island.
3PermissionsUnderstand and change the starter's owner-only access policy.
4Sync and recoveryProvision managed sync and understand the account lifecycle.
5TestingRun fast tests and the opt-in two-client offline convergence example.
6DeploymentBuild, preview, customize, and host the static PWA.
7Application-origin migrationMove a deployed app across a browser security boundary with recovery, verification, rollback, and retirement.

Blocked at any step — environment, browser, build, or test failures? Go straight to Troubleshooting.

The root README provides the shortest product overview and command summary. AI agents can ingest these docs as llms.txt (index) or llms-full.txt (complete corpus including the API reference).

Reference

The author boundary

Generated projects intentionally divide application source from versioned framework code:

  • Change src/schema.ts, src/permissions.ts, src/app.ts, src/pages/, src/layouts/, src/islands/, and src/styles/.
  • Import documented runtime seams from @nzip/lofi; no framework implementation is copied into src/.
  • Change files under public/ when customizing the icon or manifest. The package build generates the service worker.
  • Keep application tests under tests/.

Framework contributor material

The following documents explain why lofi behaves as it does. They are useful when changing the framework, but they are not application tutorials:

Spike evidence records the state of an experiment at a specific commit and package pin. Preserve it as historical evidence; do not update it to look like the current generated app.