Batch 1 Verification — Frontend Regression Check

Date: 2026-05-24 Verifier: worker

Build Result

PASS

vite v8.0.14 building client environment for production...
transforming... ✓ 621 modules transformed.
rendering chunks...
dist/index.html                     0.42 kB │ gzip:   0.28 kB
dist/assets/index-DTmTBGd6.css     17.31 kB │ gzip:   3.60 kB
dist/assets/lib-CHwV_tJc.js       497.26 kB │ gzip: 125.51 kB
dist/assets/index-C4gnVVS-.js   1,038.17 kB │ gzip: 347.38 kB

✓ built in 3.83s

Warnings: One pre-existing chunk-size warning (Some chunks are larger than 500 kB after minification). This is not a new regression and is unrelated to the server/bot changes.

Files Inspected

File	Key Observations
`frontend/package.json`	Build script: `"build": "vite build"`. Dependencies: Svelte 5, Vite 8, DOMPurify, highlight.js, mammoth, marked.
`frontend/src/routes/ViewContent.svelte`	Fetches metadata via `fetchMetadata(cxid, sc)`. Displays `metadata.current_views` / `metadata.max_views` only if `max_views` exists. No assumptions about view-count increment behavior. All file URLs pass `password` (sc) correctly.
`frontend/src/routes/Home.svelte`	Accepts `cxidInput` and optional `passwordInput`. Checks `meta.has_password` client-side before verifying. Navigates to view route via `history.pushState`. No view-count logic here.
`frontend/src/lib/api.js`	`API_BASE` hard-coded to `http://127.0.0.1:8090`. `BOT_USERNAME = "council_websharingbot"`. `fetchMetadata` and `verifyPassword` use GET and POST respectively. No HEAD requests.

Regression Assessment

No regressions detected from the server HEAD-request fix.
The frontend does not issue HEAD requests; all API calls are GET (fetchMetadata, file URLs) or POST (verifyPassword).
View-count display is read-only from metadata. There is no client-side logic that depends on whether the server increments the counter on HEAD vs GET.

Notes for Upcoming Batches

Batch 3 — Password UX

ViewContent.svelte: Password submission does verifyPassword → fetchMetadata (two round trips). Consider adding:
- Show/hide password toggle.
- Loading state during submitPassword (currently no phase = 'loading').
- Auto-focus on password input when phase === 'password_required'.
Home.svelte: Password flow also does two round trips (fetchMetadata to check has_password, then verifyPassword, then fetchMetadata again). Error messages are generic (e.message || 'Content not found.').
Shared concern: Passwords travel in query string (?sc=...) for shared links. This is pre-existing behavior but worth noting for any security-focused UX work.

Batch 10 — Homepage Bot Link

Home.svelte already references BOT_USERNAME imported from api.js (value: council_websharingbot).
The Telegram deep-link https://t.me/{BOT_USERNAME}?start=submit is correctly constructed.
No concerns unless the bot username changes (in which case only api.js needs updating).

Conclusion

Frontend is safe to proceed. Build is clean, and the server/bot changes in Batch 1 do not affect frontend behavior.

3.2 KiB Raw Blame History