Previews and Manual Checks
Purpose: Confirm the change works in the built frontend or live backend Preview before opening a pull request.
What Preview Shows
Preview is a header control on the work item view that opens the built application or live service for the session. For a frontend module it serves the built SPA — open / to land on the home route or any specific route to land there directly. For a backend module it calls the running service — enter a path such as /swagger-ui.html to land on API docs or any endpoint path the service exposes.
Preview is the end-to-end view; App → Pages and Components show isolated stories in Storybook. The two complement each other — Storybook is the right place to confirm a single component renders all its states, Preview is the right place to confirm the full screen behaves correctly when the user navigates through the app.
Triggering a Build
A Preview build runs on the session branch before the application or service is reachable, and the trigger lives in the work-item ⋮ menu under work-session actions. Use Rebuild to start a fresh build whenever the branch has changed materially — a new component generated, a new endpoint implemented, a follow-up commit from chat. Backend previews can go idle between uses; opening Preview wakes the service back up.
Update from Main also lives in the same menu and is the standard way to pick up changes from the repository's default branch into the session. Resolve any conflicts in Dev or in your usual Git workflow before you trigger the next Rebuild.
Manual Checks Against Acceptance Criteria
Acceptance criteria authored on the work item are the reviewer's checklist in Preview — walk each criterion against the built behaviour and confirm match or mismatch. The acceptance criteria sit on the Reqs tab and are visible while you have Preview open in another tab, so the checklist and the running application are side by side.
A useful diagnostic — when acceptance criteria are clear and complete but Preview behaviour still misses them, that is a signal that the platform itself was the bottleneck (the agent did not implement to spec), not a sign that the description was inadequate. Capture the gap in chat as a follow-up to the developer agent rather than rewriting the criteria.
Storybook for Components
Embedded Storybook lives in App → Components for frontend sessions and is the right place to review a single component before it appears inside any page layout. Stories define the states the component should handle — typically empty, partial, and full — and reviewing them is the cheapest way to catch missing states before they propagate into the assembled UI.
| What to check in Storybook | Why |
|---|---|
| Empty state renders without errors | A component reused on a list view will hit this state on first load. |
| Partial state covers the realistic mid-population case | Catches assumptions like "the array always has at least one item". |
| Full state matches the design tokens | Confirms colours, typography, and spacing line up with Styles. |
| Edge cases (long text, large numbers) | Catches layout overflow and truncation before integration. |
For pages, the same embedded Storybook lives in App → Pages and renders page-level stories — useful for screen-level review without spinning up the full Preview.
Test Tab
The Test tab is available on frontend or testing modules and is where Playwright-based test cases and runs live alongside QA Tester in chat. The tab has two sub-tabs — Test cases (filters, paginated table, New test case button) and Test runs (run history with per-case results).
| Action | Where | Result |
|---|---|---|
| Create a test case manually | Test → Test cases → New test case | Opens a dialog for scenario and steps. |
| Generate cases and scripts | Chat → QA Tester → Generate Test Cases / Generate Test Scripts | Populates Test cases. |
| Run selected cases | Test → Test cases → select rows → Run test cases | Creates a run; the tab switches to Test runs automatically. |
| Run by suite | Test → Test cases → Run test cases (nothing selected) | Opens a suite-picker dialog. |
| Inspect failures | Test → Test runs → click row → View issues | Shows error message, code snippet, and replay where captured. |
Bulk selection respects only cases that are not deleted, not set to ignore, and have a usable script. For cases without a script, use the row ⋮ menu to run, edit, or generate one through QA Tester.