The statement is ready. Goal: the app is comfortable to open from a phone from 360 px and from a computer, it deploys itself to GitHub Pages from main, and the README explains what it is, how to run it and how to turn Pages on.
What I checked on a copy of the project, I did not change the project itself. Now at 360 px with long names the page scrolls sideways: the document width is 495 at a window width of 360. Long names without spaces stick out in the list rows, the checkbox labels and the field group, whose minimum width by default equals the content width. Buttons and fields are 37 px high, checkboxes 13 by 13 px. The proposed set of rules removes the scroll at 360, 768 and 1280 px and makes fields and buttons 44 px high; without a ban on shrinking the "Remove" button in the lists shrinks and wraps. With the Vite config and a relative base path make check is green, the paths in the built page are relative, the build works from a subdirectory. The current major tags of the actions are found through the list of tags of the repositories.
Plan. First, the styles: at the beginning of the file introduce custom properties for colors, radii, the gap between sections, the column width and the touch target of 44 px and move all rules to them; enable box-sizing border-box for all, wrapping of long words on the whole page body, zero minimum width for the field group, full width for text fields and select lists, a minimum height of 44 px for fields and buttons; make checkboxes flex containers, so that the whole label becomes the touch zone; in the lists align the rows to the center and forbid shrinking of the buttons. The layout is fluid, media queries only when needed, do not touch the markup and the page. Second, the Vite config with a relative base path and a Russian comment on "why": the app opens from any subdirectory without the owner's name in the code, the state lies in the address fragment. The file is exactly js, because ts outside tsconfig breaks the linter. Third, the deployment workflow: run on push to main and manually, permissions exactly for reading content, writing to Pages and the id token, a limit of concurrent runs, a build job (checkout, Node 22 with the npm cache, install dependencies, make check, which already builds dist, configure Pages, upload the artifact) and a deployment job with the environment github-pages. Fourth, the screenshot and the README: a script from a temporary directory shoots the built app at a width of 390 px with a double pixel density, the example is Ann, Ben, Clara, Dan and three expenses, the size up to about 600 KB; the README with sections about the purpose, the screenshot, features, local run, the project structure, deployment to Pages and limitations.
The layout check script lies outside the project. It builds the app, puts it into a subdirectory, starts a static server and in Chromium fills the bill with long names and a huge amount at the widths 360, 768 and 1280. It checks that there is no horizontal scroll, no element goes beyond the right edge, fields, buttons and checkboxes are not lower than 44 px, the button text is not cut and does not wrap. At 360 px it additionally checks the states after "Share" and after opening a garbage fragment, at 1280 — that the column is not wider than 640 px and stands in the center. There must be no page errors or failed requests.
Accepted decisions: a relative base path in the Vite config, not a flag and not a hardcoded subdirectory; there is no separate build step in the workflow, because make check already builds dist, and the checks are not bypassed; permissions at the level of the whole workflow, as in the official template; a fluid layout without media queries and without new dependencies; wrapping of long words by one rule on the page body; the check and screenshot scripts lie outside the repository, only the PNG goes into it; three commits — styles, config with the deployment workflow, README with the screenshot.
Done criteria: the check script passes at three widths, including "Share" and a broken link at 360; make check is green, formatting changes nothing; the paths in the built page are relative, the app works from a subdirectory; the development mode opens the app; the deployment workflow matches the listed, the action tags exist, the YAML parses; the screenshot is 390 or 780 px wide and up to about 600 KB, the README links to it by a relative path; the README has all the sections, the owner's name is hardcoded nowhere, there are no keys or personal data; the existing tests were not changed and pass, the interface files and the page were not changed. There are no new tests: there is no new logic in the task.
Out of scope: the aria-live area on the summary section; the same caption on all expense delete buttons; no favicon; no formatting check in make check and CI; CI does not run on pull requests; the Vite config is not checked by tsc. What the human should click: in the repository settings open Pages, in the build section choose the source "GitHub Actions", then push to main or run the workflow manually on the main branch; the address will appear in the Pages settings and in the run summary of the "Deploy" job.