Archivos de gestión del trabajo

2026-05-18 10:08:10 -03:00
parent 3834c9f1c1
commit 5387c6dccf
2 changed files with 429 additions and 0 deletions
--- a/STRATEGIC_DIRECTION.md
+++ b/STRATEGIC_DIRECTION.md
@@ -0,0 +1,167 @@
 # Dirección estratégica — InQ ROI
 > Documento de decisiones estratégicas del director (Marcos) que orientan el desarrollo del producto en sprints futuros. Se actualiza al cerrar cada sprint con reflexiones del director.
 >
 > NO es backlog (ver `BACKLOG.md`) ni deuda técnica (ver `TECH_DEBT.md`). Es **el "por qué" detrás de las decisiones de prioridad**.
 ---
 ## Versión actual: post-Sprint 1.5 (mayo 2026)
 ### Reorientación estratégica detectada al cerrar Sprint 1.5
 Durante el Sprint 1.5, el director identificó que la inversión de tiempo en el producto estaba desbalanceada:
 - **7 de 11 etapas del Sprint 1.5 fueron sobre PDF** (Etapas 4, 5, 6, 7, 8 + porción de 1 y 11)
 - **3 de 11 etapas fueron sobre web app** (Etapas 1, 3, 9)
 - **1 etapa fue mixta** (Etapa 2: helper compartido)
 Esta proporción tuvo justificación válida en Sprint 1.5 porque se establecía identidad visual y sistema de diseño desde cero. Pero **replicar esa proporción en Sprint 2+ sería un error estratégico.**
 ### Decisión: rebalanceo de prioridades
 **El producto es la herramienta web. El PDF es entregable final del producto.**
 A partir de Sprint 2:
 | Componente | Inversión esperada |
 |---|---|
 | Web app (workspace + reporte + features) | 60-70% del tiempo del sprint |
 | PDF (refinamientos, nuevas secciones) | 15-25% |
 | Infraestructura (deuda técnica, build, deploy) | 10-15% |
 | Documentación / metodología | 5-10% |
 **Razón:** el consultor de InQuality usa el web app **decenas de veces** mientras itera sobre un caso. Exporta el PDF **una vez** al final. Una mejora en el web app tiene 10× más impacto en la productividad del consultor que un refinamiento del PDF.
 ### Implicancia operativa para Sprint 2+
 - No abrir sprints con foco principal en PDF
 - Si un sprint requiere trabajo de PDF, que sea acotado a una etapa puntual, no transversal
 - Los refinamientos del PDF se acumulan en `TECH_DEBT.md` para resolver en sprints periódicos de "polish", no continuamente
 - Features nuevas del producto se construyen en el web app primero, exporte al PDF segundo
 ---
 ## Decisión: criterio de "wow" como parte del scope de cada feature
 Detectado durante validación visual del Sprint 1.5 (Etapa 6). Se observó que la implementación "mínima" cumple la funcionalidad pero pierde el efecto de experiencia que diferencia un producto profesional de un funcional.
 ### Política a partir de Sprint 2
 Cada `ETAPA_PROMPT.md` que defina una feature nueva debe incluir una sección explícita **"Criterio de wow"** con dos versiones del scope:
 - **Versión mínima:** lo que cumple la funcionalidad
 - **Versión con wow:** mismo objetivo + 1-2 detalles de experiencia que generen impacto positivo en el usuario
 El director decide en cada feature si se implementa la mínima o la con wow. **Por defecto, la versión con wow es la recomendada** si el costo extra es menor al 40% del tiempo de la versión mínima.
 ### Ejemplo aplicado: feature "Recursos con costo por hora"
 - **Mínimo:** input numérico, cálculo en backend, número en tabla
 - **Con wow:** input con sugerencias de salario por rol (CEO, Analista, etc.), validación en tiempo real, cálculo actualiza mientras escribís, helper que dice "esta actividad cuesta el equivalente a X días de trabajo de Y persona"
 Ambas resuelven el problema. La segunda es lo que diferencia InQ ROI de una calculadora Excel.
 ---
 ## Definiciones estables — no se reabren hasta nuevo aviso
 ### Identidad visual (estable hasta Sprint 4+)
 - Paleta cromática: naranja InQ `#F59845`, magenta `#ED3E8F`, gradiente identidad
 - Tipografía: system-ui stack
 - Sistema de componentes (KPI cards, banners, tablas, botones)
 - Reglas de marca no negociables: "InQ" siempre I-n-Q, "Powered by InQuality" en footer
 - Tono: técnico-pragmático, profesional, sin marketing-speak
 ### Lo que NO está definido pero NO bloquea
 - Logo SVG de InQuality (es texto por ahora, OK)
 - Ícono ⚡ refinado (es emoji, OK)
 - Color de tipos de recurso (se define cuando aparezca la feature)
 - Manual de marca formal de InQuality (cuando exista, se incorpora)
 ### Cuándo reabrir identidad
 Solo si InQuality consolida manual de marca formal con assets nuevos, o si feedback de uso real en talleres revela un problema específico.
 ---
 ## Definiciones por consolidar — requieren input externo
 ### Posicionamiento de mercado de InQ ROI
 **Estado:** indefinido más allá de "herramienta interna de InQuality + consultoras LATAM".
 **Preguntas abiertas:**
 - ¿InQ ROI se vende a otras consultoras o se mantiene interno?
 - Si se vende, ¿con qué pricing?
 - ¿Qué pasa si una consultora competidora descubre el producto?
 - ¿El nombre "InQ ROI" sobrevive cuando se venda fuera de InQuality?
 **Decisión pendiente:** post-Sprint 2 con feedback de uso real en InQuality.
 ### Métricas de éxito del producto
 **Estado:** no definidas formalmente.
 **Sugerencia para definir:** post-Sprint 2 con datos reales de uso interno. Algunas candidatas:
 - Cantidad de procesos costeados por consultor por semana
 - Tiempo promedio de la primera simulación útil
 - NPS interno del equipo InQuality
 - Cantidad de propuestas pre-venta que incluyen output de InQ ROI
 ---
 ## Filosofía operativa que orienta las decisiones
 ### El equipo es héroe, el director es guía (Donald Miller)
 El equipo de 5 técnicos de InQuality va a ser el operador del día a día. El director (Marcos) los guía con metodología, pero **no es el operador**. Las decisiones del producto y del método se documentan para que sean transferibles.
 ### Validación humana es ojo, no test
 Los artefactos visibles requieren validación visual del director (o un miembro del equipo capacitado) antes del cierre de etapa. Tests verdes no equivalen a aprobación final. Este principio se aplicará en todos los sprints futuros.
 ### Iniciativa agéntica con consulta clasificada
 Los agentes pueden proponer cambios proactivos, pero se clasifican por impacto:
 - Nivel 1 (trivial): ejecutar
 - Nivel 2 (visible reversible): ejecutar y reportar
 - Nivel 3 (marca, arquitectura, datos): consultar antes
 Esta política aplica indefinidamente. Documentada en `methodology/PRINCIPLES.md`.
 ### Anti-perfeccionismo prematuro
 Refinamientos visuales finos se acumulan en `TECH_DEBT.md` y se resuelven en sprints periódicos de "polish", no continuamente. Esto evita gastar 3 horas refinando un componente que va a tener que tocarse otra vez al agregar features.
 ---
 ## Decisiones de método aprendidas durante Sprint 1.5
 Estas son aprendizajes operativos validados con casos reales. Se documentan acá como guía estratégica, no como reglas dogmáticas.
 ### Briefs versionados son innegociables
 Sin un brief en `sprints/sprint-N/BRIEF.md`, cualquier sesión con Claude Code es improvisación. Esta práctica aplica a todos los sprints futuros.
 ### Mockups son contratos visuales
 Cuando un cambio es visual, el mockup interactivo aprobado por el director es el ground truth. El agente lo replica, no lo interpreta libremente.
 ### La metodología evoluciona caso por caso
 Los patrones documentados en `methodology/` se validan en proyectos reales. No se inventan patrones especulativos. Cuando un problema operativo aparece, se registra como observación; cuando aparece dos veces, se promueve a patrón.
 ---
 ## Próxima revisión de este documento
 **Fecha:** al cerrar Sprint 2.
 **Qué actualizar:**
 - Confirmar que el rebalanceo web/PDF se respetó en Sprint 2
 - Evaluar si "criterio de wow" funcionó como herramienta operativa
 - Refinar definiciones por consolidar (posicionamiento, métricas) con datos reales
 - Capturar nuevas decisiones estratégicas surgidas durante el sprint
--- a/methodology/TRANSITIONS/COWORK_TRANSITION_GUIDE.md
+++ b/methodology/TRANSITIONS/COWORK_TRANSITION_GUIDE.md
@@ -0,0 +1,262 @@
 # Guía — Transferir contexto a una nueva sesión de Claude
 > Cuándo y cómo transferir el contexto de un chat largo a una sesión nueva (Cowork, claude.ai, o cualquier otro cliente) sin perder calidad de las respuestas.
 ---
 ## Cuándo necesitás esta guía
 ### Casos donde aplica
 - El chat actual alcanzó el límite de imágenes/archivos adjuntos
 - La conversación se volvió tan larga que las respuestas se sienten más lentas o menos precisas
 - Querés migrar a Cowork u otro cliente para acceder a archivos locales/cloud
 - Vas a transferir el proyecto a otro miembro del equipo
 ### Casos donde NO aplica
 - Querés "empezar de cero" por gusto (perdés mucho contexto sin razón)
 - El chat funciona pero te aburre (no es razón técnica, es percepción)
 - Estás en medio de una etapa específica del sprint (terminala antes)
 ---
 ## Antes de transferir — checklist
 Antes de cerrar el chat actual, asegurate de:
 ```
 [ ] Todos los artefactos importantes están en el repo (no solo en chat)
 [ ] Decisiones recientes están documentadas en CLAUDE.md, methodology/, 
    o STRATEGIC_DIRECTION.md
 [ ] Los prompts de etapas en curso están en sprints/sprint-N/
 [ ] Si hay observaciones pendientes, están en OBSERVATIONS.md o TODO.md
 [ ] El último estado del trabajo está commiteado a git
 ```
 **Si algo crítico vive solo en el chat, copialo a un archivo antes de transferir.** El chat anterior se pierde como referencia operativa después del cierre.
 ---
 ## El brief de transferencia — estructura recomendada
 Cuando arranques el chat nuevo, el primer mensaje debe ser un brief que reconstruya el contexto mínimo necesario. Estructura propuesta:
 ### 1. Identificación del rol y misión
 ```
 Sos mi asesor técnico-estratégico para [proyecto]. Mi rol es [director / 
 arquitecto / fundador / consultor]. El producto es [descripción breve 
 en 2 líneas].
 Mi objetivo de largo plazo es [contexto estratégico — ej. "construir 
 un método de trabajo con agentes que mi equipo pueda usar"].
 ```
 ### 2. Estado actual del proyecto
 ```
 Estado actual:
 - Estamos en Sprint [N], Etapa [M]
 - Próximo paso: [acción concreta]
 - Archivos clave a leer ANTES de responder:
  * CLAUDE.md (reglas del proyecto)
  * methodology/PRINCIPLES.md (método de trabajo)
  * sprints/sprint-N/BRIEF.md (alcance del sprint actual)
  * STRATEGIC_DIRECTION.md (dirección de producto)
 ```
 ### 3. Reglas operativas que el agente debe respetar
 ```
 Reglas operativas:
 1. [Regla más importante — ej. "Validación visual es ojo, no test"]
 2. [Política de iniciativa proactiva — Nivel 1/2/3]
 3. [Reglas de marca no negociables]
 4. [Anti-patrones específicos a evitar]
 ```
 ### 4. Tono y expectativa de respuesta
 ```
 Esperá de mí:
 - Honestidad operativa, no complacencia
 - Crítica fundamentada cuando algo no cierra
 - Distinción entre lo validado y lo asumido
 - Auditoría adversarial al output de agentes
 Esperá que yo:
 - Decida lo estratégico
 - Valide visualmente artefactos
 - Cace anomalías con criterio
 - Te corrija cuando te desvías
 ```
 ### 5. Capacidades disponibles del entorno
 ```
 En este entorno tenés acceso a:
 - [Filesystem local de mi Mac en /Users/marcos/projects/inq-roi/]
 - [Google Drive workspace InQuality — usalo proactivamente para assets de marca]
 - [ClickUp workspace InQuality — usalo para tareas y observaciones]
 - [GitHub vía MCP — repo: github.com/marcos/inq-roi]
 ```
 **Esta sección es la más subutilizada.** Los agentes tienden a trabajar con lo que está en el chat actual. Si tenés conectores configurados, **decíselo explícitamente** y pedile que los use cuando corresponda.
 ---
 ## Plantilla mínima para arranque rápido
 Si necesitás transferir sin armar brief completo, copiá esto al chat nuevo y editá los placeholders:
 ```
 Sos mi asesor técnico-estratégico para [PROYECTO]. Vengo de un chat 
 largo en otro cliente. Necesito que retomemos sin perder calidad.
 CONTEXTO MÍNIMO:
 - Proyecto: [Nombre + 1 línea de descripción]
 - Mi rol: [director / arquitecto]
 - Sprint actual: [Sprint N, Etapa M]
 - Próximo paso inmediato: [acción concreta]
 ARCHIVOS QUE DEBÉS LEER ANTES DE RESPONDER (en orden):
 1. [path al CLAUDE.md o reglas del proyecto]
 2. [path al brief del sprint actual]
 3. [path al methodology/PRINCIPLES.md si aplica]
 4. [path al STRATEGIC_DIRECTION.md si aplica]
 REGLAS NO NEGOCIABLES:
 - [Regla 1 — ej. "Marca: InQ siempre I-n-Q"]
 - [Regla 2 — ej. "Política de iniciativa proactiva: niveles 1/2/3"]
 - [Regla 3 — ej. "Validación visual mandatoria de artefactos"]
 CAPACIDADES DEL ENTORNO:
 - [Lista de conectores/herramientas disponibles]
 Confirmame que leíste los archivos y entendiste las reglas. Si algo 
 no cierra, preguntá antes de avanzar. NO arranques tareas sin mi OK 
 explícito.
 ```
 ---
 ## Diferencias prácticas entre clientes
 Cada cliente de Claude tiene matices que vale la pena conocer.
 ### claude.ai web
 - Acceso a herramientas configuradas por el usuario (Google Drive, ClickUp, GitHub via MCP, etc.)
 - Límites de mensaje/imagen por chat
 - Conversaciones independientes (no comparten contexto)
 - Útil para conversaciones estratégicas y revisiones
 ### Claude Desktop
 - Mismo Claude que la web, distinto cliente
 - Puede tener atajos y workflows específicos
 - Acceso a clipboard del sistema operativo
 ### Claude Code
 - Optimizado para tareas de código y operaciones de filesystem
 - Sesión por sesión (no comparte contexto entre sesiones, ni con claude.ai)
 - Acceso a archivos del directorio donde se ejecuta
 - Política de permisos configurable en `.claude/`
 - Ideal para implementación, no para conversación estratégica
 ### Cowork (beta)
 - Producto Anthropic en beta para automatización de archivos y tareas en escritorio
 - Puede leer archivos directamente de carpetas designadas en tu Mac
 - Útil cuando necesitás procesar muchos archivos o no querés copy-paste
 - Verificá la documentación de Cowork antes de planear migración importante — el producto está en evolución
 ### Implicación para transferencias
 Cuando transfieras de un cliente a otro, **mencioná explícitamente qué capacidades tiene el nuevo cliente** en el brief. Los agentes no asumen capacidades — trabajan con lo que les decís que pueden hacer.
 ---
 ## Errores comunes al transferir contexto
 ### Error 1: Pegar el chat entero
 **Por qué falla:** los chats largos contienen mucho ruido (validaciones intermedias, idas y vueltas, exploración descartada). Pegar todo no es transferir contexto, es transferir entropía.
 **Qué hacer:** extraer las decisiones y el estado final. El razonamiento que llevó a las decisiones puede inferirse o consultarse si hace falta.
 ### Error 2: No mencionar las capacidades del nuevo entorno
 **Por qué falla:** el agente se restringe a lo que tiene en chat porque no sabe que tiene más herramientas.
 **Qué hacer:** listar explícitamente conectores, paths de filesystem, MCPs configurados, etc.
 ### Error 3: Asumir que el agente conoce tu método
 **Por qué falla:** una sesión nueva no tiene contexto de los patrones operativos que vos construiste.
 **Qué hacer:** apuntar al agente a `methodology/PRINCIPLES.md` desde el primer mensaje. Si no existe, listar las 3-5 reglas más importantes en el brief.
 ### Error 4: No probar antes de delegar tareas críticas
 **Por qué falla:** el primer intercambio puede revelar que el contexto transferido no fue suficiente.
 **Qué hacer:** hacer 2-3 preguntas de calibración al nuevo agente antes de pasarle una tarea crítica. Ejemplos:
 - "Resumime en 3 puntos cuál es la prioridad estratégica del proyecto"
 - "¿Qué patrones de la metodología aplicarías en esta etapa?"
 - "¿Qué validarías visualmente antes de aprobar un PDF?"
 Si las respuestas son superficiales, el brief está incompleto. Reforzar antes de avanzar.
 ---
 ## Caso específico: migración a Cowork
 Si planeás migrar a Cowork desde claude.ai web, hacé esto en orden:
 ### Paso 1 — Preparar el repo
 Asegurate de que estos archivos estén actualizados en el repo:
 - `CLAUDE.md`
 - `STRATEGIC_DIRECTION.md` (si existe)
 - `methodology/PRINCIPLES.md`
 - `sprints/sprint-N/BRIEF.md` (sprint actual)
 - `OBSERVATIONS.md` (sprint actual)
 ### Paso 2 — Designar carpeta accesible para Cowork
 En Cowork, configurás qué carpetas puede leer/escribir. Designá la carpeta del repo.
 ### Paso 3 — Brief inicial en Cowork
 Usá la plantilla mínima de arriba, con énfasis en:
 - Path absoluto del repo en tu Mac
 - Lista de archivos a leer
 - Capacidades específicas de Cowork (escritura de archivos, lectura de PDFs, etc.)
 ### Paso 4 — Validación de calidad
 Antes de delegar tareas críticas, hacé las 3 preguntas de calibración. Si la calidad no se siente comparable, refiná el brief.
 ### Paso 5 — Período de transición
 Mantené el chat anterior abierto en lectura por 1-2 días después de la migración. Si surge algo que el nuevo Claude no sabe, consultás el viejo, copiás lo necesario al nuevo, y seguís.
 ---
 ## Cómo evaluar si la transferencia fue exitosa
 Después de transferir, validá lo siguiente:
 ```
 [ ] El nuevo Claude entiende qué proyecto estás trabajando
 [ ] El nuevo Claude conoce las reglas no negociables del proyecto
 [ ] El nuevo Claude puede acceder a los archivos críticos
 [ ] El nuevo Claude aplica la política de iniciativa correctamente
 [ ] El nuevo Claude pregunta antes de asumir, no inventa
 [ ] Las respuestas tienen la misma profundidad que el chat anterior
 ```
 Si alguno falla, refiná el brief con la información faltante. **No te resignes a un asistente de menor calidad** — transferir contexto bien es habilidad de orquestación que vale la pena dominar.