# 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)