Development workflow

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. 01

   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. 02

   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. 03

   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

Minimal reproducible specification#

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.