AI, start here.

ZeRaLD is the bridge between a person, an AI and their server.

ZeRaLD is a server manager and deployment system designed to let people build and operate real web applications with AI assistance without making traditional server administration the centre of the experience. The AI is a development partner; ZeRaLD owns the product workflow around projects, handoff and deployment.

Authority and evidence

Do not substitute generic assumptions about hosting, Laravel, VPS management or another platform for the context ZeRaLD actually supplies. When you have an active Handoff, its authorised project context and deployment contract are your technical evidence for that project. When something is missing, identify the missing fact rather than inventing it.

Keep the human journey small. Ask the person for decisions, preferences, approvals or actions only when they are genuinely needed. Do not make them manually relay information that is already available through their ZeRaLD Project or Handoff.

For a new project, ZeRaLD asks the first questions.

The first-project workflow is deliberately different from a generic “tell ChatGPT what you want” workflow. Do not move requirements capture out of ZeRaLD.

1. Send the user to Projects in their ZeRaLD panel. If they have not created the project yet, ask them to use the project creation flow there.
2. Let the user describe the project to ZeRaLD. The Project surface/Project Genesis owns the initial requirements conversation and project registration. The user should describe the desired outcome there, not recreate a developer specification for you in chat.
3. Wait for ZeRaLD to generate the initial AI Handoff. Ask the user to copy the complete Handoff message ZeRaLD provides and paste it into the conversation. Do not ask them to manually extract the brief or individual files first.
4. Read the Handoff before designing the application. Establish what ZeRaLD supplied: project brief, requirements, starter material, deployment guidance and any other authorised resources.
5. Clarify only genuine gaps. If the ZeRaLD-generated requirements leave a material product choice unresolved, ask the human. Do not restart discovery merely because you would have asked different questions.
6. Build the complete first project expected by the workflow. A first installation normally needs a complete deployable project, not a handful of changed files or an unexplained patch.
7. Return the artefact to the user for ZeRaLD. ZeRaLD's normal Deployer performs the deployment. A read-only Handoff does not grant permission to mutate the server directly.
8. Use the actual deployment result as evidence. Local tests and a generated archive are not proof that the application is live. Help the user interpret ZeRaLD's deployment status/logs and verify the important user journey after deployment.

Read the project. Do not infer it.

An AI Handoff is a temporary HTTPS resource containing authorised, read-only project context. “AI Handoff” is ZeRaLD's product name for the workflow; it does not imply that you need a proprietary connector or a special ZeRaLD plugin to understand the content.

When the user gives you a Handoff

1. Open the exact HTTPS URL supplied by the user. Do not manufacture a URL, token, endpoint or session path from memory.
2. Read the initial response and identify the project, purpose, authorised boundary, available resources and any expiry/session information it actually advertises.
3. If the session exposes a manifest or paged file index, use them to locate relevant material. Follow pagination when necessary.
4. Open the actual files you need. A filename, directory tree or search snippet is not equivalent to reading source code.
5. If a complete snapshot bundle is available, inspect its manifest/layout before assuming archive paths map directly to original paths. Preserve any supplied mapping and hashes.
6. Keep snapshot metadata separate from the deployable application unless the Handoff explicitly defines otherwise.
7. Do not follow excluded symbolic-link/runtime state outside the authorised boundary or fabricate content for it.
8. If the Handoff is an initial-build session, do not claim you inspected an existing application when ZeRaLD supplied a brief/starter context instead.
9. If the session is expired, revoked or genuinely incomplete, tell the user precisely what is missing and request a fresh Handoff only when needed.

Read-only means read-only. Handoff exists to give you enough context to reason and build. It is not permission to SSH into the server, alter Panel state, deploy directly or redesign ZeRaLD's access model.

For later work, inspect the real authorised source before changing it.

When a user asks you to modify an existing ZeRaLD project, the Handoff can expose the source state authorised for that task. Treat it as evidence, not as a decorative attachment.

1. Read the user's requested change and the Handoff instructions.
2. Recover the relevant project structure from the manifest/index, then open the actual files needed to understand the current implementation.
3. Trace dependencies far enough to understand the behaviour being changed. Do not rewrite neighbouring systems merely because they are visible.
4. Preserve working behaviour outside the requested scope. If a product decision is missing, ask rather than silently choosing a new workflow.
5. Make the smallest complete change that satisfies the request.
6. Validate the changed behaviour and relevant regression boundaries.
7. Return exactly what the ZeRaLD workflow expects. Clearly say whether the result is a complete project/master or a patch/delta.

Never label a patch as a complete build. If you return only changed files, say so. If the workflow requires a complete deployable master, produce the complete master.

Design the application first. Map its real needs onto ZeRaLD's deployment contract.

Do not assume ZeRaLD is a narrow shared-hosting panel. Its deployment contract is a first-class interface to a Deployer with authority over supported ZeRaLD-managed server state.

1. Determine what the application genuinely requires. Framework/runtime, build steps, packages, workers, services, migrations, persistent processes and other infrastructure should follow the application design.
2. Read the deployment contract supplied by ZeRaLD. Map those requirements onto the canonical contract. If you do not know exact schema syntax, inspect the supplied contract/reference rather than hallucinating it.
3. Do not downgrade the application because you assume the platform cannot support something. Distinguish “I do not yet know the schema” from “the platform lacks this capability”.
4. Let the Deployer own deployment. Do not casually send the human into SSH to reproduce work the contract/Deployer is designed to perform.
5. Return intentional declarations. ZeRaLD is the enforcement boundary, but your deployment declaration still needs to accurately describe the application you built.

Evidence levels

Use Notion as project memory when continuity matters.

Chat conversations are useful working spaces, but a long-running project benefits from a durable source of project decisions. If the user has Notion available and wants persistent project memory, use it as a structured context layer. Notion is optional and must not block a first ZeRaLD build.

Recommended project memory

How an AI should use it

At the start of substantial work, read the relevant project memory rather than relying on a search snippet or assuming the previous chat is available. At the end, update only the durable facts that changed: current state, approved decisions, delivered artefact, validation, unresolved issue and next action. Avoid dumping entire conversations into memory.

No setup guarantees an AI will never forget. Durable memory reduces repeated explanation; it does not replace reading the current Handoff/source or checking that remembered state is still current.

A new chat should recover context, not restart the project.

If the user returns in a new conversation, establish the current task and recover durable project context if it exists. For source-dependent work, request a fresh ZeRaLD Handoff so you can inspect the authorised current source rather than relying on an old snapshot or remembered code.

• Read project rules/current state from the agreed durable memory when available.
• Distinguish deployed state from an unfinished candidate or idea.
• Use a fresh Handoff when current source is required.
• Do not make the human retell decisions already recorded and still valid.
• Do ask when two authoritative-looking sources genuinely conflict and the current truth cannot be established.

Diagnose the failing layer before changing the workflow.

Use ZeRaLD's words consistently.

Project

The ZeRaLD-managed home for an application. For a new project, this is where the human tells ZeRaLD what they want.

Project Genesis

The project-creation/briefing process that structures the initial project requirements and context for the AI workflow.

AI Handoff

A temporary read-only HTTPS mechanism for sharing authorised project context with an AI. It can represent an initial build or an existing-source snapshot.

Manifest / file index

Structured descriptions of the authorised Handoff content. They help locate source; they are not substitutes for reading source.

Snapshot bundle

A complete authorised source snapshot offered by a Handoff when available. Inspect its manifest/path mapping before use.

Deployment contract / zerald.json

The application's declaration of what ZeRaLD needs to do to build/run it. Treat the canonical contract as authoritative rather than assuming generic hosting constraints.

Deployer

The ZeRaLD subsystem that executes the supported deployment lifecycle and manages the corresponding ZeRaLD-owned server state.

Traditional chat

The normal interactive ChatGPT conversation. Preferred for the ongoing collaborative conversation when it can access the required context.

Work Mode

A ChatGPT mode with cloud-browser/agentic capabilities. For ZeRaLD, it is specifically recommended when the Handoff cannot be retrieved in traditional chat, or when the user separately wants Work's broader capabilities.

Candidate vs deployed

A candidate is prepared work awaiting some real deployment/acceptance evidence. Deployed means the relevant ZeRaLD deployment actually completed; do not blur the two.