La ruta canónica es
/topics. /watchers sigue funcionando como alias obsoleto para CLIs antiguas y se elimina en una versión posterior.CRUD principal
La respuesta de lectura es el contexto canónico. Incluye un veredicto plano
trust (reviewed | proposed | draft) más classification.status y un bloque governance: la señal de confianza que consume un agente. Usa trust directamente como clave:
Búsqueda y emparejamiento
GET /workspaces/:slug/topics también acepta ?tags=a,b (separados por comas, semántica OR). Los nombres de tags se normalizan del lado del servidor (minúsculas, espacios→guiones).
Tags
El registro de tags del workspace: los tags como objetos de primera clase para poder crearlos por adelantado con una descripción antes de que algún topic los use. Adjuntar un tag no registrado mediante una escritura de topic lo registra automáticamente.Salud y grafo
Gobernanza
Un topic se convierte en Knowledge solo cuando un owner/admin lo fusiona. Consulta Gobernanza.approve / reject y el merge / reject de Edición sugerida requieren autoridad de owner/admin. Tienen éxito para un principal owner/admin en cualquier superficie (dashboard, key de CLI con dueño, o un token OAuth/MCP que el owner/admin autorizó), y la fusión se sella con approved_via (human o agent). Un principal sin rostro o que no es owner es rechazado.
Relaciones
Las respuestas de
POST /topics y PATCH /topics/:topic pueden incluir anchor_validation: conteos de coincidencias por patrón contra la rama por defecto del repo (ok / overbroad / zero, con muestras y advertencias). Solo informativo: nunca bloquea la escritura. Se omite cuando la escritura no lleva ningún patrón, o cuando no hay un repo vinculado. Cuando SÍ hay repo vinculado pero el deployment no tiene índice de archivos para él, el campo llega como { "skipped": "…" } nombrando la razón — para que un campo ausente nunca se lea como «tus globs se revisaron y están bien». POST …/relations es accesible para principales OAuth (MCP) con topics:write; eliminar relaciones sigue siendo solo para humanos.