Lo que un visitante desconectado puede hacer y lo que necesita una cuenta

Cualquiera puede probar OrbitingFox sin registrarse. Así es como se ve eso y — igual de importante — lo que deliberadamente no pretende ofrecer.

Capturando sin una cuenta

Un visitante puede capturar algunos Blinks de prueba directamente desde la página de inicio, y luego abrir uno para agregar detalles. Esas son filas reales de nuestro lado, no solo algo guardado en el navegador, y si la persona se registra en la misma sesión todo lo que capturó se convierte en un Blink real en su nueva cuenta. Volver y iniciar sesión más tarde también lo recupera.

Por qué el formulario muestra cosas que no puedes usar (2026-09-11)

La página de "agregar detalles" es el formulario real de Blink — el mismo que obtienen los titulares de cuentas. Hasta ahora, las partes que un visitante no podía usar estaban simplemente ocultas, y el propietario reportó exactamente lo que eso produjo: "ese formulario simple no muestra todo nuestro sistema, y ellos piensan que no es un sistema completo. No tienen idea de que tenemos sistemas mucho más avanzados."

Tenía razón. Una barra de pestañas con las pestañas interesantes faltantes se lee como un juguete. Así que esas secciones ahora son visibles y bloqueadas: las pestañas de Vínculo y Finanzas están en la pantalla, y abrir una explica en palabras simples lo que hace en un verdadero Blink y que una cuenta lo desbloquea.

Bloqueado significa que no hay nada en qué escribir

Esta es la parte que vale la pena entender, porque la versión obvia de este cambio habría sido peor que no hacer nada.

La captura de un visitante solo puede sostener un título, una descripción y un tipo. Eso es todo lo que hay espacio. Si las secciones bloqueadas simplemente se activaran, alguien podría completar categorías, objetivos, vínculo y finanzas, presionar Guardar, y cada una de esas respuestas desaparecería sin una palabra. Un producto que muestra un campo y desecha la respuesta enseña a las personas a no confiar en él.

Por lo tanto, las secciones bloqueadas no contienen ningún campo en absoluto. No se puede escribir, por lo que no se puede perder nada.

El ejemplo es lo que realmente muestra la profundidad

Un formulario vacío con cada pestaña disponible no prueba nada. Debajo del formulario ahora hay un Blink de ejemplo lleno — categorías, un objetivo, un proyecto, un vínculo, finanzas, una nota de voz — claramente marcado como un ejemplo y no como datos del visitante. Eso es lo que demuestra lo que hace el producto cuando realmente se está utilizando.

Lo que necesita una cuenta

• Notas de voz y archivos — grabar en un Blink, conservar el audio, transcripción automática, y adjuntar imágenes o documentos.
• Vínculo — tu propio árbol de categorías y conectar un Blink a objetivos, proyectos, negocios y vínculos guardados.
• Finanzas — un monto, ingreso o gasto, tratamiento fiscal y una fecha.
• Conservar cualquier cosa de forma permanente — las capturas de los visitantes están atadas a una sesión del navegador hasta que se conviertan.

Para desarrolladores

Las capturas de los visitantes son filas en adminapp.GuestCapture clave por session_key — no datos de sesión. docs/blink/SRS.md §3.7 dijo request.session["guest_winks"] hasta que BL-466 lo corrigió; eso había estado obsoleto desde que se movió el almacenamiento.

El modelo contiene seis campos y config.views.guest_capture_edit guarda tres (título, descripción, tipo_blink). Esa asimetría es toda la restricción de esta función. Si un visitante alguna vez va a conservar más, GuestCapture tiene que aumentar los campos primero y el camino de promoción tiene que llevarlos a través — no es un cambio de plantilla.

Las vistas bloqueadas viven detrás de {% if not guest_mode %} …{% else %} en templates/blink/_blink_form.html, y un guardia (adminapp/test_guest_sees_depth.py) afirma que la rama del visitante no contiene ningún <input>, <textarea> o <select>, por lo que el fallo de silencio no puede ser reintroducido accidentalmente. El mismo archivo asegura que la conversión en el registro sigue funcionando, porque el propietario pidió específicamente que eso se verificara en lugar de suponerse.

El ejemplo es templates/guest/_sample_blink.html y es deliberadamente estático: un visitante es anónimo, la página debe renderizarse idénticamente para todos, y debe nunca depender de que seed_sample_data haya sido ejecutado en un entorno dado — lo cual no ha sido así en producción. El principio precede a la fila: docs/auth/User-Registry-and-Authorization-Flow.txt:239 — "La demostración anónima debe usar datos de muestra, datos de sesión temporales o ejemplos solo de solo lectura."