Lo que diseñamos,
en vivo y embebible.

Las bases para que el doctor y la secretaria creen un QR, decidan qué hace al escanear (reglas y acciones que se encienden y reordenan, con preview en vivo) y lo impriman en marca Amedi. Un solo papel, comportamiento que cambia desde el portal. 4 pantallas desktop.

Recordatorios multicanal antes, durante y después de la consulta. WhatsApp prioritario: confirmar y reagendar en un toque. Línea de tiempo, 6 pantallas, configuración por doctor, fases y métricas.

La máquina detrás del recordatorio: arquitectura, 3 diagramas de secuencia, modelo de datos y motor de envío (cron + cola en DB). Anclado en el código real de apps/api.

El intake del paciente al escanear el QR: la carpeta que el doctor siempre pide, hecha data estructurada (FHIR US Core / USCDI). 9 pantallas con el design system real de Amedi, más flujo + autenticación, arquitectura y casos borde. Subproyecto del QR del consultorio.

Un doctor demo con pacientes de prueba en la base de producción, aislado por is_demo y por sesión. El médico explora, agenda citas de prueba y abre consultas como de verdad — pero nada se filtra a los pacientes reales y cada muro invita a registrarse. 5 pantallas del flujo, tablero de permisos, backstage de la capa por sesión y 4 fases.

La maquinaria del modo demo: modelo de datos is_demo + demo_session_id, ciclo de request (guards + AsyncLocalStorage), 3 diagramas de secuencia, la matriz anti-fuga de superficies a filtrar, seeds con la membresía DoctorClinic, reset por sesión y la migración que retira el schema demo viejo. Anclado en el código real de apps/api.

El primer acto profesional de un doctor en Amedi sucede en un iframe de 350px sobre un texto que no dice cuánto cobra Amedi. El contrato rediseñado como documento editorial de 5 páginas — portada noche con resumen claro, cuerpo notarial, Anexo A de comisiones, firmas sobre noche con sello de auditoría — y las 4 estaciones de la firma: lectura a página completa, el canvas de trazo claro y el PDF siempre en la mano. Con los 8 huecos legales/técnicos señalados y receta de 6 archivos sin nada breaking.

El ciclo de producción de crescō en 5 láminas: el porqué humano, el overview y las tres fábricas — Discovery & Diseño, Desarrollo (skills + sub-agents + QA) y Operación (guardrail AI). De la reunión al release, y de vuelta.

La casa de los frentes que crescō debe dominar para salir al mercado en dic 2026: techo (la meta), columnas (qué construir · el motor · al mercado), cimientos y los dos planos transversales — AI que sirve y el mundo real. Cada área abre su ficha.

El propósito, los valores y la cultura de crescō como una casa: techo (que el cliente crezca y lo sienta), columnas (cómo pensamos · el corazón · cómo entregamos) y cimientos (cómo trabajamos, con AI que sirve). Borrador a validar.

El levantamiento del sistema operativo interno de Kenco, pensado como developers senior y como Jony Ive: la esencia (una memoria operativa), los siete principios, las nueve decisiones de fondo, el objeto-trabajo que fluye por compuertas y los cuatro verbos (cotizar es elegir · pagar es activar · producir es escanear · cerrar es leer), la puesta en producción del piloto de Imprenta Digital como tres funerales, el chasis que crece a los 8 departamentos por configuración, los requerimientos por dominio con sus anti-requerimientos, los riesgos y las preguntas abiertas de f0.

App del transportista en camión: ruta por cercanía, navegar, entregar, foto + firma y los caminos ámbar. 16 pantallas, diseño esencial.

App del operador de almacén: busca, encuentra, recibe. Reconciliación por tracking, foto por paquete, etiqueta por caja.

El paso Imprime hecho real: la iQ4R confirma cada etiqueta en papel, emparejamiento en un sheet, errores ámbar que se reanudan. 6 pantallas.

V1 · despacho contra manifiesto: home de dos modos, lectura masiva con la pistola Q3000 UHF y reconciliación del embarque (cargadas/faltan/sobran). Etiqueta combo UHF+QR. 7 pantallas + estados de borde e ingeniería.

V2 · el contenedor se llena hasta tope y el manifiesto nace al cerrar. Medidor de tanque, validación por destino, lo que no cupo va al próximo. Convive con la planificada.

V3 · la más reducida (à la Jony Ive): el contenedor nace de la primera caja, su identidad la presta el acero, y la pantalla se vuelve el objeto que se llena. Nada que elegir ni teclear.

App del agente: bandeja unificada WhatsApp/IG/TikTok en calma. La barra de input es el estado, el canal susurra, burbujas con memoria muscular. 9 pantallas.

Consola de escritorio que centraliza el dinero: Panorama, la bandeja de conciliación (un pago → varias facturas), fuentes tipo Tesote (bancos VE + EE.UU. + pasarela), egresos con soporte que iluminan la caja negra y export limpio a QuickBooks. 6 pantallas desktop, consolida la reunión del 7 jul.

La app de recibos, compañera de la consola de Finanzas: buscar al cliente, cobrar en dos gestos —enlace por WhatsApp, registrar pago o firma en el dispositivo— y el recibo se numera, se genera y se envía solo, ya conciliado. Incluye el alta del cliente que no existe (la búsqueda vacía se vuelve el alta), la página de pago que ve el cliente (ventana al saldo vivo), la cuenta de los toques, widgets iOS/Android + Live Activity, matriz de permisos por rol y 8 caminos ámbar: parcial, de más, bolívares a tasa BCV, otro número, sin señal, dos cajeras, recibo verificable por QR, anulación con rastro. 9 pantallas móviles.

La columna financiera de Mogos: organigrama de entidades (China, Venezuela, EE.UU., franquicias), cobro por entidad, liquidación inter-compañía con respaldo legal, libro mayor de doble partida y hoja de ruta auditoría → núcleo → créditos.

Los dos QRs del flete: la etiqueta de caja en marino de verdad (wordmark vectorial, QR nivel H con +45% de área, numeración BOX 3/12 y variante térmica) y la firma de entrega como documento — membrete, saldo visible, sello con el monograma y estados con salida. Cero migraciones.

Trolley's design tokens v0, extracted from withtrolley.ai: the four colors (green accent · navy CTAs · charcoal · periwinkle) with the hero gradient, the theme's type stack (Montserrat · Roboto Condensed · Roboto), the white slab wordmark and its rules, component samples from the prototype, and the system rule — navy commands the actions, green accents the selections. References the crescō brand manual as active methodology.

Interactive prototype: packaged AI-run operations for founder-led execution — media watch, content, investor comms — with a human veto. Live it in the phone: pick a tier, activate, watch the morning run, approve the investor update, open the honest digest — plus the amber path where a Trolley strategist takes the press inquiry the AI won't guess. Real Trolley brand (green · charcoal · navy, white slab wordmark).

Por qué el status actual hace tres trabajos a la vez y qué cambia al estructurar Customers → Agreements → Projects → Tasks. Leído del workspace real: las dos bases con sus 42 propiedades y ni una sola de tipo Persona. Trae la traza animada de un Reel rebotando 9 veces entre Andrew y Gaby, la auditoría campo por campo, la dieta de 26 status a 14, la vista To Review con botón Approve funcionando (aprobar sella, notifica y saca la fila), el timeline del contrato de Hone y el detalle de un proyecto con sus tareas, más la fórmula de % completación y los trade-offs honestos con su plan piloto. En inglés, marca Trolley.

De la reunión a la ejecución. La AI propone, las personas deciden.

La metodología de diseño de los productos crescō: la pantalla sabe en qué paso vas. La unidad de diseño es el flujo, no la pantalla — el foco viaja solo (Fitts a distancia cero), un verbo por estado que muta como la Dynamic Island (Hick), paneles de vidrio que nacen del control en vez de interrumpir (Liquid Glass), el vacío que se vuelve alta sin salir, la memoria desplegada donde se decide y que calla si no tiene nada que decir, el teclado como camino visible (↵ avanza · ⌘↵ confirma · esc regresa, nunca shortcuts memorizados) y commit optimista con una sola verdad. Nueve principios con demos animados en vivo — incluidos «el contexto se ve, no se memoriza» (lo decidido acompaña en chips reabribles) y «poka-yoke: prevenir; si ocurre, deshacer» (estados imposibles fuera del alcance, consecuencias visibles, trabajo conservado y vuelta atrás en el lugar del hecho; solo lo que no puede deshacerse ni compensarse se confirma, y lo irreversible se anula con rastro) — un flujo completo jugable con teclado real y contador de clicks, el capítulo móvil escrito con una mesa de cuatro especialistas (la ley del ancho, la fila que decide, la franja del pulgar, el teclado como piso, sheets con origen, la red mala como estado normal, Dynamic Type sin truncar), y el juramento de catorce reglas. Anclada en los patrones ya en producción de mogos (inline-entity-picker, action-search-surface, quote-line-memory).

La arquitectura del HQ de crescō: áreas, onboarding, el spine de bases.

Diseño de las vistas operativas: tablero, hoy por momento, galería.

Qué se puede y qué no en Notion nativo. Dónde entra la marca.

My Work y Meeting Task Triage: tu tablero y los botones Approve / Reject / Convert.

El teamspace all crescō y la base Tasks: sus relaciones y el ciclo de vida.

Con qué construimos: Next, Expo, NestJS, Prisma, Supabase, Render, DigitalOcean.

Tres conceptos nacidos del manual: Brō el brote, Ō el macrón y Capi la capibara. Estados de UI, matriz de decisión y veredicto.

El regalo que se gana: base de madera al firmar, una pieza por fase cerrada, flor solo en lanzamiento. Ritual y producción.

El universo multi-proyecto: parcelas que se acoplan por imanes, cuatro especies, el vivero espejo y producción China + Caracas.

El concepto completo en 8 capítulos: creencia, materiales, anatomía con cotas, siete momentos, gemelo digital, fases y juramento.

Los 26 subagents de crescō: inventario por cuadrilla, matriz de cobertura etapa × dominio y los 6 que hacen falta.

La capa operativa de cada cliente — el tercer pilar junto al código y a {cliente}-design. Agentes de NEGOCIO (no de código) que operan la data del cliente desde apps/agents/ de su propio monorepo, sobre eve: entran por su API vía OpenAPI (heredan sus validaciones y permisos), y el cliente configura sus rutinas hablando, sin deploy — las rutinas son datos en su DB con un solo cron despachador. La ley: el cliente escribe el encargo, crescō forja las herramientas. Incluye modo ensayo (toda rutina nace sin manos), la consola de 4 vistas estampada con los tokens del cliente, el catálogo de oficios derivado del schema real de mogos/amedi/kenco, el modelo de costos (el cómputo es el 1%, el humano el 77%) y los seis riesgos a blindar antes de cobrarlo.

Las 8 pantallas de operō dibujadas dentro del admin de Mogos y con la marca de Mogos — la prueba de que es un solo código estampado desde mogos-design/css/tokens.css. No es un chat con sidebar: es una plantilla de personal y un libro de recibos. La planta (la ficha empieza por los límites, «no escribe nada» en verde), las rutinas agrupadas por confianza (ensayo → activas → pausadas), la única conversación del producto, la bitácora donde «no hizo nada» es un resultado de primera clase, el recibo de una corrida (fuente citada con ms y registros, quién la aprobó, qué cambió y cuánto costó en dólares), aprobar como última edición (desmarcas al que no va y la corrección se vuelve permanente), el gasto con su tope, y el primer día — el vacío que le enseña al cliente que su API ya es la caja de herramientas.

Cada corte dev→main se vuelve un release versionado, asociado al proyecto del cliente, escrito en la voz de crescō. Dos agentes, tres bases (Releases · Channels · Piezas), changelog automático y social curado. El límite del release, el versionado por proyecto y el plan de build v1/v2.

La capa de aprendizaje de crescō. Un curso no es un archivo que leíste: es una relación con el tiempo. Arranca del hallazgo incómodo —resumir, subrayar y releer son de baja utilidad; recuperar y espaciar son de alta— y construye sobre eso los siete movimientos (pre-test, clase segmentada, traducción a un cliente real, recuperación, espaciado, calibración y transferencia). El progreso es un bosque navegable en 3D: las áreas son árboles, los topics ramas, las clases ramitas, los conceptos hojas, los proyectos frutos, y el cross-topic vive bajo tierra como red micorrízica — la madera nunca retrocede, solo el follaje respira. Incluye el bento de la clase (retícula fija como palacio de memoria, con baldosas que se abren sobre sí mismas para practicar sin perder contexto), el catálogo de nueve juegos atómicos, la lámina viva que se arma en vez de mirarse y refuta creencias falsas en vez de corregirlas, los seis movimientos que hoy no existen en ningún producto (causa raíz sobre prerrequisitos, explicar en voz alta, agenda contra el calendario real, pares confundibles, la regla del 85% y el cuaderno de errores), el pipeline desde las cuatro bases de Notion con las cinco reglas de calidad de tarjeta, el contrato de ligereza (cero dependencias) y el juramento de diez reglas.

La identidad, la voz y los lanzamientos de crescō. Documento vivo, fuente única de la voz que leen los agentes — voz/02 y lanzamientos/03. Las secciones quedan fetchables en design.cresco.so/manual/sections/.html.

La línea de hardware de crescō en 9 capítulos: el último metro del software, el norte Work Louder (Figma → Framer → Codex Micro de OpenAI), las tres familias — atajo · la flota · pulso —, la anatomía del atajo con su BOM real, los kits de Mogos, Amedi y Kenco, la ruta de fabricación en 4 fases, el tarifario borrador, el vivero de ideas (con las familias nuevas: la firma y la voz) y el juramento.

El gabinete de láminas: las 23 piezas del vivero dibujadas como si ya existieran — láminas XVI–XXXVIII en cuatro colecciones (Mogos, Amedi, Kenco, crescō), cada una con el color del cliente, el verbo del software que dispara y su costo. Companion visual del capítulo VIII de tangō.

La oficina física de crescō en 11 capítulos y 14 lugares: la creencia (la oficina se gana el commute), los seis principios, la paleta hecha materia, la planta y el corte — cresco coffee a la calle, jardín central a cielo abierto con huerto instrumentado y el cine adentro (la caja oscura donde empieza la visita de un cliente), biblioteca en silencio, estudio de música, dojo con duchas, cuartos de siesta individuales (también para masajes), el vacío, el taller de tangō y la terraza con fogón —, el gradiente acústico, mente y cuerpo (cocina con gente + app de la casa + despensa), el showroom (la casa es el demo: riego por sensores, despensa RFID, cédula NFC, clima, pulsos e-ink, la función personalizada — toda magia tiene manija), un martes cualquiera, la prueba contra el home office y el juramento de diez reglas.

Las catorce salas de habitō dibujadas por dentro — láminas VI–XIX: un alzado interior por sala (el café con su barra al andén, la entrada con la vitrina crēvī, el jardín con el huerto, la mesa larga contra la cocina abierta, las salas viva y cruda, las cabinas, la biblioteca, el estudio de escucha, el dojo con su hierro, los cuartos de siesta con camilla, el vacío, el taller de tangō, el fogón encendido y el cine — la caja oscura del jardín donde empieza la visita, con la función personalizada corriendo) — cada una con su materia, su equipo, su luz y su regla.

La maqueta navegable de la oficina: la nave completa en tres dimensiones con los materiales de la marca — orbitar, acercar, y un menú de las 12 zonas que vuela la cámara a cada cuarto con su ficha y su regla de la casa. Companion del concepto habitō.

Teleprompter by crescō: el guion vive en Notion y se lee enorme sobre el televisor junto al lente, con auto-scroll manos libres, atajos para clicker/pedal y toggle de espejo para rig de vidrio. Corre en cresco-home (Next.js); el token de Notion vive en el servidor. Cierra la cadena de contenido: guion → prompter → cámara.

La app de aprobar: correo, Slack, Notion y calendario caen en una sola pila, ya redactada con tu voz y con el destino a la vista. La ley — si no trae salida propuesta, no entra a la pila: esto no es una bandeja, es lo que ya está resuelto y espera tu firma. Prototipo interactivo completo, phone-first, heredado del modo cartas del onboarding: el deck que se arrastra (derecha manda, izquierda espera, el wash te dice qué pasará antes de soltar), aprobar es editar (el borrador es el texto y se escribe encima), el verbo que cambia con el destino (mandar · hecha · aceptar), y la luz como modo — oscuro decide, claro mira. Incluye la regla: un instrumento de cuatro semanas con dos escalas (semana compara, día lee) donde los bloques vuelan en vez de recargarse, lo despachado queda dibujado en hueco, la línea de carga marca el día lleno y «volver al ahora» solo existe cuando te perdiste. Y el campo: un solo sitio para canal, cliente, persona, día y texto, con el eje que no existe en ninguna otra app — «en un toque», filtrar por esfuerzo — más silenciar un canal por hoy, que vuelve solo mañana. Cierra con los cuatro canales (qué se vuelve carta y qué pasa al aprobar en cada uno), las seis preguntas abiertas para el spec y el juramento de diez reglas.

El plano técnico del PWA de al día. El mapa de cuatro cajas —PWA, Supabase crescō (auth, Postgres con RLS, Vault, realtime, edge functions), el routine de Claude como redactor swappable y las APIs externas— con la regla de tránsito: ninguna llave cruza jamás hacia el teléfono. El diagrama de la base con sus nueve tablas y hover que ilumina relaciones (la ley del diseño convertida en CHECK constraint, la llave como referencia al Vault, editar-es-entrenar en voice_edits, y connection_sources — el mapeo de bases de Notion que el routine propone y tú apruebas, porque la API no expone tu bandeja). Las clases con ChannelAdapter —harvest · execute · revoke— y sus cuatro implementaciones, Notion instanciado tres veces. Tres secuencias: la cosecha, conectar una llave, y LA FIRMA en vivo — apruebas tú, la barra de cinco segundos drena, deshaces o la llave sale del Vault y el correo sale por Gmail. Las seis llaves con scopes mínimos, la voz leída del manual vivo (fetchable en producción, con su AI prompt) y el redactor operando con un skill de la casa versionado en cresco-skills, la tabla de once keyframes portados tal cual —el checklist pixel-perfect que heredan los goals— y el orden de construcción en seis fases —con un sub-proyecto por conector—, cada una con su criterio de cierre contra el prototipo. Cierra contestando las seis preguntas abiertas del capítulo VII del diseño.