Infinity is the unified TronXVI workspace for conversation, creation, development, research, and everyday work.

What Infinity is

Infinity is the main TronXVI workspace shell. It is the product layer that keeps the navigation model, active workspace, account entry point, theme preferences, and native conversation experiences together. A person can move from a general question to a research task, from a document to a presentation, or from a project brief to a coding run without opening a separate top-level product every time.

The word “unified” describes the shell and the user journey, not a claim that every capability is built from one codebase. Infinity contains native React surfaces and route-mounted specialist tools. Those tools retain their own domain logic, tests, persistence choices, and provider requirements. Infinity supplies the common frame and loading boundary while each tool remains responsible for the work it understands best.

Infinity is therefore best understood as three things at once: a launcher for focused tools, a conversation workspace for model-assisted work, and an account-aware shell for the wider TronXVI product system. The sidebar is the map; the active workspace is the current room; the services behind that room determine what can happen inside it.

The Infinity mental model

One shell, several kinds of surface

A native surface is rendered by the Infinity frontend itself. General Chat, Companion, Group Chat, and Notes are examples. They can share shell state directly, respond to the shell’s theme, and participate in the shell’s navigation without an embedded document boundary.

An embedded surface is a specialist workspace mounted at a dedicated route. Manifest, Genesis, Inbox, Research, Template, Document, PowerPoint, Calendar, Matrix, Testing, Education, Articulate, Polyglot, Platform, CARFINDER, and Marketplace are examples. Selecting one tells the shell which route to mount and which workspace to make active. The tool owns its internal controls; the shell owns selection and context.

Active does not mean everything is loaded

Infinity keeps the initial shell focused on the active surface. The specialist workspaces are not all competing for network, JavaScript, memory, and provider work during the first paint. A workspace can be prepared when intent is clear and kept warm within a bounded cache, but the product’s loading strategy is still selection-led: the tool you choose gets priority.

Shared frame, separate responsibility

The shell can provide a common visual language, account affordances, and appearance variables while still allowing a spreadsheet to behave like a spreadsheet and a slide editor to behave like a slide editor. The shared boundary is intentionally narrow. It synchronizes what needs to be shared and leaves specialized behavior with the specialist tool.

The shell and navigation

The left navigation

The left navigation is the stable orientation layer. It exposes the main tools in a predictable order and gives each tool a recognizable label and icon. General Chat, Notes, Research, Group Chat, Manifest, Platform, Genesis, Inbox, Template, Document, PowerPoint, Calendar, Matrix, Testing, Education, Polyglot, Articulate, Marketplace, CARFINDER, and Companion are all first-class sidebar destinations.

The sidebar can be expanded for labels or collapsed into an icon rail when the workspace needs more room. On narrow screens the same navigation becomes a compact control surface. The intent is not to create a second mobile product; it is to preserve the same tool map while changing how much chrome is visible.

Active state and deep links

A selected tool is represented as an active surface. Infinity can restore a stored surface and can interpret a requested surface from the URL, including route names such as ?surface=research or?surface=genesis. Legacy aliases are normalized at the shell boundary so a historical name can still resolve to the current tool without creating a duplicate product surface.

Account and shell controls

The account entry point is separate from the tool list. It is where profile identity, plan information, settings, Status, Leaderboard, and support-oriented controls can be reached. The shell also exposes search, sidebar customization, appearance options, and workspace controls where the current signed-in state allows them.

Split-screen and reduced-width behavior

Infinity’s navigation is designed to remain useful when the browser is narrow or split beside another application. Icons retain their center alignment in the compact rail, labels can disappear without changing tool order, and the active workspace receives the remaining width. A narrow viewport should change density, not change which tool the user selected.

Initialization, loading, and routing

What happens on first load

1. The Infinity shell loads its layout, navigation, identity state, and theme state.
2. The shell resolves the requested or remembered active surface.
3. Native surfaces render directly inside the shell.
4. Embedded tools mount only when their surface becomes active or an intentional preload signal is present.
5. The selected tool then performs its own API, asset, and provider initialization.

This sequence matters because a specialist tool can be large even when its first screen looks simple. A document editor, spreadsheet, presentation editor, or research workspace may need substantial code and data before it can become interactive. Deferring those surfaces keeps the shell responsive and prevents tools the user did not request from slowing down the first decision.

Intent-based preparation

A pointer approaching a tool, a keyboard focus entering its control, or a deliberate navigation action can give Infinity an early signal that a workspace is likely to be used. That signal may prepare the next tool, but it does not replace the active-selection rule. The active tool remains the priority and the warm cache is bounded so that preparation cannot grow without limit.

Embedded route inventory

These route names describe the internal workspace boundary. They are not a promise that each tool has the same service topology. Some are static or browser-led, some call an API, and some use a separate deployed service behind the route. The route is the shell’s address for the tool; the tool’s own documentation and readiness state determine what is available after it opens.

General Chat

General Chat is the everyday entry point. It is designed for questions, planning, drafting, explanation, quick help, and work that does not yet belong to a specialist editor. Its configuration describes it as the place for everyday questions, planning, and ideas, which makes it the right starting point when the desired outcome is still being shaped.

Conversation controls

General Chat exposes model and effort choices. The current model choices are Mini, Scout, Atlas, and Sentinel; the effort choices are Instant and Normal. These controls let a person trade response speed and depth according to the task rather than treating every question as if it needs the same amount of work.

A conversation can include text, attachments, markdown, code, and generated artifacts. The composer can also expose image and video generation controls when the account and provider path support them. A generated result belongs to the current conversation context and should be treated as an artifact to inspect, revise, or save rather than as proof that an external action has happened.

Research and connected context

General Chat can use a research-oriented mode and connector context. GitHub is represented as the live project-context connector. Vercel, Netlify, Cloudflare, Hugging Face, Google Drive, Google Docs, Notion, and Gmail are represented as manual or user-provided connection paths. “Available in the interface” does not mean every provider is automatically authenticated; a connector must still be configured and authorized.

Streaming and state

Replies are streamed so the user can see progress before the full answer is complete. Threads, active projects, attachments, web-search preferences, and general chat settings are persisted through the shell’s browser-side state contracts where appropriate. A refresh should restore useful local context, but it should not be interpreted as a guarantee that a provider-side operation can be resumed.

Companion

Companion is the focused assistant surface inside Infinity. It is separate from General Chat so that an assistant-oriented interaction can have its own controls and identity without changing the general-purpose conversation surface.

Use Companion when the task is about guided assistance, a focused instruction set, or a smaller assistant context. Use General Chat when the task is open-ended and may need broad model, attachment, media, research, or connector controls. The distinction is about workspace intent, not a promise that one surface is always more capable than the other.

Companion is account-aware. If the current identity or configuration cannot provide its required assistant context, Infinity should make that state visible rather than presenting a successful-looking answer from an unrelated fallback path.

Group Chat

Group Chat is the shared-conversation surface. It exists for work that benefits from more than one voice, role, or participant context. The shell keeps Group Chat distinct from General Chat so that shared discussion can have its own thread and participant model without making every everyday conversation collaborative by default.

When to use it

• Use it when a discussion needs several participants or perspectives in one workspace.
• Use General Chat when one person is asking for a direct answer or drafting help.
• Use a specialist editor when the conversation has matured into a document, deck, sheet, or test.

Group Chat is a conversation surface, not a replacement for project permissions or a general-purpose team directory. Access, identity, and any provider-backed action remain governed by the current account and the service that owns the action.

Notes

Notes is the lightweight writing surface for quick capture. It supports multiple notes, note tabs, a title, editable content, creation of a new note, and closing the notes surface. The current native implementation restores notes in the browser and writes changes back to browser storage, which makes it useful for local scratch work and persistent short-form context.

Notes can be moved within the window by its drag handle, and its active note is retained as part of the local notes state. This is intentionally smaller than Document: Notes is for fast capture and lightweight editing; Document is for page-oriented writing and document production.

Because Notes is local browser state, do not treat it as a server-backed archive or as a synchronized team record unless a future version explicitly adds that capability. Back up or export important material before clearing browser data or changing profiles.

Manifest

Manifest is the media-generation workspace. Its primary flow is to describe a visual idea and generate a fresh image or video while controlling the shape of the output. The workspace has a central creation area and a settings rail for media type, reference guidance, aspect ratio, and generation options.

Image and video work

The media switch distinguishes Image from Video. An image request is a still visual; a video request is a time-based generation. The available video duration choices are 4 seconds, 8 seconds, and 12 seconds. The platform presets cover common destinations such as TikTok, Instagram, YouTube Shorts, Snapchat, YouTube, Facebook, X, and LinkedIn, with Auto available when a destination should not determine the ratio.

The current video model choices include Sora 2 at 720p and Sora 2 Pro at 1024p or 1080p. These are provider-backed generation choices, not a guarantee that a request will complete without credentials, quota, policy checks, or service availability.

Reference guidance and prompt discipline

A reference image can guide the final look. The prompt should describe the subject, composition, movement, mood, lighting, typography, and intended audience as clearly as possible. A reference guides a generation; it does not automatically grant rights to use the image or the people depicted in it.

Manifest is separate from General Chat’s media controls. General Chat can help develop a brief or prompt; Manifest is the focused creation surface where media-specific choices are visible.

Platform

Platform is the developer workspace. It is where a developer can understand the TronXVI API surface, create and inspect projects, manage developer keys, use a playground, review billing, and read documentation.

Typical developer path

1. Open the dashboard and identify the project that will own the integration.
2. Create or review an API key using the project’s access rules.
3. Use the playground to understand the request and response shape.
4. Read the docs before copying a request into an application.
5. Review usage and billing before moving a prototype into a production workflow.

API keys are credentials. Do not place them in client-side code, screenshots, public repositories, prompts, or shared notes. Platform is a tool for managing developer access; it is not a reason to expose a key to the Infinity shell or to an embedded tool that does not need it.

For the broader developer explanation, read the Website’s Developer guide. That guide is separate from the Platform workspace and explains the public developer story without opening a live app surface.

Genesis

Genesis is the coding-agent workspace. It is designed for controlled repository work rather than casual chat. Its public run-control family is the versioned work.run.request.v1 flow, and its retained execution path moves through a RunController, agent loop, model gateway, tool runtime, process executor, verification and review, then a completion controller.

What a Genesis run means

A run is an attempt to perform a defined coding task under policy and verification boundaries. The workspace can present the repository context, chat transcript, files, terminal state, run history, budget controls, schedule controls, review state, and terminal truth. A completed run should have a clear terminal decision; an interrupted or unverified run should remain visibly different from a successful one.

What Genesis is not

Genesis is not a public multi-user coding service, a plugin marketplace, a cloud delegation layer, or a promise that every repository mutation is safe to apply automatically. Provider credentials, authorization, tenant isolation, process containment, and controlled execution still matter. A visible interface cannot turn an unavailable provider or an unverified mutation into a successful run.

Use Genesis when the desired output is repository work with evidence. Use General Chat to discuss an idea before it becomes a coding run, and use Document or Notes when the desired output is writing rather than a changed codebase.

Inbox

Inbox is the mail workspace. Its main view is organized around mailbox navigation and three message states: Unread, Opened, and Sent. It also exposes the familiar mail actions Inbox, Compose, Unread, Starred, Snoozed, Sent, Drafts, Spam, and Trash, with search, filtering, and a message-type selector at the top.

Mail workflow

1. Open Inbox to review the current mailbox state.
2. Use search or filters to narrow the visible messages.
3. Open a message to move from an unopened list state into the opened view.
4. Compose a message when a new outbound draft is needed.
5. Use Drafts, Sent, Starred, Snoozed, Spam, or Trash for the message lifecycle.

Inbox has compatibility paths for external mail connection concepts, but the presence of a Google or Microsoft label does not mean those accounts are automatically connected. Provider scopes, authorization, mailbox availability, and the current TRON mail service determine whether messages can be loaded.

Treat mail as sensitive. Do not paste credentials into the composer, do not assume a failed provider connection means a message was sent, and verify the Sent state before relying on a delivery action.

Research

Research is the evidence-oriented workspace. It turns a question into a retrieval and synthesis task and keeps the difference between a source, an extracted result, and a written explanation visible.

Research tiers

The current research service describes Light, Balanced, and Best tiers. These tiers map to different model and provider paths, including a lighter model, a balanced deep-research path, and a best-available deep- research path. The exact result depends on provider configuration and the request’s mode.

Source-grounded work

A strong Research workflow states the question, retrieves relevant material, checks source metadata and dates, separates evidence from inference, and then writes a synthesis. If the backend is not ready because provider credentials are missing, the correct state is not-ready or unavailable; Infinity should not imply that a live research result was produced.

Research is different from General Chat web search. General Chat is the broad conversational surface; Research is the place for a more explicit evidence and explanation workflow.

Template

Template is the design and template workspace. Its gallery helps a person discover templates, search the library, and move into a creation flow. Its editor places the working canvas in the center and the template library and tool controls in the right-side workspace where the design can be shaped without sending the user to a separate bottom-of-page template area.

Gallery and editor

The gallery is for browsing and selecting a starting point. The editor is for changing the selected design, adding pages, using templates and elements, editing text, managing brand or upload material, and using the available design tools. A blank design can be created when a template is not the right starting point.

Template projects can be saved in the browser when the local design path is used, and the workspace also has backend project routes for supported project operations. The visible UI should make the difference clear: a browser-saved design is not the same thing as a server-persisted team project.

Design boundaries

Template is not Document, even though both can contain text. Template is composition-first and canvas-first; Document is page-first and writing-first. Template is also not a guarantee of professional print, brand, or licensing clearance. Review uploaded assets, fonts, and third-party template content before publishing.

Document

Document is the writing and page-layout workspace. It is intended for structured documents where page shape, text flow, headings, editing, and document-oriented artifacts matter more than a free-form design canvas.

When Document is the right tool

• Use it for reports, letters, briefs, structured notes, and page-oriented writing.
• Use it when the output should read as a document rather than a poster or a slide.
• Use Template when visual composition and reusable design starting points are the primary need.
• Use PowerPoint when the output is a sequence of presentation slides.

A document workspace should preserve the distinction between the editor surface and the paper-like page. The page is the authored artifact; surrounding controls are editing chrome. Saving, exporting, or sharing a document should not be confused with simply changing the current browser state.

PowerPoint

PowerPoint is the presentation editor. It is built around a canonical presentation model, command and history behavior, persistence, and compatibility-oriented import and export. It supports presentation formats in the PowerPoint and OOXML family, including PPTX, PPTM, PPSX, PPSM, POTX, POTM, and THMX targets where the current capability path supports them.

Presentation workflow

1. Start with a new deck or open an imported presentation.
2. Build the slide sequence and establish a clear visual hierarchy.
3. Edit slide content through the presentation model and command history.
4. Review the deck in presentation order, not only one slide at a time.
5. Export to the required format and inspect the result in a compatible viewer.

Compatibility is a boundary, not a universal promise. Complex third-party extensions, unsupported OOXML parts, fonts, media codecs, and advanced PowerPoint-only behavior may not round-trip perfectly. Keep a copy of the original file when importing important work and verify the exported deck before distribution.

Calendar

Calendar is the scheduling workspace. It presents calendars and events and provides the basic event lifecycle: read calendars, read events, create an event, update an event, and delete an event.

Event lifecycle

A calendar event is not merely a card on screen. It has an owner, a time range, a calendar context, and a persistence path. Creating or editing an event should be treated as a write operation; the useful success state is the confirmed saved event, not the optimistic form state before the service responds.

If Calendar cannot reach its API, the correct experience is an explicit unavailable or not-ready state. Avoid entering the same event repeatedly while waiting for a response, and verify the event after a retry when the service becomes available again.

Matrix

Matrix is the spreadsheet workspace. It is designed around a green-and-white sheet interface, a right-side control area, and spreadsheet operations that work in the browser or local application boundary rather than requiring a cloud account for every action.

Core spreadsheet work

The current capability set includes direct cell editing, a formula bar, range selection, fill, copy and paste, row and column insertion/deletion/hiding/freezing, worksheets, undo and redo, formulas, dynamic arrays, LET, a function helper, precedent and dependent tracing, number formats, conditional formatting, tables, sorting, filtering, duplicate removal, data validation, charts, sparklines, Goal Seek, notes, hyperlinks, protection, find and replace, print, and CSV/XLSX import and export.

Compatibility expectations

Matrix is not a promise to implement the entire Microsoft Excel product. The current limits include a selected function set rather than the full function catalogue, no full LAMBDA or external-workbook system, basic charts rather than every advanced chart family, a local pivot-style summary rather than every pivot feature, and no Power Query/database refresh, slicers, PivotCharts, maps, or icon sets in the documented capability boundary.

When exchanging files, import a copy, inspect formulas and formats, and verify the exported workbook in the destination application. Spreadsheet compatibility should be judged by the calculation and layout you need, not only by whether a file downloaded successfully.

Testing

Testing is the test-builder and practice workspace. It supports a flow from a creation brief through policy checks, blueprint generation, question generation, validation and repair, persistence, preview, test taking, grading, reports, and skill progress.

Creation to report

1. Describe the test or choose a built-in test.
2. Let the generation path create and validate a blueprint and question set.
3. Preview the result before making it available for practice.
4. Take the test and submit an attempt.
5. Review deterministic or rubric-based grading, the report, and skill updates.

Generated tests can be stored in a local store, Postgres, or a hybrid mode depending on configuration. A browser draft and an in-progress taking session are different from a saved generated test. If a service or database is unavailable, check whether the current storage mode permits local work before assuming the test has been lost.

Education

Education is the school workspace. Its subject areas include Language & Literature, Mathematics, Sciences, Humanities / Individuals & Societies, Language Acquisition, The Arts, Health & PE, and Design & Technology. It also includes schedule, lesson, and lesson-builder concepts.

Learning workflow

A learner or educator can move from a subject to a topic, from a topic to a lesson, and from a lesson to a scheduled learning plan. A lesson builder is the creation path; a lesson page is the delivery or reading path; the schedule is the planning path. Keeping those paths distinct makes it easier to understand whether a change is drafting content or committing a teaching plan.

Education may depend on provider configuration for model-backed generation or other live capabilities. A visually complete lesson builder does not imply that every generation provider is configured. Look for the tool’s actual ready, unavailable, and saved states.

Articulate

Articulate is the focused communication workspace. It is designed to turn a piece of communication into a clear assessment and an actionable improvement path. Its current product language emphasizes reading what was done well, identifying the next small steps, and making progress visible.

Assessment and improvement

A typical flow is to provide a written or spoken sample, let the tool assess the sample, read the feedback, and use the resulting improvement plan or recent activity to guide the next attempt. The aim is not merely a score; it is a readable explanation of what to improve and how to practice it.

Because speech and written samples can contain personal information, review what is submitted and how the current provider path handles it. Articulate should be treated as an assessment workspace, not as a public publishing destination by default.

Polyglot

Polyglot is the language-learning workspace. It begins with language discovery and course setup, then moves through a learning roadmap: Welcome, Lesson 1, Lesson 2, Lesson 3, and Lesson 4. The course setup includes a level choice such as Beginner, Intermediate, Pro, or Expert and a session size for the available tasks.

Lesson modes

Lessons can be in Learn or Test mode. Learn mode can show an answer example and hint; Test mode asks the learner to provide an answer for review. The workspace supports typed answers, feedback, correction and transcript details where available, and a voice-answer path that can be started and stopped from the lesson.

Saved courses and completion state belong to the learning workflow. A course being visible in the browser is not the same as a provider-backed lesson being generated successfully; check the lesson and feedback state after each request.

CARFINDER

CARFINDER is the vehicle discovery workspace. It organizes vehicle inventory into a searchable experience so a person can browse categories, inspect listings, and narrow a decision by the characteristics that matter to them.

Its asset and category model includes common groups such as hatch, sedan, coupe, convertible, SUV, wagon, ute, off-road 4x4, performance, hybrid, EV, and new cars. The exact inventory is a data concern: a category label or image does not mean that the corresponding stock is current, available, or located near the user.

Responsible vehicle research

Use CARFINDER to discover and compare possibilities, then verify price, condition, availability, financing, ownership history, and seller details through the appropriate listing or seller process. Treat inventory data as time-sensitive and do not rely on a cached card as a binding offer.

Marketplace

Marketplace is the product catalogue and discovery workspace. Its catalogue engine is source-driven: approved retailer sources provide explicit product-page URLs, the service reads product metadata, normalizes the result, and publishes an atomic JSON snapshot. It does not guess product URLs or expose a product merely because a crawler happened to find a page.

Browsing and catalogue boundaries

The interface supports product search, categories, region and currency selection, saved items, filters, product detail, product media, specifications, variants, reviews, and pagination or catalogue navigation. A product card is a discovery record. It is not a purchase confirmation, inventory guarantee, price lock, or endorsement of the retailer.

The backend uses a local JSON cache and a synchronization state so the public catalogue can remain available between source refreshes. If synchronization fails, the last valid snapshot may still be useful, but its publication timestamp and source state matter when making a time-sensitive decision.

Follow the destination’s purchase and return terms before buying. Marketplace’s role is to present approved catalogue information and a safe route to the intended product page, not to silently perform a purchase.

Account and settings

Account is the identity and preference surface around the workspace. It can show the current profile, plan, email, password-management state, and account actions. It is also the natural home for appearance settings, billing, usage, support, and service-related links.

Profile and plan

Profile information belongs to the account context rather than to one tool. A plan label describes the current account tier; it does not automatically guarantee that every provider-backed tool is enabled or that every quota is unlimited. Provider, tool, and plan checks can still produce a not-ready state.

Appearance and customization

Appearance is limited to Grey, White, and Black. Accent is a separate preference with its own palette. These preferences are shell state that can be bridged to embedded tools through shared theme variables. A tool can retain specialized content styling while its surrounding chrome follows the shell’s appearance.

Billing, usage, and support

Billing and usage are account-level concerns. Read the relevant plan and provider information before assuming a generation, research, or integration action is included. Support is the right path when an account or service problem cannot be explained by a tool’s visible readiness state.

Status and Leaderboard

Status and Leaderboard are service-awareness surfaces associated with the account and wider TronXVI system. Status helps distinguish a local UI problem from a provider or deployment incident. Leaderboard presents the current ranking data when that service is available and authorized to return it.

How to use Status

Check Status when several tools fail at once, when a previously healthy provider becomes unavailable, or when a deployment appears to have changed behavior. A shell that loads successfully can still contain a tool whose backend is down; status information helps separate those layers.

How to interpret Leaderboard

Leaderboard is live service data, not a static decoration. Rankings, avatars, scores, and refresh timing are determined by the leaderboard service. If its endpoint is unavailable, the correct experience is an empty, loading, or unavailable state rather than fabricated rankings.

Data and boundaries

There is no single Infinity database

Some shell state lives in browser storage: active surface, theme choice, sidebar preferences, chat settings, notes, drafts, or workspace hints. Some tool state lives in a tool-specific local store. Some state is owned by a service database or a provider. The fact that a tool opens inside Infinity does not change who owns its data.

Native versus embedded trust boundaries

Native surfaces can use direct shell contracts, but they still must respect account and provider boundaries. Embedded tools communicate through a route and a controlled theme or host integration boundary. The shell should not reach into an embedded tool’s internal state as if it were a shared React component, and an embedded tool should not assume that the shell can satisfy its backend credentials.

Provider-backed features

Research, media generation, mail providers, developer integrations, coding-agent runs, education generation, language feedback, and catalogue synchronization can all have different readiness requirements. A visible button is an entry point, not proof of provider configuration. Good failure behavior says what is unavailable, preserves the user’s input where safe, and avoids claiming a write or generation completed when it did not.

Secrets and sensitive material

• Never put API keys, passwords, access tokens, or private credentials in chat prompts or notes.
• Do not treat screenshots as a safe place for account identifiers or provider errors.
• Review attachments before sending them to a model, research provider, or external integration.
• Verify the destination and permissions before sharing a generated artifact or exported file.
• Use the owning tool’s sign-in and authorization path rather than inventing a shared credential path.

What “local” means here

Local can mean browser-local state, a local development service, or a tool that has a local-first path. It does not mean that every Infinity tool is offline, and it does not mean a request never crosses a network. Always distinguish local UI state from provider-backed work and from a deployed service mounted behind the shell.

Responsive and accessible use

Infinity is designed to preserve the tool map across desktop, split-screen, and narrow layouts. The shell should keep controls keyboard reachable, expose labels for icon-only buttons, preserve an active indication, and make loading and unavailable states readable without relying only on color.

Keyboard and focus

Use the browser’s normal keyboard navigation to move through the sidebar, account controls, composer, and active workspace. A selected tool should be understandable from its label or accessible name. When a panel or menu opens, focus should remain usable and should not become trapped behind an inactive workspace.

Reduced width

In split-screen, the compact navigation rail may show symbols without full text. Symbols should remain centered, the logo or home entry should retain its intended location, and search should remain available in the shell’s compact control path. Tool content receives the space that remains after navigation and account chrome are accounted for.

Loading and error states

A loading state should explain what is loading; an error state should identify the affected boundary; an empty state should distinguish “no data” from “data could not be loaded.” This is particularly important for Inbox, Research, Calendar, Marketplace, Testing, and any generation surface.

Recommended workflows

From idea to finished artifact

1. Start in General Chat to clarify the goal, audience, constraints, and desired format.
2. Move to Research if the work needs sources, dates, evidence, or a defensible synthesis.
3. Choose Document, Template, PowerPoint, Matrix, or Manifest based on the artifact’s actual shape.
4. Use the specialist tool to author and inspect the artifact rather than asking chat to simulate its editor.
5. Export or share only after checking the saved state, format, and destination permissions.

From code idea to verified change

1. Use General Chat for initial explanation or scoping.
2. Use Genesis for repository work that needs files, commands, policies, and verification.
3. Inspect the run’s terminal truth, review state, and completion result.
4. Do not call a change complete because a response was generated; require evidence from the run.

From question to decision

1. Use Research for source-grounded investigation.
2. Use CARFINDER or Marketplace when the decision concerns vehicles or products.
3. Use Calendar when the next action must become a scheduled event.
4. Keep the source, date, price, availability, and confidence visible before committing.

From learning goal to practice

1. Use Education for subject, lesson, and schedule context.
2. Use Polyglot for language-course setup and practice.
3. Use Articulate when the goal is to improve a spoken or written communication sample.
4. Use Testing when the goal is a generated assessment, practice session, or report.

Troubleshooting

The shell loads but a tool does not

This usually means the shell is healthy and the selected tool’s route, service, provider, or frame policy is not. Confirm the active tool, wait for its loading state, then check whether the tool reports a backend or provider problem. Do not repeatedly reload the whole shell before identifying the boundary that failed.

A tool is visible but its data is empty

Empty can mean there is genuinely no data, the account has no authorized records, the service has not synchronized yet, or the request failed and the UI collapsed the error. Check the tool’s status or error message, then confirm identity, provider scopes, and the owning service.

A generation or research request does not complete

Check provider readiness, model or tier selection, quota, request size, and whether the service is reporting an explicit failure. Keep the prompt or brief locally if the interface allows it. A retry should be deliberate: confirm that the first request did not already succeed before submitting a duplicate.

A file opens differently after import or export

Use the owning editor’s compatibility boundary. For Matrix and PowerPoint especially, inspect formulas, fonts, media, charts, slide order, and unsupported features in the destination application. Keep the original source file and compare the exported result before deleting anything.

The compact layout feels crowded

Collapse the sidebar, keep the tool rail at its intended width, and use the active workspace’s own scrolling region. The shell should not require every tool to be visible at full width simultaneously. If a symbol is not understandable, expand the rail or use its accessible name rather than changing the active tool by accident.

When to check Status

Check Status when multiple independent tools fail, when a known service returns a readiness error, or when a deployment appears to be serving an unexpected version. A single tool failure usually starts with that tool’s own route and provider; a broad failure suggests checking the shared shell or platform status.

What Infinity is not

Infinity is not a claim that every tool is one monolith. It is not a guarantee that every feature is available offline. It is not a universal credential vault, a replacement for every tool’s service, or a promise that an embedded route has the same storage and provider behavior as the shell.

Infinity is also not a substitute for the specialist product’s compatibility documentation. A presentation editor still has presentation compatibility limits; a spreadsheet still has formula and file limits; a mail surface still depends on mailbox authorization; a research surface still depends on sources and provider readiness.

Finally, this document is not an operational status page. It explains the product and its intended boundaries. For a live incident or service state, use the Status surface; for public developer concepts, use theDeveloper guide; for the developer platform product itself, use thePlatform document.

Product direction

The durable direction for Infinity is a faster, calmer, more legible workspace: load the selected tool first, keep navigation stable, make provider boundaries visible, preserve user work through interruptions, and let each specialist tool remain excellent at its own job.

That direction favors measured improvements over a second UI for every capability. The shell should become lighter without flattening the tools; embedded workspaces should become more reliable without losing their specialized controls; and account, data, and readiness states should become clearer without hiding failures.

Infinity in one sentence

Infinity is the TronXVI workspace shell that unifies native conversation surfaces and specialist embedded tools behind one navigation, account, loading, and appearance model while preserving each tool’s own job, data boundary, and readiness requirements.

To understand the wider public product story, read the About page, theRoadmap, and the Platform document. This page remains the complete Infinity product explanation and does not launch the application itself.