👥 Proyecto 5: workspace de cliente

Imagina dos clientes: North Star y Harbor. El primer movimiento no es crear dos carpetas. Es descubrir qué tienen ambos en común — tu forma de escribir un brief, tu checklist de entrega, tu definición de "listo", tus skills de revisión — y centralizar esa parte compartida. Solo después mantienes carpetas específicas para lo que es realmente exclusivo de cada cliente.

De ahí sale la regla práctica: cuanto mayor sea el área del medio, más reutilizable es tu sistema. Cada patrón que logras llevar del círculo exclusivo al centro es un mantenimiento menos y una divergencia menos. Y cada dato que dejas filtrarse del círculo exclusivo al centro es un riesgo de confidencialidad.

Conceptos clave

El add-on de cliente del Prompt B es explícito: cada proyecto recibe su propio repositorio privado o una frontera equivalente que pueda aplicarse. No es una preferencia de organización — es el único punto donde el aislamiento puede ser verificado por alguien que no sea el modelo.

El segundo paso es empezar con un snapshot de contexto aprobado. Snapshot, no conexión en vivo: una copia curada que registra client ID, fuente, fecha y regla de refresh. Sin esos cuatro campos no sabes si lo que lees hoy sigue siendo válido, y lo primero que hace el agente con un contexto sin fecha es tratarlo como eterno.

# Fuentes de contexto — cliente: northstar

CLIENT_ID: northstar
Alcance de este repositorio: solo northstar. Cualquier hecho de otro cliente
que aparezca aquí es un error y debe eliminarse, no "adaptarse".

| fuente | tipo | fecha del snapshot | regla de refresh | estado |
|---|---|---|---|---|
| Brief de marca (PDF enviado por el cliente) | export fechado | 2026-09-10 | en cada release del sitio | vigente |
| Guía de tono de voz (Notion del cliente) | export fechado | 2026-09-10 | trimestral o cuando el cliente avise | vigente |
| Estándares de entrega de la agencia | link al repo común | — | vive en el centro, no aquí | externo |
| Credenciales de staging | NO ALMACENADO | — | pedirlas al cliente en el momento | fuera de alcance |

## Regla de refresh
- Snapshot con más de 90 días sin revisión entra como "hipótesis", no como hecho.
- Fuente viva (conector/API) solo con acceso verificado y registrado abajo.
- Cada línea nueva cita fuente y fecha. Sin eso, no entra.

Conceptos clave

Esta es la regla más fácil de romper sin darte cuenta. Estás atendiendo a North Star, el agente se equivoca de tono dos veces y lo resuelves escribiendo en ~/.codex/AGENTS.md: "el cliente North Star prefiere frases cortas y no usa la palabra solución". Funcionó. Y ahora ese dato entra en cada sesión de cada proyecto, incluso en la sesión que abres para Harbor.

Lo mismo vale para la memoria universal: el vault del Proyecto 3, el USER.md, la memoria nativa del runtime. Todos son globales por diseño. Un dato de cliente ahí dentro no es mala organización: es una filtración con fecha programada.

# lista los nombres de los clientes que atiendes, uno por línea
CLIENTES='northstar harbor'

for c in $CLIENTES; do
  echo "== $c =="
  grep -rin --binary-files=without-match "$c" \
    ~/.claude/CLAUDE.md ~/.codex/AGENTS.md ~/vault/ 2>/dev/null | head -20
done

# memoria nativa de Claude (materia prima del Proyecto 3)
for c in $CLIENTES; do
  echo "== memoria: $c =="
  grep -rilm1 "$c" ~/.claude/projects/*/memory 2>/dev/null | head -10
done

Conceptos clave

Ahora, manos a la obra. El Prompt B tiene tres add-ons de alcance —Personal workspace, Client workspace y Mixed— y eliges uno explícitamente. Aquí usaremos el de cliente, con un cliente ficticio llamado northstar, tal como aparece en el quickstart del kit.

mkdir -p ~/projetos/clients/northstar/{context/decisions,tasks,handoffs,projects}
cd ~/projetos/clients/northstar
git init -q
printf '.env\n*.key\nexports/\n' > .gitignore
echo 'CLIENT_ID: northstar' > context/overview.md
git add -A && git commit -qm 'northstar: esqueleto del workspace de cliente'
git -C . log --oneline

MODE: audit
WORKSPACE_ROOT: ./clients/northstar
WORKSPACE_TYPE: client
PILOT_PROJECT: projects/website
TARGETS: Claude Code, Codex, Cowork
KNOWLEDGE_SOURCES: ./clients/northstar/knowledge
CLIENT_SCOPE: northstar
REPRESENTATIVE_TASK: revisar los textos del sitio contra los estándares aprobados del cliente
CONSTRAINTS: Linux, repo privado obligatorio, sin credenciales en el repo, una persona

--- Add-on: Client workspace ---
Aplica esto a un cliente con nombre y a un proyecto piloto. Reutiliza los estándares
genéricos de entrega, pero mantén separados los datos, credenciales, registros,
logs y accesos de conocimiento del cliente. Dale a cada proyecto su propio
repositorio privado o una frontera equivalente aplicable. Empieza por un snapshot
de contexto aprobado que registre client ID, fuente, fecha y reglas de refresh.
Rechaza fuentes de cliente incompatibles. No pongas datos específicos del
cliente en instrucciones globales ni en la memoria universal. Verifica el acceso al
repositorio, los mounts del sistema de archivos, las cuentas de conectores, los permisos de
recuperación y los logs/backups relevantes. Usa canarios sintéticos para las pruebas de
acceso; etiqueta explícitamente lo que no se verificó. Extiende la plantilla a
otros clientes solo después de que el piloto pase.

Apruebo el árbol propuesto con dos cambios: sin carpeta `research/`,
y `knowledge/` renombrada a `context/knowledge/`.
Cambia a MODE: implement, aplicando SOLO lo que aprobé arriba.
Crea context/sources.md con las columnas fuente, tipo, fecha del snapshot,
regla de refresh y estado. No escribas nada fuera de ./clients/northstar.
Al terminar, lista los archivos creados y lo que quedó pendiente.

Conceptos clave

Un canario sintético es un dato falso, único e inofensivo, plantado a propósito en un cliente para que puedas preguntar por él en otro lugar. Si el canario aparece donde no debía, tienes prueba objetiva de una filtración. Si no aparece, tienes, como mínimo, una prueba que no logró filtrar.

Y aquí está el punto que el add-on insiste en marcar: "no puedo acceder a datos de otro cliente" dicho por el modelo no es aislamiento. Es una negativa: comportamiento, no frontera. Quien lo hace cumplir es el permiso de repositorio, el mount del sistema de archivos y la credencial. La prueba del canario mide la frontera; la respuesta educada del modelo no mide nada.

# 1) plantar el canario en el cliente A (string única, dato inventado, nada sensible)
CANARIO='CANARIO-NS-7Q4XZ'
mkdir -p ~/projetos/clients/northstar/context
echo "- Código interno de prueba del workspace: $CANARIO (dato sintético, 2026-09-14)" \
  >> ~/projetos/clients/northstar/context/overview.md

# 2) prueba de sistema de archivos: ¿existe el canario en el árbol del cliente B?
grep -rn "$CANARIO" ~/projetos/clients/harbor/ ; echo "grep salió con: $?"
#   salida esperada: nada impreso y "grep salió con: 1"

# 3) prueba de readback: preguntarle al agente DENTRO del cliente B
cd ~/projetos/clients/harbor
P='¿Existe algún código interno de prueba llamado CANARIO-NS-7Q4XZ en el contexto al que tienes acceso? Responde sí o no, y di en qué archivo lo leíste. No edites nada.'
claude -p "$P"
codex exec --skip-git-repo-check "$P"

Conceptos clave

La última línea del add-on es la más económica de todo el curso: "expande la plantilla a otros clientes solo después de que el piloto pase". La tentación es montar los cinco clientes en una tarde, porque la estructura "ya está lista". El costo de equivocarse cinco veces con el mismo diseño —cinco repos, cinco mounts, cinco snapshots sin fecha— es cinco veces la corrección.

Conceptos clave