gh-discussions

Plugin de composición para DeepSeek Harness (dsh) que expone GitHub Discussions como Tools nativas del modelo: gh_discussion_search, gh_discussion_create, gh_discussion_comment.

No reimplementa nada — es un envoltorio delgado sobre gh api graphql (GitHub Discussions no tiene subcomando propio en gh, solo GraphQL).

Requisito

gh CLI instalado y autenticado en la máquina (gh auth status). El plugin usa la sesión de gh ya logueada, no maneja credenciales propias.

Instalación

1. Dependencias locales:

   cd gh-discussions
   npm install
   

2. Montarlo en el perfil de dsh (~/.dsh/profiles/<perfil>/cordis.patch.yml):

   - insert:
       - id: gh-discussions
         name: 'file:///C:/ruta/a/gh-discussions/host.js'
   

3. Reiniciar el proceso de dsh para que cargue el plugin.

Tools

gh_discussion_search

Búsqueda de solo lectura. Sin aprobación.

Parámetro	Tipo	Requerido	Descripción
owner	string	sí	Owner/org del repo.
repo	string	sí	Nombre del repo.
query	string	sí	Términos de búsqueda (sintaxis de búsqueda de GitHub).
first	integer	no	Máximo de resultados. Default 10.

gh_discussion_create

Crea una discussion nueva. Publica públicamente — pide aprobación real al usuario antes de ejecutar.

Parámetro	Tipo	Requerido	Descripción
owner	string	sí
repo	string	sí
category	string	sí	Nombre de categoría (case-insensitive), ej. "General".
title	string	sí
body	string	sí	Markdown.
justification	string	sí	Motivo, se muestra al usuario en el prompt de aprobación.

gh_discussion_comment

Comenta una discussion existente. Publica públicamente — pide aprobación real al usuario antes de ejecutar.

Parámetro	Tipo	Requerido	Descripción
owner	string	sí
repo	string	sí
discussionNumber	integer	sí
body	string	sí	Markdown.
justification	string	sí	Motivo, se muestra al usuario en el prompt de aprobación.

Decisiones de diseño (por qué está armado así)

• create/comment pasan por ctx.approval.request() antes de ejecutar cualquier mutación. Publicar en GitHub es una acción pública e irreversible (borrar una discussion no la des-publica del historial/notificaciones); a diferencia de kdd-gates, acá no hay una escalada de sandbox de por medio — es el seam genérico de aprobación (@deepseek-ai/dsh-user-approval), el mismo que usa dsh-tool-pwsh para sus reintentos escalados. Sin un answerer configurado (ej. corriendo en el perfil headless), la petición falla cerrada (unavailable) — nunca publica por default. search es de solo lectura y no pasa por esta gate.
• gh api graphql vía ctx.subprocess.spawn directo, no ctx.shell. A diferencia de preflight.py en kdd-gates, gh no lanza sus propios subprocesos anidados — el problema que forzó a usar ctx.shell ahí (ver discussion #4796) no aplica acá.
• Los argumentos van por argv (spawn sin shell), nunca interpolados en un string de comando. Evita inyección de shell aunque title/body traigan comillas, backticks o saltos de línea.
• Sin dependencia de @deepseek-ai/dsh-sandbox. El paquete de sandbox es específico para escalar el modo de sandbox (workspace-write → danger-full-access); acá se usa ctx.get('approval') directo, que es el seam genérico — no hace falta esa dependencia.

Estado verificado

• gh_discussion_search probado contra deepseek-ai/deepseek-harness real: devolvió correctamente #4797 y #4799.
• gh_discussion_create probado en el perfil headless (sin answerer): falló cerrado con reason: unavailable, no publicó nada — confirma que la gate de aprobación no tiene bypass.