Genesis is easiest to understand as a controlled system rather than as a chat box with a terminal attached. A user gives it an objective, a workspace, an intent, acceptance conditions, permissions, a model choice, and a budget. Genesis then builds a durable run, inspects before editing, uses a narrow typed capability set, verifies the result, and records what happened. The interface is important, but the run contract and its evidence are the product’s centre of gravity.
What Genesis is
Genesis is TronXVI’s local coding-agent workspace. It is designed for repository work: understanding an unfamiliar codebase, planning a change, editing files, running focused checks, diagnosing failures, reviewing a diff, and leaving a durable record of the outcome. It is deliberately narrower than a general autonomous computer operator. The system’s job is to make software work inspectable, permissioned, and recoverable.
The canonical public run family is POST /api/work/runs with the contract identifierwork.run.request.v1. That request enters RunController, moves through the canonical pipeline, and returns a versioned response plus an ordered event stream. The frontend projects those facts into the workspace. It does not invent a separate completion result from a model message.
Genesis has a strong local orientation. The workspace, source files, test commands, services, and runtime evidence are treated as the primary operating context. Model access is one dependency at the model boundary, not the owner of the run. If model calls are disabled or a required provider is unavailable, Genesis is expected to fail closed and explain the limitation rather than pretend that work completed.
Product boundaries
Genesis owns the coding-agent run experience: objective intake, workspace context, typed capabilities, process execution, verification, review, recovery, and durable run history. It does not claim ownership of every tool in the wider TronXVI ecosystem. Infinity can provide a shell or embedding boundary around products, but Genesis remains the coding-agent product with its own backend contract and frontend state.
The repository documentation explicitly keeps one truthful execution path. There is one run controller, one production AgentLoop, one model gateway, one process executor, one completion controller, one runtime database and event ledger, and one frontend projection model. This avoids the dangerous situation where a visible chat says one thing while a hidden worker, alternate endpoint, or second renderer does another.
Genesis also has a distinction between what exists in the implementation and what is promised as a public product surface. Controlled extension admission and operator-facing capability controls exist in the backend, but Genesis is not described as a public marketplace, open plugin ecosystem, or unrestricted connector platform. Capability access remains subject to policy, trust, grants, and enablement state.
The Genesis mental model
A workspace is the boundary around work
A workspace gives a run a concrete place to inspect and change. It may be an opened repository, an uploaded batch, or a workspace prepared through the local runner path. Genesis tracks workspace identity, readiness, repository metadata, file paths, attachments, and service information so that an answer is tied to the code that was actually inspected.
A run is a durable process, not a single prompt
A prompt can start a run, but the run continues through multiple observations and actions. It has a stable identifier, a request snapshot, an event cursor, usage and budget records, approval checkpoints, tool results, verification evidence, and a terminal outcome. This is why a run can be replayed, resumed, cancelled, retried, paused, or inspected without reconstructing the entire story from chat text.
Tools are capabilities with contracts
The model does not receive a magic “do anything” shell. It can select from typed tools whose inputs, outputs, effect classes, approval needs, and workspace rules are known to the runtime. The distinction is practical: a read-only search can be evaluated differently from deleting a path or restarting a service.
The workspace surfaces
The Genesis frontend is a working console around the run contract. Its main views are designed to answer different questions without changing the underlying source of truth: what is the user asking for, what is the agent doing, what files are open, what services are alive, what does the budget allow, and what evidence proves the result.
| Surface | What it does | Why it matters |
|---|---|---|
| Chat / composer | Captures questions, objectives, attachments, and run intent. | Separates conversation context from executable work. |
| Run panel | Shows stage, tool activity, budget, approvals, and terminal state. | Makes execution visible instead of hiding it behind a spinner. |
| Code view | Explores the repository, opens tabs, shows source, and supports approved edits. | Keeps source inspection and change review in the same workspace. |
| Layout view | Organizes chat, code, progress, service status, and run statistics. | Lets the user choose a working arrangement without changing run semantics. |
| Schedule view | Stores scheduled workspace messages and their send times. | Separates planned communication from an already-running execution. |
| Service status | Shows declared services, ports, health, process state, and freshness. | Turns “the app is broken” into a diagnosable runtime fact. |
| Download / device entry | Explains browser and desktop runner choices and their boundaries. | Prevents desktop execution from silently falling back to a browser runner. |
The run contract
Every canonical run is shaped by WorkRunRequestV1. The request carries a schema version, client request ID, workspace ID, pipeline name, client mode, task thread, objective, intent, acceptance conditions, requested model, budget, run policy, permissions, data classification, verification policy, review policy, optional schedule time, metadata, and attachment IDs.
The intent is explicit: inspect, implement, fix, refactor, test, build, or deploy. Scope is explicit. The request can state whether extra changes are allowed. Acceptance conditions can be mandatory and can name the verification requirement that must prove them. Run policy includes inspect-before-edit, network access, and a maximum parallel writer count. This turns vague autonomy into a set of checkable commitments.
Permissions are not implied by a friendly sentence. The contract distinguishes read-only chat, no-code-edit execution, inspect-only work, write-with-approval, safe auto-write, and operator-full modes. Data classification also matters: public, internal, confidential, restricted, or secrets-present data should not all be handled with the same provider or logging policy.
Requests are idempotent through the client request ID. If a client retries because a network response was lost, the backend can identify the accepted request instead of creating a second run by accident. The response returns the run ID, task and workspace identity, acceptance time, initial state, resolved model, budget, and the first event cursor.
How a Genesis run works
The complete lifecycle is Plan → Inspect → Implement → Verify → Review → Complete. The labels are not decorative. Each stage is an ownership boundary with evidence and failure behavior.
| Stage | Detailed behavior |
|---|---|
| Plan | The objective, intent, acceptance conditions, permissions, model, and budget are made explicit. |
| Inspect | Genesis reads the relevant repository context, finds owners and consumers, and checks the workspace before editing. |
| Implement | The AgentLoop uses typed tools and bounded mutations, with approval where the effect requires it. |
| Verify | Focused tests, related tests, type checks, builds, diagnostics, and runtime probes produce evidence. |
| Review | The run checks the resulting diff, changed boundaries, and required review policy. |
| Complete | CompletionController commits a terminal state only when the contract’s requirements are met. |
Plan
Genesis first turns the request into a bounded objective. It identifies the requested action, target scope, acceptance conditions, allowed data class, requested verification, and permission level. If the request is underspecified in a way that affects safety or correctness, the run can ask for clarification.
Inspect
Before editing, the AgentLoop uses repository tree, search, symbol, dependency, diagnostics, and related implementation tools to find the real owner. It checks neighboring tests and contracts rather than patching the first matching string. Inspection results are observations; they are not silently treated as completed implementation.
Implement
Changes are made through typed mutation tools and the workspace boundary. Multiple writers are constrained by policy. A mutation can require approval. File writes can be compared against an expected base hash, and the resulting change is available for later review. The execution path does not turn a model-generated code block into an untracked side effect.
Verify, review, complete
Verification is selected from the acceptance conditions and affected owners. Tests, type checks, builds, diagnostics, runtime health, browser evidence, or review can all matter. CompletionController owns the terminal decision. A confident model sentence cannot override a failed required check.
State, events, and replay
The durable event ledger is the chronological account of a run. Each WorkRunEventV1 carries a run ID, event ID, sequence, event type, creation time, and payload. The sequence is ordered and replayable. The frontend consumes that history through run detail, events, and stream paths, then projects it into the visible run state.
This model distinguishes an event from a display message. A model-authored progress update may explain what the agent believes it is doing, but a terminal process exit, test result, approval decision, or stored file mutation is a stronger operational fact. The UI can show both; it must not confuse them.
Durable replay is especially important after a browser refresh, network interruption, process restart, or worker recovery. The user should be able to see what was accepted, what ran, what was approved, what failed, and what remains unknown without relying on an ephemeral websocket buffer.
Model gateway and budgets
ModelGateway is the model boundary. It resolves the requested model, passes only the permitted request context, accounts for usage, handles bounded retries, and returns structured results to the AgentLoop. The gateway also owns fake or controlled clients used for local tests so verification does not require an uncontrolled live provider call.
Budgets are multidimensional. A run can be limited by USD cost, input or output tokens, model calls, attempts, retries, repair cycles, tool calls, wall-clock time, context size, output size, parallelism, or reserved budget. The frontend presents the current cost, cap, remaining amount, reservations, attempts, retries, and uncertainty. Warnings can appear before exhaustion; exhaustion prevents further model calls.
Retry behavior is not permission to loop forever. The run records retry and repair budgets, preserves the reason for another attempt, and exposes when an outcome is uncertain. There is no silent provider fallback that changes the meaning of the task or hides a missing credential. A blocked model boundary is a truthful blocked run.
The typed tool registry
The registry contains 54 typed tools grouped by effect and responsibility. Tool availability can still be narrowed by client mode, permissions, approval state, workspace readiness, and policy. The list below is the complete canonical registry scanned from the Genesis backend; it is not a promise that every tool is shown in every user mode.
| Tool | Family | Capability | Effect |
|---|---|---|---|
read_file | Read | Read one bounded text file with explicit workspace path handling. | Read-only |
read_files | Read | Read a bounded set of files when a task needs related context together. | Read-only |
search_files | Read | Search repository files using a structured file-search request. | Read-only |
repository_tree | Read | Inspect the repository tree without opening every file into context. | Read-only |
lexical_search | Intelligence | Find exact lexical matches across the indexed workspace. | Read-only |
semantic_search | Intelligence | Find conceptually related code or documentation in the workspace index. | Read-only |
semantic_search_explain | Intelligence | Explain why semantic matches were returned and what evidence supports them. | Read-only |
repo_index_status | Intelligence | Report repository indexing state and freshness before relying on search results. | Read-only |
repo_intelligence_map | Intelligence | Build a higher-level map of repository structure and important owners. | Read-only |
find_related_implementation | Intelligence | Locate implementation neighbors for a requested behavior. | Read-only |
similar_file_search | Intelligence | Find files with similar structure or responsibility. | Read-only |
dependency_graph_search | Intelligence | Trace dependency relationships relevant to a change. | Read-only |
find_symbol | Code navigation | Locate a named symbol and its owning file or module. | Read-only |
find_references | Code navigation | Find known references to a symbol before changing it. | Read-only |
go_to_definition | Code navigation | Resolve a symbol to its definition for precise inspection. | Read-only |
outline_file | Code navigation | Return a structural outline of a file without loading all contents. | Read-only |
rename_symbol_preview | Code navigation | Preview the affected references for a symbol rename. | Preview |
lsp_status | Code navigation | Report language-server availability and current workspace support. | Read-only |
workspace_diagnostics | Diagnostics | Collect workspace-level diagnostics for the active repository. | Read-only |
changed_file_diagnostics | Diagnostics | Check diagnostics for files changed by the current task. | Read-only |
inspect_binary_file | Inspection | Inspect supported binary metadata without treating binary data as source text. | Read-only |
write_file | Mutation | Write one approved file using the workspace mutation contract. | Write |
write_files | Mutation | Write a coordinated set of approved files with bounded paths. | Write |
apply_patch | Mutation | Apply a structured patch after the relevant source has been inspected. | Write |
apply_unified_patch | Mutation | Apply a unified diff with explicit file and hunk boundaries. | Write |
codemod_replace | Mutation | Perform a constrained mechanical replacement with explicit scope. | Write |
move_path | Mutation | Move a path while preserving workspace boundary checks. | Write |
delete_path | Mutation | Delete an approved path only when the run policy and permissions allow it. | Destructive write |
run_command | Process | Run an explicitly described command through the policy-controlled process executor. | Approval / write |
service_list | Services | List declared workspace services and their known runtime metadata. | Read-only |
service_health | Services | Probe a declared service health endpoint or process health contract. | Read-only |
service_logs | Services | Read bounded service logs for diagnosis and evidence. | Read-only |
service_start | Services | Start a declared local service through the service owner. | Process control |
service_stop | Services | Stop a declared local service through the service owner. | Process control |
service_restart | Services | Restart a declared local service when verification requires it. | Process control |
git_facts | Review | Read repository facts needed to explain current source state. | Read-only |
worktree_prepare | Review | Prepare a task-scoped worktree when the execution policy permits it. | Workspace control |
worktree_cleanup | Review | Clean up a task-scoped worktree after its lifecycle is complete. | Workspace control |
worktree_status | Review | Report the state of a task-scoped worktree. | Read-only |
review_diff | Review | Review a commit or diff for correctness and unintended changes. | Read-only |
review_workspace_diff | Review | Review the current workspace diff as task evidence. | Read-only |
review_commit | Review | Review a specific commit when that review is part of the authorized task. | Read-only |
review_base_branch | Review | Compare work against the configured base branch for review evidence. | Read-only |
detect_test_commands | Verification | Detect the repository’s relevant test commands and conventions. | Read-only |
plan_verification | Verification | Construct a verification plan from the task, scope, and changed owners. | Read-only |
run_focused_tests | Verification | Run the smallest relevant test set for the changed behavior. | Process |
run_related_tests | Verification | Run broader tests around the changed module or boundary. | Process |
run_typecheck | Verification | Run the applicable type checker and return structured results. | Process |
run_compile | Verification | Compile or build an affected package and return evidence. | Process |
parse_test_failures | Verification | Turn test output into structured failure records. | Read-only |
map_failure_to_file | Verification | Map a failure to the most likely owning file or code path. | Read-only |
browser_verify | Network | Verify a browser-visible local surface with approval and bounded evidence capture. | Approval-gated |
web_search | Network | Perform an approval-gated, read-only web search through the configured provider path. | Approval-gated |
generate_image | Media | Request one bounded, approval-gated image generation operation. | Approval-gated |
The registry is intentionally explicit. It gives the runtime something it can validate, authorize, log, test, and explain. It also gives the user a way to understand why Genesis can inspect a repository, make a patch, run a test, or check a service without being an unrestricted shell process.
Reading and repository intelligence
The read and intelligence families are how Genesis builds an accurate mental model before acting. Basic file reads and searches are complemented by repository trees, outlines, symbol definitions, references, dependency relationships, language-server status, diagnostics, related implementations, similar files, and semantic search explanations.
Index freshness matters. Genesis can report whether its repository index is ready and how current it is; search results should not be treated as complete if the index is stale or the workspace changed underneath it. The intended workflow is to use cheap structural inspection first, then open the smallest set of source files needed to understand the active path and its consumers.
Diagnostics are evidence, not decoration. Workspace diagnostics find broad issues; changed-file diagnostics focus on the current task. Failure mapping connects test output to likely owners so the next inspection step can move upstream toward the cause instead of applying a downstream visual patch.
Mutation and file changes
Genesis has several mutation tools because different changes need different levels of structure. A direct file write is useful for a complete bounded file. A structured patch preserves hunk intent. A unified patch is useful when an external diff is already the clearest representation. A codemod is for a deliberately constrained mechanical replacement. Move and delete are separate capabilities because their effect is more consequential than reading or editing text.
The mutation path validates paths against the active workspace, checks policy and permission, serializes writers where required, and records the resulting change. For collaborative safety, a save can include an expected base hash so a stale editor does not silently overwrite a newer file. The user-visible code panel can show save state, diagnostics, and the agent read cursor rather than implying that every typed character is already committed.
“Auto-safe” does not mean “anything is safe.” It means the run policy has explicitly classified the proposed effect as allowed within its scope. Deleting a path, changing an environment file, mutating outside the workspace, or altering a protected boundary should remain blocked or approval-gated according to policy.
Commands and services
run_command is a typed process request, not a free-form text escape hatch. Its contract can describe an executable identity, argument vector, working directory, environment policy, network setting, resource limits, stdin behavior, timeout, expected exit code, purpose, and success criteria. The ProcessExecutor owns actual launch, output capture, timeout, termination, and terminal classification.
Service tools keep declared services separate from arbitrary process invention. Genesis can list a service, start it, stop it, restart it, inspect health, and read bounded logs when the service is part of the active workspace configuration. This is useful for checking a frontend, backend, worker, or local API, but it does not make every process on the computer part of the workspace.
A service health response should include enough context to be useful: service identity, process state, port, working directory, last verified URL or endpoint, health result, and freshness. “Port open” is not automatically “application healthy”; the health contract and runtime evidence are what matter.
Git facts, worktrees, and review
Genesis includes read-only review capabilities for repositories where that is authorized. Git facts can describe source state; review tools can examine a workspace diff, commit, or base comparison. Worktree tools provide a task-scoped preparation, status, and cleanup lifecycle when the execution environment uses a separate checkout.
Review is evidence, not a substitute for tests. It catches accidental edits, missing files, stale aliases, scope creep, and changes that are syntactically valid but outside the requested behavior. A run can require internal read-only review before CompletionController commits the final state.
This Website report does not perform or promise any source-control operation. It documents Genesis’s product capability and the boundaries around it; actual repository operations remain subject to the active task’s permissions and operating instructions.
Verification tools
Verification starts by discovering the project’s own commands and conventions. Genesis can detect test commands, plan a verification set, run focused tests, run related tests, run type checks, compile or build, parse failures, and map those failures to likely files. The goal is proportional breadth: narrow evidence first, then broader checks based on the changed boundary.
A good verification plan separates source correctness from runtime availability. A unit test can prove a function’s behavior. A type check can prove contract compatibility. A build can prove bundling. A service health probe can prove a local process is responding. A browser check can prove a user-visible route. None of these should be silently substituted for a different check just because the first one is inconvenient.
Required acceptance conditions remain authoritative. If a mandatory condition says a test, build, or browser state must be verified, CompletionController should record a blocked or failed outcome when that proof is unavailable instead of downgrading the requirement behind a green status.
Browser, web, and image tools
Network-capable tools are deliberately separate from repository reads and writes. browser_verifyis intended for approval-gated, bounded verification of a browser-visible local surface. It should not be used as a hidden login mechanism or as a way to bypass the user’s knowledge of an external action.
web_search is a read-only, approval-gated research capability through the configured provider path. The current Genesis documentation describes a fixed Brave search endpoint and does not treat web search as an unrestricted connector system. Search results are external observations and must be kept distinct from repository evidence.
generate_image is an approval-gated media operation with a bounded low-cost 1024×1024 request. It is not a hidden background image pipeline and does not grant the agent unrestricted media generation. The run should record the request and resulting artifact metadata as part of its evidence.
Workspace and file safety
Workspace safety begins with path resolution. A requested file must resolve inside the active workspace and must not escape through traversal, symlinks, ambiguous roots, or a stale workspace identity. The safe owner is the workspace manager and mutation layer, not the model’s string formatting.
File changes should be atomic where possible, attributable to the current run, and reviewable as a diff. Hash-aware saves prevent stale editors from replacing newer content. The system records enough information to explain what changed, which tool changed it, and what verification ran afterward. Undo and recovery should operate from recorded mutation history rather than from a model’s memory of its last answer.
Secrets are a separate data classification. Genesis should avoid copying credentials into prompts, logs, generated reports, or event payloads. A repository containing secrets is not automatically safe for every provider or every tool. Permissions and classification must narrow the run accordingly.
Process safety and containment
The process boundary is explicit, but the repository’s current truth is nuanced. The intended design uses a controlled ProcessExecutor, declared executable identities, bounded arguments, resource and timeout limits, output capture, and workspace-aware working directories. The desktop runner is a separate product mode and must not silently fall back to the browser runner or a remote sandbox.
Current Genesis documentation also records limitations: native Windows strong-containment proof is not yet complete, and the controlled Docker mutation proof must remain current before it is treated as a release gate. Those are important operational facts. The product should report them as limitations rather than presenting a stronger security guarantee than the evidence supports.
Service start, stop, restart, command execution, and desktop packaging all belong to this boundary. They need environment-specific tests, clear rollback behavior, and exact runtime evidence. A successful model plan or a generated command is never proof that the process actually ran safely.
The frontend experience
The frontend is a Next.js workspace shell around the Genesis contracts. It can run in its local browser mode, in an embedded Infinity context, or through the separate desktop experience. The UI changes its arrangement for those contexts, but the underlying run contract remains the same. The frontend should project facts from the backend rather than fork lifecycle logic into client-only state.
The main navigation includes New Chat, Code, Home, Layout, Schedule, quick actions, and Download app. Layout choices can place work progress and service status beside the code or put chat and run statistics in a right-side workspace. These are presentation choices. They do not create separate run engines or change which controller owns completion.
Loading, empty, partial, success, blocked, failed, cancelled, and recovery states all matter. A skeleton should not look like a completed result, a model progress message should not look like terminal truth, and a stale event stream should not overwrite newer durable state. The UI is strongest when its visual language makes those distinctions obvious.
Chat versus Run
Chat is for conversation, questions, context gathering, and planning. A run is for an explicit executable objective with a contract, permissions, acceptance conditions, and verification. The same workspace can contain both, but they should not be conflated. Sending a message does not automatically grant write access, and asking for a change does not remove the need to verify it.
The task thread gives the conversation continuity. The run ID gives execution continuity. Attachments can add context, but the backend still needs to record what was attached and what data classification applies. A chat can remain useful even when execution is blocked; a blocked run should not be disguised as a helpful chat response that implies the change happened.
This separation also improves cost control. The user can discuss a design, inspect a repository, or ask for a plan without reserving the budget required for mutation and verification. When the user is ready, the run request can make the intended effect explicit.
Repository explorer and editor
The Code panel presents a repository explorer, open-file tabs, plain and syntax-aware views, an edit area, save state, and diagnostics. It is designed for informed editing: find the file, understand its neighboring contracts, make a bounded change, then verify and review it.
When an AGENTS.md or equivalent local instruction file is missing, the product can expose the need to create one as an explicit action. That is preferable to silently inventing repository policy. The same principle applies to file saves: the user should be able to see whether a save is pending, accepted, rejected because of a base mismatch, or awaiting a run permission.
The editor is not an alternate source of truth. Backend persistence, mutation records, run events, and verification evidence remain authoritative. If the browser reconnects, it should reconcile against that durable state rather than assume its local textarea is the final repository content.
Services and runtime health
Genesis can understand declared services associated with a workspace. The service panel is intended to show backend and frontend health, process IDs where available, ports, working directories, last verified URLs, freshness, logs, and lifecycle controls. This turns a multi-service development environment into something the run can inspect and report.
Health is layered. A process can exist but fail its health route. A health route can respond while a required database is unavailable. A frontend can render while a backend mutation route is unhealthy. Genesis should preserve those distinctions in its evidence and avoid reducing a layered failure to a single “online” badge.
Starting or restarting services is a process effect and should remain scoped to declared services. The run needs exact service identity and a reason for the operation; it should not terminate unrelated user processes just because a port is occupied.
Schedules, attachments, and history
The Schedule panel is for workspace messages that should be sent at a chosen time. It stores repository, chat, message, and send-time context, and it provides removal controls. A schedule is not the same as a background autonomous run; an executable run still needs its own request, permissions, budget, and evidence.
Attachments let a task carry supporting files into the conversation or run. The attachment ID belongs in the request contract so the backend can apply retention, classification, and access checks consistently. The user should be able to understand which attachments informed a run and whether any were unavailable.
Chat history, repository history, run history, and event history answer different questions. Chat history explains the conversation. Repository history explains source state. Run history explains attempted work. Event history explains the ordered operational facts. Keeping those layers distinct is what makes debugging and recovery credible.
Verification and terminal truth
Genesis must distinguish four kinds of truth: model-authored explanation, tool observation, process outcome, and durable terminal commitment. A message that says “I fixed it” is an explanation. A patch result is a tool observation. A test exit code is a process outcome. A succeeded terminal state is a commitment made only after the completion rules are satisfied.
| Outcome | Meaning |
|---|---|
succeeded_verified | The requested work completed and required verification passed. |
partial_verified | A bounded result is available, but the contract records that only part of the requested scope was verified. |
blocked_approval | Progress requires a user or operator approval that was not granted. |
blocked_budget | The run reached a configured token, cost, call, retry, or time limit. |
blocked_environment | A required local service, dependency, workspace, or provider is unavailable. |
blocked_policy | The requested operation is outside the run’s permissions or safety policy. |
failed_runtime | An execution component failed and recovery did not establish a valid continuation. |
cancelled | The run was explicitly cancelled before completion. |
interrupted | Execution stopped before a terminal result was safely committed. |
unknown_after_crash | The runtime cannot prove what happened after a crash and requires inspection or recovery. |
This is why a missing service, unavailable database, failed test, exhausted budget, denied approval, or unknown post-crash state should remain visible. A truthful blocked result is more useful than a polished false success because it tells the user what evidence is missing and what must happen next.
Recovery and interruption
Recovery is designed around durable state. On restart, the recovery coordinator can inspect runs that were left active, determine whether the last event and process outcome are known, and decide whether safe resume preconditions exist. If they do not, the run should become interrupted or unknown-after-crash rather than guessing.
User controls include pause, cancel, resume, retry, approval, clarification, and undo where the relevant state permits them. Resume continues a known run from durable facts. Retry is a new attempt within the run’s budget and should preserve why it was needed. Clarification changes the missing input. Approval changes the authorization state. Undo reverses a recorded mutation where the system has enough evidence to do so safely.
Recovery must also protect against duplicate work. Idempotent request handling, ordered event cursors, attempt records, and mutation hashes help prevent a lost browser response from launching a second copy of a write or test operation.
Desktop Genesis
Desktop Genesis is a separate Windows product mode, not a browser tab with extra permissions. It uses a desktop-scoped runner, desktop workspace bindings, update and installer behavior, and a packagedgenesis-runner.exe built from the runner source. The desktop mode identifies itself withclient_mode=desktop so the backend can apply the correct contract.
The desktop runner must not silently fall back to the browser runner or a remote sandbox. If the desktop execution requirement is unavailable, the user should see that it is unavailable. Installer signing, containment proof, and desktop integration tests are release requirements rather than optional polish.
This report documents both modes so the boundary is clear. It does not change the desktop app, browser app, embedded version, or their layout. Device choice changes the execution boundary; it does not create a second product promise.
Deployment and operations
The documented production topology places Genesis behind the Infinity integration boundary with a Genesis tool service and a Genesis backend service. The backend uses a durable data volume for runtime state and keeps server-to-server credentials away from the browser. The route and service names are operational deployment facts, not links this document uses to launch the product.
Production readiness is more than a successful build. It includes compile and quality gates, frontend lint and type checks, smoke coverage, durable storage, model credential and budget configuration, controlled provider tests, service health, and user access or tenant-isolation proof. Current repository documentation records that some of those gates remain environment-dependent, especially model enablement, native Windows containment, Docker mutation proof, and multi-user authorization.
Operational evidence should be current. Historical deployment records can explain how a system was once released, but they do not prove that today’s service is healthy. Genesis’s own status and verification model follows the same rule: current evidence beats a remembered success.
Security, privacy, and permissions
Genesis treats security as a chain of boundaries: authenticated backend requests, workspace identity, path containment, typed tool admission, effect classification, approvals, process controls, data classification, provider policy, durable evidence, and recovery. A weakness in one layer should not be hidden by claiming that another layer handled it.
The browser should not receive server-only backend tokens. Logs and events should avoid secrets and should preserve enough metadata for debugging without copying sensitive content. Restricted or secrets-present data should narrow model and network choices. Web search and browser verification should be explicit, bounded, and approval-gated rather than silently occurring as a side effect of a coding request.
Permission names are part of the user promise. Read-only means no source mutation. Inspect-only means the run can understand but not edit. Write-with-approval means a user decision remains in the path. Safe auto-write is limited by the policy’s safe set. Operator-full is an administrative capability and should not be treated as the default browser experience.
Recommended workflows
Understand a repository
Start with an inspect-only request. Ask Genesis to map the repository, identify the canonical owner, find tests and deployment surfaces, and report unknowns. This creates useful context without prematurely writing files.
Make a focused change
State the target behavior, affected scope, acceptance conditions, and whether extra changes are allowed. Let Genesis inspect first, implement through typed mutations, run focused checks, then run related checks based on the blast radius. Review the diff before accepting completion.
Diagnose a failure
Provide the exact failure and environment. Ask for failure parsing, owner mapping, diagnostics, and a reproduction plan. Keep the first run read-only when the cause is unclear. Only authorize mutation after the evidence identifies a plausible owner.
Operate a local service
Use declared service health and logs first. If a restart is necessary, identify the exact service and record the reason. After the process action, verify the health endpoint and user-visible route separately.
Troubleshooting
If Genesis cannot start a run, check the request contract, workspace readiness, backend health, model configuration, and budget before retrying. A missing model credential is a provider configuration problem; it is not fixed by changing the frontend spinner.
If a run appears stuck, compare the latest durable event with the stream connection and process health. If the stream is stale but the backend has advanced, replay from the event cursor. If the process outcome is unknown, do not start a second mutation until recovery establishes whether the first one ran.
If tests fail, preserve the exact output, parse and map the failure, inspect the responsible owner, and rerun the narrow check after the root-cause fix. Do not replace a failing required check with an unrelated green check. If a local dependency or service is unavailable, record a blocked environment outcome.
If the browser and desktop show different capabilities, check client_mode, workspace binding, runner identity, and service policy. The desktop mode is intentionally not a silent fallback for browser mode, and browser mode is not proof of desktop containment.
What Genesis is not
- It is not an unrestricted shell or a hidden computer-control agent.
- It is not a public plugin marketplace or an arbitrary connector platform.
- It is not a second chat-only lane that can claim code work without a run.
- It is not a guarantee that every provider, database, container, or Windows containment mode is available.
- It is not a replacement for tests, type checks, builds, review, or runtime evidence.
- It is not the same thing as Infinity, Manifest, Platform, or the other specialist tools.
- It is not allowed to turn an uncertain post-crash state into a made-up success.
These boundaries make Genesis more trustworthy. A focused system can state what it knows, what it changed, what it verified, and what remains blocked. That is more useful for real repository work than a broad promise that collapses every capability into one opaque assistant.
Product direction
Genesis’s direction is to make software work more legible and more dependable: faster repository indexing, clearer run projections, stronger verification planning, better recovery, safer process boundaries, and more useful evidence at the end of a task. The goal is not to make the UI look busy or to add autonomous surface area without proof. The goal is to reduce the distance between an objective and a verified, reviewable result.
The next improvements should preserve the canonical architecture: one run lifecycle owner, one AgentLoop, one model gateway, one tool runtime, one process executor, one completion controller, one durable event ledger, and one frontend projection path. New capability should enter through typed contracts, explicit effect classes, focused tests, broader boundary verification, and current operational evidence.
For the wider TronXVI product map, the Website also provides documentation-only pages for Infinity,Platform, and TRON. Those pages explain their own products; this Genesis document remains focused on the coding-agent workspace and does not launch any of them.