Le problème
Les gestionnaires de tâches généralistes encouragent l’accumulation. The Five impose une contrainte volontaire : pas plus de cinq objectifs par jour. Chaque objectif peut être décomposé en sous-tâches, le travail terminé s’efface visuellement et les journées passées restent disponibles pour la réflexion plutôt que de former un backlog indéfiniment modifiable.
Le produit associe un modèle d’interaction ciblé, une persistance multi-utilisateur et une authentification sans mot de passe, sans framework frontend ni étape de build.
Architecture
JavaScript natif · Shell PWA
Authentification · sessions · API
Utilisateurs · jours · objectifs · étapes
Frontière de confiance : l’état du navigateur améliore l’interface, mais les sessions authentifiées côté serveur restent l’autorité pour l’identité et les données quotidiennes.
Choix produit
- La limite de cinq objectifs transforme la priorisation en règle du produit.
- Le calendrier et l’historique chronologique exposent les journées terminées ou incomplètes sans rechargement.
- Reporter un objectif crée un nouvel enregistrement sans modifier la journée historique d’origine.
- Le mode Anti-procrastination verrouille les jours passés tout en laissant leurs détails consultables.
- Les préférences de réduction des animations sont respectées pour le réordonnancement et la célébration finale.
Choix de sécurité
- L’inscription et la connexion sans mot de passe utilisent des codes e-mail à six chiffres, valables dix minutes et limités à cinq tentatives.
- Les sessions sont gérées côté serveur, transmises par cookies HttpOnly et expirent après sept jours.
- Les OTP et jetons de session bruts ne sont pas stockés directement ; seules leurs représentations hachées persistent.
- Les API de données quotidiennes exigent une session valide et imposent la propriété par utilisateur.
- Le changement d’adresse exige la vérification de la nouvelle adresse et ferme les autres sessions.
Limite assumée : le jalon actuel est un prototype multi-utilisateur local. L’e-mail dépend de Gmail SMTP, les rappels ne fonctionnent que lorsque l’application reste ouverte, et les fonctions multi-appareils dépendantes du backend restent à venir. Une exploitation en production exigerait aussi déploiement durci, HTTPS, secrets gérés, supervision, sauvegardes, contrôles anti-abus et tests de sécurité plus larges.
État des preuves : projet en ligne et étude d’ingénierie. Aucun dépôt source public n’est actuellement revendiqué.