DocsExamples

Examples

Every example below is a complete, copy-ready brief. Open Logic64 Studio → paste a brief into a new project, adjust the stack and constraints during planning, then generate. Treat them as starting points, not templates — Logic64 produces a fresh bundle for whatever you actually ask for.

The fastest way to understand Logic64 is to see what people actually ask it to build. The six examples on this page show the range of workspaces Logic64 produces, the kinds of decisions it locks during planning, and what arrives in the bundle when generation completes.

Each example is structured the same way: a copyable brief in plain English, the architectural decisions Logic64 will lock with you during the planning conversation, and the deliverables that land on your machine after logic64 pull.

What's not yet supported

Setting expectations is part of being useful. Logic64 produces complete, validated workspaces — but the platform has a defined scope, and a brief that falls outside it will be flagged during planning rather than silently degraded.

  • Modifications to existing codebases. The current release scaffolds new workspaces. Editing an existing project in place is not the intended use — and the validation chain is calibrated for greenfield bundles, not incremental patches.
  • Native mobile projects. Mobile-platform output (iOS, Android, native cross-platform shells) is on the roadmap but not part of the current target-assistant model.
  • Anything requiring paid-only or proprietary licenses. Logic64 will not lock a stack decision onto something a developer cannot independently install and run.
  • Multi-project monorepos. Logic64 currently produces a single project per bundle. Support for multi-project workspaces is planned but not exposed yet.
  • Briefs that violate locked decisions mid-stream. If you ask for one stack in planning and then change your mind mid-generation, the request is rejected. You re-plan, you regenerate — there is no silent override.

Writing a better brief

Every brief in the gallery follows the same shape. Briefs that produce better bundles tend to share four traits:

  • Name the project type in the first sentence. "A REST API for…", "A CLI that…", "A dashboard with…". This lets the planning conversation skip to the decisions that actually matter.
  • List the resources, pages, or commands explicitly. Logic64 will fill gaps with sensible defaults if you do not, but explicit nouns produce a tighter scaffold.
  • Mention conventions you care about. Loading states, error responses, authentication shape, log format. These become locked decisions rather than guesses.
  • Leave the stack open unless you have a strong preference. The planning conversation is the right place to negotiate stack — locking it in the brief is fine when you already know, and skipping it is fine when you want a recommendation.

Next steps

Pick a brief that resembles your project, paste it into a new Studio session, and see how Logic64 handles the planning conversation. The pages below are good companions: