# Rogue: public product guides / guias públicos do produto

> English and Brazilian Portuguese versions of the public documentation. The canonical HTML pages linked below are the reference for each language.

> Versões em inglês e português do Brasil da documentação pública. As páginas HTML canônicas indicadas abaixo são a referência de cada idioma.

# Developer documentation

> Rogue's project formats, build and runtime lifecycle, publication, code export, authentication boundaries, and agent integration.

[Canonical page](https://rogueon.ai/docs)

## Product scope

Rogue is a hosted environment for generating and revising web artifacts through structured requests. This documentation covers the resulting project, its build and runtime dependencies, versioned previews, publication, and export. It distinguishes capabilities of the web workspace from services used by a generated application.

- [Development workflow](https://rogueon.ai/docs/getting-started)
- [Project architecture](https://rogueon.ai/docs/project-architecture)

## Request, artifact, and release

- Specify the output, data contract, invariants, dependencies, and acceptance criteria.
- Follow the request state and inspect the saved artifact and preview. A request being accepted is not a completed build.
- Validate behavior and authorization, then publish the selected version. Subsequent edits remain in preview until another publication.

- [Build lifecycle and revisions](https://rogueon.ai/docs/build-and-refine)
- [Runtime validation](https://rogueon.ai/docs/preview-and-testing)

## Specifications and context

Use bounded specifications with explicit inputs, state transitions, expected failures, and non-goals. Provide reference files or URLs with their intended role. Keep fixtures separate from production data and declare whether the project needs persistent storage, user identity, or external services.

- [Specification examples](https://rogueon.ai/docs/prompting)
- [Website workflow guide](https://rogueon.ai/create-website-with-ai)

## Workspace and artifact formats

Sites is the web-project workflow; Chat and Slides have separate roles. The generic app entry can open Chat. Within Sites, a saved result can be direct HTML or a Vite project. Vite can bundle HTML/TypeScript, a React island, or a React application: inspect `package.json`, entry points, and imports instead of assuming one framework.

- [HTML, source, build output, and runtime](https://rogueon.ai/docs/project-architecture)

## Source ownership and portability

Generated code is yours; Rogue itself is not open source. The code viewer exposes saved files for inspection and copying. When available, GitHub export delivers an HTML or Vite project according to that version's artifact format.

Code export does not transfer database records, user identities, provider credentials, or hosted service routing. Establish the destination's build and runtime configuration and validate it before moving users. Review generated README content and Git history before changing repository visibility.

- [Export and external development](https://rogueon.ai/docs/exporting)
- [Terms & Conditions](https://rogueon.ai/terms)

## Publication boundaries

Publish selects which reviewed artifact is served at the managed site address, with hosting included. Publishing a site, committing code to GitHub, and changing backend data are separate operations. Validate the destination rather than inferring its state from a successful preview.

Rogue-managed site addresses currently use X-Robots-Tag: noindex. You can share their public links, but these addresses are not intended to appear in search. For search discovery, export and configure a separate hosting destination you control. noindex does not make a public page private.

Custom domains are not supported by this workflow yet. Web output runs in a browser; Rogue does not generate .apk or .ipa packages or publish native apps to the App Store or Play Store.

- [Version selection and publication](https://rogueon.ai/docs/publishing)

## Availability and capacity

Rogue is in free beta with session and weekly usage limits. Free is the plan in use; Go and Max are listed below with their prices and are not on sale yet. Account usage, request context limits, and external-provider quotas are distinct constraints.

- Free: $0/month.
- Go: $10/month (coming soon).
- Max 5x: $50/month (coming soon).
- Max 25x: $150/month (coming soon).

- [Capacity and request limits](https://rogueon.ai/docs/plans-and-limits)
- [Pricing and availability](https://rogueon.ai/pricing)

## Runtime and agent integration

Distinguish account connectors, generated-app dependencies, and agent access to documentation. A catalogue entry does not establish a connected account. Frontend export does not supply hosted authentication or credential proxies. Validate the actual connection, permissions, origin behavior, and provider response.

Public guides are available as canonical HTML and equivalent Markdown. Use the agent integration reference for discovery and supported documentation interfaces; reading product documentation does not authorize actions on private projects.

- [Service integration boundaries](https://rogueon.ai/docs/integrations)
- [Authentication and data](https://rogueon.ai/docs/data-and-permissions)
- [Agent integration](https://rogueon.ai/docs/agent-integration)

## Diagnostics and references

For a defect, include the tested version, environment, minimal reproduction, expected and actual result, and sanitized network or console evidence. Identify whether it occurs in the preview, published site, or exported project.

- [Runtime diagnostics](https://rogueon.ai/docs/troubleshooting)
- [About Rogue](https://rogueon.ai/about)
- [Contact](https://rogueon.ai/contact)
- [caio@rogueon.ai](mailto:caio@rogueon.ai)
- [Privacy Policy](https://rogueon.ai/privacy)



# Development workflow

> Create a bounded web project and follow its request, build, preview, and publication lifecycle.

[Canonical page](https://rogueon.ai/docs/getting-started)

## Define the artifact and its boundaries

Rogue produces web artifacts from a specification and follow-up requests. The saved result may be a direct HTML page or a Vite source project. Identify the actual output before assuming a framework, package manager, backend, or deployment process.

Start with a reproducible vertical slice: one route or screen, explicit input data, and observable acceptance criteria. Separate the UI from persistence, authentication, and external services. A mock dataset is useful for a prototype; it must not be mistaken for a functioning backend.

## Initialize a Sites conversation

1. **Open the web workspace**

   Open Sites using the link below and authenticate if prompted. The generic app entry can open Chat; Sites and Slides are separate output modes.

2. **Submit a specification**

   State the artifact, test data, required states, and acceptance criteria. Attach only the sources needed for this change. Resolve clarification requests in the same conversation.

3. **Track the result**

   Distinguish an accepted request, a running build, a failed or interrupted run, and a ready preview. A submitted request is not evidence of a completed artifact.

- [Open Sites](https://app.rogueon.ai/build?format=site)

## Minimal reproducible specification

**Frontend-only prototype**

```text
Artifact: responsive issue list.
Data: three explicit fixtures with id, title, status, and priority.
Behavior: filter by status; combine filter with a title search.
States: loading, empty result, populated list.
Boundary: fixtures only; no login, database, or external calls.
Acceptance: filtering does not mutate the original data; clearing filters restores all items; keyboard users can reach every control.
Report the generated format and any unimplemented requirement.
```

## Verify before advancing the release

Inspect the preview and saved files, execute the acceptance criteria, and record defects against the version you tested. Continue with a scoped follow-up rather than changing the specification and diagnosing a runtime failure in the same request.

Publication explicitly selects the version served at the public site address. A later build remains a preview until published. GitHub export is an independent delivery channel for the code; neither operation migrates database records or service credentials.

## Related guides

- [Project and runtime architecture](https://rogueon.ai/docs/project-architecture)
- [Specifications and context](https://rogueon.ai/docs/prompting)
- [Preview and runtime validation](https://rogueon.ai/docs/preview-and-testing)



# Project and runtime architecture

> Identify HTML versus Vite output, source versus build artifacts, and the hosted services a frontend may depend on.

[Canonical page](https://rogueon.ai/docs/project-architecture)

## Identify the generated format

Rogue's web output has two artifact paths. A direct HTML page is delivered as index.html with its associated assets. A Vite project has source files and a build step; it can use HTML and TypeScript, a React island, or a React application. Inspect package.json and the actual imports: Vite alone does not imply React. The saved files determine the architecture you received.

|  | Direct HTML | Vite project |
| --- | --- | --- |
| Source | index.html and associated assets. | index.html, source under src/, and assets under public/ according to the saved version. |
| GitHub export | Page, assets, and README. | Source, assets, package.json, Vite/TypeScript configuration, and README. |
| Local build | No required compilation for the page. | package.json scripts; default output in dist/. |
| Runtime | Browser and network services used by the HTML. | Compiled JavaScript/CSS in the browser and network services used by the app. |

## Source is not the deployed bundle

For Vite output, edit the source in your development environment and rebuild; editing dist directly is not a durable source change. Inspect the exported scripts and README for that version. The generated GitHub project adds dev, build, and preview scripts, but it does not recreate Rogue's own server application.

For direct HTML, serve the exported directory to test relative assets and browser behavior. The example below requires Python 3 and serves only on the loopback interface. It verifies static delivery, not the presence of backend services.

**Direct HTML: local static server**

```sh
python3 -m http.server 8000 --bind 127.0.0.1
```

## Map the frontend-to-service boundary

A project can render without a backend, store browser-local state, or depend on managed persistence and authentication. These are different architectures. For a database-backed project, inspect its actual data panel and generated code. Do not infer persistence from a form that merely updates local state.

Managed authentication and provider-key calls can rely on server routing at the page's origin. Copying frontend files to another host does not copy those server implementations, credentials, or origin configuration. Inventory every network dependency before choosing a deployment target.

## Record the deployment contract

- Artifact format, source entry points, assets, build command, and output directory.
- Required runtime URLs, authentication flow, allowed origins, and session assumptions.
- Data owner, schema, migration/export plan, and authorization checks.
- External-service credentials, billing owner, quotas, and failure behavior.
- Exact source revision and validation evidence for the deployed artifact.

## Related guides

- [Export and external development](https://rogueon.ai/docs/exporting)
- [Authentication, data, and permissions](https://rogueon.ai/docs/data-and-permissions)
- [Preview and runtime validation](https://rogueon.ai/docs/preview-and-testing)



# Specifications and context

> Structure requests around contracts, invariants, dependencies, and observable acceptance criteria.

[Canonical page](https://rogueon.ai/docs/prompting)

## Define a contract for the change

Treat a request as a specification the generated result can be checked against. Identify the target screen or component, data shape, supported actions, failure states, and explicit non-goals. For an existing project, name the behavior that must remain unchanged.

- Inputs: field names, types, valid and invalid examples, and the source of truth.
- State transitions: initial, loading, success, empty, error, and retry behavior.
- Dependencies: distinguish fixtures, browser storage, shared backend data, and external providers.
- Invariants: authorization rules, immutable fields, ordering, and existing public behavior.

## Request a bounded implementation

**Change specification**

```text
Target: existing issue-list screen.
Change: add a status filter with all/open/closed values.
Data contract: { id: string, title: string, status: 'open' | 'closed' }.
Preserve: item IDs, existing sort order, detail navigation, and visual tokens.
Empty state: show a clear message and a Reset filters action.
Acceptance:
- Filter and text search compose.
- Reset returns the original order.
- No network request is added for local filtering.
- Controls have accessible labels and keyboard focus.
Return: changed files, validation performed, and unresolved dependencies.
```

## Supply bounded source context

The Sites composer supports source mentions, reference URLs, supported text files, and images. Explain which aspect of a reference is authoritative: schema, content, layout, or behavior. A URL supplies context; it does not authorize account access or import the referenced system's backend.

Supported text formats include TXT, Markdown, CSV, JSON, HTML, CSS, JavaScript, and TypeScript. The text path expects UTF-8 rather than binary documents. Mention context is bounded separately from file size; use the smallest excerpt that preserves the contract instead of attaching an entire dependency tree.

## Make evaluation independent of generation

Keep acceptance criteria concrete enough to execute manually or in your own test environment. A request to add tests is not evidence that tests ran: inspect the reported validation and reproduce critical behavior. Distinguish implemented, mocked, and unavailable dependencies in the result.

Use synthetic records and placeholders for credentials. Connect services through their dedicated controls after defining the data flow, permissions, and expected cost boundary.

## Related guides

- [Build lifecycle and revisions](https://rogueon.ai/docs/build-and-refine)
- [Authentication, data, and permissions](https://rogueon.ai/docs/data-and-permissions)
- [Preview and runtime validation](https://rogueon.ai/docs/preview-and-testing)



# Build lifecycle and revisions

> Track request state, inspect changed files, and separate artifact revisions from publication and data changes.

[Canonical page](https://rogueon.ai/docs/build-and-refine)

## Keep the revision attached to its context

Continue in the existing project conversation to refine its current artifact. A follow-up request uses the project context; a new conversation is a different starting point. Identify the tested version and the narrow change required, especially when a public version and a newer preview coexist.

A request can require clarification, run, fail, be interrupted, or produce a ready preview. The availability of a Stop, retry, or resume action depends on that state. Do not treat an interrupted connection as proof that server-side work never completed.

## Constrain the revision

**Regression-oriented change request**

```text
Base: the current preview in this conversation.
Observed: submitting an empty title creates an empty list item.
Expected: reject empty or whitespace-only titles before adding an item.
Preserve: stable IDs, status filtering, ordering, and the current layout.
Validate: empty input, whitespace, valid input, repeated submit, and keyboard submit.
Do not add persistence or change the data model. Report the changed files and validation results.
```

## Inspect the resulting delta

When the changed-files card is present, Review opens the relevant file and available differences. Check additions, removals, and unexpected changes outside the requested scope. Large differences may fall back to the full file rather than a line-by-line comparison.

The code panel displays saved source and supports copying; it is not an in-place source editor. For external development, export the artifact and inspect it in your own tools. Preview success, a source diff, and a passing production build answer different questions and should be checked separately.

## Separate artifact rollback from data rollback

Undo, when offered, returns to a previous artifact version after confirmation and requires the owner's project context. It can also affect the version at the published address. It does not provide a transaction rollback for database writes, sent emails, or actions already completed by external services.

Ordinary forward changes remain in preview until explicitly published. If the conversation is linked to GitHub, later completed versions can independently generate commits. Review both the deployed website and the repository state when coordinating a release.

## Related guides

- [Preview and runtime validation](https://rogueon.ai/docs/preview-and-testing)
- [Publication and version selection](https://rogueon.ai/docs/publishing)
- [Export and external development](https://rogueon.ai/docs/exporting)



# Preview and runtime validation

> Validate the rendered artifact, network dependencies, authorization behavior, and the exact version selected for publication.

[Canonical page](https://rogueon.ai/docs/preview-and-testing)

## Understand the test surface

The embedded preview renders the generated page in an iframe. Desktop and mobile controls resize that surface while preserving its state; they do not emulate an operating system, browser engine, network connection, or fresh user session. Reproduce critical flows in a separate tab and on the target browser or device.

Identify the preview URL and version before recording a failure. For frontend diagnosis, open browser DevTools on the generated page: inspect console errors and the failed network request, including status, response, and origin. Redact authorization headers, cookies, tokens, and personal payloads before sharing evidence.

## Validation matrix

| Layer | Checks |
| --- | --- |
| Rendering | No unhandled errors; assets load; empty, loading, and error states appear when expected. |
| Interaction | Keyboard, focus, input validation, repeated submission, and navigation preserve the contract. |
| Persistence | Data survives reload and appears in another client when it must be shared. |
| Authorization | User A cannot read or change B's private records; anonymous access follows the rules. |
| Services | Responses come from the intended service; failures and limits do not become fabricated success. |
| Publication | The public address serves the approved version and its main flow remains functional. |

## Capture a reproducible failure

**Runtime defect report**

```text
Version / URL: [tested artifact]
Environment: [browser, viewport, signed-in or anonymous]
Preconditions: [synthetic records and initial state]
Steps: [smallest sequence]
Expected: [contract]
Actual: [visible result]
Evidence: [redacted console message or request status]
Regression checks: [behaviors that must remain unchanged]
Fix the cause and report which checks were actually executed.
```

## Verify the release candidate

Retest the defect against the revised artifact and run the surrounding regression checks. A static render does not validate database permissions or a payment workflow. Use test accounts and provider test environments where available; distinguish simulated behavior from completed external actions.

After publication, repeat the critical path at the public address. Source changes, deployed files, and runtime configuration can diverge; validate the destination rather than inferring it from the build result.

- [Diagnose preview failures](https://rogueon.ai/docs/troubleshooting#preview)

## Related guides

- [Build lifecycle and revisions](https://rogueon.ai/docs/build-and-refine)
- [Authentication, data, and permissions](https://rogueon.ai/docs/data-and-permissions)
- [Publication and version selection](https://rogueon.ai/docs/publishing)



# Publication and version selection

> Promote a reviewed artifact to the managed site address and distinguish publication from preview, GitHub delivery, and data migration.

[Canonical page](https://rogueon.ai/docs/publishing)

## A public address points to a selected version

Completing a site build produces a versioned preview. Publish selects that version for the conversation's managed public address. A subsequent build does not ordinarily replace the live artifact until you publish again. Record the tested version before promotion so a later preview is not mistaken for the release candidate.

This operation changes which artifact the address serves. It is not a database migration, a transfer of provider accounts, or a GitHub push. Those states need their own verification when a release changes more than frontend files.

## Publish a reviewed version

1. **Select the ready artifact**

   Open the original site conversation with owner access. Confirm that generation is complete and that the displayed preview is the version you tested.

2. **Execute Publish**

   Use Publish and wait for the success state and returned address. A disabled control or error is not a completed deployment.

3. **Verify the destination**

   Copy the public link, open it separately, and check the critical flow, assets, authentication, and service calls that apply to this project.

## Coordinate revisions and repository delivery

Keep a distinction between the latest preview, the selected public version, and the latest GitHub commit. The GitHub integration can create commits for subsequent completed changes after the conversation is linked; that does not publish those changes at the site address.

If the site appears unchanged, check the public address and selected version before starting another build. If you use Undo, read its confirmation: reverting an artifact can affect the public version, but does not reverse database mutations or external side effects.

## Sharing a link and appearing in search

Rogue-managed site addresses currently return the HTTP header X-Robots-Tag: noindex. They are intended for reviewing and sharing the selected web artifact, not for search indexing. A title, description, or social card does not override that header. Anyone with the public link can still open the site: noindex is not access control.

If search discovery is a project requirement, export the code and configure a separate hosting destination you control. Review the files for private information, establish required runtime services, and verify indexable responses at that destination before submitting its sitemap. Export does not guarantee indexing or transfer backend services automatically.

- [Export and configure the destination](https://rogueon.ai/docs/exporting#search-ready-hosting)

## Deployment boundaries

Managed publication includes hosting for the web artifact. Custom domains are not supported through this product workflow yet. Sites output runs in a browser; this is not an .apk or .ipa build or an App Store/Play Store submission workflow. Slides use a separate delivery path.

Publication requires owner context. If the app asks for the original browser or conversation, restore that context rather than clearing browser storage. For network or temporary service errors, retry publication after checking the status; avoid regenerating a correct artifact solely to retry delivery.

## Related guides

- [Preview and runtime validation](https://rogueon.ai/docs/preview-and-testing)
- [Export and external development](https://rogueon.ai/docs/exporting)
- [Runtime diagnostics](https://rogueon.ai/docs/troubleshooting)



# Export and external development

> Inspect saved source, deliver it to GitHub, and establish the build and runtime configuration required outside Rogue.

[Canonical page](https://rogueon.ai/docs/exporting)

## Artifact ownership and export scope

The generated code is yours; Rogue itself is not open source. Export availability depends on the saved version and artifact format. Direct HTML output contains the page and its associated assets. Vite exports include saved source files, project configuration, and a generated README. Inspect the exported tree rather than assuming every output is a React project.

## Inspect source and establish a local baseline

From preview actions, open View code, select a file, and use Copy. This copies the open file, not the whole project or its assets. Use the GitHub path for the packaged project when available. The viewer does not provide in-place source editing.

For a Vite export, inspect the README and package.json before installing dependencies. If the exported scripts include dev, build, and preview, the following commands establish the frontend baseline. Run them from the repository root with a compatible Node environment; use the terminal's reported address.

**Vite export with the generated npm scripts**

```sh
npm install
npm run dev
# Stop the development server before the next commands.
npm run build
npm run preview
```

## Understand the repository update model

When the integration is available, connect GitHub and use the project's GitHub publication action, which may be labeled Publicar no GitHub. The first publication creates a private repository. Subsequent completed versions in a linked conversation can create commits automatically.

Generated files can be rewritten by later Rogue updates. If the repository has commits outside Rogue's last update, the integration can create a separate branch for comparison instead of overwriting that history. Review the branch and diff before merging; keep independent changes in their own branch when coordinating both workflows.

The generated README and commit messages can contain request text. Before sharing the repository or changing its visibility, review the README, source, assets, and Git history for confidential information.

> **OAuth scope**
> GitHub's repo permission is broader than Rogue-created repositories. Rogue uses it for repositories it creates, but the grant itself is broad. Disconnecting preserves existing repositories.

## Prepare an exported website for search

Choose a hosting destination for the exported artifact. A direct HTML page needs its index.html and assets served together. A Vite export needs its documented build and the resulting output deployed. Start with a static informational site when you do not need a backend. Custom domains and search indexing at that destination are configured outside Rogue.

1. **Verify the final address**

   Check the actual page response and assets on the destination domain. Intentional public pages should return 200, have useful visible content, and have no unintended noindex header or meta tag. A robots.txt allowance alone cannot override noindex.

2. **Describe the published page**

   Use its real title, summary, main heading and canonical destination URL. Link all useful pages through navigation. Verify social cards with permitted images rather than assuming the editor's preview matches a shared link.

3. **Verify ownership and request discovery**

   Verify the destination in Search Console, inspect representative URLs and submit a sitemap containing its public canonical pages. Monitor indexing and search performance. Discovery, indexing, rankings and traffic are separate outcomes; none is guaranteed by publishing.

- [Google Search technical requirements](https://developers.google.com/search/docs/essentials/technical)

## Migrate runtime dependencies separately

A successful frontend build does not recreate hosted authentication, service proxies, database records, or provider credentials. Inventory relative network paths, allowed origins, sessions, environment configuration, and data ownership. Implement or reconfigure the required services at the destination before redirecting users.

- [HTML and Vite artifact architecture](https://rogueon.ai/docs/project-architecture)

## Related guides

- [Project and runtime architecture](https://rogueon.ai/docs/project-architecture)
- [Authentication, data, and permissions](https://rogueon.ai/docs/data-and-permissions)
- [Publication and version selection](https://rogueon.ai/docs/publishing)



# Integration boundaries

> Distinguish account connectors, generated-app service calls, permission grants, and external billing.

[Canonical page](https://rogueon.ai/docs/integrations)

## Account connector or application dependency?

Account connections operate in the Rogue workflow: GitHub delivers code and Gmail can send a reviewed draft when available. A generated application's service dependencies are separate. Connecting Gmail to your Rogue account does not configure an email backend for every generated form.

| Surface | Verify |
| --- | --- |
| Account connection | Authorized account, granted scopes, connected state, and permitted action. |
| Application dependency | Destination endpoint, client or server execution, credential, quota, and billing account. |
| Catalogue item | Actual availability; Coming soon is not an active connection. |

## Verify authorization and connection state

Use Preferences > Connections for the services offered to your account. Review the provider's authorization screen, then confirm the account and permissions shown after returning to Rogue. Availability and successful authorization are separate states.

On disconnection, read whether provider revocation was confirmed. If only the local connection was removed, complete revocation in the provider's account settings. A repository or an already sent message does not disappear when a connector is disconnected.

## Gmail: draft, authorization, explicit send

For accounts with Gmail enabled, the conversation can produce a draft card. Inspect recipients, subject, and body before Send or Connect and send. The sending operation follows that explicit action. If the available action is Open in Gmail, delivery is completed outside Rogue rather than by a connected send operation.

Mailbox reading and search require separate availability and permission. Do not infer read access from send access or from signing in to Rogue with a Google account.

## Generated-app service configuration

When App API keys is offered, use that interface for supported credentials. Managed calls can pass through Rogue's server so the provider key is not embedded in frontend code. That routing is a hosted runtime dependency; an exported static frontend does not implement it automatically.

Validate the service's real response and error behavior after configuration. Provider calls may consume that account's credits and quotas independently of Rogue usage. Key removal, revocation, or a provider quota can break an otherwise unchanged artifact.

## Related guides

- [Authentication, data, and permissions](https://rogueon.ai/docs/data-and-permissions)
- [Export and external development](https://rogueon.ai/docs/exporting)
- [Runtime diagnostics](https://rogueon.ai/docs/troubleshooting)



# Authentication, data, and permissions

> Separate Rogue account access, generated-app sessions, authorization policies, service credentials, and data portability.

[Canonical page](https://rogueon.ai/docs/data-and-permissions)

## Separate the trust boundaries

Your Rogue session grants access to the builder. A user session inside a generated app belongs to that app's authentication flow. Database access and external-service authorization are additional boundaries. Success at one layer does not imply access at the others.

Treat frontend files, rendered content, and downloaded assets as observable by the client. A preview URL or noindex instruction is not an authorization mechanism. Use synthetic fixtures in specifications; keep secrets out of prompts, client bundles, URLs, screenshots, and exported source.

## Authentication is not authorization

A login form establishes identity only when it is wired to the app's authentication service. Authorization must still constrain which records and actions that identity can access. Test anonymous access, two different users, and any administrative role; hiding a control in the UI does not enforce a server-side permission.

For managed database-backed projects, authentication can depend on same-origin routing and host-specific session cookies. Moving frontend files to a new host changes that environment. Review origins, cookie behavior, session acquisition, and data-access configuration instead of copying a production URL into a local project.

## Validate storage and credential ownership

| Boundary | Required check |
| --- | --- |
| Persistence | Distinguish in-memory state, browser-local storage, and shared backend records. |
| Isolation | Verify reads and writes with two users; enforce policy in the data service rather than only a visual filter. |
| Credentials | Use the supported key control; identify account ownership, billing, revocation, and rotation responsibility. |
| Database lifecycle | Read displayed status, expiry, and transfer information; provisional storage is not permanent storage. |

## Code portability and data portability differ

A repository export contains frontend artifacts, not a complete migration of application records, identities, service keys, or server-side infrastructure. Before cutover, inventory dependencies, determine how data and accounts will move, verify access at the destination, and keep a recovery plan for the source environment.

Use the Privacy Policy for Rogue's data-handling terms and the team contact for account-data requests. This technical guide does not establish a retention guarantee for every generated app or provider.

- [Privacy Policy](https://rogueon.ai/privacy)
- [Contact](https://rogueon.ai/contact)

## Related guides

- [Project and runtime architecture](https://rogueon.ai/docs/project-architecture)
- [Integration boundaries](https://rogueon.ai/docs/integrations)
- [Export and external development](https://rogueon.ai/docs/exporting)



# Capacity and usage limits

> Read beta availability, session and weekly capacity, context limits, and external-provider quotas as separate constraints.

[Canonical page](https://rogueon.ai/docs/plans-and-limits)

## Current availability

Rogue is in free beta with usage limits. There is no checkout and no paid plan on sale; everyone is on the Free plan. Go and Max are announced on the pricing page and have not opened. Talk to the team if a project needs more capacity.

Capacity is not a deterministic number of prompts or completed apps. Workload, model activity, and tool execution vary by request. Use the account's observed usage and limit messages when planning a larger run, rather than estimating it in advance.

- [Pricing and availability](https://rogueon.ai/pricing)

## Inspect the account state

Preferences > Account shows the current session and weekly usage. Check both meters and the displayed reset time. A warning, a reached limit, and a provider failure are different conditions; use the error's context before retrying a request.

A usage session is independent of your authentication session. Signing out, opening a new tab, or restarting the browser does not reset the account's usage window.

## Identify the limiting layer

| Constraint | Interpretation |
| --- | --- |
| Usage session | Five-hour window starting with a request when no usage session is open. |
| Weekly usage | Seven-day cadence from the first request; use the reset displayed in the account. |
| Sites context | Up to eight mentions, 16,000 characters of mention context, and 20,000 in the expanded request. |
| Text files | Up to four per selection, 48 KB per file, and 64 KB combined; context limits still apply. |
| External service | Provider quota, billing, timeout, and key limits are independent of Rogue capacity. |

## Reduce avoidable work

Scope changes against the current artifact, supply the relevant source excerpt, and make validation explicit. Diagnose a preview load or publication error before repeating generation: retrying delivery and generating another artifact have different costs and effects.

When a limit is reached, follow its displayed reset or recovery instruction. Repeated submissions do not create extra capacity. External-service limits must be resolved in the service configuration or account responsible for those calls.

## Related guides

- [Specifications and context](https://rogueon.ai/docs/prompting)
- [Runtime diagnostics](https://rogueon.ai/docs/troubleshooting)
- [Integration boundaries](https://rogueon.ai/docs/integrations)



# Runtime diagnostics

> Classify failures by request, generation, artifact loading, runtime dependencies, and publication before retrying.

[Canonical page](https://rogueon.ai/docs/troubleshooting)

## Request admission and context

First establish whether the request was sent and accepted. A composer error can indicate missing attachments, oversized context, authentication, a usage limit, or an active run. Correct that condition before investigating generated code. For expired sign-in or an email-code flow, follow the actual sign-in screen rather than assuming a particular provider is enabled.

## Artifact loading versus application failure

Open the preview separately and inspect Console and Network in browser DevTools. Record the failing URL without secrets, HTTP status, response type, visible message, and whether the document, an asset, or a service request failed. A 200 response for HTML does not establish that JavaScript initialized or data requests succeeded.

Use Reload preview or the offered recovery action for a loading failure. For a runtime defect, reproduce the smallest interaction sequence and send that evidence with the relevant version. If the external export works visually but authentication or service calls fail, inspect missing host-side routing before rewriting UI code.

## Interrupted generation

Read the last run state and use its specific action: Try reconnecting, Resume build, or Try again when offered. They are not interchangeable. Before starting a duplicate request, verify whether an artifact was saved or the prior run recovered. A disconnected client does not prove that a provider operation was cancelled.

## Publication and ownership

Compare the preview version with the public version. Ordinary edits require a new Publish action. If publication reports missing owner access, reopen the original conversation/browser as directed. Clearing local storage can remove useful project context and should not be a default diagnostic step.

## Credential, origin, and quota failures

Check the live connector state, the project's key status, and the provider response. Distinguish an unavailable integration, a disconnected account, a missing or rejected key, an origin/session mismatch, and an exhausted quota. Use the app's displayed message and response details; an HTTP status alone does not identify the root cause.

## Provide a diagnostic bundle

**Support report**

```text
Project/conversation URL and tested version:
Time and timezone:
Browser/device and signed-in state:
Minimal reproduction:
Expected versus actual result:
Failed request status or console message (redacted):
Whether it reproduces in preview, public site, or exported project:
Recovery actions already attempted:
```

- [Contact engineering support](https://rogueon.ai/contact)

## Related guides

- [Preview and runtime validation](https://rogueon.ai/docs/preview-and-testing)
- [Project and runtime architecture](https://rogueon.ai/docs/project-architecture)
- [Capacity and usage limits](https://rogueon.ai/docs/plans-and-limits)



# Agent integration

> Connect your coding agent to Rogue documentation. Search, retrieve a section, and verify the source through a read-only MCP server.

[Canonical page](https://rogueon.ai/docs/agent-integration)

## Connect an MCP client

The public endpoint is `https://rogueon.ai/mcp`. Choose Streamable HTTP in your MCP client. It requires no API key, account, OAuth flow, or model subscription to read the documentation. Let the client negotiate the protocol; the endpoint supports the 2026-07-28 protocol and compatible 2025 clients.

For Cursor, merge the following entry into your project's `.cursor/mcp.json`, preserving any existing servers. Reload the MCP configuration and confirm that `list_docs`, `search_docs`, and `get_doc` are listed. Other editors may use a different configuration format for the same endpoint.

**Cursor · .cursor/mcp.json**

```json
{
  "mcpServers": {
    "rogue-docs": {
      "url": "https://rogueon.ai/mcp"
    }
  }
}
```

- [Cursor MCP configuration reference](https://cursor.com/docs/mcp)

## Claude Code

Run this in the project where you want the documentation available. The command registers the remote server; it does not generate or publish an app. Use `/mcp` in Claude Code to inspect the connection. If `rogue-docs` is already configured, inspect or update that entry instead of adding a duplicate.

**Claude Code · terminal**

```bash
claude mcp add --transport http rogue-docs https://rogueon.ai/mcp
```

- [Claude Code HTTP MCP reference](https://code.claude.com/docs/en/mcp)

## Tool contract

All tools accept `locale`: `en` or `pt-br`, defaulting to `en`. Tool results include source URLs. Markdown resources are also discoverable through `resources/list` and readable through `resources/read`.

| Tool | Arguments | Result |
| --- | --- | --- |
| `list_docs` | `locale?` | Catalog of slugs, URLs, sections and content hashes. |
| `search_docs` | `query`, `locale?`, `limit?` | Ranked excerpts and canonical section links. Limit 1–16; default 8. |
| `get_doc` | `slug`, `locale?`, `section?` | Full Markdown, or one section when its ID is provided, with its SHA-256 hash. |

**get_doc · arguments**

```json
{
  "slug": "project-architecture",
  "locale": "en",
  "section": "runtime-services"
}
```

## Search → retrieve → verify

1. **Find the relevant source**

   Use search_docs with a focused query. Search matches all words, ignores accents, and returns excerpts; an excerpt is not the whole reference.

2. **Read the smallest useful section**

   Use the document slug and section ID with get_doc. Omit section when surrounding context is necessary. Keep conditions about artifact format, runtime and availability in any summary.

3. **Retain source and revision**

   Cite the returned canonical URL and retain the SHA-256 with cached context. Check the manifest before reusing old content. The hash describes content identity, not a product release or update date.

**Task context for a coding agent**

```text
Before changing a Rogue-generated project:
1. Identify the actual artifact format from its files.
2. Search Rogue docs for the relevant runtime or export contract.
3. Retrieve that section with get_doc; retain its canonical URL.
4. Distinguish documented behavior from assumptions about this project.
5. Implement only the requested change and validate its acceptance criteria.
6. Report the source, changed files, verification, and unresolved dependencies.
```

## Retrieve Markdown over HTTP

Every article has an explicit `/markdown` URL. HTML and Markdown are generated from the same source; the Markdown response declares the canonical HTML URL. This path works with a normal HTTP client when MCP is unavailable or unnecessary.

**Read architecture documentation**

```bash
curl -fsSL https://rogueon.ai/docs/project-architecture/markdown
```

- [Architecture · Markdown](https://rogueon.ai/docs/project-architecture/markdown)

## Cache by content hash

The JSON manifest has `schemaVersion: 1` and lists each document's `slug`, `url`, `markdownUrl`, `sha256`, byte count and section IDs. Document hashes cover the exact UTF-8 Markdown response body; section hashes cover that section's Markdown. The HTTP ETag identifies the manifest representation and supports `If-None-Match` with a 304 response.

**manifest.json · HTTP**

```bash
curl -fsS -D - https://rogueon.ai/docs/manifest.json
```

- [Open documentation manifest](https://rogueon.ai/docs/manifest.json)

## Discovery and complete corpus

`llms.txt` is the compact discovery index. `llms-full.txt` contains the public guides in both languages. Prefer a page or section for routine retrieval; use the full corpus when an offline task needs broader coverage. These files are discovery resources, not crawler permission rules or a guarantee of ingestion.

- [llms.txt](https://rogueon.ai/llms.txt)
- [llms-full.txt](https://rogueon.ai/llms-full.txt)

## Transport, limits and scope

Tool calls are read-only and do not invoke a language model. Your coding agent still has its own provider usage and permissions. An explicit browser Origin must be on the server allowlist; ordinary server-side MCP clients can connect without an Origin header. Recheck configuration and protocol errors before retrying, rather than adding credentials this endpoint does not require.

| Contract | Behavior |
| --- | --- |
| HTTP | POST for MCP; successful calls return JSON. No persistent SSE stream, session ID or subscription. GET returns 405. |
| Input | Maximum 16 KiB per request. Search: 1–200 characters, up to 12 words. Only catalog slugs and section IDs are accepted. |
| Output | Up to 16 search hits; maximum 64 KiB of Markdown per document. Tool validation failures are returned as errors, not guessed content. |
| Access | Public documentation only. No account data, private projects, code execution, generation or publication tools. |

## Related guides

- [Project and runtime architecture](https://rogueon.ai/docs/project-architecture)
- [Export and external development](https://rogueon.ai/docs/exporting)
- [Authentication, data, and permissions](https://rogueon.ai/docs/data-and-permissions)



---

# Documentação técnica

> Formatos de projeto, ciclo de build e runtime, publicação, exportação de código, fronteiras de autenticação e integração com agentes da Rogue.

[Página canônica](https://rogueon.ai/pt-br/docs)

## Escopo do produto

A Rogue é um ambiente hospedado para gerar e revisar artefatos web por meio de pedidos estruturados. Esta documentação cobre o projeto resultante, suas dependências de build e runtime, prévias versionadas, publicação e exportação. Ela distingue capacidades do ambiente web e serviços usados pela aplicação gerada.

- [Fluxo de desenvolvimento](https://rogueon.ai/pt-br/docs/getting-started)
- [Arquitetura do projeto](https://rogueon.ai/pt-br/docs/project-architecture)

## Pedido, artefato e publicação

- Especifique saída, contrato de dados, invariantes, dependências e critérios de aceite.
- Acompanhe o estado do pedido e inspecione o artefato salvo e a prévia. Um pedido aceito não é um build concluído.
- Valide comportamento e autorização e publique a versão selecionada. Edições posteriores permanecem na prévia até outra publicação.

- [Ciclo de build e revisões](https://rogueon.ai/pt-br/docs/build-and-refine)
- [Validação de runtime](https://rogueon.ai/pt-br/docs/preview-and-testing)

## Especificações e contexto

Use especificações delimitadas com entradas, transições de estado, falhas esperadas e itens fora do escopo. Forneça arquivos ou URLs de referência com sua função declarada. Separe dados de teste e de produção e indique se o projeto precisa de persistência, identidade de usuários ou serviços externos.

- [Exemplos de especificação](https://rogueon.ai/pt-br/docs/prompting)
- [Guia de criação de sites](https://rogueon.ai/pt-br/create-website-with-ai)

## Ambiente e formatos de artefato

Sites é o fluxo para projetos web; Chat e Slides têm funções separadas. A entrada geral do app pode abrir Chat. Em Sites, um resultado salvo pode ser HTML direto ou um projeto Vite. Vite pode compilar HTML/TypeScript, uma ilha React ou uma aplicação React: inspecione `package.json`, pontos de entrada e imports em vez de assumir um framework.

- [HTML, fontes, saída de build e runtime](https://rogueon.ai/pt-br/docs/project-architecture)

## Propriedade das fontes e portabilidade

O código gerado é seu; a Rogue em si não é open source. O visualizador expõe os arquivos salvos para inspeção e cópia. Quando disponível, a exportação para GitHub entrega um projeto HTML ou Vite conforme o formato daquela versão.

Exportar código não transfere registros do banco, identidades, credenciais ou roteamento de serviços hospedados. Configure build e runtime no destino e valide antes de mover usuários. Revise o README gerado e o histórico Git antes de mudar a visibilidade do repositório.

- [Exportação e desenvolvimento externo](https://rogueon.ai/pt-br/docs/exporting)
- [Termos e Condições](https://rogueon.ai/pt-br/terms)

## Limites da publicação

Publicar seleciona o artefato revisado servido no endereço gerenciado, com hospedagem incluída. Publicar o site, enviar código ao GitHub e alterar dados no backend são operações separadas. Valide o destino em vez de inferir seu estado por uma prévia funcional.

Endereços de sites gerenciados pela Rogue usam hoje X-Robots-Tag: noindex. Você pode compartilhar os links públicos, mas esses endereços não são destinados à busca. Para descoberta na busca, exporte e configure outra hospedagem sob seu controle. noindex não torna uma página pública privada.

Domínios próprios ainda não são suportados por esse fluxo. A saída web roda no navegador; a Rogue não gera pacotes .apk ou .ipa nem publica apps nativos na App Store ou Play Store.

- [Seleção de versão e publicação](https://rogueon.ai/pt-br/docs/publishing)

## Disponibilidade e capacidade

A Rogue está em beta gratuito com limites de uso por sessão e semana. O Free é o plano em uso; o Go e o Max aparecem abaixo com preço e ainda não estão à venda. Uso da conta, limites de contexto e cotas de provedores externos são restrições distintas.

- Free: R$ 0/mês.
- Go: R$ 50/mês (em breve).
- Max 5x: R$ 250/mês (em breve).
- Max 25x: R$ 750/mês (em breve).

- [Capacidade e limites de pedidos](https://rogueon.ai/pt-br/docs/plans-and-limits)
- [Planos e disponibilidade](https://rogueon.ai/pt-br/pricing)

## Integração de runtime e agentes

Diferencie conectores da conta, dependências do app gerado e acesso de agentes à documentação. Um item do catálogo não estabelece uma conta conectada. Exportar o frontend não fornece autenticação hospedada ou proxies de credenciais. Valide conexão, permissões, comportamento de origem e resposta do provedor.

Os guias públicos estão disponíveis em HTML canônico e Markdown equivalente. Use a referência de integração com agentes para descoberta e interfaces de documentação suportadas; ler documentação não autoriza ações em projetos privados.

- [Fronteiras das integrações](https://rogueon.ai/pt-br/docs/integrations)
- [Autenticação e dados](https://rogueon.ai/pt-br/docs/data-and-permissions)
- [Integração com agentes](https://rogueon.ai/pt-br/docs/agent-integration)

## Diagnóstico e referências

Para relatar uma falha, inclua versão testada, ambiente, reprodução mínima, resultado esperado e observado e evidências de rede ou console sem dados sensíveis. Identifique se ocorre na prévia, no site publicado ou no projeto exportado.

- [Diagnóstico de runtime](https://rogueon.ai/pt-br/docs/troubleshooting)
- [Sobre a Rogue](https://rogueon.ai/pt-br/about)
- [Contato](https://rogueon.ai/pt-br/contact)
- [caio@rogueon.ai](mailto:caio@rogueon.ai)
- [Política de Privacidade](https://rogueon.ai/pt-br/privacy)



# Fluxo de desenvolvimento

> Crie um projeto web com escopo definido e acompanhe o ciclo de pedido, build, prévia e publicação.

[Página canônica](https://rogueon.ai/pt-br/docs/getting-started)

## Defina o artefato e suas dependências

A Rogue produz artefatos web a partir de uma especificação e de pedidos de alteração. O resultado salvo pode ser uma página HTML direta ou um projeto com fontes Vite. Identifique a saída real antes de assumir framework, gerenciador de pacotes, backend ou processo de deploy.

Comece com uma entrega pequena e verificável: uma rota ou tela, dados de entrada explícitos e critérios de aceite observáveis. Separe interface, persistência, autenticação e serviços externos. Dados simulados são úteis para um protótipo, mas não equivalem a um backend funcional.

## Inicie uma conversa em Sites

1. **Abra o ambiente web**

   Abra Sites pelo link abaixo e autentique-se se solicitado. A entrada geral do app pode abrir Chat; Sites e Slides são modos de saída distintos.

2. **Envie a especificação**

   Declare o artefato, os dados de teste, os estados necessários e os critérios de aceite. Anexe apenas as fontes necessárias para essa alteração. Responda aos pedidos de esclarecimento na mesma conversa.

3. **Acompanhe o resultado**

   Diferencie pedido aceito, build em execução, execução interrompida ou com falha e prévia pronta. Enviar um pedido não comprova a conclusão do artefato.

- [Abrir Sites](https://app.rogueon.ai/build?format=site)

## Especificação mínima reproduzível

**Protótipo apenas de frontend**

```text
Artefato: lista responsiva de tarefas.
Dados: três registros de teste com id, título, status e prioridade.
Comportamento: filtrar por status e combinar com busca pelo título.
Estados: carregamento, resultado vazio e lista preenchida.
Limites: apenas dados simulados; sem login, banco ou chamadas externas.
Aceite: filtrar não altera os dados originais; limpar os filtros restaura todos os itens; todos os controles são acessíveis por teclado.
Informe o formato gerado e qualquer requisito não implementado.
```

## Valide antes de avançar a publicação

Inspecione a prévia e os arquivos salvos, execute os critérios de aceite e associe as falhas à versão testada. Continue com uma alteração delimitada, em vez de mudar a especificação e investigar uma falha de runtime no mesmo pedido.

Publicar seleciona explicitamente a versão servida no endereço público do site. Um build posterior permanece na prévia até ser publicado. A exportação para GitHub é um canal independente de entrega do código; nenhuma dessas operações transfere registros do banco ou credenciais de serviços.

## Guias relacionados

- [Arquitetura do projeto e do runtime](https://rogueon.ai/pt-br/docs/project-architecture)
- [Especificações e contexto](https://rogueon.ai/pt-br/docs/prompting)
- [Prévia e validação de runtime](https://rogueon.ai/pt-br/docs/preview-and-testing)



# Arquitetura do projeto e do runtime

> Identifique saídas HTML e Vite, fontes e artefatos de build e os serviços hospedados dos quais o frontend pode depender.

[Página canônica](https://rogueon.ai/pt-br/docs/project-architecture)

## Identifique o formato gerado

A saída web da Rogue tem dois caminhos de artefato. Uma página HTML direta é entregue como index.html com os assets associados. Um projeto Vite tem fontes e etapa de build; pode usar HTML e TypeScript, uma ilha React ou uma aplicação React. Inspecione package.json e os imports reais: Vite por si só não implica React. Os arquivos salvos determinam a arquitetura recebida.

|  | HTML direto | Projeto Vite |
| --- | --- | --- |
| Fontes | index.html e assets associados. | index.html, fontes em src/ e assets em public/ conforme a versão salva. |
| Exportação GitHub | Página, assets e README. | Fontes, assets, package.json, configuração Vite/TypeScript e README. |
| Build local | Nenhuma compilação obrigatória para a página. | Scripts do package.json; saída padrão em dist/. |
| Runtime | Navegador e serviços de rede usados pelo HTML. | JavaScript/CSS compilados no navegador e serviços de rede usados pelo app. |

## Fontes não são o bundle publicado

Para saídas Vite, edite as fontes no seu ambiente e gere outro build; editar dist diretamente não é uma alteração durável nas fontes. Inspecione scripts e README da versão exportada. O projeto entregue ao GitHub acrescenta scripts dev, build e preview, mas não recria a aplicação de servidor da Rogue.

Para HTML direto, sirva o diretório exportado para testar assets relativos e comportamento do navegador. O exemplo abaixo exige Python 3 e atende apenas na interface local. Ele verifica entrega estática, não a presença dos serviços de backend.

**HTML direto: servidor estático local**

```sh
python3 -m http.server 8000 --bind 127.0.0.1
```

## Mapeie a fronteira entre frontend e serviços

Um projeto pode renderizar sem backend, guardar estado local no navegador ou depender de persistência e autenticação gerenciadas. São arquiteturas diferentes. Em projetos com banco, inspecione o painel de dados e o código gerado. Não infira persistência por um formulário que apenas altera estado local.

Autenticação gerenciada e chamadas com chaves de provedores podem depender de roteamento no servidor da origem da página. Copiar os arquivos do frontend para outro host não copia essas implementações, credenciais ou configuração de origem. Levante cada dependência de rede antes de escolher um destino de deploy.

## Registre o contrato de deploy

- Formato, entradas das fontes, assets, comando de build e diretório de saída.
- URLs de runtime necessárias, fluxo de autenticação, origens permitidas e premissas de sessão.
- Responsável pelos dados, schema, plano de migração/exportação e testes de autorização.
- Credenciais externas, responsável pela cobrança, cotas e tratamento de falhas.
- Revisão exata das fontes e evidências de validação do artefato publicado.

## Guias relacionados

- [Exportação e desenvolvimento externo](https://rogueon.ai/pt-br/docs/exporting)
- [Autenticação, dados e permissões](https://rogueon.ai/pt-br/docs/data-and-permissions)
- [Prévia e validação de runtime](https://rogueon.ai/pt-br/docs/preview-and-testing)



# Especificações e contexto

> Estruture pedidos por contratos, invariantes, dependências e critérios de aceite observáveis.

[Página canônica](https://rogueon.ai/pt-br/docs/prompting)

## Defina um contrato para a alteração

Trate o pedido como uma especificação contra a qual o resultado possa ser verificado. Identifique a tela ou componente, o formato dos dados, as ações, os estados de falha e o que está fora do escopo. Em um projeto existente, indique os comportamentos que devem permanecer.

- Entradas: nomes e tipos dos campos, exemplos válidos e inválidos e fonte de verdade.
- Transições: estado inicial, carregamento, sucesso, vazio, erro e comportamento da repetição.
- Dependências: diferencie dados simulados, armazenamento no navegador, backend compartilhado e serviços externos.
- Invariantes: regras de autorização, campos imutáveis, ordenação e comportamento público existente.

## Peça uma implementação delimitada

**Especificação de alteração**

```text
Alvo: tela existente de lista de tarefas.
Alteração: adicionar filtro de status com valores all/open/closed.
Contrato de dados: { id: string, title: string, status: 'open' | 'closed' }.
Preservar: IDs, ordenação existente, navegação para detalhes e tokens visuais.
Estado vazio: mensagem clara e ação Limpar filtros.
Aceite:
- Filtro e busca textual funcionam juntos.
- Limpar restaura a ordem original.
- Filtragem local não acrescenta chamada de rede.
- Controles têm rótulos acessíveis e foco por teclado.
Retorno: arquivos alterados, validação executada e dependências pendentes.
```

## Forneça contexto de referência delimitado

O composer de Sites aceita menções a fontes, URLs de referência, arquivos de texto compatíveis e imagens. Declare qual aspecto da referência é obrigatório: schema, conteúdo, layout ou comportamento. Uma URL fornece contexto; não autoriza acesso a contas nem importa o backend do sistema referenciado.

Os formatos de texto aceitos incluem TXT, Markdown, CSV, JSON, HTML, CSS, JavaScript e TypeScript. Esse caminho espera UTF-8, não documentos binários. O contexto de menções tem limite próprio, separado do tamanho do arquivo; use o menor trecho que preserve o contrato, em vez de anexar toda a árvore de dependências.

## Separe geração e avaliação

Mantenha critérios concretos o suficiente para executar manualmente ou no seu ambiente de testes. Pedir testes não comprova que foram executados: confira a validação relatada e reproduza os comportamentos críticos. Diferencie dependências implementadas, simuladas e indisponíveis no resultado.

Use registros sintéticos e marcadores para credenciais. Conecte serviços pelos controles próprios depois de definir fluxo de dados, permissões e responsabilidade pelas cobranças.

## Guias relacionados

- [Ciclo de build e revisões](https://rogueon.ai/pt-br/docs/build-and-refine)
- [Autenticação, dados e permissões](https://rogueon.ai/pt-br/docs/data-and-permissions)
- [Prévia e validação de runtime](https://rogueon.ai/pt-br/docs/preview-and-testing)



# Ciclo de build e revisões

> Acompanhe o estado dos pedidos, inspecione arquivos alterados e separe revisões do artefato, publicação e mudanças de dados.

[Página canônica](https://rogueon.ai/pt-br/docs/build-and-refine)

## Mantenha a revisão vinculada ao contexto

Continue na conversa existente para revisar o artefato atual. Um pedido de alteração usa o contexto do projeto; outra conversa é um ponto de partida diferente. Identifique a versão testada e a mudança necessária, principalmente quando uma versão pública e uma prévia mais recente coexistem.

Um pedido pode exigir esclarecimento, executar, falhar, ser interrompido ou produzir uma prévia pronta. A disponibilidade de Parar, repetir ou retomar depende desse estado. Uma conexão interrompida não comprova que o processamento no servidor deixou de concluir.

## Delimite a revisão

**Pedido de alteração com controle de regressão**

```text
Base: a prévia atual desta conversa.
Observado: enviar um título vazio cria um item vazio na lista.
Esperado: rejeitar títulos vazios ou apenas com espaços antes de criar o item.
Preservar: IDs estáveis, filtro de status, ordenação e layout atual.
Validar: entrada vazia, espaços, entrada válida, envio repetido e envio por teclado.
Não adicione persistência nem altere o modelo de dados. Informe arquivos alterados e resultados da validação.
```

## Inspecione a diferença produzida

Quando o cartão de arquivos alterados estiver presente, Revisar abre o arquivo e as diferenças disponíveis. Confira adições, remoções e mudanças inesperadas fora do escopo. Diferenças grandes podem ser apresentadas como arquivo completo, sem comparação linha a linha.

O painel de código exibe fontes salvas e permite copiar; não é um editor de fontes no próprio painel. Para desenvolvimento externo, exporte o artefato e use suas ferramentas. Uma prévia funcional, um diff e um build de produção sem erros respondem a perguntas distintas e devem ser verificados separadamente.

## Separe reversão de artefato e de dados

Desfazer, quando disponível, volta a uma versão anterior do artefato após confirmação e exige o contexto de quem criou o projeto. Também pode afetar a versão no endereço publicado. Não fornece rollback de transações do banco, e-mails enviados ou ações concluídas em serviços externos.

Alterações comuns permanecem na prévia até publicação explícita. Se a conversa estiver vinculada ao GitHub, versões concluídas podem gerar commits de forma independente. Confira o site publicado e o estado do repositório ao coordenar uma entrega.

## Guias relacionados

- [Prévia e validação de runtime](https://rogueon.ai/pt-br/docs/preview-and-testing)
- [Publicação e seleção de versão](https://rogueon.ai/pt-br/docs/publishing)
- [Exportação e desenvolvimento externo](https://rogueon.ai/pt-br/docs/exporting)



# Prévia e validação de runtime

> Valide o artefato renderizado, as dependências de rede, a autorização e a versão exata selecionada para publicação.

[Página canônica](https://rogueon.ai/pt-br/docs/preview-and-testing)

## Entenda o ambiente de teste

A prévia integrada renderiza a página gerada em um iframe. Os controles desktop e mobile redimensionam esse espaço preservando o estado; não emulam sistema operacional, engine do navegador, rede ou sessão nova. Reproduza fluxos críticos em outra aba e no navegador ou aparelho de destino.

Identifique a URL e a versão da prévia antes de registrar uma falha. Para diagnosticar o frontend, abra o DevTools na página gerada: confira erros do console e a requisição que falhou, incluindo status, resposta e origem. Remova cabeçalhos de autorização, cookies, tokens e dados pessoais antes de compartilhar evidências.

## Matriz de validação

| Camada | Verificações |
| --- | --- |
| Renderização | Sem erros não tratados; assets carregam; estados vazio, carregamento e erro estão visíveis quando esperados. |
| Interação | Teclado, foco, validação de entrada, envio repetido e navegação preservam o contrato. |
| Persistência | Dados sobrevivem ao reload e aparecem em outro cliente quando devem ser compartilhados. |
| Autorização | Usuário A não lê nem altera registros privados de B; acesso anônimo respeita as regras. |
| Serviços | A resposta corresponde ao serviço real; falhas e limites não viram sucesso fictício. |
| Publicação | O endereço público serve a versão aprovada e mantém o fluxo principal funcional. |

## Registre uma falha reproduzível

**Relato de defeito em runtime**

```text
Versão / URL: [artefato testado]
Ambiente: [navegador, viewport, autenticado ou anônimo]
Pré-condições: [registros sintéticos e estado inicial]
Passos: [menor sequência]
Esperado: [contrato]
Observado: [resultado visível]
Evidência: [mensagem do console ou status da requisição, sem dados sensíveis]
Regressão: [comportamentos que devem permanecer]
Corrija a causa e informe quais verificações foram realmente executadas.
```

## Valide a versão candidata à publicação

Reproduza o teste na revisão e execute as verificações de regressão próximas. Uma renderização estática não valida permissões do banco nem um fluxo de pagamento. Use contas de teste e ambientes de teste dos serviços quando disponíveis; diferencie simulação de ações externas concluídas.

Depois de publicar, repita o caminho crítico no endereço público. Fontes, arquivos publicados e configuração de runtime podem divergir; valide o destino em vez de inferir seu estado pelo resultado do build.

- [Diagnosticar falhas na prévia](https://rogueon.ai/pt-br/docs/troubleshooting#preview)

## Guias relacionados

- [Ciclo de build e revisões](https://rogueon.ai/pt-br/docs/build-and-refine)
- [Autenticação, dados e permissões](https://rogueon.ai/pt-br/docs/data-and-permissions)
- [Publicação e seleção de versão](https://rogueon.ai/pt-br/docs/publishing)



# Publicação e seleção de versão

> Publique um artefato revisado no endereço gerenciado e diferencie publicação, prévia, entrega no GitHub e migração de dados.

[Página canônica](https://rogueon.ai/pt-br/docs/publishing)

## O endereço público aponta para uma versão selecionada

Concluir um build de site produz uma prévia versionada. Publicar seleciona essa versão para o endereço público gerenciado da conversa. Um build posterior normalmente não substitui o artefato no ar até outra publicação. Registre a versão testada antes da publicação para não confundir uma prévia posterior com a versão aprovada.

Essa operação altera qual artefato o endereço serve. Não é migração de banco, transferência de contas de serviços nem push para GitHub. Esses estados precisam de verificação própria quando a entrega muda mais do que arquivos de frontend.

## Publique uma versão revisada

1. **Selecione o artefato pronto**

   Abra a conversa original do site com acesso de proprietário. Confirme que a geração terminou e que a prévia exibida é a versão testada.

2. **Execute Publicar**

   Use Publicar e aguarde o estado de sucesso e o endereço retornado. Um controle desabilitado ou uma mensagem de erro não confirma um deploy.

3. **Valide o destino**

   Copie o link público, abra separadamente e confira o fluxo crítico, os assets, a autenticação e as chamadas de serviços aplicáveis ao projeto.

## Coordene revisões e entrega no repositório

Diferencie a prévia mais recente, a versão pública selecionada e o último commit do GitHub. A integração com GitHub pode criar commits para alterações concluídas depois que a conversa está vinculada; isso não publica essas alterações no endereço do site.

Se o site parecer inalterado, confira o endereço público e a versão selecionada antes de iniciar outro build. Ao usar Desfazer, leia a confirmação: reverter um artefato pode afetar a versão pública, mas não reverte alterações no banco ou efeitos externos.

## Compartilhar um link e aparecer na busca

Os endereços de sites gerenciados pela Rogue retornam hoje o cabeçalho HTTP X-Robots-Tag: noindex. Eles servem para revisar e compartilhar o artefato web selecionado, não para indexação na busca. Título, descrição ou cartão social não anulam esse cabeçalho. Quem tiver o link público ainda pode abrir o site: noindex não é controle de acesso.

Se aparecer na busca for um requisito do projeto, exporte o código e configure outra hospedagem sob seu controle. Revise os arquivos para identificar informações privadas, configure os serviços de runtime necessários e confirme respostas indexáveis no destino antes de enviar o sitemap dele. Exportar não garante indexação nem transfere automaticamente serviços de backend.

- [Exportar e configurar o destino](https://rogueon.ai/pt-br/docs/exporting#search-ready-hosting)

## Limites do deploy

A publicação gerenciada inclui hospedagem do artefato web. Domínios próprios ainda não são suportados por esse fluxo do produto. A saída de Sites roda no navegador; esse não é um fluxo de build .apk ou .ipa nem de envio para App Store ou Play Store. Slides têm um caminho de entrega separado.

Publicar exige o contexto de proprietário. Se o app pedir o navegador ou a conversa original, recupere esse contexto em vez de limpar o armazenamento do navegador. Para erros de rede ou de serviço temporário, confira o estado e tente publicar novamente; não regenere um artefato correto apenas para repetir a entrega.

## Guias relacionados

- [Prévia e validação de runtime](https://rogueon.ai/pt-br/docs/preview-and-testing)
- [Exportação e desenvolvimento externo](https://rogueon.ai/pt-br/docs/exporting)
- [Diagnóstico de runtime](https://rogueon.ai/pt-br/docs/troubleshooting)



# Exportação e desenvolvimento externo

> Inspecione as fontes salvas, entregue ao GitHub e configure build e runtime para desenvolvimento fora da Rogue.

[Página canônica](https://rogueon.ai/pt-br/docs/exporting)

## Propriedade e escopo da exportação

O código gerado é seu; a Rogue em si não é open source. A exportação depende da versão salva e do formato do artefato. A saída HTML direta contém a página e os assets associados. Exportações Vite incluem fontes salvas, configuração do projeto e README gerado. Inspecione a árvore exportada em vez de assumir que toda saída é um projeto React.

## Inspecione as fontes e estabeleça uma base local

Nas ações da prévia, abra Ver código, selecione um arquivo e use Copiar. Isso copia o arquivo aberto, não o projeto inteiro ou seus assets. Use o caminho do GitHub para obter o conjunto do projeto quando disponível. O visualizador não oferece edição de fontes no próprio painel.

Em uma exportação Vite, inspecione README e package.json antes de instalar dependências. Se os scripts exportados incluírem dev, build e preview, os comandos abaixo estabelecem a base do frontend. Execute na raiz do repositório com um ambiente Node compatível e use o endereço informado no terminal.

**Exportação Vite com os scripts npm gerados**

```sh
npm install
npm run dev
# Encerre o servidor de desenvolvimento antes dos próximos comandos.
npm run build
npm run preview
```

## Entenda o modelo de atualização do repositório

Quando a integração estiver disponível, conecte o GitHub e use a ação Publicar no GitHub do projeto. A primeira publicação cria um repositório privado. Versões posteriores concluídas em uma conversa vinculada podem gerar commits automaticamente.

Arquivos gerados podem ser reescritos por atualizações posteriores da Rogue. Se o repositório tiver commits além da última atualização da Rogue, a integração pode criar uma branch para comparação em vez de sobrescrever esse histórico. Revise a branch e o diff antes do merge; mantenha mudanças independentes em uma branch própria ao coordenar os dois fluxos.

O README gerado e as mensagens de commit podem conter texto do pedido. Antes de compartilhar o repositório ou mudar sua visibilidade, revise README, fontes, assets e histórico Git para identificar informações confidenciais.

> **Escopo OAuth**
> A permissão repo do GitHub é mais ampla do que os repositórios criados pela Rogue. A implementação usa esse acesso nos repositórios que cria, mas a autorização é abrangente. Desconectar preserva os repositórios existentes.

## Prepare o site exportado para a busca

Escolha uma hospedagem para o artefato exportado. Uma página HTML direta precisa servir index.html e assets juntos. Uma exportação Vite precisa executar o build documentado e publicar a saída resultante. Comece com um site informativo estático quando não precisar de backend. Domínio próprio e indexação nesse destino são configurados fora da Rogue.

1. **Verifique o endereço final**

   Confira a resposta real da página e os assets no domínio de destino. Páginas destinadas ao público precisam retornar 200, ter conteúdo útil visível e não ter cabeçalho ou meta tag noindex acidental. Permitir acesso em robots.txt, sozinho, não anula noindex.

2. **Descreva a página publicada**

   Use título, resumo, heading principal e URL canônica reais do destino. Ligue as páginas úteis pela navegação. Verifique os cartões sociais com imagens autorizadas em vez de assumir que a prévia do editor é igual ao link compartilhado.

3. **Verifique a propriedade e facilite a descoberta**

   Verifique o destino no Search Console, inspecione URLs representativas e envie um sitemap com as páginas públicas canônicas. Acompanhe indexação e desempenho na busca. Descoberta, indexação, posições e tráfego são resultados separados; publicar não garante nenhum deles.

- [Requisitos técnicos da Pesquisa Google](https://developers.google.com/search/docs/essentials/technical)

## Migre as dependências de runtime separadamente

Um build de frontend bem-sucedido não recria autenticação hospedada, proxies de serviços, registros do banco ou credenciais. Levante caminhos relativos de rede, origens permitidas, sessões, configuração de ambiente e propriedade dos dados. Implemente ou reconfigure os serviços necessários no destino antes de redirecionar usuários.

- [Arquitetura dos artefatos HTML e Vite](https://rogueon.ai/pt-br/docs/project-architecture)

## Guias relacionados

- [Arquitetura do projeto e do runtime](https://rogueon.ai/pt-br/docs/project-architecture)
- [Autenticação, dados e permissões](https://rogueon.ai/pt-br/docs/data-and-permissions)
- [Publicação e seleção de versão](https://rogueon.ai/pt-br/docs/publishing)



# Fronteiras das integrações

> Diferencie conectores da conta, chamadas de serviços do app gerado, permissões e cobrança externa.

[Página canônica](https://rogueon.ai/pt-br/docs/integrations)

## Conector da conta ou dependência do app?

Conexões da conta operam no fluxo da Rogue: GitHub entrega código e Gmail pode enviar um rascunho revisado quando disponível. As dependências de serviços de um app gerado são separadas. Conectar Gmail à conta da Rogue não configura um backend de e-mail para cada formulário gerado.

| Superfície | Verifique |
| --- | --- |
| Conexão da conta | Conta autorizada, escopos concedidos, estado conectado e ação permitida. |
| Dependência do app | Endpoint de destino, execução no cliente ou servidor, credencial, cota e conta responsável pela cobrança. |
| Item do catálogo | Disponibilidade real; Em breve não é uma conexão ativa. |

## Valide autorização e estado da conexão

Use Preferências > Conexões para os serviços oferecidos à sua conta. Revise a tela de autorização do provedor e confirme a conta e as permissões exibidas ao voltar à Rogue. Disponibilidade e autorização concluída são estados distintos.

Ao desconectar, confira se a revogação no provedor foi confirmada. Se apenas a conexão local foi removida, conclua a revogação nas configurações da conta do serviço. Um repositório ou uma mensagem já enviada não desaparece ao desconectar um conector.

## Gmail: rascunho, autorização e envio explícito

Para contas com Gmail disponível, a conversa pode produzir um cartão de rascunho. Inspecione destinatários, assunto e corpo antes de Enviar ou Conectar e enviar. A operação de envio depende dessa ação explícita. Se a ação disponível for Abrir no Gmail, a entrega é concluída fora da Rogue, não por uma operação de envio conectado.

Leitura e busca na caixa de entrada exigem disponibilidade e permissão separadas. Não infira acesso de leitura pela permissão de envio nem pelo login na Rogue com uma conta Google.

## Configuração de serviços do app gerado

Quando Chaves de API do app estiver disponível, use essa interface para credenciais compatíveis. Chamadas gerenciadas podem passar pelo servidor da Rogue para que a chave do provedor não fique no frontend. Esse roteamento é uma dependência do runtime hospedado; um frontend estático exportado não o implementa automaticamente.

Valide a resposta real e o tratamento de falhas do serviço depois da configuração. Chamadas ao provedor podem consumir créditos e cotas dessa conta independentemente do uso da Rogue. Remoção da chave, revogação ou cota do provedor podem interromper um artefato que não mudou.

## Guias relacionados

- [Autenticação, dados e permissões](https://rogueon.ai/pt-br/docs/data-and-permissions)
- [Exportação e desenvolvimento externo](https://rogueon.ai/pt-br/docs/exporting)
- [Diagnóstico de runtime](https://rogueon.ai/pt-br/docs/troubleshooting)



# Autenticação, dados e permissões

> Separe acesso à conta Rogue, sessões do app gerado, políticas de autorização, credenciais e portabilidade dos dados.

[Página canônica](https://rogueon.ai/pt-br/docs/data-and-permissions)

## Separe as fronteiras de confiança

Sua sessão na Rogue dá acesso ao construtor. Uma sessão de usuário dentro do app gerado pertence ao fluxo de autenticação desse app. Acesso ao banco e autorização de serviços externos são fronteiras adicionais. Sucesso em uma camada não implica acesso às demais.

Trate arquivos de frontend, conteúdo renderizado e assets baixados como observáveis pelo cliente. Uma URL de prévia ou instrução noindex não é mecanismo de autorização. Use dados sintéticos nas especificações e mantenha segredos fora de prompts, bundles do cliente, URLs, capturas e fontes exportadas.

## Autenticação não define autorização

Um formulário de login estabelece identidade apenas quando está ligado ao serviço de autenticação do app. A autorização ainda precisa limitar quais registros e ações essa identidade pode acessar. Teste acesso anônimo, dois usuários distintos e eventuais perfis administrativos; esconder um controle na interface não aplica permissão no servidor.

Em projetos com banco gerenciado, a autenticação pode depender de roteamento na mesma origem e cookies de sessão vinculados ao host. Mover os arquivos do frontend para outro host muda esse ambiente. Revise origens, cookies, obtenção de sessão e configuração de acesso aos dados, em vez de apenas copiar uma URL de produção para o projeto local.

## Valide armazenamento e propriedade das credenciais

| Fronteira | Verificação necessária |
| --- | --- |
| Persistência | Diferencie estado em memória, armazenamento local do navegador e registros compartilhados no backend. |
| Isolamento | Verifique leitura e escrita com dois usuários; valide políticas no serviço de dados, não só no filtro visual. |
| Credenciais | Use o controle de chaves compatível; identifique responsável pela conta, cobrança, revogação e rotação. |
| Ciclo do banco | Leia estado, expiração e transferência exibidos; banco provisório não significa armazenamento permanente. |

## Portabilidade de código e de dados são distintas

Uma exportação de repositório contém artefatos de frontend, não uma migração completa de registros, identidades, chaves ou infraestrutura de servidor. Antes da mudança, levante dependências, defina como dados e contas serão transferidos, valide o acesso no destino e mantenha um plano de recuperação do ambiente de origem.

Consulte a Política de Privacidade para as condições de tratamento de dados da Rogue e o contato do time para solicitações relativas à conta. Este guia técnico não estabelece garantia de retenção para todos os apps gerados ou provedores.

- [Política de Privacidade](https://rogueon.ai/pt-br/privacy)
- [Contato](https://rogueon.ai/pt-br/contact)

## Guias relacionados

- [Arquitetura do projeto e do runtime](https://rogueon.ai/pt-br/docs/project-architecture)
- [Fronteiras das integrações](https://rogueon.ai/pt-br/docs/integrations)
- [Exportação e desenvolvimento externo](https://rogueon.ai/pt-br/docs/exporting)



# Capacidade e limites de uso

> Interprete disponibilidade do beta, capacidade de sessão e semana, limites de contexto e cotas externas como restrições distintas.

[Página canônica](https://rogueon.ai/pt-br/docs/plans-and-limits)

## Disponibilidade atual

A Rogue está em beta gratuito com limites de uso. Não há checkout nem plano pago à venda; todo mundo está no plano Free. O Go e o Max estão anunciados na página de planos e ainda não abriram. Fale com o time se um projeto precisar de mais capacidade.

Capacidade não é uma quantidade determinística de prompts ou apps concluídos. Carga de trabalho, atividade de modelos e execução de ferramentas variam por pedido. Use os medidores da conta e os avisos de limite ao planejar uma execução maior, em vez de estimá-la de antemão.

- [Planos e disponibilidade](https://rogueon.ai/pt-br/pricing)

## Inspecione o estado da conta

Preferências > Conta mostra o uso da sessão atual e da semana. Confira os dois medidores e o horário de renovação exibido. Um aviso, um limite atingido e uma falha de provedor são condições distintas; use o contexto do erro antes de repetir um pedido.

A sessão de uso é independente da sessão de autenticação. Sair da conta, abrir outra aba ou reiniciar o navegador não reinicia a janela de consumo.

## Identifique a camada que impõe o limite

| Restrição | Interpretação |
| --- | --- |
| Sessão de uso | Janela de cinco horas iniciada por um pedido quando não há sessão de uso aberta. |
| Semana | Janela de sete dias em cadência a partir do primeiro pedido; use o prazo exibido na conta. |
| Contexto de Sites | Até oito menções, 16.000 caracteres de contexto de menções e 20.000 no pedido expandido. |
| Arquivos de texto | Até quatro por seleção, 48 KB por arquivo e 64 KB no conjunto; o limite de contexto ainda se aplica. |
| Serviço externo | Cota, cobrança, prazo e limite de chave do provedor são independentes da capacidade da Rogue. |

## Reduza trabalho evitável

Delimite mudanças sobre o artefato atual, forneça o trecho de referência relevante e explicite a validação. Diagnostique falhas de carregamento da prévia ou de publicação antes de repetir a geração: repetir a entrega e gerar outro artefato têm custos e efeitos diferentes.

Ao atingir um limite, siga a renovação ou recuperação indicada. Envios repetidos não criam capacidade extra. Limites de serviços externos precisam ser resolvidos na configuração ou na conta responsável pelas chamadas.

## Guias relacionados

- [Especificações e contexto](https://rogueon.ai/pt-br/docs/prompting)
- [Diagnóstico de runtime](https://rogueon.ai/pt-br/docs/troubleshooting)
- [Fronteiras das integrações](https://rogueon.ai/pt-br/docs/integrations)



# Diagnóstico de runtime

> Classifique falhas de pedido, geração, carregamento, dependências de runtime e publicação antes de repetir a execução.

[Página canônica](https://rogueon.ai/pt-br/docs/troubleshooting)

## Aceitação do pedido e contexto

Primeiro determine se o pedido foi enviado e aceito. Um erro no composer pode indicar anexos ausentes, contexto excessivo, autenticação, limite de uso ou execução ativa. Corrija essa condição antes de investigar o código gerado. Para acesso expirado ou fluxo por código de e-mail, siga a tela real, sem assumir que um provedor específico esteja habilitado.

## Carregamento do artefato ou falha da aplicação

Abra a prévia separadamente e inspecione Console e Network no DevTools. Registre a URL sem segredos, o status HTTP, o tipo de resposta, a mensagem visível e se falhou o documento, um asset ou uma chamada de serviço. Uma resposta 200 para HTML não comprova que o JavaScript iniciou ou que as consultas funcionaram.

Use Recarregar prévia ou a ação de recuperação oferecida para falhas de carregamento. Para um defeito de runtime, reproduza a menor sequência de interação e envie a evidência com a versão correspondente. Se a exportação externa funciona visualmente, mas login ou serviços falham, investigue roteamento ausente no host antes de reescrever a interface.

## Geração interrompida

Leia o último estado e use a ação específica: Tentar reconectar, Retomar construção ou Tentar de novo quando disponível. Elas não são equivalentes. Antes de iniciar um pedido duplicado, verifique se um artefato foi salvo ou se a execução anterior se recuperou. A desconexão do cliente não comprova cancelamento da operação no provedor.

## Publicação e propriedade

Compare a versão da prévia com a versão pública. Alterações comuns exigem outra ação Publicar. Se a publicação indicar falta de acesso de proprietário, reabra a conversa ou o navegador original conforme solicitado. Limpar o armazenamento local pode remover contexto útil e não deve ser a primeira etapa de diagnóstico.

## Falhas de credencial, origem e cota

Confira o estado da conexão, o estado da chave do projeto e a resposta do provedor. Diferencie integração indisponível, conta desconectada, chave ausente ou rejeitada, incompatibilidade de origem ou sessão e cota esgotada. Use a mensagem exibida e os detalhes da resposta; o status HTTP isolado não identifica a causa.

## Forneça um relato de diagnóstico

**Relato ao suporte**

```text
URL do projeto/conversa e versão testada:
Horário e fuso:
Navegador/aparelho e estado de autenticação:
Reprodução mínima:
Resultado esperado e observado:
Status da requisição ou mensagem do console (sem dados sensíveis):
Ocorre na prévia, no site público ou no projeto exportado:
Ações de recuperação já tentadas:
```

- [Contato para suporte técnico](https://rogueon.ai/pt-br/contact)

## Guias relacionados

- [Prévia e validação de runtime](https://rogueon.ai/pt-br/docs/preview-and-testing)
- [Arquitetura do projeto e do runtime](https://rogueon.ai/pt-br/docs/project-architecture)
- [Capacidade e limites de uso](https://rogueon.ai/pt-br/docs/plans-and-limits)



# Integração com agentes

> Conecte seu agente de código à documentação da Rogue. Busque, leia uma seção e confira a fonte por um servidor MCP de leitura.

[Página canônica](https://rogueon.ai/pt-br/docs/agent-integration)

## Conecte um cliente MCP

O endpoint público é `https://rogueon.ai/mcp`. Escolha Streamable HTTP no cliente MCP. A leitura da documentação não exige chave de API, conta, OAuth ou assinatura de modelo. Deixe o cliente negociar o protocolo; o endpoint aceita o protocolo 2026-07-28 e clientes compatíveis de 2025.

No Cursor, acrescente a entrada abaixo ao `.cursor/mcp.json` do projeto, preservando servidores existentes. Recarregue a configuração MCP e confirme a presença de `list_docs`, `search_docs` e `get_doc`. Outros editores podem usar um formato de configuração diferente para o mesmo endpoint.

**Cursor · .cursor/mcp.json**

```json
{
  "mcpServers": {
    "rogue-docs": {
      "url": "https://rogueon.ai/mcp"
    }
  }
}
```

- [Referência de configuração MCP do Cursor](https://cursor.com/docs/mcp)

## Claude Code

Execute no projeto em que quer disponibilizar a documentação. O comando registra o servidor remoto; não gera nem publica um app. Use `/mcp` no Claude Code para inspecionar a conexão. Se `rogue-docs` já estiver configurado, confira ou atualize essa entrada em vez de criar uma duplicata.

**Claude Code · terminal**

```bash
claude mcp add --transport http rogue-docs https://rogueon.ai/mcp
```

- [Referência HTTP MCP do Claude Code](https://code.claude.com/docs/en/mcp)

## Contrato das ferramentas

Todas as ferramentas aceitam `locale`: `en` ou `pt-br`, com padrão `en`. Os resultados incluem URLs de referência. Recursos Markdown também são descobertos por `resources/list` e lidos por `resources/read`.

| Ferramenta | Argumentos | Resultado |
| --- | --- | --- |
| `list_docs` | `locale?` | Catálogo com slugs, URLs, seções e hashes do conteúdo. |
| `search_docs` | `query`, `locale?`, `limit?` | Trechos ordenados por relevância e links canônicos para seções. Limite 1–16; padrão 8. |
| `get_doc` | `slug`, `locale?`, `section?` | Markdown completo ou uma seção quando seu ID é informado, com hash SHA-256. |

**get_doc · arguments**

```json
{
  "slug": "project-architecture",
  "locale": "pt-br",
  "section": "runtime-services"
}
```

## Busque → leia → verifique

1. **Encontre a fonte relevante**

   Use search_docs com uma consulta específica. A busca exige correspondência de todas as palavras, ignora acentos e retorna trechos; um trecho não é a referência completa.

2. **Leia a menor seção suficiente**

   Use o slug do documento e o ID da seção em get_doc. Omita section quando precisar do contexto completo. Preserve as condições sobre formato, runtime e disponibilidade ao resumir.

3. **Preserve a fonte e a revisão**

   Cite a URL canônica retornada e guarde o SHA-256 junto do contexto em cache. Confira o manifesto antes de reutilizar conteúdo antigo. O hash identifica conteúdo, não uma versão do produto ou data de atualização.

**Contexto de tarefa para um agente de código**

```text
Antes de alterar um projeto gerado pela Rogue:
1. Identifique o formato real do artefato pelos arquivos.
2. Busque nas docs o contrato de runtime ou exportação relevante.
3. Leia a seção com get_doc e preserve a URL canônica.
4. Separe comportamento documentado de premissas sobre este projeto.
5. Implemente a alteração solicitada e valide os critérios de aceite.
6. Relate fonte, arquivos alterados, validação e dependências pendentes.
```

## Consulte Markdown por HTTP

Cada artigo tem uma URL explícita terminada em `/markdown`. HTML e Markdown são gerados da mesma fonte; a resposta Markdown declara a URL HTML canônica. Esse caminho funciona com um cliente HTTP comum quando MCP não está disponível ou não é necessário.

**Ler a documentação de arquitetura**

```bash
curl -fsSL https://rogueon.ai/pt-br/docs/project-architecture/markdown
```

- [Arquitetura · Markdown](https://rogueon.ai/pt-br/docs/project-architecture/markdown)

## Use o hash do conteúdo no cache

O manifesto JSON usa `schemaVersion: 1` e lista `slug`, `url`, `markdownUrl`, `sha256`, quantidade de bytes e IDs de seção. O hash do documento corresponde ao corpo exato da resposta Markdown em UTF-8; hashes de seção correspondem ao Markdown daquela seção. O ETag HTTP identifica a representação do manifesto e aceita `If-None-Match` com resposta 304.

**manifest.json · HTTP**

```bash
curl -fsS -D - https://rogueon.ai/pt-br/docs/manifest.json
```

- [Abrir manifesto da documentação](https://rogueon.ai/pt-br/docs/manifest.json)

## Descoberta e corpus completo

`llms.txt` é o índice compacto de descoberta. `llms-full.txt` reúne os guias públicos nos dois idiomas. Prefira uma página ou seção nas consultas comuns; use o corpus completo quando uma tarefa offline precisar de cobertura ampla. Esses arquivos são recursos de descoberta, não regras de permissão de crawler nem garantia de ingestão.

- [llms.txt](https://rogueon.ai/llms.txt)
- [llms-full.txt](https://rogueon.ai/llms-full.txt)

## Transporte, limites e escopo

As ferramentas apenas leem conteúdo e não chamam modelos de linguagem. Seu agente de código continua tendo consumo e permissões próprios. Um Origin explícito de navegador precisa estar na lista aceita pelo servidor; clientes MCP de servidor podem conectar sem esse cabeçalho. Confira configuração e erros de protocolo antes de repetir, em vez de acrescentar credenciais que esse endpoint não exige.

| Contrato | Comportamento |
| --- | --- |
| HTTP | POST para MCP; chamadas bem-sucedidas retornam JSON. Sem stream SSE persistente, ID de sessão ou assinatura. GET retorna 405. |
| Entrada | Máximo de 16 KiB por requisição. Busca: 1–200 caracteres, até 12 palavras. Apenas slugs e IDs de seção do catálogo são aceitos. |
| Saída | Até 16 resultados de busca; máximo de 64 KiB de Markdown por documento. Falhas de validação retornam erros, sem conteúdo presumido. |
| Acesso | Somente documentação pública. Sem dados de contas, projetos privados ou ferramentas de execução, geração e publicação. |

## Guias relacionados

- [Arquitetura do projeto e do runtime](https://rogueon.ai/pt-br/docs/project-architecture)
- [Exportação e desenvolvimento externo](https://rogueon.ai/pt-br/docs/exporting)
- [Autenticação, dados e permissões](https://rogueon.ai/pt-br/docs/data-and-permissions)