oll.in — the v2 plan

This is the frozen-spines thesis paying off — with one honest exception. Radar is "point the existing dossier route at a scheduled feed"; Get-found is "a draft-post variant + a scheduler." Those are routes + deltas, no new infrastructure. Ollie (v2.4) is the exception — a per-user autonomous loop is a capacity model, not a route (see its section). Everything up to v2.3 is new code on the frozen spines; v2.4 is the one item that may need new infra. Naming that up front is the point.

Status (2026-07-08): oll-scout promoted to a real service → PR #93 (50 tests, ruff clean, docker build clean; saved-search CRUD keyed off the Core JWT + per-user tick + daily Core-email digest + ownership isolation, all proven by curl). The /radar frontend renders real scored match cards off a live tick (pulled 7 → 4 strong → digest sent), with a live min-score filter and a "Build dossier" hand-off into the v1 composer. The review-fix caught + fixed a real broken hop (the BFF hit the now-auth-required scout with no Bearer → 401 → 0 matches); now forwards the real Core JWT. The CHF 19/mo tier is wired to a real Core subscription-mode session (no fake charge) — the one product that legitimately is a subscription. Anon preview — SOLID: a public, no-auth GET /api/scout/sample-matches (PR #93, fixture-scored in-memory — no PII, no Core round-trip) now backs the logged-out /radar preview, so a stranger sees real scored cards with zero 401s in prod; signed-in still forwards the real JWT to the ownership-scoped /matches (verified: prod-mode sample-matches → 200 with no Core hop, while the old anon path correctly 401'd). Sam-gated: AUTH_PROVIDER=core in prod · a live CHF 19/mo recurring price + RADAR_PLAN_GATE · a Jooble key for live CH coverage (Arbeitnow works keyless today).

Status (2026-07-08): the /get-found route is built and honest. The draft is real oll-write/Groq generation grounded on the corpus (4 grounded passages; honest abstain on a miss). Postiz connections honestly report "no key"; the schedule action returns a real 501/409 ("no LinkedIn channel connected") — never a fake "scheduled." Sam-gated: a POSTIZ_API_KEY + a LinkedIn OAuth app to actually schedule (sanctioned OAuth only — never scraping).

Status (2026-07-08): the review-queue is built and proven end-to-end (after the shared Radar bearer-fix): a real match (score 100) → real dossier compose (oll-memory grounding + oll-write generation) → a draft with citations, prepared_by=ollie, status=draft, nothing sent. UI is honest: "drafts for you to review, never auto-sent"; "Approve & mark sent" is a status marker, not an employer submission (hard ethics/ToS line — no auto-apply, human-on-send always). The always-on per-user runtime is deferred, infra-gated — "Prepare now" is an honest manual trigger today.

⚠️ The hidden cost — this is a capacity model, not a feature. Everything else in v2 is a frontend route + a small backend delta. Ollie is a per-user agent runtime: an OpenCLAW loop running on a schedule, per subscriber. On a shared €5 VPS that is a real capacity question (concurrent loops, memory, rate-limits, cost-per-user) — new infrastructure, not new code. That's the honest reason it's last, alongside the ToS care. Don't let the "effort L" label hide that this rung needs a capacity plan before a line of it ships.

Status (2026-07-08): Tracker+ status pipeline built; the RAV reminder emails the user's own account address via Core (recipient-scoped, 401 if not signed in — real error surfaced), correctly framed "Swiss-format Bewerbung." German is in via next-intl (de.json, working language toggle; build passes). German — SOLID, proven by a Playwright walk across every surface (home/compose, /photo, /radar, applications, Ollie): a real defect was found + fixed (/photo and /radar were never wired to next-intl — English content under a German shell); now every visible string is routed through useTranslations (rich markup + interpolation), full EN/DE key parity, zero missing-key fallbacks or unresolved {vars}, no layout overflow on the longer German strings.

⚠️ The ladder has to add up out loud — or it confuses the exact everyday-professional we built for. A RAV job-seeker owes 10–12 applications/month. At CHF 9 each that's CHF 90–108/mo — which makes a CHF 99 pass look like mere break-even and Radar (CHF 19/mo) look strangely cheap next to per-dossier pricing. The fix is not the price, it's capping the CHF 9 unit visibly: frame it as "first application CHF 9 · the Pass pays for itself by application #11", so the page does the arithmetic for the buyer. CHF 9 is a trial rung, not the everyday unit — the Pass (unlimited) or Radar (found-for-you) is the home for anyone applying at volume. Each rung must be the obviously-right choice for one kind of user; per-application pricing that silently out-costs the Pass is a ladder that fights itself.

Gate order: v1 deploys + earns the first stranger franc → v2.1 guest photo (merge Core guest-checkout) → then a data-gated fork: v2.2 Radar ⇄ v2.3 Get-found → v2.4 Ollie → v2.5 polish. Radar is architecturally next (it reuses the whole dossier route + oll-scout), but which ships first is a data call, not a now call. Get-found needs only a LinkedIn OAuth app + a prompt, and it's what employed-and-curious users — the broader audience — want first; Radar is what active seekers want. Let the waitlist + the first francs vote: if the first ten buyers skew active-seeker, ship Radar; if they skew employed-and-curious, flip to Get-found. This is exactly what the attribution nights are for. Companion: the feature scope · architecture.