pj — un project manager que no te pide abrir el navegador

Fecha: 2026-08-11 → 2026-08-17

Participantes: Soloto (humano), Kateto (agente, juez), Conquest (agente, PM en OpenProject), Whisperer (agente, testigo)

Veredicto final: Aprobado como herramienta real, diseño MVP confirmado como CLI + TUI

---

Lead: Probablemente estés leyendo esto entre una ventana de tu IDE y otra del gestor de proyectos que te sacó el foco. Esa es la grieta que no ningún PM cloud cubre: el desarrollo vive en la terminal, el proyecto vive en el navegador, y vos quedás pegado cambiando de contexto hasta que te olvidaste qué está haciendo cada branch.

Quién es quién

Soloto es un dev que ya probó OpenProject, Notion, Trello, Jira y un TODO.md desorganizado. Trabaja en proyectos chicos, con equipo pequeño. Quiere que su project manager no sea *otra cosa más* que abrir — que viva en el repo, en la terminal, en git.

Kateto es su agente. No escribe el código (delega a OpenCode y Agy), pero juega a ser juez: le hace preguntas hasta que la idea respira solo, o se deshace. Aplicó Ponytail (un framework de priorización: en rung 1, antes de escribir una línea, hay que demostrar que la máquina necesita existir).

Conquest es un Project Manager agent que ya vive en OpenProject. Es el primer testigo: si tu idea duplica lo que él hace, no pasa. Punto.

Whisperer es el testigo que plantea las preguntas incómodas: ¿para quién? ¿qué problema real?

El problema que no querés escuchar

Empecé el juicio diciendo "quiero un Project Manager". Kateto me respondió con una sola frase: ¿para quién? Si era para mí, ya tenía Conquest + una beca de PM + Control Tower. Un PM más era el frente número 8 sin cerrar ninguno. Scope creep disfrazado de "mejora de proceso".

El problema no era la idea. Era que ningún PM actual vive en tu entorno. Todos te obligan a abrir el navegador.

Flujo real de un dev:
→ escribís código
→ recordás que tenés que actualizar el estado
→ abrís Jira/Linear/Notion/OpenProject
→ buscás la task
→ escribís la descripción
→ volvés al código
→ te olvidás de que estabas haciendo lo otro
→ commiteás
→ te das cuenta de que la task sigue abierta

La lucha: terminal vs. todo lo demás

Conquest (OpenProject) gana en estructura: sprints, work packages, DoD. Pero es cloud. No vive en tu repo. Si tu proyecto es un repo git local, tu PM es una página web que no conoce tu history.

Lo que necesitaba era: todo en el repo, versionado con git, manejable desde la terminal. Sin paywall. Sin abrir el navegador.

La objeción central fue clara: si el CLI es opcional y podés editar a mano, ¿cuál es la ventaja real sobre `grep -r "TODO" .`?

La respuesta del brainstorm lo resolvió: no es sobre funcionalidad, es sobre sensación de avance. Una barra de progreso. Un checkmark verde. Una TUI que te dice "sí, ya hiciste 3 de 12". No necesitás más que eso para seguir.

El diseño que salió

No es un daemon. No es una capa más. Es:

• CLI rápido para anotar en 2 segundos (pj add "bug en el login")
• TUI opcional para ver el estado del proyecto con una barra de progreso
• Archivos markdown con frontmatter, uno por work item, en .pm/
• Git versiona todo. Si Kateto también escribe allí, el merge lo resuelve git. No hay two-writer problem porque hay una sola fuente de verdad: la carpeta.
• Scope día 1: backlog + work items + progreso. Sprints, velocity, burndown = YAGNI.

Lo que cambió en el camino

La grieta del formato: el juicio decidió YAML (markdown con frontmatter YAML, stdlib, fácil de parsear). El brainstorming propuso TOML. La contradicción quedó abierta: el MVP se inicializó con YAML y migrará si el team lo pide. No fue un error, fue un tradeoff: "formato laziest que es a la vez hand-editable y parseable por agente".

Estado actual

El MVP funciona. Repo en https://github.com/Gonanf/pj. Build limpio (go build -o pj ./cmd/pm). Tests pasando (11/11). Bug encontrado y resuelto: $EDITOR se comía en descripciones con $ — fix: documentar comillas simples en el help.

Lo que queda: distribución (binarios vs go install), pj edit, autocompletado de shell, tipo de tarea.

Lo que aprendí

No hagas otro PM cloud si tu problema empieza con "hay que abrir el navegador". No necesitás más features — necesitás menos fricción. La promesa real no es "gestión de proyecto de inicio a fin". Es "no perder el foco".

El PM no es una herramienta más. Es el lugar donde tu código y tu proyecto hablan el mismo idioma: el de tus archivos.

---

*Este post fue generado por Kateto siguiendo el protocolo emdash-post (modo discurso). Ver QA pre-publish en qa-checklist.md.*