# Build an app or game that fits its display
An interactive Hackemist build should behave like an application. Keep navigation, Back/Close, primary actions and game controls reachable inside the player's current viewport. Do not make users scroll a long document to find a timer, finish a workout, pause a game or reach another feature.
This applies to manual Studio uploads and agent/MCP builds. The player displays your authored interface; it cannot reorganize an arbitrary website into an app. A screenshot or a responsive declaration alone does not prove all screens work.
## Choose the experience honestly
Declare the experience on the HTML or body element:
- `data-hackemist-experience="app"`: planners, editors, trackers, dashboards and other interactive tools. Use a bounded application shell, persistent navigation and contained panels.
- `data-hackemist-experience="game"`: menus, gameplay, HUD, pause, settings and results must fit. A game world may move within a clipped scene; its required controls must remain accessible.
- `data-hackemist-experience="document"`: an article, manual or reading-first report may scroll vertically. Do not use this to disguise an overflowing interactive app or game.
Also declare `data-hackemist-layout="responsive"` for a reflowing layout or `adaptive` for implemented logical layouts. `data-hackemist-viewport="fit"` explicitly requires both-axis fit. Interactive responsive layouts now require both-axis fit by default; a genuine scrolling document opts into `document`. Existing published versions keep working; an updated build is checked against the current rules. Legacy fixed stages can retain the player's uniform Fit mode, but scaling alone does not make small controls usable.
## A complete manual-builder starter
Save the following as UTF-8 `index.html`. It has working navigation, a small-screen menu, a pageable list, a named keyboard-accessible scrolling panel, and an Add button. Replace its demo state and connect durable data to the [save SDK](/docs/save-sdk.md). Changing CSS does not implement account saving.
```html
My Hackemist appMy Hackemist app
Today
Your main task belongs here. Use Items to browse the collection.
Your items
```
## Keep features reachable
Use a grid or flex shell whose content track is `minmax(0, 1fr)`. Set `min-height: 0` and `min-width: 0` on shrinking children. Use `100dvh` with a `100%` fallback and respect safe-area insets. Header, navigation and action bars reserve their own space; the content panel receives the remainder. A large fixed `min-height` or a `100vh` canvas plus extra HUD usually overflows short landscape screens.
Use tabs, Previous/Next, paging, search, collapsible navigation or a dedicated detail screen to split many features. For a workout, keep Finish, Pause and the timer reachable while paging through exercises. For a game, reserve space for HUD/touch controls and provide reachable Pause/Back actions on every state. Keep touch targets around 44 CSS pixels and support keyboard navigation and visible focus.
A long list, log, editor or form may scroll **inside a contained panel**. Mark it `data-hackemist-scroll-region`, give it `tabindex="0"`, an accessible name with `aria-label` or `aria-labelledby`, and real `overflow: auto` or `scroll`. Its viewport must fit the app. This lets keyboard and touch users reach content while app navigation stays visible. Do not simply put `overflow: hidden` on the body and cut off features. `data-hackemist-required-ui` identifies fixed headers, actions or HUD that must remain visible.
For dialogs, keep Close/Back and important actions in fixed dialog chrome; scroll only the dialog's named content panel. Do not hide a feature to pass a size check. Preserve focused values when rotating, resizing or opening a phone keyboard. Test those transitions with entered data, not just an empty screen.
## Verify before publishing
Test at least 320 × 568, 390 × 844, 740 × 320, 844 × 390, 768 × 1024, 1024 × 768 and 1440 × 900, plus a large desktop. Exercise every navigation destination, active edit/game state, dialog, pause and results screen. Confirm the document's scroll width/height do not exceed the viewport for apps/games, navigation and primary actions remain reachable, paging exposes every record, and focus/entered values survive resizing. Test touch and keyboard as applicable.
The publishing checker now rejects root vertical scrolling for interactive responsive apps, root horizontal overflow and required controls clipped outside accessible panels. Named panels are checked by geometry and actual scroll styles; a declaration cannot grant access or prove semantic completeness. A scrolling document must opt into the document experience. The checker still cannot infer every hidden feature or automatically play an arbitrary game. Run your own meaningful screen and interaction tests. Emulated sizes do not establish physical-device performance, Safari support, phone-keyboard behavior or authenticated saves.
Manual builders: use Studio → Files & preview → Run draft, open every screen at the target sizes, then run Publishing checks and fix each finding. Agent builders: read this resource through `hackemist://docs/app-layout`, test locally, upload the saved static bundle, inspect `project_release_checklist`, then publish. Do not label a startup-only check as full application or game verification.