Creating a Workspace

1Describe your project

Open a new project in Logic64 Studio and type your description into the project prompt field. This is the most important input you give to Logic64 — the Engine uses it to lock your architecture before writing a single file.

A good description answers four questions at once:

• Goal — what does the application do? Be specific about its primary function.
• Audience — who will use it, and how? (e.g., "internal team dashboard", "public SaaS", "CLI tool for developers")
• Key features — list the 3–5 core capabilities you need in the first version.
• Framework preference — if you have a strong preference (e.g., Next.js App Router, Fastify REST, CLI-only), state it here.

Here are three examples that produce great results:

# Example 1 — SaaS dashboard
A multi-tenant project tracker for software teams. Users can create
workspaces, invite members, and manage tasks with priority labels and
due dates. Built with a Next.js App Router frontend and a REST API
backend. Target audience: small engineering teams.
# Example 2 — CLI dev tool
A command-line tool for developers that scans a project directory,
detects the framework in use, and outputs a structured JSON report of
all environment variables required. Node.js CLI with TypeScript.
# Example 3 — Internal analytics tool
An internal dashboard that pulls sales data from a REST API, displays
weekly revenue trends in charts, and exports reports as CSV. React
frontend, no auth required — accessed only inside a private network.

You do not need to specify every detail. Logic64's Hallucination-Constrained Architecture fills in the remaining decisions during the plan phase — and shows you exactly what it chose before generating anything.

2Review the plan

After you submit your description, Logic64 enters the PLAN phase. Within a few seconds, Studio displays a structured architecture plan — not code, just decisions. This is your chance to review and adjust before any file is written.

The plan shows:

• Proposed stack — the framework, language, and tooling chosen for each layer of your project.
• Modules and structure — a breakdown of the top-level directories and their responsibilities.
• Key decisions — architectural choices that have been locked (e.g., REST vs. GraphQL, auth strategy, file routing rules).

You can lock individual decisions to prevent the Engine from changing them, or leave items open for the Engine to resolve during generation. If a proposed framework does not match your needs, edit the description and regenerate the plan before proceeding — changing the stack mid-generation is not supported.

3Approve and generate

When the plan looks right, click Approve & Generate. Studio hands the approved plan to the Logic64 backend, which places your request in a priority queue.

The backend then launches a fully isolated cloud process dedicated to your workspace. This process isolation is a core part of the Hallucination-Constrained Architecture — each generation run has no access to any other project's state and cannot be affected by concurrent requests from other users. Once your process starts, Studio transitions to live streaming mode.

4Watch the generation stream

Studio connects to a live event stream and displays progress in real time. You will see file-by-file updates as the Engine builds your workspace. There is nothing to do here — just watch it unfold.

The stream surfaces four categories of events:

• token — incremental content as each file is written, streamed character by character.
• state_update — phase transitions (e.g., moving from scaffold generation to config file writing).
• tool_status — signals from internal tools, including validation checks as each file completes the 11-step chain.
• bundle_ready — the final event, confirming that all files passed validation and the bundle is available for download.

If a file fails validation, you will see a tool_status event with the rejection reason. Logic64 does not silently skip broken files — a failed validation stops the process and surfaces the exact rule that was violated. See Validation Report for details on what each validation step checks.

5Get your bundle ID

When the bundle_ready event arrives, Studio displays your bundle ID — a unique identifier that looks like a3f2bc89-4d1e-47a0-b8c6-2e5f91340abc. Copy it, then run the following command in your terminal to pull everything to your local machine:

$ logic64 pull a3f2bc89-4d1e-47a0-b8c6-2e5f91340abc
# ↓ Downloading bundle a3f2bc89…
# ✓ 27 files written — project scaffold, CLAUDE.md, memory.md, MCP configs
# ✓ Config merged into ~/.config/claude-code/config.json
# ✓ resolution_log.json written to project root
# → Next: cd my-workspace && open your editor

The CLI reads manifest.json inside the bundle ZIP and routes every file to the correct destination — project root, global config directory, or skills folder. Every action is recorded in resolution_log.json at the project root, so you always have a full audit trail of what was written and where.

Bundle IDs are also visible in your Project Library in Studio, so you can re-pull any past workspace at any time.