V0.1.1 release, close to actual release. Bug & security fixes/improvements.

agent3_content_delivery.md

@@ -0,0 +1,66 @@
+# 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.