docs: restore and update tracking documents for upstream-reset state

https://claude.ai/code/session_01W9xh1kJCqtHqBgBAMQikon

Author: claude

docs/PENDIENTES_DE_EMPEZAR.md

@@ -0,0 +1,29 @@
+# Pendientes de empezar (sin comenzar)
+
+> Fecha: junio 2026. Cobertura global actual: **69,3 %** (sobre `main` = upstream).
+
+## Paquetes con menor cobertura (objetivos)
+
+| Paquete | Cobertura | Notas |
+|---|---:|---|
+| `internal/ghmcp` | **0,0 %** | Arranque del servidor, hosts GHES/GHEC, transporte HTTP. Mayor hueco e impacto. |
+| `cmd/mcpcurl` | ~55 % | **En progreso** (este trabajo). Resto sin cubrir: rutas con subproceso (`executeServerCommand`, `Run`). |
+| `internal/githubv4mock` | 18,1 % | Utilidad de test; cobertura indirecta. |
+| `pkg/http` | 37,4 % | Capa del servidor HTTP remoto. |
+| `pkg/http/transport` | 46,7 % | Transporte HTTP. |
+| `pkg/log` | 47,4 % | Logging E/S. |
+| `pkg/http/middleware` | 50,6 % | Middleware del servidor. |
+| `pkg/utils` | 54,0 % | Helpers de resultados. |
+
+## Tareas concretas sin empezar
+1. **`internal/ghmcp`**: tests de derivación de hosts GHES/GHEC, wrappers de
+   transporte/`RoundTrip`, middleware. Mayor impacto en el total.
+2. **`pkg/http` y submódulos** (`transport`, `middleware`, `oauth`): rutas del
+   servidor remoto.
+3. **`cmd/mcpcurl`** (rematar): cubrir `executeServerCommand` y el `Run` de los
+   comandos generados (requiere un binario/servidor de prueba por stdio).
+
+## Recomendación de orden
+Confirmar primero la estabilidad vs upstream (ver PENDIENTES_DE_RESOLVER). Si se
+mantiene: `internal/ghmcp` → `pkg/http*`. Re-medir la cobertura del paquete antes
+de cada tarea, porque el repo cambia con frecuencia.

docs/PENDIENTES_DE_RESOLVER.md

@@ -0,0 +1,18 @@
+# Pendientes de resolver (en curso / decisión pendiente)
+
+> Fecha: junio 2026.
+
+## 1. ¿Abrir PR con los tests de `cmd/mcpcurl`?
+- Estado: el fichero `cmd/mcpcurl/coverage_test.go` está hecho y verde en local,
+  commiteado en la rama. Falta decidir si se abre PR contra `main`.
+
+## 2. Estabilidad del repo frente al upstream — RIESGO
+- `main` ya se ha reseteado al upstream una vez, borrando trabajo previo.
+- Mientras no se aclare la política del fork (¿se sigue sincronizando con
+  `github/github-mcp-server`?), **cualquier test nuevo puede volver a perderse**.
+- Pendiente: confirmar con el responsable si el fork va a divergir del upstream
+  o seguir sincronizándose, para decidir cuánto esfuerzo invertir.
+
+## 3. Documentos de seguimiento
+- Recuperados en `docs/` y puestos al día (este conjunto). Pendiente: mantenerlos
+  vivos según avance el trabajo.

docs/TRABAJO_REALIZADO.md

@@ -0,0 +1,34 @@
+# Trabajo realizado
+
+> Proyecto: **github-mcp-server** (servidor MCP en Go). Fecha: junio 2026.
+> Rama de trabajo: `claude/test-coverage-analysis-s33ri0`.
+
+## Nota de contexto importante
+El `main` del fork se **sincronizó/reseteó con el upstream oficial
+`github/github-mcp-server`**. Eso **eliminó de `main`** todo el trabajo previo
+del fork (tests de `pkg/lockdown` del PR #5, documentos de estado, los arreglos
+de workflows, etc.). El historial actual de `main` es el del upstream. Por eso
+este documento se ha reescrito para reflejar la realidad actual.
+
+## Histórico (referencia)
+- Análisis inicial de cobertura del repo.
+- **PR #5** (fusionado en su momento): tests de `pkg/lockdown` → perdidos en el reset.
+- **PR #10** (cerrado sin fusionar): arreglo de CI mezclado con docs.
+- **PR #12** (cerrado): reintento de arreglo de CI; quedó obsoleto porque el
+  reset a upstream eliminó los workflows rotos (`python-package.yml`,
+  `go-build.yml`) que pretendía borrar.
+- Diagnósticos de CI hechos por el camino (colisión de símbolos por refactor
+  paralelo, crash de golangci-lint por Go 1.26 vs golangci 1.25, workflow de
+  Python sobre repo Go).
+
+## Trabajo vigente sobre el `main` nuevo (upstream)
+- **Re-medición de cobertura** desde cero: total **69,3 %**.
+- **Tests para `cmd/mcpcurl`**: subido de **8,9 % → ~55 %** añadiendo
+  `cmd/mcpcurl/coverage_test.go` (sin tocar el test existente). Cubre:
+  - `buildArgumentsMap` → 100 % (todos los tipos: string/number/integer/boolean/
+    array de strings/array de objetos vía `-json`, y error de JSON inválido).
+  - `printResponse` → 88,5 % (sin pretty, objeto, array/JSONL, vacío, JSON inválido).
+  - `buildJSONRPCRequest` → 75 %.
+  - `addCommandFromTool` → 63,5 % (registro de flags, flags requeridos, validación
+    de `enum` vía `PreRunE`).
+- Verificado en local: `gofmt`, `go vet ./...`, `go test ./...` → **todo verde**.