14 KiB
Summary Index: AI Weekly Synth Refactoring Analysis
Generated: 2026-03-21 Source reports: 4 team analysis files
1. Overview
Four specialists have independently analyzed the proposed refactoring of AI Weekly Synth from its current React/Firebase/Gemini SPA architecture to a Rust backend, SolidJS frontend, SQLite database, and custom authentication system. Their reports cover UX migration risks and new interaction flows, backend architecture and API design, security vulnerabilities and hardening measures, and a critical challenge of the entire refactoring's scope and technology choices. Together, these analyses reveal a project that is technically ambitious but carries significant risks around scope, timeline, and the gap between a "refactoring" label and what is effectively a complete greenfield rewrite.
2. Reports
| # | Filename | Focus Area | Summary |
|---|---|---|---|
| 1 | 01-ux-analysis.md |
UX and user experience | Inventories every screen, interaction pattern, and visual design element of the current app. Maps React-to-SolidJS migration risks at the UI level, designs new auth flows (sign-up, magic link login, session management), proposes admin module layouts, multi-provider settings UX, and SSE-based generation progress feedback. Identifies 8 concrete UX issues to fix during the rewrite (mobile nav, inconsistent deletion, missing validation, accessibility). |
| 2 | 02-architecture-analysis.md |
Backend architecture and API design | Recommends Axum over Actix-web, defines a clean 3-layer project structure (handlers/services/db), designs 7 SQL migrations, a full REST API with 20+ endpoints, an LLM provider trait abstraction with per-provider web search strategies, a token-bucket rate limiter, the two-pass generation pipeline in Rust, SolidJS frontend scaffolding with auth context, and a Firebase-to-SQLite data migration plan. |
| 3 | 03-security-analysis.md |
Security audit and hardening | Documents 9 security vulnerabilities in the current app (API key exposure, Gmail OAuth handling, prompt injection, CORS proxy data leakage, hardcoded PII). Designs the magic link token lifecycle with SHA-256 hashing, session cookie security, CSRF double-submit pattern, AES-256-GCM encryption for API keys at rest, SSRF prevention for URL scraping, Content Security Policy headers, Docker container hardening, and a 10-item threat model. |
| 4 | 04-devils-advocate.md |
Critical challenge and risk assessment | Questions every technology choice (Rust, SolidJS, SQLite), argues this is a complete rewrite not a refactoring, estimates 7-14 months realistic timeline for a single developer, identifies the multi-LLM abstraction as the hardest unsolved problem, warns that hand-rolled auth replaces a battle-tested managed service, and proposes two alternative approaches: a minimal 2-4 week backend proxy, or a phased 5-phase incremental migration. |
3. Consolidated Open Questions
All questions and ambiguities raised across the four reports, deduplicated and organized by theme. Reference numbers (e.g., Q-AUTH-1) allow the project owner to respond item by item.
Authentication
| # | Question | Raised by |
|---|---|---|
| Q-AUTH-1 | Will Google SSO be kept alongside the new email+magic link auth, or dropped entirely? If dropped, existing users lose access unless a migration path exists. | UX, Architecture, Devil's Advocate |
| Q-AUTH-2 | What is the migration path for existing Google-authenticated users? Options: dual auth during transition (UX recommends), forced migration, or pre-migration email campaign. | UX |
| Q-AUTH-3 | How will the first admin account be created? Options: (a) CLI command at deployment, (b) first-user-is-admin, (c) environment variable with seed admin email. Security recommends (a); Architecture assumes env var. | Security, Architecture |
| Q-AUTH-4 | Should registration be open (anyone can create an account) or require admin approval / invite-only? | Security |
| Q-AUTH-5 | What session duration is appropriate? Architecture proposes 30 days; Security proposes 7 days absolute with 24-hour idle timeout. These differ significantly. | Architecture, Security |
Architecture
| # | Question | Raised by |
|---|---|---|
| Q-ARCH-1 | How many concurrent users are expected? This determines whether SQLite is viable (fine for <5, problematic at 10-20 concurrent writers) or whether Postgres is needed from day one. | Architecture, Devil's Advocate |
| Q-ARCH-2 | Is the Rust choice driven by the project's technical needs or by a learning goal? Both are valid but lead to different decisions. | Devil's Advocate |
| Q-ARCH-3 | Is "without Docker" deployment a hard requirement or nice-to-have? Supporting both Docker and bare-metal doubles deployment documentation and testing. | Devil's Advocate |
| Q-ARCH-4 | What is the data migration volume? How many existing users and syntheses need migrating? This determines whether a one-shot script suffices or incremental tooling is needed. | Architecture |
| Q-ARCH-5 | Should legacy SynthesisData fields (majorAnnouncements, financialSector, etc.) be migrated to the sections[] format, or dropped entirely? |
Architecture |
| Q-ARCH-6 | What is the concrete timeline and deadline? Without one, scope expands indefinitely. | Devil's Advocate |
| Q-ARCH-7 | What is the target response time for synthesis generation? Should generation be synchronous or asynchronous (start and get notified when done)? | Devil's Advocate |
Scope
| # | Question | Raised by |
|---|---|---|
| Q-SCOPE-1 | Is this a refactoring or a complete rewrite? Every component is being replaced with zero code reuse. The project should be named and planned accordingly. | Devil's Advocate |
| Q-SCOPE-2 | What happens if the project is abandoned at 50% completion? With a total rewrite, all investment is wasted. With phased delivery, each phase provides value independently. | Devil's Advocate |
| Q-SCOPE-3 | Which LLM providers are actually needed on day one? If only Gemini, the multi-provider abstraction can be deferred (YAGNI). | Devil's Advocate |
| Q-SCOPE-4 | What is the testing strategy? The current app has zero tests and the proposal does not mention testing. Is testing budgeted? | Devil's Advocate |
UX
| # | Question | Raised by |
|---|---|---|
| Q-UX-1 | Will the new backend provide WebSocket/SSE for real-time updates, or will the app switch to polling? The current Firestore onSnapshot provides live updates on Home and Sources. Losing this is a perceived UX regression. |
UX |
| Q-UX-2 | Is internationalization (i18n) planned? The entire UI is currently in French. This affects how text is structured in the SolidJS rewrite. | UX |
| Q-UX-3 | Who is "admin"? Is this a single-tenant self-hosted scenario (deployer = admin) or multi-tenant SaaS with super-admin? | UX |
| Q-UX-4 | Can each user choose their preferred LLM provider, or does the admin configure one global provider? If user-level, do users bring their own API keys? | UX |
| Q-UX-5 | What replaces the Gmail API email sending feature now that Google auth is being removed? Backend SMTP? Dedicated email service? Or is the feature dropped? | UX |
Security
| # | Question | Raised by |
|---|---|---|
| Q-SEC-1 | Will there ever be shared syntheses between users (e.g., team workspaces)? This fundamentally changes the authorization model from strict per-user isolation. | Security |
| Q-SEC-2 | For the master encryption key (API keys at rest), is an environment variable acceptable, or should a KMS (Vault, AWS KMS) be used? | Security |
| Q-SEC-3 | Should LLM API rate limits be global (shared across all users) or per-user with a global ceiling? | Security |
| Q-SEC-4 | Will you self-host SMTP (e.g., Postfix in Docker) or use an external transactional email service (Resend, SES, Mailgun)? This affects DNS configuration (SPF/DKIM/DMARC) and deliverability. | Security |
| Q-SEC-5 | What is the budget for external services (email, LLM APIs, domain/TLS, VM hosting)? If budget is zero, Firebase's free tier is hard to beat. | Devil's Advocate |
| Q-SEC-6 | Who will operate this in production? Self-hosted means self-operated: backups, TLS renewal, security patches, monitoring. Is someone committed to this ongoing work? | Devil's Advocate |
| Q-SEC-7 | How will API keys stored in SQLite be protected, given that SQLite stores data in a plain file readable by anyone with file access? | Devil's Advocate |
LLM Providers
| # | Question | Raised by |
|---|---|---|
| Q-LLM-1 | How will web search grounding be handled for non-Google providers? Gemini's googleSearch is deeply integrated; OpenAI and Anthropic have different or no equivalent. |
UX, Architecture, Devil's Advocate |
| Q-LLM-2 | Is the 2-pass generation pipeline (search + scrape + rewrite) non-negotiable? If it can be simplified for some providers, the multi-provider problem becomes much easier. | Devil's Advocate |
| Q-LLM-3 | Are you building one abstraction over fundamentally different capabilities, or three separate pipelines behind a common interface? The first is a leaky abstraction; the second is honest but expensive. | Devil's Advocate |
| Q-LLM-4 | Is the Gmail email sending feature (user sends from their own Gmail account) being kept, or replaced with system-sent email? These have different privacy implications. | Devil's Advocate |
4. Key Tensions
The following areas surface conflicting perspectives or implicit disagreements across the reports.
Tension 1: Full Rewrite vs. Incremental Migration
The Architect (02) designs a comprehensive new system assuming the full rewrite is happening. The Devil's Advocate (04) argues this is reckless -- none of the current problems require a full rewrite, and a 200-line proxy server solves the two most critical issues (API key exposure and CORS). The Devil's Advocate proposes a 5-phase incremental plan where each phase delivers value independently, versus the all-or-nothing approach the Architect designs for.
Tension 2: Rust as the Backend Language
The Architect (02) designs the entire backend around Rust/Axum with detailed code samples, crate selections, and compile-time query checking. The Devil's Advocate (04) challenges this directly: the application proxies LLM API calls that take 10-60 seconds each, so Rust's performance advantages are irrelevant. Go or Python/FastAPI would deliver the same user experience with 3-5x faster development velocity and a dramatically larger hiring pool.
Tension 3: SolidJS vs. Keeping React
The UX Specialist (01) and Architect (02) accept SolidJS as a given and work through the migration risks. The Devil's Advocate (04) points out that the current React frontend is only ~900 lines across 7 files, and SolidJS provides zero user-visible benefit for an app with 5 pages. The cost/benefit ratio of the framework switch is questioned: React 19 or Svelte would avoid the rewrite cost or provide a larger ecosystem respectively.
Tension 4: Custom Auth vs. Managed/Third-Party Auth
The Architect (02) designs a full custom auth system (magic links, sessions, captcha). The Security Specialist (03) provides detailed implementation guidance but acknowledges the complexity. The Devil's Advocate (04) warns this is "building a mini identity provider" with hidden work (email deliverability, token management, session storage, account recovery, rate limiting, GDPR compliance) and recommends self-hosted solutions like Authentik or Keycloak that provide all of this out of the box.
Tension 5: SQLite vs. Postgres
The Architect (02) designs for SQLite with a claimed "Postgres upgrade path" via sqlx feature flags. The Devil's Advocate (04) calls this an upgrade path "myth" -- the SQL dialects differ enough that you either write to the lowest common denominator of both (losing benefits of each) or maintain separate query sets. The Devil's Advocate recommends starting with Postgres from the outset since Docker makes it trivial.
Tension 6: Session Duration
The Architect (02) proposes 30-day sessions with extension on each request. The Security Specialist (03) recommends 7-day absolute expiration with a 24-hour idle timeout. For a weekly-use app, the UX Specialist (01) notes that session duration must be at least 7 days to avoid forcing weekly re-login. These three positions need reconciliation.
Tension 7: CSRF Strategy
The Architect (02) recommends a custom X-Requested-With header as sufficient CSRF protection when combined with SameSite=Lax. The Security Specialist (03) recommends a full Synchronizer Token pattern (dedicated CSRF token stored server-side, sent via X-CSRF-Token header) plus Origin header validation for defense-in-depth. These are different approaches at different security/complexity tradeoffs.
Tension 8: Captcha Provider
The Architect (02) recommends Cloudflare Turnstile (external SaaS). The Security Specialist (03) recommends mCaptcha (self-hosted, open-source) to align with the "no external dependencies" philosophy. The UX Specialist (01) recommends against Google reCAPTCHA but suggests hCaptcha or Turnstile for better UX. These need a decision based on the self-hosting requirement's strictness.
5. Recommended Reading Order
-
04-devils-advocate.md-- Read first. This report challenges every assumption and raises the most fundamental questions (should this rewrite happen at all? is the scope realistic?). Answering its 15 hard questions will shape every subsequent decision. -
01-ux-analysis.md-- Read second. This provides a complete inventory of the current app's UX, identifies what must be preserved, and designs the new auth and admin flows. Understanding the user-facing surface area grounds the technical decisions. -
02-architecture-analysis.md-- Read third. Once scope and UX are decided, this report provides the detailed technical blueprint: API design, database schema, project structure, LLM abstraction, and deployment configuration. -
03-security-analysis.md-- Read last. This report audits the current vulnerabilities, then provides security requirements for every component designed by the Architect. It adds constraints and refinements (encryption, SSRF protection, threat model) that should be layered on top of the architecture.