App Tab

Purpose: Operational reference for the App tab — the six sub-sections (Pages, Data model, Logic, API Library, Components, Styles), what each shows, what you can do in it, and when to open it during a session.

The App tab is where Swifter renders the artefacts a session produces — specs, design views, embedded Storybook — separated from the source code (Dev tab) and the running application (Preview). Which sub-sections appear depends on the work item's module type:

Module type	Sub-sections shown
Frontend	Pages · Data model · Logic · API Library · Components · Styles
Backend	Data model · Logic · API Library
Testing	(App tab not available — work in Test tab instead)

Opening the App tab without a sub-path defaults to Pages for frontend modules and Data model for backend modules.

Common layout

Every sub-section shares the same skeleton:

• Far left — section switcher. A vertical icon bar picks the active sub-section. Same bar across the App tab; only which icons appear follows the module-type rules above.
• Main area — list/scope on the left, detail/preview on the right. Pick something on the left, inspect it on the right. When the sub-section is a single embedded Storybook view (Pages, Components), the "left" is Storybook's own story tree inside the embed and the "right" is the canvas — the same pick-on-the-left / inspect-on-the-right pattern.

Pages

Embedded Storybook for page-level stories — the full screen the user lands on, not a single control. The right pane is the story canvas; the left pane is Storybook's own sidebar inside the embed.

A page is what Frontend Analyst records via define-page-spec and Frontend Developer realises via generate-page — layout, behaviour, and ties to Reqs / Data model / design inputs. The Pages sub-section is the way to sanity-check page specs and generated layout in isolation, before exercising the full app in Preview.

There are no Swifter-specific edit controls in this view beyond what Storybook itself provides — browse stories, switch variants, inspect the canvas.

Data model

Structured domain model for the session — entities, attributes, relationships, and the validation rules that reference them.

• Left pane. Sidebar lists entities grouped under headings — by page / component / service depending on what was modelled.
• Right pane. Selected entity's fields (attributes, types, constraints) and any validation rules referencing it.

Populated primarily by /swifter-frontend-analyst:work-on-component-data-model (or the backend equivalent inside /generate-scoped-specifications). The most useful review action here is Remove on an entity (the ⋯ overflow); deleting from the working session is the way to correct a misclassified or duplicate entity. Confirm naming against Reqs and against any sibling components' data models — drift caught at this stage is cheap, drift caught after generate-component / generate-page costs a session.

Logic

Behavioural specs for the session — functions (flows, side effects, API calls), display rules (what to show or expose and when), and validation rules (what counts as valid data). Frontend work items group items by page and component; backend work items group functions and validation rules by service.

• Left pane. A scope control switches between all items and items for a specific page / component / service. Add creates a function or validation rule (and a display rule for frontend work items). Search narrows the lists. Subsections (Functions / Display rules / Validation rules) appear only when populated.
• Right pane. Selected item's title, ID, and full rule or function text. When the model stores cross-references, Uses and Used by appear as collapsible blocks — Uses is split into Functions / API calls / Entities for a function; Functions / Components / Entities for a display rule; Functions / Entities for a validation rule. Edit and Remove live in the ⋯ overflow when the session is not read-only.

Populated by /swifter-frontend-analyst:work-on-component-logic (frontend) or the backend analyst command. Read here before the developer pass to verify the rules from the WI body landed correctly; read here after the developer pass to confirm generate-component / generate-page honoured every function and rule it was supposed to. Conditional-logic format (see Work-Item Description Composition § Principle 4) is preserved end-to-end — what the WI body said should appear here verbatim.

API Library

Catalogue of HTTP APIs and operations for the session, with one or more configurations per API (internal routing to another work item's preview, external base URLs).

• Left pane. Search box, the + menu (Import from work item or Import from file), and a tree navigated as library → endpoint → method. Each library is Consumed (you call it) or Exposed (you provide it). Open a library → open an endpoint → pick the HTTP method to see operation detail.
• Right pane (library selected). The ⋯ menu offers update spec (from file or work item), rename, remove. Below sits the Configuration table — name, base URL, which row is active. The + button adds an internal (toward another work item's Preview) or external (with auth, headers, params) configuration. Row ⋯ offers active / edit / remove.
• Right pane (endpoint selected). Endpoint description.
• Right pane (method selected). General, Request, Response, and Usage sub-panels — Usage lists every function from Logic that references this operation (as an API dependency or a bound method), so you can trace each consumer back to its function spec.

Where to find an OpenAPI spec for "Import from file"

Backend modules typically commit an OpenAPI document on the session branch; the path depends on the framework. Open the file in the Dev tab, download or copy it locally, then upload via Import from file.

Backend module framework	Where to look in Dev (typical)
Spring Boot	Repo root or src/main/resources/**: openapi.yaml, openapi.yml, openapi.json; sometimes static/ or api/ specs — search for openapi / swagger.
Quarkus	src/main/resources/META-INF/openapi.yaml (or .yml / .json).
.NET (ASP.NET Core)	Project folder: openapi.json, swagger.json, or a *.yaml spec — depends on template; search the module root.
Node.js + Express	openapi.json, swagger.json, docs/openapi.yaml, or a path wired in the server entry file — search the tree.

How API Library plugs into a session

Backend work items register what the service exposes (and what it consumes from other services). Backend Analyst's generate-scoped-specifications and Backend Developer's implement-scoped-changes update specs and code in the repository; they do not push straight into App → API Library, so use this tab to import the freshly-written OpenAPI document and double-check what other sessions can pick up.

Frontend work items consume APIs:

• Import from work item — pick a backend session, then the Exposed library you added there. Swifter routes API calls from this frontend session to that backend session's Preview (an internal configuration). This is how Journey 3's API library precondition is satisfied in practice when both ends are on the same engagement.
• Import from file — for external URLs, attach the OpenAPI document directly and set the base URL in the Configuration table.

End-to-end flow: Journey 3 — FE-BE Integration. The contract-first sequence (backend WI → import to API library → frontend WI → work-on-component-logic + generate-page) keeps the integration mechanical.

Components

Embedded Storybook for component-level stories — the reusable building blocks (buttons, fields, cards, badges) the page is built from. Same shape as Pages: Storybook's internal sidebar on the left, the preview canvas on the right.

Components are shaped by /swifter-frontend-analyst:define-component-spec (or onboard-component for an existing UI element being brought into Swifter coverage), then implemented by /swifter-frontend-developer:generate-component. The right time to open Components is after the analyst step and before the developer step — walk each story (empty / partial / full / error) against the corresponding Figma frame; missing states here are spec gaps the developer will inherit if left alone.

The same embedded Storybook engine runs both Components and Pages; only the story kind changes (the analyst step writes a page_preview tag on page-level stories and a component_preview tag on component-level stories, which determines which view picks them up).

Styles

The frontend module's design tokens — colours, typography, spacing values, and other tokens that show up across Pages, Components, and the live Preview.

• Layout. Tokens are listed in the main pane, one row each. Click Edit on a row to open a dialog that lets you change the token value.
• Error state. If Swifter cannot load or interpret the token set, the section shows an explicit error with on-screen hints — most often a sign that the Figma integration's style mapping is out of date and needs a re-run of match-figma-styles.

Use Styles to confirm token alignment after analyst or developer runs — what the design system says a primary colour or a header font should be, and what the session's spec actually committed. Mismatches caught here propagate; mismatches caught in Preview have already cost a Storybook build.

When to open each sub-section

Sub-section	When to read	Common follow-up
Pages	After define-page-spec and after generate-page	If a state is wrong, refine in chat with the analyst (spec) or developer (implementation).
Data model	After work-on-component-data-model; again before integration	Remove duplicates; rename via the toolset skills, never raw-edit the YAML.
Logic	After work-on-component-logic; again after generate-component / generate-page	If a rule was missed, refine the WI body and re-run the analyst command.
API Library	When importing a contract; when wiring a consumer	Import from work item (internal) or file (external); set the active configuration.
Components	After define-component-spec; after generate-component	Verify every state Figma defines has a matching story.
Styles	After analyst's match-figma-styles runs	If tokens look wrong, re-run match-figma-styles rather than hand-editing.

The App tab is the cheapest review surface in Swifter — far cheaper than Preview or PR-time review. Spend time here and the rest of the journey runs in minutes.