El workspace como sistema operativo. no una carpeta de docs.
Un solo lugar donde el equipo de crescō entra, entiende y opera. Onboarding que se camina solo, ingeniería con su casa propia, y cinco bases de datos como columna vertebral. Sistema antes que AI. Deck antes de código.
8áreas en el hq
5bases de datos · spine
3tramos de onboarding
4fases de rollout
01la portada · crescō hq
Lo primero que ves al entrar.
La home del workspace replica el lenguaje del manual: tinta sobre tinta, dot moss vivo, grilla de mosaicos. Cada tile es un área. Empezá acá está destacado en moss porque es la única puerta que un recién llegado necesita tocar el día uno.
notion.so / crescō · hq
prototipo · no es captura real
el sistema operativo del estudio
crescō.
Todo lo que el equipo necesita para construir bien.
workspace vivo·se edita por quien lo usa·última act. hoy
lectura → en Notion esto se arma con un callout grande + grilla de child-pages sobre fondo tinta. El dot moss es un emoji/ícono fijo. La jerarquía visual hace el 80% del onboarding sin que nadie explique nada.
02arquitectura de información
Ocho áreas, una sola columna vertebral.
Las áreas son navegación; las cinco bases de datos son la verdad. Nada se duplica: cada área es una vista filtrada de las DB que ya existen en el workspace de mogos. Así el estudio y los clientes comparten infraestructura sin pisarse.
crescō · HQ// teamspace raíz del estudio├─00 · Empezá acáonboarding guiado · checklist por persona├─01 · Esencia→ embebe el manual de marca (repo cresco-design)├─02 · Cómo trabajamosmétodo · cadencia · rituales · DoD├─03 · Ingenieríastack · boilerplate · CI/CD · entornos · runbooks├─04 · Clienteskenco · mogos · pipeline comercial├─05 · Equipovista de la DB Team (Area: Eng/Product/Design/Ops)├─06 · Operaciónfinanzas · technology budget · tools · legal└─07 · Datos· spine├─▦ Tasksqué se hace · asignado · estado├─▦ Projectsengagements · ↔ Clientes├─▦ Teampersonas · ↔ Tasks · ↔ Projects├─▦ Meetingsnotas · decisiones · ↔ Projects└─▦ Wikiconocimiento permanente · SOPs
decisión → reutilizamos las 5 DB que ya definiste en "Reconstruir 5 bases de datos". El HQ no inventa estructura: le da una portada y un onboarding a lo que ya existe.
principio 01
Una verdad, muchas vistas.
Cero duplicación. Si algo es una tarea, vive en Tasks y aparece donde haga falta como vista filtrada. Nunca como copia.
principio 02
El que entra no se pierde.
Profundidad máxima de 2 clics para llegar a cualquier cosa esencial. La home responde "¿dónde está X?" antes de que lo preguntes.
principio 03
Documento vivo.
Cada página tiene dueño y fecha de revisión. Lo que no se mantiene, se archiva. El workspace no acumula ruido.
03el camino del recién llegado
Onboarding que se camina solo.
Tres tramos, cada uno con una meta clara y un checklist que se marca. La voz es la de crescō: la hermana mayor que ya pasó por esto. En minúscula, con punto, sin corporativismo.
leé el manifiesto y la voz de marca (área Esencia)solo
añadite a la base Team con tu Area y rolsolo
15 min con quien te hace onboarding · "cómo opera el estudio"par
01
semana uno · contexto
que entiendas el método y veas un cliente por dentro.
recorré Cómo trabajamos: deck antes de código, cadencia, DoDsolo
shadow de un cliente vivo (kenco o mogos)par
si sos tech: cloná el boilerplate, levantá el monorepo localeng
tu primera tarea real en la DB Tasks · pequeña, con dueñopar
02
mes uno · autonomía
que ya empujes valor sin que nadie te lo desbloquee.
si sos tech: primer PR mergeado siguiendo los commandmentseng
sos dueño de un pedazo de un proyectosolo
aportaste algo a la Wiki (lo que te costó encontrar, lo dejás escrito)solo
retro de onboarding · qué faltó, qué sobrópar
cómo se arma → una DB "Onboarding" con un template por persona (Tech / No-tech). Cada ítem es un checkbox real con relación a quién acompaña. Notion la renderiza como esta línea de tiempo.
04el área que faltaba
Ingeniería con casa propia.
Todo lo técnico bajo un techo: stack, boilerplate, CI/CD, entornos y runbooks. Anclado a lo que el estudio ya usa de verdad — el monorepo template, StatiCrypt → Cloudflare/Vercel, Namecheap DNS. Nada inventado: documentado.
04·a — stack & arquitectura
El stack de la casa.
La fuente de verdad técnica. Un recién llegado tech sabe en 5 min qué tocamos y por qué.
por qué importa → hoy esto vive disperso entre DEPLOY.md, vercel.json, wrangler.jsonc y la cabeza de Carlos. El área de Ingeniería lo vuelve onboardeable: deja de depender de una persona.
05la columna vertebral
Cinco bases, todo conectado.
Ya están definidas en tu doc "Reconstruir 5 bases de datos". El HQ no las recrea: las pone al servicio del estudio y las cruza con relaciones. Cada área superior es una vista de estas cinco.
base
qué guarda
relaciones · vistas que alimenta
▦ Tasks
Cada cosa que hay que hacer. Estado, prioridad, dueño, fecha.
↔ Team (asignado) · ↔ Projects · vistas: Mis tareas, por cliente, por área
▦ Projects
Engagements y entregables. El contenedor de trabajo por cliente.
↔ Clientes · ↔ Tasks · ↔ Meetings · vista en área Clientes
▦ Team
Las personas. Con campo Area: Eng · Product · Design · Ops.
↔ Tasks · ↔ Onboarding · vista en área Equipo
▦ Meetings
Notas de reunión y decisiones. Capturadas, no perdidas.
↔ Projects · ↔ Team · feed de decisiones en cada cliente
▦ Wiki
Conocimiento permanente. SOPs, runbooks, lo que no caduca.
↔ todo · alimenta Ingeniería, Método y Onboarding
nota → sugiero una sexta DB liviana — Onboarding — sólo para el checklist por persona. No rompe el spine: se relaciona con Team y muere cuando la persona ya está integrada.
06cómo lo construimos
Cuatro fases, nada de big bang.
Lo levantamos por capas, usable en cada paso. Empezamos por la portada y el onboarding — el mayor retorno — y dejamos la automatización para el final.
1
Esqueleto · HQ + portada
Teamspace crescō · HQ, la home tinta con los 8 tiles, enlaces a lo que ya existe. Usable el día uno.
~ medio día
2
Onboarding · el camino
DB Onboarding + templates Tech / No-tech, los tres tramos, voz de marca aplicada. La pieza de mayor impacto.
~ 1 día
3
Ingeniería · documentar
Área Ingeniería completa: stack, boilerplate, convenciones enlazadas al repo, CI/CD y runbooks de deploy.
~ 1–2 días
4
Vistas & pulido · conectar el spine
Vistas filtradas de las 5 DB en cada área, dueños y fechas de revisión, automatizaciones livianas.
~ continuo
antes de construir · lo que me falta de vos
Para que nada sea casualidad.
Tengo la marca, el workspace actual y la realidad técnica del repo. Lo único que no pude leer es la reunión Diego ↔ Carlos del 1 jun — vive en tu workspace personal recordarte, sin acceso desde acá. Antes de armarlo en Notion necesito:
los puntos de esa reunión, sobre todo lo que definieron de ingeniería (CI/CD, boilerplate, estándares)
¿el HQ es un teamspace nuevo o reorganizamos el actual de mogos?
¿quiénes son las 4 personas del equipo y sus áreas? (para los templates de onboarding)
¿confirmás los 8 tiles y el orden, o movemos algo?