Ce qu'un visiteur déconnecté peut faire, et ce qui nécessite un compte

Quiconque peut essayer OrbitingFox sans s'inscrire. Voici à quoi cela ressemble, et — tout aussi importamment — ce qu'il ne fait pas semblant d'offrir.

Capturer sans un compte

Un visiteur peut capturer quelques Blinks de test directement depuis la page d'accueil, puis en ouvrir un pour ajouter des détails. Ce sont de vraies lignes de notre côté, pas juste quelque chose conservé dans le navigateur, et si la personne s'inscrit dans la même session tout ce qu'elle a capturé devient un vrai Blink sur son nouveau compte. Revenir et se connecter plus tard permet également de les récupérer.

Pourquoi le formulaire montre des choses que vous ne pouvez pas utiliser (2026-09-11)

La page "ajouter des détails" est le vrai formulaire Blink — le même que les titulaires de compte recevraient. Jusqu'à présent, les parties qu'un invité ne pouvait pas utiliser étaient simplement cachées, et le propriétaire a rapporté exactement ce que cela produisait : "ce simple formulaire ne montre pas l'ensemble de notre système, et ils pensent que ce n'est pas un système complet. Ils n'ont aucune idée que nous avons des systèmes beaucoup plus avancés."

Il avait raison. Une barre d'onglets avec les onglets intéressants manquants semble être un jouet. Donc, ces sections sont désormais visibles et verrouillées : les onglets Lien et Finances sont à l'écran, et en ouvrant l'un d'eux il est expliqué en mots simples ce qu'il fait sur un vrai Blink et qu'un compte le déverrouille.

Verrouillé signifie qu'il n'y a rien à taper

C'est la partie à comprendre, car la version évidente de ce changement aurait été pire que de ne rien faire.

La capture d'un invité ne peut contenir qu'un titre, une description et un type. C'est tout ce qu'il y a de l'espace pour. Si les sections verrouillées étaient simplement activées, quelqu'un pourrait remplir catégories, objectifs, lien et finances, appuyer sur Sauvegarder, et chacune de ces réponses disparaîtrait sans un mot. Un produit qui montre un champ et jette la réponse enseigne aux gens à ne pas lui faire confiance.

Donc, les sections verrouillées ne contiennent aucun champ. Rien ne peut être tapé, donc rien ne peut être perdu.

L'exemple montre réellement la profondeur

Un formulaire vide avec chaque onglet disponible ne prouve rien. Sous le formulaire, il y a maintenant un exemple de Blink rempli — catégories, un objectif, un projet, un lien, des finances, une note vocale — clairement marqué comme un exemple et non les données propres du visiteur. C'est ce qui démontre ce que le produit fait lorsqu'il est réellement utilisé.

Ce qui nécessite un compte

• Notes vocales et fichiers — enregistrer dans un Blink, conserver l'audio, transcription automatique, et joindre des images ou des documents.
• Lien — votre propre arbre de catégories, et connecter un Blink aux objectifs, projets, entreprises et liens enregistrés.
• Finances — un montant, un revenu ou une dépense, traitement fiscal et une date.
• Conserver quoi que ce soit de manière permanente — les captures d'invités sont liées à une session de navigateur jusqu'à ce qu'elles soient converties.

Pour les développeurs

Les captures d'invités sont des lignes dans adminapp.GuestCapture clés par session_key — pas les données de session. docs/blink/SRS.md §3.7 disait request.session["guest_winks"] jusqu'à ce que le BL-466 le corrige ; cela avait été obsolète depuis le déplacement de stockage.

Le modèle contient six champs et config.views.guest_capture_edit enregistre trois (titre, description, type_blink). Cette asymétrie est toute la contrainte de cette fonctionnalité. Si un invité doit un jour conserver plus, GuestCapture doit d'abord faire croître les champs et le chemin de promotion doit les transporter — ce n'est pas un changement de modèle.

Les aperçus verrouillés vivent derrière {% if not guest_mode %}{% else %} dans templates/blink/_blink_form.html, et une garde (adminapp/test_guest_sees_depth.py) affirme que la branche invitée ne contient pas de <input>, <textarea> ou <select>, donc la défaillance de rejet silencieux ne peut pas être réintroduite par accident. Le même fichier indique que cette conversion lors de l'inscription fonctionne toujours, car le propriétaire a spécifiquement demandé que cela soit vérifié plutôt que présumé.

L'exemple est templates/guest/_sample_blink.html et est délibérément statique : un invité est anonyme, la page doit se rendre de la même manière pour tout le monde, et elle ne doit jamais dépendre de seed_sample_data ayant été exécuté dans un environnement donné — ce qui n'est pas le cas en production. Le principe date de la ligne : docs/auth/User-Registry-and-Authorization-Flow.txt:239 — "La démo anonyme doit utiliser données d'exemple, données de session temporaires, ou exemples en lecture seule seulement."