Ctrl K

Guides API Reference Examples Pricing Help Center

Get StartedCore Concepts

Core Concepts

These concepts are the mental model behind every Logic64 workspace. If a generation ever behaves in a way that surprises you — a file rejected, a dependency refused, a config left untouched — the explanation lives on this page. New here? Start with the Introduction →

Logic64 is built around a small set of ideas that compose into the entire experience. Once you have the shape of them, every behavior of the platform becomes predictable: why a generation pauses for clarification, why a file gets rejected, why a config merge takes the path it does, and why a bundle is always either fully delivered or not delivered at all.

This page describes those concepts in the order you encounter them — from the moment you describe a project to the moment the CLI finishes writing files on your disk.

Plan, Generate, Pull

Logic64 enforces three discrete phases. They do not overlap, they cannot run in parallel, and they cannot be skipped. The shape of the flow is identical for every project, regardless of stack or scope.

flow

Plan        (conversational)
   |
   v   Architecture State accumulated — every decision locked
   |
Generate    (transactional)
   |
   v   Bundle produced server-side, validated end-to-end
   |
Pull        (local)
   |
   v   Files routed onto your machine, resolution log written

1The Plan phase

You describe the project you want to build in plain English. Logic64 responds conversationally, proposing the stack, surfacing trade-offs, and asking targeted questions when your brief is ambiguous. Each agreement you reach is converted into a locked decision recorded in the Architecture State.

Locks are append-only inside a planning session. Once a decision is locked, no generation step can contradict it. If you want to revisit a locked choice, you make the conflict explicit and re-plan — there is no quiet override.

2The Generate phase

When you click Generate, the Engine receives a payload containing the full Architecture State, the project memory, and a compressed summary of the planning conversation. It then runs a reasoning loop that produces files one at a time, each passing validation before the next is written.

Generation is transactional. There is no partial bundle that "mostly worked": either every file passes per-file validation and the bundle passes cross-file consistency, or the entire generation is rejected and reported back to you with a structured failure reason.

3The Pull phase

Generation produces a single, sealed bundle and a bundle_id. Files are not written to your machine yet. You move the bundle to your local environment by running:

bash

$ logic64 pull <bundle_id>

The CLI downloads the archive, reads its manifest, applies Smart Routing to place each file at the correct location, merges any required configuration safely, and writes a resolution log next to your project. Once the pull succeeds, the CLI sends an acknowledgement back to the platform — the bundle is then marked as delivered.

The Strict Project Bundle

The deliverable of every Logic64 session is a single archive called a Strict Project Bundle. It is self-describing — meaning the CLI does not need any out-of-band knowledge to extract it correctly.

A typical bundle contains:

manifest.json — the routing table. Every file in the bundle has an entry describing where it should be placed, how it should be merged, and what kind of file it is.
The project scaffold — directories, source files, environment templates, configuration files.
A rules file for the target AI assistant, calibrated to your stack and conventions.
A memory file documenting the architectural decisions locked during planning.
Assistant configuration files intended for safe merge into your global AI assistant config.

The bundle is immutable: you cannot edit a file inside it and re-pull. To change anything, you regenerate. This is intentional — it means the bundle is always traceable to a specific, validated generation, and a delivered bundle is never quietly mutated.

Architecture State

At the heart of every Logic64 session is a structure called the Architecture State: the accumulated set of decisions you have locked in.

Each entry records a single, specific architectural choice — for example, that the frontend will use React with a particular styling system, or that authentication will be handled by a particular pattern. The Architecture State has two non-negotiable properties:

It is append-only within a session. Once a key is locked, it cannot be silently overwritten. Any attempt to relock the same key is treated as a conflict and surfaced explicitly.
It is the single source of truth for generation. The Engine reads it before writing any file. Every generated file is checked against it before it is accepted into the bundle.

The Architecture State is what makes Logic64 deterministic in spirit even though the underlying generation is probabilistic. The AI can phrase code freely; it cannot redefine the architecture mid-way.

Three-Layer Safety

Every generated file passes through three independent layers of safety. A file must satisfy all three to enter the bundle. The layers are deliberately redundant — if a problem slips past one, the next is designed to catch it.

Layer 1 — Prompt constraints. The reasoning engine is shaped, by construction, to operate only within the agreed architecture. It is told what it may produce and what it must refuse.
Layer 2 — Input validation. Every file the engine attempts to write is checked against schemas, size limits, path safety rules, and forbidden patterns before it is accepted.
Layer 3 — State gating. Files are checked against the Architecture State. A file claiming to use a library or framework that contradicts a locked decision is rejected before it enters the bundle.

The point of three layers is not paranoia — it is the explicit acknowledgement that no single guardrail is enough when a language model is producing structured output. Rejecting bad files is cheap; explaining a corrupt scaffold to a developer is not.

The validation chain

Per file, the Engine runs an 11-step validation chain before the file is considered accepted. The chain is ordered cheapest-first — meaning the fastest checks run first, so the overwhelming majority of failures are caught in microseconds.

The categories of checks, in order:

Path safety — no directory traversal, no writes outside the workspace root, no targets on the deny list.
Structural integrity — no empty files, no duplicate paths, no oversize content.
Stack compliance — content is scanned for technology references; anything that contradicts the Architecture State is a hard rejection.
Dependency policy — forbidden libraries and packages, defined per project, are blocked at the file level.
Schema validation — configuration files are checked against their schemas. Invalid JSON, missing required fields, or incorrect types are rejected.
Content safety — rules files are scanned for prompt-injection patterns that would compromise the assistant's behavior on your machine.
Cross-file consistency — once all files exist, a final pass checks that they agree with each other: the rules file matches the scaffold, internal references resolve, and the manifest is complete.

If the final pass fails, the bundle is not sealed and not delivered. The platform returns a structured error to Studio describing what failed and why; you adjust and regenerate. A bundle that reaches your CLI has, by definition, passed every check end-to-end.

Stateless generation

The Engine carries no memory between requests. Every generation runs in a fully isolated environment that is created when the job starts and discarded when it ends. Anything the Engine needs to know — the Architecture State, the project memory, the conversation summary — is injected per request via a structured payload.

This pattern is deliberate. It buys three properties:

No state bleed. A generation for project A cannot accidentally inherit context from project B, even if the same machine handles both back-to-back.
Reproducibility. Given the same payload, the same generation produces results within the same class — the inputs fully describe the run.
Safety. A failed, malformed, or hostile payload cannot poison subsequent generations because the environment never persists.

Statelessness is the reason you can run a generation, hit a problem, fix the brief, and regenerate with full confidence that nothing from the failed attempt is hiding in the next one.

Smart Routing & safe merging

A bundle does not simply dump files into your current directory. Different files belong in different places: the project source belongs in the workspace root, the assistant configuration belongs in your global config directory, skills belong in the assistant's skills tree.

The CLI reads manifest.json and applies the Smart Routing Matrix to place each file correctly. When a destination is already occupied — for example, you already have a global assistant config — the CLI does not overwrite. It merges, deterministically:

Configuration files are merged key-by-key with explicit conflict rules. Your existing settings are preserved unless the bundle explicitly requires a change.
Replaced files are backed up locally before any write. Nothing is destroyed silently.
Port and name conflicts in scaffolded services are auto-resolved with a deterministic rule, not a random pick. The same bundle, applied twice, resolves the same way.
Every change is logged in resolution_log.json, so you can audit exactly what landed where.

Target Assistant model

Logic64 generates output tuned to the AI coding assistant you actually use. Each project carries a target assistant field, and that target determines several things about the bundle:

Which rules file is produced — the assistant's expected name, location, and structure.
Where assistant configuration files are merged, and in which format.
Which skills or subagent prompts are generated, formatted for that assistant's prompt system.
How the CLI's routing matrix interprets each file in the manifest.

The current release officially targets Claude Code CLI: the rules file is CLAUDE.md, configuration is merged into the standard Claude Code config location, and skills are emitted in the format Claude Code expects. Support for additional target assistants will follow as the platform matures.

Transparency & rollback

After every successful pull, the CLI writes resolution_log.json next to your project. The log is the single source of truth for everything that happened during extraction:

Every file written, and the destination it was written to.
Every configuration merged, and the keys that were added or changed.
Every port, name, or path conflict that was auto-resolved, and the rule used to resolve it.
The bundle ID, the generation timestamp, and the target assistant.

The log feeds directly into the rollback command. If you decide the pull was a mistake, or you want to cleanly remove a workspace and try again:

bash

$ logic64 rollback <bundle_id>
# Reverses every file write and config merge recorded in resolution_log.json

Because every change is recorded, every change is reversible. There is no "mysterious mess" left behind by a failed pull — only the entries in the log, each of which can be undone.

Next steps

With the mental model in place, the rest of the documentation covers the surfaces you interact with directly — Studio for planning, the CLI for delivery, the API for integration:

NextStudio Overview