From e4ad0927517063078564af5aa744e338ba58a86f Mon Sep 17 00:00:00 2001 From: Arnaud Date: Sat, 18 Jul 2026 01:35:35 +0200 Subject: [PATCH] docs: drop /changelog from vitrine plan, flag in-app "what's new" gap MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit CHANGELOG.ts is a dev log (migration reminders, bug-fix jargon), not fit for public display. Removed the public changelog page from the vitrine's page list/rollout/PUBLIC_PATHS example. Added §6 flagging the real underlying need — a curated, in-app "What's New" surfaced to existing users (bell/badge, keyed off last-seen version) — as a separate, smaller feature to scope properly later, not folded into this plan. --- VITRINE_PLAN.md | 33 +++++++++++++++++++++++++-------- 1 file changed, 25 insertions(+), 8 deletions(-) diff --git a/VITRINE_PLAN.md b/VITRINE_PLAN.md index 68ad7cb..f202a60 100644 --- a/VITRINE_PLAN.md +++ b/VITRINE_PLAN.md @@ -5,8 +5,7 @@ **Current state, confirmed by reading the actual code, not assumed:** - `apps/web/app/page.tsx` — `/` unconditionally `redirect("/recipes")`, no marketing content exists. - `apps/web/proxy.ts` (the app's middleware, `export default proxy` + `config.matcher`) gates every path **not** in `PUBLIC_PATHS` behind a session cookie, redirecting straight to `/login`. `/` is not in that list — so today, an anonymous visitor hitting `/` never even reaches `page.tsx`'s redirect; they're bounced to `/login` first. **This is the one integration point that actually matters** — the vitrine is invisible to anonymous visitors until `PUBLIC_PATHS` changes. -- No `/privacy`, `/terms`, `/about`, `/contact`, `/features`, `/pricing`, or public `/changelog` route exists anywhere. -- `apps/web/lib/changelog.ts` already has a `CHANGELOG` array — currently only rendered at `/admin/changelog` (admin-only). Directly reusable for a public changelog page, no new data source needed. +- No `/privacy`, `/terms`, `/about`, `/contact`, `/features`, or `/pricing` route exists anywhere. - No `sitemap.ts`/`robots.ts` — Next.js supports both as file-based special routes (same convention already used for `app/manifest.ts`, seen in that file) — currently missing entirely, worth adding as basic SEO hygiene regardless of how much content the vitrine ends up with. --- @@ -18,7 +17,6 @@ | `/` | Home — hero, value prop, 3-4 feature highlights with screenshots, primary CTA → `/signup` | | `/features` | Deeper tour: AI recipe generation, meal planning, pantry tracking, social (follows/ratings/comments), the cooking assistant + its tool-calling (create recipe / add to shopping list from chat) | | `/pricing` | Free/Pro/Family comparison table, CTA into Checkout once Stripe ships (`STRIPE_PLAN.md` §5/§7), or straight to `/signup` before it does | -| `/changelog` | Public version of the existing `CHANGELOG` data — social proof of active development, good for conversion and for existing users checking what's new | | `/about` | Story/mission — why this exists, who's building it | | `/privacy` | Privacy policy — needed once collecting emails regardless of Stripe timing (GDPR, since you're in France/EU per `STRIPE_PLAN.md` §10) | | `/terms` | Terms of service | @@ -41,7 +39,7 @@ Not in v1, deferred: a blog (`/blog`) — real SEO value but ongoing content-pro ```ts const PUBLIC_PATHS = [ "/login", "/signup", /* ...existing... */, - "/", "/features", "/pricing", "/changelog", "/about", "/privacy", "/terms", "/contact", + "/", "/features", "/pricing", "/about", "/privacy", "/terms", "/contact", ]; ``` Note `/` needs an **exact** match, not `startsWith` — the current check is `pathname.startsWith(p)`, which is fine for `/features` etc. (nothing else starts with those prefixes) but `"/"` as a prefix would make `PUBLIC_PATHS.some(p => pathname.startsWith(p))` true for literally every path, since every path starts with `/`. This needs a small tweak to the matching logic, not just an array addition — e.g. check `pathname === "/"` as its own condition alongside the `startsWith` list, don't add bare `"/"` into the array. @@ -52,7 +50,7 @@ Note `/` needs an **exact** match, not `startsWith` — the current check is `pa ## 3. SEO basics (currently entirely missing) -- `app/sitemap.ts` — list the 8 marketing routes (file-based Next.js route, same pattern as the existing `app/manifest.ts`). +- `app/sitemap.ts` — list the 7 marketing routes (file-based Next.js route, same pattern as the existing `app/manifest.ts`). - `app/robots.ts` — allow marketing routes, disallow `/api`, `/admin`, `(app)` authenticated routes, `/r/`/`/s/`/`/u/` if those shouldn't be indexed (check current intent — they're public-but-unlisted-ish today, decide explicitly rather than defaulting). - Per-page `generateMetadata` (title/description/OpenGraph image) — every existing app page already sets `export const metadata: Metadata = {}` as a placeholder pattern; marketing pages should actually fill these in, they're the ones search engines/social shares see. - One shared OG image (or per-page) — doesn't need to be fancy, just present; a page with no OG image looks broken when shared on socials, more damaging than a plain one. @@ -71,6 +69,25 @@ Note `/` needs an **exact** match, not `startsWith` — the current check is `pa 1. `sitemap.ts`/`robots.ts` + the `PUBLIC_PATHS`/root-`page.tsx` change (§2–3) — plumbing first, still no real content, safe to ship and verify the routing/auth-gating logic works before writing copy. 2. `/` (home) + `/features` — the two pages that actually sell the product; ship these before pricing exists if Stripe isn't live yet (CTA → signup, not checkout). -3. `/changelog` — cheapest page to build (data already exists), good early win. -4. `/privacy` + `/terms` + `/about` + `/contact` — required-but-not-persuasive pages, batch together. -5. `/pricing` — once `STRIPE_PLAN.md` pricing (§1c) is confirmed and ideally once Checkout exists, so the CTA goes somewhere real instead of just to signup. +3. `/privacy` + `/terms` + `/about` + `/contact` — required-but-not-persuasive pages, batch together. +4. `/pricing` — once `STRIPE_PLAN.md` pricing (§1c) is confirmed and ideally once Checkout exists, so the CTA goes somewhere real instead of just to signup. + +--- + +## 6. Separate concern: advertising new features to existing users + +Not part of this plan (in-app, not public/marketing), but flagged since it +came up here: `apps/web/lib/changelog.ts`'s `CHANGELOG` array is written +for you, not users — entries mix real feature announcements with internal +notes ("not applied in sandbox — run `pnpm db:migrate`", bug-fix jargon, +migration reminders). That's correctly *not* public. But there's a real +gap: users have no clean way to learn what shipped since they last looked. + +Direction for later, not scoped in detail here: a curated, user-facing +"What's New" — either a hand-picked subset/rewrite of `CHANGELOG` entries +(only the ones worth telling a user about, in plain language, not the raw +dev log) or a separate small table if the two need to diverge more than a +filter allows. Surfaced in-app — a badge/dot on a bell icon, a dismissible +panel on next login, keyed off "last version the user has seen" so it only +shows genuinely new items. This is a distinct, smaller feature from the +vitrine and can be scoped properly in its own pass.