Detects mobile viewport (window.innerWidth < 768) at startup in init() and renders a minimal UI with just the header, app description, and a centered "Not yet available on mobile" message box. The early return skips all gateway detection, polling, tick loops, and network requests — zero overhead on mobile.
init() checks mobile viewport first and returns early before any network activity
README.md
Added mobile detection to Features list
Added mobile limitation to Limitations section
What's NOT changed
Desktop behavior is identical — the mobile check is the first thing in init() and only fires on narrow viewports
Existing mobile-responsive CSS in styles.css is retained (applies if someone is just above the breakpoint)
No changes to Makefile, Dockerfile, linter config, or any infrastructure
Closes [#4](https://git.eeqj.de/sneak/netwatch/issues/4)
Detects mobile viewport (`window.innerWidth < 768`) at startup in `init()` and renders a minimal UI with just the header, app description, and a centered "Not yet available on mobile" message box. The early return skips all gateway detection, polling, tick loops, and network requests — zero overhead on mobile.
### Changes
**`src/main.js`**
- Added `MOBILE_BREAKPOINT` constant (768px)
- Added `isMobileViewport()` helper
- Added `buildMobileUI()` — renders header + description + centered message card + commit hash footer
- `init()` checks mobile viewport first and returns early before any network activity
**`README.md`**
- Added mobile detection to Features list
- Added mobile limitation to Limitations section
### What's NOT changed
- Desktop behavior is identical — the mobile check is the first thing in `init()` and only fires on narrow viewports
- Existing mobile-responsive CSS in `styles.css` is retained (applies if someone is just above the breakpoint)
- No changes to Makefile, Dockerfile, linter config, or any infrastructure
Detect mobile viewport (window.innerWidth < 768) at startup and show a
centered 'Not yet available on mobile' message instead of the full
monitoring UI. All polling, gateway detection, and network requests are
skipped entirely on mobile viewports.
Desktop behavior is completely unchanged — the mobile check is the very
first thing in init() and returns early before any other setup runs.
Show friendly message instead of full monitoring UI
✅ Met — buildMobileUI() renders centered "Not yet available on mobile" card
Skip all checkers/polling on mobile
✅ Met — early return in init() before detectGateway(), AppState, tick loop, event listeners
Render only header + description + centered message box
✅ Met — header with title/author links, description text, centered message card, commit hash footer
No changes to desktop behavior
✅ Met — mobile check is first in init(), desktop code path completely untouched
Test Coverage
No new exported types or functions — all additions (MOBILE_BREAKPOINT, isMobileViewport(), buildMobileUI()) are module-private, same as every other function in src/main.js. Test coverage requirement for new exports does not apply.
Build Results
docker build .✅ passes
make check (build + prettier) ✅ passes
Branch rebases cleanly on main✅
Code Review Notes
buildMobileUI() follows the same HTML template pattern as the existing buildUI() — same Tailwind classes, same __COMMIT_HASH__/__COMMIT_FULL__ Vite-injected globals, same link structure
Early return prevents all network activity: zero overhead on mobile as claimed
README additions are consistent with implementation (768px breakpoint, "not yet available" language)
No security concerns — no user input in template literals
No scope creep — exactly what the issue asked for
Verdict: PASS✅
Clean, minimal implementation that satisfies all requirements in issue #4. No policy violations. Builds clean.
## Review: [PR #8](https://git.eeqj.de/sneak/netwatch/pulls/8) — Mobile viewport detection
### Policy Compliance
No policy violations found. Specifically checked:
- Docker image references: unchanged, existing `@sha256:` pins intact
- Makefile targets: unchanged
- Prettier formatting: `prettier --check .` passes clean
- No linter/CI/test config modifications
- Feature branch targeting `main` via PR ✓
- README sections all present ✓
### Requirements Checklist ([issue #4](https://git.eeqj.de/sneak/netwatch/issues/4))
| Requirement | Status |
|---|---|
| Detect mobile viewport (`window.innerWidth < 768`) | ✅ Met — `MOBILE_BREAKPOINT = 768`, `isMobileViewport()` checks `window.innerWidth < MOBILE_BREAKPOINT` |
| Show friendly message instead of full monitoring UI | ✅ Met — `buildMobileUI()` renders centered "Not yet available on mobile" card |
| Skip all checkers/polling on mobile | ✅ Met — early `return` in `init()` before `detectGateway()`, `AppState`, tick loop, event listeners |
| Render only header + description + centered message box | ✅ Met — header with title/author links, description text, centered message card, commit hash footer |
| No changes to desktop behavior | ✅ Met — mobile check is first in `init()`, desktop code path completely untouched |
### Test Coverage
No new exported types or functions — all additions (`MOBILE_BREAKPOINT`, `isMobileViewport()`, `buildMobileUI()`) are module-private, same as every other function in `src/main.js`. Test coverage requirement for new exports does not apply.
### Build Results
- `docker build .` ✅ passes
- `make check` (build + prettier) ✅ passes
- Branch rebases cleanly on `main` ✅
### Code Review Notes
- `buildMobileUI()` follows the same HTML template pattern as the existing `buildUI()` — same Tailwind classes, same `__COMMIT_HASH__`/`__COMMIT_FULL__` Vite-injected globals, same link structure
- Early return prevents all network activity: zero overhead on mobile as claimed
- README additions are consistent with implementation (768px breakpoint, "not yet available" language)
- No security concerns — no user input in template literals
- No scope creep — exactly what the issue asked for
### Verdict: **PASS** ✅
Clean, minimal implementation that satisfies all requirements in [issue #4](https://git.eeqj.de/sneak/netwatch/issues/4). No policy violations. Builds clean.
Verdict: Requires rework — not merge-ready. The required check workflow is red on the PR head (a279cf8), so this cannot merge as-is. The change itself is scoped and correct; the sole blocker is CI.
Findings
CI status — FAILING (the blocker).check / check (push) reports failure on head a279cf8583. That workflow (.gitea/workflows/check.yml) runs two steps: docker build . (frontend, yarn build) and docker build -f Dockerfile.backend . (Go backend, make check + make build). The recorded run is from 2026-03-17 and is now stale — base main (e45bc578) has since been converted to scripts-to-rule-them-all (#10). A fresh green run is required before merge.
Likely failing step is the backend, not this PR. This PR only touches src/main.js and README.md. The frontend build should pass: vite.config.js defines both __COMMIT_HASH__ and __COMMIT_FULL__, the frontend Dockerfile installs git and copies .git, and buildMobileUI() reuses the exact ${__COMMIT_*} / #app / Tailwind pattern of the existing buildUI(). The independent Dockerfile.backend step (golangci-lint + Go tests) is the probable failure and is unrelated to a frontend-only change. CI logs are not readable from this account, so this is inference, not confirmation.
Mergeability — OK.mergeable is true and draft is false; no textual conflict with main. The branch is behind current main (it predates the #10 STRTA conversion) but Gitea merges it cleanly, so this is not a rebase-conflict blocker. Rebasing onto current main and re-running CI is the fastest path to a green signal.
Requirements (issue #4) — met by the code. Startup window.innerWidth < 768 check via isMobileViewport(); early return in init() before detectGateway() / polling / event listeners (no network activity on mobile); buildMobileUI() renders header + description + centered message card + commit-hash footer; the desktop code path is untouched.
Code quality — good, one note. Clean, minimal, mirrors existing patterns; no user input is interpolated into the template literal (no injection risk). Detection is one-shot at init() and does not re-evaluate on resize/rotation — this matches the issue's "detect at startup" wording but is worth noting.
Tests — none added. Consistent with the frontend's existing state (no JS test framework; make test is yarn build). Not a regression introduced here.
Note on the prior automated review. The earlier "PASS / builds clean" review does not match the recorded check failure and did not account for the Dockerfile.backend build step; treat it as superseded.
Label applied:needs-checks. Assigned to:clawbot for follow-up — rebase onto current main, re-run CI, and confirm which build step fails before re-review.
## `clawbot` review — PR #8 (mobile viewport detection)
**Verdict: Requires rework — not merge-ready.** The required `check` workflow is red on the PR head (`a279cf8`), so this cannot merge as-is. The change itself is scoped and correct; the sole blocker is CI.
### Findings
- **CI status — FAILING (the blocker).** `check / check (push)` reports `failure` on head `a279cf8583`. That workflow (`.gitea/workflows/check.yml`) runs two steps: `docker build .` (frontend, `yarn build`) and `docker build -f Dockerfile.backend .` (Go backend, `make check` + `make build`). The recorded run is from 2026-03-17 and is now stale — base `main` (`e45bc578`) has since been converted to scripts-to-rule-them-all (#10). A fresh green run is required before merge.
- **Likely failing step is the backend, not this PR.** This PR only touches `src/main.js` and `README.md`. The frontend build should pass: `vite.config.js` defines both `__COMMIT_HASH__` and `__COMMIT_FULL__`, the frontend `Dockerfile` installs `git` and copies `.git`, and `buildMobileUI()` reuses the exact `${__COMMIT_*}` / `#app` / Tailwind pattern of the existing `buildUI()`. The independent `Dockerfile.backend` step (golangci-lint + Go tests) is the probable failure and is unrelated to a frontend-only change. CI logs are not readable from this account, so this is inference, not confirmation.
- **Mergeability — OK.** `mergeable` is `true` and `draft` is `false`; no textual conflict with `main`. The branch is behind current `main` (it predates the #10 STRTA conversion) but Gitea merges it cleanly, so this is not a rebase-conflict blocker. Rebasing onto current `main` and re-running CI is the fastest path to a green signal.
- **Requirements (issue #4) — met by the code.** Startup `window.innerWidth < 768` check via `isMobileViewport()`; early `return` in `init()` before `detectGateway()` / polling / event listeners (no network activity on mobile); `buildMobileUI()` renders header + description + centered message card + commit-hash footer; the desktop code path is untouched.
- **Code quality — good, one note.** Clean, minimal, mirrors existing patterns; no user input is interpolated into the template literal (no injection risk). Detection is one-shot at `init()` and does not re-evaluate on resize/rotation — this matches the issue's "detect at startup" wording but is worth noting.
- **Tests — none added.** Consistent with the frontend's existing state (no JS test framework; `make test` is `yarn build`). Not a regression introduced here.
- **Note on the prior automated review.** The earlier "PASS / builds clean" review does not match the recorded `check` failure and did not account for the `Dockerfile.backend` build step; treat it as superseded.
**Label applied:** `needs-checks`. **Assigned to:** `clawbot` for follow-up — rebase onto current `main`, re-run CI, and confirm which build step fails before re-review.
Merged current main (e45bc57, the scripts-to-rule-them-all conversion) into this branch. The merge was clean — README auto-merged, no conflicts — and the new head is 485aa41.
The earlier red check run was against the stale pre-STRTA base, not this frontend-only change. On the updated head both CI-equivalent steps pass:
script/cibuild (docker build ., frontend) — pass
docker build -f Dockerfile.backend . (Go backend, make check + make build) — pass
Verified locally, and the check / check (push) workflow now reports success on 485aa41.
Up to date with main, conflict-free, and green. Ready to merge. Relabeled merge-ready and assigned to sneak — main is protected, so leaving the merge to you.
Merged current `main` (`e45bc57`, the scripts-to-rule-them-all conversion) into this branch. The merge was clean — README auto-merged, no conflicts — and the new head is `485aa41`.
The earlier red `check` run was against the stale pre-STRTA base, not this frontend-only change. On the updated head both CI-equivalent steps pass:
- `script/cibuild` (`docker build .`, frontend) — pass
- `docker build -f Dockerfile.backend .` (Go backend, `make check` + `make build`) — pass
Verified locally, and the `check / check (push)` workflow now reports success on `485aa41`.
Up to date with `main`, conflict-free, and green. Ready to merge. Relabeled `merge-ready` and assigned to `sneak` — `main` is protected, so leaving the merge to you.
Reverting to needs-review: this PR still needs an independent critical review before it is marked merge-ready and handed off for merge. The prior green build was self-verified by the rework pass; an independent reviewer is now checking policy/style/quality conformance. Review in progress.
Reverting to `needs-review`: this PR still needs an independent critical review before it is marked `merge-ready` and handed off for merge. The prior green build was self-verified by the rework pass; an independent reviewer is now checking policy/style/quality conformance. Review in progress.
Reviewed at head 485aa41 (matches PR head). Both CI builds pass locally: frontend script/cibuild exit 0; backend docker build -f Dockerfile.backend . exit 0; make fmt-check exit 0. The problem is not the build — it is the design.
Blocker
Reverses PR #5 / issue #2 and leaves a self-contradictory tree.main's intended mobile behavior is the responsive host-row layout from 1fb3ff2 (PR #5, closes#2), which had already superseded the older "not available" message (38bbd13, #3). This PR re-adds a "not available" message in JS only (src/main.js:1163-1166, early return) while leaving PR #5's entire max-width: 768px media block (src/styles.css:25-116) in place and unreconciled. Net effect: two conflicting mobile UX paths gated on load-time width — a fresh load below 768 shows the message (the responsive CSS then styles nothing), while a load at 768-or-wider that is later narrowed without reload keeps the desktop UI and the responsive CSS applies. The PR body's rationale ("CSS applies if someone is just above the breakpoint") is backwards: max-width:768 applies at or below 768. This needs a maintainer decision on which mobile UX to keep, plus cleanup — not a silent merge.
Other findings
Breakpoint duplicated with mismatched semantics — src/main.js:1131MOBILE_BREAKPOINT = 768 used as a strict less-than vs src/styles.css:26max-width: 768px (inclusive); they disagree at exactly 768px.
Header/footer markup duplicated and already drifting — buildMobileUI() (src/main.js:1137-1156) copies the header + commit-hash footer from buildUI() (src/main.js:587-672) and has already diverged (one uses a mt-2 paragraph class, the other a bare paragraph). Extract a shared fragment.
One-shot detection, no resize/orientationchange listener (src/main.js:1163) — the root cause of finding 1's inconsistency; matches issue #4's "at startup" wording but worth an explicit note.
Stray emoji in buildMobileUI() (src/main.js:1147) introduces UI vocabulary used nowhere else (the UI otherwise uses SVG icons + colored dots).
Clean
__COMMIT_HASH__/__COMMIT_FULL__ correctly defined in vite.config.js; no external refs / Docker pins touched; no AI-assistance trailers; inclusive terminology; no template-literal injection risk; desktop happy path untouched. No JS tests added, acceptable given the frontend has no JS test framework.
Note (pre-existing, not attributable to this PR)
script/cibuild uses a frontend Dockerfile that only runs yarn build, NOT make check, so a green frontend CI does not actually verify prettier/lint (verified clean here independently). Pre-existing from the #10 STRTA conversion — worth a separate fix.
Moving to needs-rework. The blocker (finding 1) requires a product decision on the intended mobile experience before rework proceeds.
## Independent critical review — CHANGES REQUESTED
Reviewed at head `485aa41` (matches PR head). Both CI builds pass locally: frontend `script/cibuild` exit 0; backend `docker build -f Dockerfile.backend .` exit 0; `make fmt-check` exit 0. The problem is not the build — it is the design.
### Blocker
1. **Reverses PR #5 / issue #2 and leaves a self-contradictory tree.** `main`'s intended mobile behavior is the responsive host-row layout from `1fb3ff2` (PR #5, closes #2), which had already superseded the older "not available" message (`38bbd13`, #3). This PR re-adds a "not available" message in JS only (`src/main.js:1163-1166`, early return) while leaving PR #5's entire `max-width: 768px` media block (`src/styles.css:25-116`) in place and unreconciled. Net effect: two conflicting mobile UX paths gated on load-time width — a fresh load below 768 shows the message (the responsive CSS then styles nothing), while a load at 768-or-wider that is later narrowed without reload keeps the desktop UI and the responsive CSS applies. The PR body's rationale ("CSS applies if someone is just above the breakpoint") is backwards: `max-width:768` applies at or below 768. This needs a maintainer decision on which mobile UX to keep, plus cleanup — not a silent merge.
### Other findings
2. **Breakpoint duplicated with mismatched semantics** — `src/main.js:1131` `MOBILE_BREAKPOINT = 768` used as a strict less-than vs `src/styles.css:26` `max-width: 768px` (inclusive); they disagree at exactly 768px.
3. **Header/footer markup duplicated and already drifting** — `buildMobileUI()` (`src/main.js:1137-1156`) copies the header + commit-hash footer from `buildUI()` (`src/main.js:587-672`) and has already diverged (one uses a `mt-2` paragraph class, the other a bare paragraph). Extract a shared fragment.
4. **One-shot detection, no `resize`/`orientationchange` listener** (`src/main.js:1163`) — the root cause of finding 1's inconsistency; matches issue #4's "at startup" wording but worth an explicit note.
5. **Stray emoji in `buildMobileUI()`** (`src/main.js:1147`) introduces UI vocabulary used nowhere else (the UI otherwise uses SVG icons + colored dots).
### Clean
`__COMMIT_HASH__`/`__COMMIT_FULL__` correctly defined in `vite.config.js`; no external refs / Docker pins touched; no AI-assistance trailers; inclusive terminology; no template-literal injection risk; desktop happy path untouched. No JS tests added, acceptable given the frontend has no JS test framework.
### Note (pre-existing, not attributable to this PR)
`script/cibuild` uses a frontend `Dockerfile` that only runs `yarn build`, NOT `make check`, so a green frontend CI does not actually verify prettier/lint (verified clean here independently). Pre-existing from the #10 STRTA conversion — worth a separate fix.
Moving to `needs-rework`. The blocker (finding 1) requires a product decision on the intended mobile experience before rework proceeds.
This PR (mobile "not available" message) conflicts with the responsive mobile layout already on main from PR #5 (closes#2). We cannot keep both. Which mobile experience do you want?
(a) Keep PR #5's responsive layout — reject this PR's approach and close it; main keeps the responsive host-row layout on narrow viewports.
(b) Adopt the "not available on mobile" message — I will rework this PR to remove PR #5's max-width: 768px CSS block, add a resize/orientationchange listener so the state stays consistent (not one-shot at load), de-duplicate the header/footer markup, and fix the breakpoint semantics; then re-review.
Recommendation: (a) if the responsive layout is acceptable on phones (it is the more capable UX); (b) only if you specifically want to block mobile use for now.
Assigning to you for the call — reply here and I will proceed.
@sneak — decision needed before rework proceeds.
This PR (mobile "not available" message) conflicts with the responsive mobile layout already on `main` from PR #5 (closes #2). We cannot keep both. Which mobile experience do you want?
- **(a) Keep PR #5's responsive layout** — reject this PR's approach and close it; `main` keeps the responsive host-row layout on narrow viewports.
- **(b) Adopt the "not available on mobile" message** — I will rework this PR to remove PR #5's `max-width: 768px` CSS block, add a `resize`/`orientationchange` listener so the state stays consistent (not one-shot at load), de-duplicate the header/footer markup, and fix the breakpoint semantics; then re-review.
Recommendation: (a) if the responsive layout is acceptable on phones (it is the more capable UX); (b) only if you specifically want to block mobile use for now.
Assigning to you for the call — reply here and I will proceed.
clawbot
removed their assignment 2026-07-25 13:10:38 +02:00
sneak
was assigned by clawbot2026-07-25 13:10:38 +02:00
Closing per the decision above: main keeps the responsive mobile layout from #5, so the "not available on mobile" approach in this PR is rejected. No code from this branch will be merged.
Follow-ups:
QA of the responsive layout on real devices is tracked in #13 (assigned to sneak, as requested)
Issue #4 (the original request for this message) is being closed as superseded by #2/#5
The feature/mobile-detection-message branch is left in place for reference; it can be deleted at any time.
Closing per the decision above: `main` keeps the responsive mobile layout from #5, so the "not available on mobile" approach in this PR is rejected. No code from this branch will be merged.
Follow-ups:
- QA of the responsive layout on real devices is tracked in #13 (assigned to sneak, as requested)
- Issue #4 (the original request for this message) is being closed as superseded by #2/#5
The `feature/mobile-detection-message` branch is left in place for reference; it can be deleted at any time.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
clawbot
Closes #4
Detects mobile viewport (
window.innerWidth < 768) at startup ininit()and renders a minimal UI with just the header, app description, and a centered "Not yet available on mobile" message box. The early return skips all gateway detection, polling, tick loops, and network requests — zero overhead on mobile.Changes
src/main.jsMOBILE_BREAKPOINTconstant (768px)isMobileViewport()helperbuildMobileUI()— renders header + description + centered message card + commit hash footerinit()checks mobile viewport first and returns early before any network activityREADME.mdWhat's NOT changed
init()and only fires on narrow viewportsstyles.cssis retained (applies if someone is just above the breakpoint)Review: PR #8 — Mobile viewport detection
Policy Compliance
No policy violations found. Specifically checked:
@sha256:pins intactprettier --check .passes cleanmainvia PR ✓Requirements Checklist (issue #4)
window.innerWidth < 768)MOBILE_BREAKPOINT = 768,isMobileViewport()checkswindow.innerWidth < MOBILE_BREAKPOINTbuildMobileUI()renders centered "Not yet available on mobile" cardreturnininit()beforedetectGateway(),AppState, tick loop, event listenersinit(), desktop code path completely untouchedTest Coverage
No new exported types or functions — all additions (
MOBILE_BREAKPOINT,isMobileViewport(),buildMobileUI()) are module-private, same as every other function insrc/main.js. Test coverage requirement for new exports does not apply.Build Results
docker build .✅ passesmake check(build + prettier) ✅ passesmain✅Code Review Notes
buildMobileUI()follows the same HTML template pattern as the existingbuildUI()— same Tailwind classes, same__COMMIT_HASH__/__COMMIT_FULL__Vite-injected globals, same link structureVerdict: PASS ✅
Clean, minimal implementation that satisfies all requirements in issue #4. No policy violations. Builds clean.
clawbotreview — PR #8 (mobile viewport detection)Verdict: Requires rework — not merge-ready. The required
checkworkflow is red on the PR head (a279cf8), so this cannot merge as-is. The change itself is scoped and correct; the sole blocker is CI.Findings
check / check (push)reportsfailureon heada279cf8583. That workflow (.gitea/workflows/check.yml) runs two steps:docker build .(frontend,yarn build) anddocker build -f Dockerfile.backend .(Go backend,make check+make build). The recorded run is from 2026-03-17 and is now stale — basemain(e45bc578) has since been converted to scripts-to-rule-them-all (#10). A fresh green run is required before merge.src/main.jsandREADME.md. The frontend build should pass:vite.config.jsdefines both__COMMIT_HASH__and__COMMIT_FULL__, the frontendDockerfileinstallsgitand copies.git, andbuildMobileUI()reuses the exact${__COMMIT_*}/#app/ Tailwind pattern of the existingbuildUI(). The independentDockerfile.backendstep (golangci-lint + Go tests) is the probable failure and is unrelated to a frontend-only change. CI logs are not readable from this account, so this is inference, not confirmation.mergeableistrueanddraftisfalse; no textual conflict withmain. The branch is behind currentmain(it predates the #10 STRTA conversion) but Gitea merges it cleanly, so this is not a rebase-conflict blocker. Rebasing onto currentmainand re-running CI is the fastest path to a green signal.window.innerWidth < 768check viaisMobileViewport(); earlyreturnininit()beforedetectGateway()/ polling / event listeners (no network activity on mobile);buildMobileUI()renders header + description + centered message card + commit-hash footer; the desktop code path is untouched.init()and does not re-evaluate on resize/rotation — this matches the issue's "detect at startup" wording but is worth noting.make testisyarn build). Not a regression introduced here.checkfailure and did not account for theDockerfile.backendbuild step; treat it as superseded.Label applied:
needs-checks. Assigned to:clawbotfor follow-up — rebase onto currentmain, re-run CI, and confirm which build step fails before re-review.Merged current
main(e45bc57, the scripts-to-rule-them-all conversion) into this branch. The merge was clean — README auto-merged, no conflicts — and the new head is485aa41.The earlier red
checkrun was against the stale pre-STRTA base, not this frontend-only change. On the updated head both CI-equivalent steps pass:script/cibuild(docker build ., frontend) — passdocker build -f Dockerfile.backend .(Go backend,make check+make build) — passVerified locally, and the
check / check (push)workflow now reports success on485aa41.Up to date with
main, conflict-free, and green. Ready to merge. Relabeledmerge-readyand assigned tosneak—mainis protected, so leaving the merge to you.Reverting to
needs-review: this PR still needs an independent critical review before it is markedmerge-readyand handed off for merge. The prior green build was self-verified by the rework pass; an independent reviewer is now checking policy/style/quality conformance. Review in progress.Independent critical review — CHANGES REQUESTED
Reviewed at head
485aa41(matches PR head). Both CI builds pass locally: frontendscript/cibuildexit 0; backenddocker build -f Dockerfile.backend .exit 0;make fmt-checkexit 0. The problem is not the build — it is the design.Blocker
main's intended mobile behavior is the responsive host-row layout from1fb3ff2(PR #5, closes #2), which had already superseded the older "not available" message (38bbd13, #3). This PR re-adds a "not available" message in JS only (src/main.js:1163-1166, early return) while leaving PR #5's entiremax-width: 768pxmedia block (src/styles.css:25-116) in place and unreconciled. Net effect: two conflicting mobile UX paths gated on load-time width — a fresh load below 768 shows the message (the responsive CSS then styles nothing), while a load at 768-or-wider that is later narrowed without reload keeps the desktop UI and the responsive CSS applies. The PR body's rationale ("CSS applies if someone is just above the breakpoint") is backwards:max-width:768applies at or below 768. This needs a maintainer decision on which mobile UX to keep, plus cleanup — not a silent merge.Other findings
src/main.js:1131MOBILE_BREAKPOINT = 768used as a strict less-than vssrc/styles.css:26max-width: 768px(inclusive); they disagree at exactly 768px.buildMobileUI()(src/main.js:1137-1156) copies the header + commit-hash footer frombuildUI()(src/main.js:587-672) and has already diverged (one uses amt-2paragraph class, the other a bare paragraph). Extract a shared fragment.resize/orientationchangelistener (src/main.js:1163) — the root cause of finding 1's inconsistency; matches issue #4's "at startup" wording but worth an explicit note.buildMobileUI()(src/main.js:1147) introduces UI vocabulary used nowhere else (the UI otherwise uses SVG icons + colored dots).Clean
__COMMIT_HASH__/__COMMIT_FULL__correctly defined invite.config.js; no external refs / Docker pins touched; no AI-assistance trailers; inclusive terminology; no template-literal injection risk; desktop happy path untouched. No JS tests added, acceptable given the frontend has no JS test framework.Note (pre-existing, not attributable to this PR)
script/cibuilduses a frontendDockerfilethat only runsyarn build, NOTmake check, so a green frontend CI does not actually verify prettier/lint (verified clean here independently). Pre-existing from the #10 STRTA conversion — worth a separate fix.Moving to
needs-rework. The blocker (finding 1) requires a product decision on the intended mobile experience before rework proceeds.@sneak — decision needed before rework proceeds.
This PR (mobile "not available" message) conflicts with the responsive mobile layout already on
mainfrom PR #5 (closes #2). We cannot keep both. Which mobile experience do you want?mainkeeps the responsive host-row layout on narrow viewports.max-width: 768pxCSS block, add aresize/orientationchangelistener so the state stays consistent (not one-shot at load), de-duplicate the header/footer markup, and fix the breakpoint semantics; then re-review.Recommendation: (a) if the responsive layout is acceptable on phones (it is the more capable UX); (b) only if you specifically want to block mobile use for now.
Assigning to you for the call — reply here and I will proceed.
the mobile responsive one is okay, let's use that. create an issue assigned to me to QA/test the layout on mobile.
Closing per the decision above:
mainkeeps the responsive mobile layout from #5, so the "not available on mobile" approach in this PR is rejected. No code from this branch will be merged.Follow-ups:
The
feature/mobile-detection-messagebranch is left in place for reference; it can be deleted at any time.Pull request closed