Set up for your business

1. Inspect requirements and prepare files

From the project's Versions page, select an immutable version and keep its project ID, version ID, environment key, and content digest. Read its runtime/model requirements, license, file list, test evidence, and integration limitations.

Use the source runner with Node.js 22 or newer, an installed Ollama or LM Studio server, and a compatible local model. The recorded runtime checks cover macOS arm64; other operating systems need their own verification. A declarative sample needs no inbox, payment, or store account.

node packages/runner/dist/cli/bin.js environment prepare <project-id> --version <version-id> --environment <environment-key> --registry https://staging.localfirst.sh --out ./my-business

Replace placeholders with the selected version's actual IDs. Preparation copies the declared bundle into a new directory and does not install a model or dependencies. It preserves existing work by refusing an occupied destination. If environment retrieval is disabled on the deployment, use the author's exact bundle with environment prepare --bundle <bundle-dir> --out <new-dir>, or try the bundled sample.

Setup effort depends on your installed runtime and model, hardware, workflow profile, and any missing adapter. Public sample preparation is a terminal workflow; live integration work requires a developer and separate provider configuration. No measured setup-time estimate is available.

2. Configure private business information

Run the public fixture first. For your own request, store a private JSON input locally. The bakery input contains a message; intake extracts items and quantities, requested date/time, and decoration. Missing or unsupported details require owner clarification.

{
  "message": "60 cupcakes: 30 chocolate and 30 vanilla, blue icing. Pickup 2026-11-06 at 10:00."
}

Use --data with a separate JSON object keyed by declared dataset names such as menu, capacity, and prices. Each supplied value replaces that dataset completely; it is not a partial merge. Copy the dataset's full shape from the starter files and edit local facts.

{
  "capacity": {
    "slots": [
      { "date": "2026-11-06", "available_units": 100 }
    ]
  }
}

Keep private files outside the published bundle and repository history. Overrides cannot change prompts, executable code, paths, or permissions. These runs are local experiments; their structural checks do not measure public-fixture accuracy, and export as public evidence is disabled.

The declarative bakery workflow has no external account connector and needs no business-service credentials. An added adapter needs its own documented secret storage and scopes; never put tokens into public data, prompts, or project drafts.

3. Review, test, and inspect results

node packages/runner/dist/cli/bin.js environment plan ./my-business --runtime ollama --endpoint http://127.0.0.1:11434 --model <installed-model> --input <private-input.json> --data <private-business-data.json>
node packages/runner/dist/cli/bin.js environment run <saved-plan-path>
node packages/runner/dist/cli/bin.js report trace <saved-report-path> --workspace ./my-business --out <new-trail.html>

To test the public fixtures, omit --input and --data. Use LM Studio's runtime name and loopback endpoint when applicable. Review every role/model binding, prompt/data identity, output destination, resource ceiling, and network or file effect before approving the saved plan locally.

A private request is observed for structure and execution, not graded against the public fixture's expected answer. Inspect the actual order, computed capacity and price, owner-review status, and generated draft. Confirm business correctness yourself; a successful process does not accept an order.

The local trail omits private content unless you explicitly choose to include it. Treat any full local trace as private. Nothing is uploaded automatically; report sharing has its own review.

4. Assess each integration before operating

Manual input

The source runner accepts a local JSON request. You supply the input, run it deliberately, and review each output. Public fixtures exercise this local workflow.

File import

Declared JSON datasets can be overridden locally. Mapping arbitrary CSV exports or provider records into those shapes requires a separate conversion step.

Your AI client

Localfirst MCP retrieves specifications and versioned files and can offer a gated local-plan handoff. It does not ingest customer messages or grant access to your business systems.

Inbox, POS, calendar

The bakery sample requires development for these adapters. Specify provider accounts, input triggers, mapping, authentication scopes, read/write effects, duplicate/retry handling, corrections, and disconnection before connecting one.

Stock replenishment

The stock-replenishment sample reviews complete fictional snapshots and drafts an owner proposal. Continuous monitoring, live stock/vendor checks, notifications, and purchase orders require development.

For your selected version, ask the author what is implemented and tested, requires configuration, requires development, or remains unknown. Tie any tested claim to an actual scoped result. A successful synthetic fixture cannot establish a live connector.

Connection consent, dependency setup, local execution, external business writes, report upload, and publication are separate approvals. Generated advice does not authorize any of them.

5. Operate and recover locally

The supported mode is a deliberate terminal run with local reports. There is no unattended inbox watcher or automatic order placement. Inspect errors and partial outputs in the report before deciding to rerun.

• If runtime preflight fails, check the installed model, endpoint, and supported output profile using the testing troubleshooting guide.
• If private configuration is wrong, preserve the prior file, correct its replacement, and make a fresh plan. Changed data invalidates approval.
• If you edited prepared project files, retain your work and prepare the intended validated bundle in a new directory.
• Keep local plan/report paths printed by the runner. Cleanup with environment remove <workspace> only removes unchanged prepared files after review; plans and reports are retained, and changed or additional files block cleanup.
• Revoke registry client access through Connections. Disconnect any separately added business adapter at its provider, following its documented procedure.

Ask your AI to help with setup

Help me set up Localfirst project [project-id], exact version [version-id], environment [key].
Read its public requirements and exact bundle through Localfirst MCP at https://staging.localfirst.sh/mcp.
Keep those immutable IDs and digests throughout setup. Check the installed runner,
runtime, model capabilities, profile, and deployment availability before commands.
Inspect public fixtures first. Explain required private input and dataset shapes,
but keep credentials and customer data in local files outside the public bundle.
Identify missing adapters and unknown integration requirements without inventing them.
Show the exact local plan and resource effects. Wait for my approval of setup,
execution, external writes, and sharing separately; never approve on my behalf.
Inspect actual outputs and failures. Do not treat a fixture pass as live integration evidence.

For reusable workflow changes, follow Create an environment and publish a distinct version with its own evidence.