Verifie en conditions reelles apres le premier vrai succes de bout en
bout de release.yml (v0.2.0, Release Forgejo #12 avec batchcooking.apk
attache) : Forgejo, contrairement a GitHub, n'implemente pas le
raccourci /releases/latest/download/<fichier>. Seul /releases/latest
lui-meme resout (redirige vers la page de la release) :
/releases/latest/download/batchcooking.apk -> 404
/releases/latest -> 303 vers /releases/tag/v0.2.0 (OK)
/releases/download/v0.2.0/batchcooking.apk -> 200 (OK, mais pas "latest")
Corrige les deux endroits qui presumaient le raccourci GitHub (issue #65
et #66, deja mergees) pour pointer vers /releases/latest tout court : un
clic de plus via la page de release Forgejo pour atteindre le fichier,
mais un lien qui resout toujours plutot qu'un raccourci qui 404 en
permanence. Met a jour le test Cypress de la page d'accueil et le
commentaire de release.yml en consequence.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Sur la page vitrine `/`, sous la rangée de CTA du hero (pas un 3e bouton :
un compte reste nécessaire quelle que soit la plateforme), un lien discret
vers l'APK Android + une ligne d'aide.
- Cible : l'asset `batchcooking.apk` de la dernière release taguée Forgejo
(`/releases/latest/download/…`, nom de fichier stable) — pas un artefact
de CI. 404 tant que #64 + la correction de release.yml ne sont pas faits :
état transitoire assumé, ce ticket n'ajoute que le lien.
- `mobileHint` : rappel honnête que c'est un .apk à sideloader, pas une
distribution Play Store.
- i18n `landing.hero.mobileDownload` / `mobileHint` ; style discret dans
landing-page.scss ; scénario Cypress de plus (présence + href du lien).
Vérifs : `pnpm build` + `pnpm lint` OK. `landing.feature` non lancé en
local (le hoist `tslib` de `@cypress/vite-dev-server` dans ce node_modules
est cassé par un `pnpm install --force` interrompu + un verrou concurrent
sur `@esbuild/win32-x64` ; `pnpm-lock.yaml` inchangé, la CI n'est pas
affectée) → couvert par le job `e2e` de la CI.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Un visiteur déconnecté sur `/` voit désormais une vraie page de
présentation avant qu'on lui demande de se connecter, au lieu d'être
renvoyé directement vers `/login`.
- `RequireAuth.tsx` devient sensible au chemin : dans sa branche `!user`,
`pathname === "/"` rend `<LandingPage />` ; toutes les autres routes
protégées redirigent vers `/login` exactement comme avant. Aucun
changement de la table de routes — `/` reste `<PlanningPage>` niché sous
`RequireAuth`+`AppLayout`, et `AppLayout` (donc la sidebar) ne monte
jamais pour la vitrine.
- `pages/landing/LandingPage.tsx` + `landing-page.scss` : hero (accroche +
illustration SVG dessinée à la main dans le langage de `lucide-react`,
zéro dépendance ni asset externe) + deux CTA, grille de 4
fonctionnalités (icônes lucide), section « aperçu », CTA final. Copie
entièrement sous le namespace i18n `landing.*`.
- `index.html` : favicon SVG (monogramme « bC ») + `<meta description>` —
`/` est maintenant une page publique partageable.
- Les 3 captures d'écran réelles de la section « aperçu » sont servies
statiquement depuis `public/landing/` (un fichier manquant retombe sur
son `alt`, ne casse pas le build) ; elles restent à produire par un
humain avec l'app lancée sur des données réelles — cf.
`public/landing/README.md`.
- Tests Cypress `landing.feature` : vitrine visible déconnecté sur `/`,
CTA vers `/login` et `/signup`, autre route protégée toujours redirigée,
visiteur connecté voit bien le planning. `smoke.cy.ts` mis à jour pour
tester la redirection depuis `/recettes` (puisque `/` ne redirige plus).
Closes#41
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
