danepps/habilidades-de-investigación-jurídica

Construir Biblioteca

Poblar una colección de Zotero con fuentes para un proyecto. Defensa de dos capas contra fuentes fabricadas: (1) verificar cada candidato contra una fuente real antes de añadirlo; (2) después de añadirlo, ejecutar el comprobador determinista incluido — ningún elemento sale sin verificar. Todas las reglas de autoridad global (nunca inventar una cita; marcar incertidumbre) se aplican durante todo el proceso.

0. Paso cero — lee toda la biblioteca antes de hacer cualquier otra cosa

Antes de definir el alcance, antes de buscar, antes de proponer un solo candidato, vuelca la biblioteca objetivo y léela completa:

python3 ${CLAUDE_PLUGIN_ROOT}/skills/build-library/library_inventory.py --group <ID>   # o --user
python3 ${CLAUDE_PLUGIN_ROOT}/skills/build-library/library_inventory.py --group <ID> --grep <términos>

Una línea por elemento de nivel superior: año, PDF-o-no, autores, título, publicación, clave del elemento. Una biblioteca de 100 elementos ocupa menos de 3k tokens. No hay excusa presupuestaria para saltarse esto ni sustituto para ello. Para una biblioteca grande (miles de elementos), guarda el volcado completo en un archivo y lee los fragmentos relevantes de --grep más la forma general — pero el coordinador sigue siendo responsable de la comprobación, y un fragmento que nunca fue buscado con grep no es prueba de ausencia.

Este es el paso cero, y no parte de la pantalla de desduplicación, porque conocer la biblioteca cambia lo que buscas. Una ejecución que lo omita propondrá cosas que el usuario ya posee, las describirá como "recién identificadas" y hará afirmaciones falsas sobre lagunas en la colección.

Cuatro reglas estrictas, cada una de un fallo real (2026-08-01, en una biblioteca de grupo de 105 elementos):

1. Nunca delegues el inventario o la comprobación de desduplicación a un subagente. Un subagente de investigación informó que el grupo tenía "solo los 13 elementos listados más un puñado de trabajos no relacionados". Tenía 105. El coordinador lo creyó y creó tres duplicados. Los subagentes son adecuados para encontrar candidatos; el coordinador es responsable de conocer la biblioteca.
2. Trata un hallazgo negativo de un subagente como no verificado. "Lo comprobé y no está ahí" es exactamente la afirmación que los subagentes se equivocan, porque la ausencia no es falseable desde dentro de una búsqueda estrecha. Vuelve a comprobar cualquier afirmación de "no está en la biblioteca" contra tu propio inventario.
3. Cada adición pasa por la comprobación, incluidas las tardías. Dos de los tres duplicados se añadieron al final de la sesión, a partir de notas al pie de un artículo que acababa de leerse — fuera del flujo principal, por lo que se saltaron la pantalla por completo. Ningún candidato es demasiado pequeño o demasiado tarde para comprobarlo; haz grep del inventario que ya tienes.
4. Pasa el inventario hacia abajo. Cualquier subagente al que se le pida encontrar fuentes recibe la lista real (o un fragmento filtrado) pegada en su prompt — nunca una instrucción de ir a comprobarlo por sí mismo.

La biblioteca también es evidencia. Cuando la tarea es "¿qué falta?", lo que el usuario ya posee te dice lo que le importa y a menudo reformula la respuesta. En la ejecución que motivó esta regla, la biblioteca del usuario resultó tener una estantería profunda de estudios sobre derecho penal exactamente sobre los temas que el memorando acababa de describir como no abordados — lo que cambió el hallazgo de "nadie ha escrito sobre esto" a "estas dos literaturas no se citan entre sí". Lee el inventario por lo que dice sobre el proyecto, no solo para la coincidencia de duplicados.

1. Fontanería de Zotero

Las herramientas MCP zotero / zotero-group son de solo lectura (buenas para comprobaciones de duplicados y búsqueda). Todas las escrituras se realizan a través de la API web de Zotero v3 con la clave de la entrada zotero en ~/.claude.json (env.ZOTERO_API_KEY; verificada para tener acceso de escritura a la biblioteca personal, <USER_ID>, y cualquier biblioteca de grupo que uses).

• Colecciones: GET /users/<USER_ID>/collections?limit=100 → encuentra la clave objetivo; crea con POST /collections si el usuario quiere una nueva (confirma el nombre primero).
• Comprobación de duplicados — inventario primero (§0), criba la lista de candidatos (§2a), control final antes de añadir: lee toda la biblioteca por adelantado (§0); desduplica la lista de candidatos antes de cualquier verificación o trabajo con PDF (§2a); luego mantén una comprobación final ligera justo antes del POST /items como control final — detecta elementos añadidos antes en la misma ejecución y colisiones de edición exacta que las pantallas anteriores pasan por alto. Para consultas puntuales durante la ejecución, library_inventory.py --grep <términos> es mejor que mcp__zotero__zotero_search_items, porque busca en la lista que ya tienes en lugar de emitir una consulta nueva y restringida.
• Crear elementos: POST /users/<USER_ID>/items con un array JSON (≤50/solicitud). Comprueba los mapas success/failed de la respuesta. Obtén una plantilla en blanco de GET https://api.zotero.org/items/new?itemType=book cuando no estés seguro de los campos.
• Convenciones: ilustradores/créditos "con" → creadores contributor más una nota extra (los libros de Zotero no tienen rol de ilustrador); editores → editor; pon la editorial/imprenta real de la edición (ej. Sentinel, no "Penguin"); fecha de publicación completa cuando esté verificada, año en caso contrario; ISBN siempre para libros, DOI siempre para artículos.

1a. Metadatos de artículos de revistas jurídicas: correcciones para defectos del Conector de Zotero (autor, 2026-07-16)

Claude crea elementos a través de la API web, por lo que puede obtenerlos correctamente donde el Conector de Zotero del usuario falla sistemáticamente. Aplica a cada artículo de revista jurídica añadido; Hein (§4a) muestra los datos correctos, así que toma los campos de allí.

1. "The"/"A"/"An" iniciales: mantén el artículo en posición frontal natural — título The Common Law, nunca el Common Law, The invertido para ordenación del Conector.
2. Año = el año del número, no el lapso del volumen. El Conector a menudo toma el rango de fechas de todo el volumen; usa el año del número específico, que da la cita de Hein.
3. Signo de interrogación final: consérvalo — Are Judges Political?, no Are Judges Political.
4. Cursivas en los títulos: el campo de título de Zotero acepta HTML en línea — envuelve los nombres de casos (y otros términos en cursiva según Bluebook) en <i>…</i>, ej. The Real Meaning of <i>Erie</i> o Rethinking <i>Chevron</i> Deference. Zotero renderiza y exporta estos como cursiva (este es el <i>nombre del caso</i> que el usuario añade manualmente).
5. Elimina las etiquetas de tipo de pieza/simposio añadidas al título — pero conserva las designaciones reales de Bluebook en extra. El Conector añade designaciones al título — Essay, Comment, Note, Foreword, Book Review, Symposium: <nombre>, etc. Conserva solo el título real del artículo tal como encabeza la pieza / aparece en la cita de Bluebook. Si no estás seguro de si el texto final es un subtítulo real o una etiqueta añadida, consulta la primera página.
   • Notas y comentarios de estudiantes (y otras designaciones que Bluebook imprime entre el autor y el título — Recent Development, Essay, Foreword, Book Review, etc.): no te limites a descartar la etiqueta. Regístrala en el campo extra del elemento como una línea genre: — genre: Note para una nota de estudiante, genre: Comment para un comentario (en mayúscula inicial; el estilo lo pone en mayúscula inicial independientemente, pero guárdalo limpio). El estilo Bluebook entonces lo inserta en el lugar correcto (Jane Doe, Note, <i>Title</i>, 120 Harv. L. Rev. 1627 (2007)). Elimínalo del título como se indicó anteriormente y añade la línea genre: — las dos van juntas para estas piezas.
   • Notas de estudiantes anónimas (sin autor listado): deja los creadores vacíos y aún así establece genre: Note. Si el campo extra ya contiene otras líneas (ej. Verified-URL:), añade genre: Note en su propia línea nueva — no las sobrescribas.
6. Sufijos ("Jr.", "III", "Sr."): Zotero no tiene campo de sufijo — codifica el sufijo en el campo Nombre, añadido al nombre dado con una coma y sin espacio (lastName se queda solo el apellido; nunca añadas el sufijo al apellido ni añadas un segundo autor). Un ! inicial en el sufijo controla si se renderiza una coma antes de él (marcado de citeproc-js, según el autor):
   • "John Smith Jr." (sin coma) → firstName: "John,Jr.", lastName: "Smith"
   • "John Smith, Jr." (con coma) → firstName: "John,!Jr.", lastName: "Smith" El nombre dado, incluyendo cualquier segundo nombre/inicial, va antes de la coma (ej. John B.,Jr.). Mismo mecanismo para numerales/otros sufijos — John,III vs John,!III, John,Sr. etc. Coincide con la forma de coma que use el autor/fuente.
7. Abreviatura de la Revista (Bluebook, mayúscula y minúscula): siempre completa el campo journalAbbreviation de Zotero ("Journal Abbr" en la interfaz) con la abreviatura Bluebook de la revista (Tabla T13) en mayúscula y minúscula normal — Colum. L. Rev., Harv. L. Rev., Nw. U. L. Rev., J. Sup. Ct. Hist., Sup. Ct. Rev. — NO en mayúsculas sostenidas. El estilo de cita aplica las versalitas él mismo, así que almacena Colum. L. Rev., nunca COLUM. L. REV. El nombre completo permanece en publicationTitle; la abreviatura va en journalAbbreviation. La visualización de la cita de Hein la renderiza en mayúsculas/versalitas ("62 COLUM. L. REV. 633") — úsala para la redacción pero conviértela a mayúscula y minúscula; para una revista desconocida, verifica la forma de la T13 en lugar de adivinarla. Para un suplemento/compañero en línea, añade el nombre del suplemento abreviado según Bluebook — Forum → F. (ej. Harv. L. Rev. F.), mientras que Colloquy no tiene forma corta (Nw. U. L. Rev. Colloquy). Excepciones conocidas específicas de nombres (no "corrijas" estas): California Law Review → Calif. L. Rev. (no Cal., aunque California es Cal. en los reportes y en otros lugares). La rareza de Calif. es específica de esa revista — en contraste, Southern California Law Review → S. Cal. L. Rev., donde California toma el habitual Cal.

2. Encontrar candidatos

Define el alcance con el usuario si la solicitud es abierta (qué jueces/eruditos/época; solo libros o también artículos; libros comerciales vs. tratados/cuadernos de casos — marca las decisiones subjetivas en el informe en lugar de decidir en silencio). Haz esto después de §0, nunca antes — el inventario te dice lo que el usuario ya tiene, lo que cambia lo que vale la pena buscar.

Busca en paralelo: WebSearch; Open Library (search.json?title=&author= es mejor que q= desnudo); infoboxes de Wikipedia (/w/index.php?title=<página>&action=raw, haz grep del infobox) para la editorial/fecha/ISBN de libros notables; páginas de editoriales. Para estudios jurídicos, HeinOnline (§4). La API de Google Books es una cuota anónima compartida que a menudo está agotada — trátala como un extra, no como la columna vertebral.

2a. Cribar candidatos contra la biblioteca

Con el inventario en mano, desduplica la lista de candidatos antes del costoso flujo de verificación → descarga → adición (§3+). Verificar metadatos y descargar PDFs (cadenas curl de Hein, attach_pdf.py) es la parte costosa de una ejecución; hacerlo para una fuente ya en la biblioteca es puro desperdicio.

1. Coincide cada candidato contra el inventario primero por autor + año, luego por título — los títulos varían (subtítulos, "Parte I", artículos invertidos para ordenación, entidades HTML) pero las colisiones de autor-más-año son un desencadenante fiable para una mirada más cercana.
2. Descarta las coincidencias claras (misma obra ya presente) — no las verifiques ni descargues.
3. Marca, no descartes silenciosamente, las coincidencias ambiguas (mismo autor, título similar pero no idéntico; una edición/impresión diferente; artículo versus su compañero en línea). A veces solo determinas la edición exacta durante la verificación, así que lleva una posible genuina hacia adelante y anótala en el informe en lugar de descartarla adivinando.

Solo los supervivientes pasan por §3. El control final previo a la adición en §1 luego detecta duplicados dentro de la ejecución y colisiones de edición exacta.

Si creas un duplicado, fusiona antes de eliminar. El elemento preexistente puede contener el PDF, las anotaciones, las etiquetas y las pertenencias a colecciones del usuario; el tuyo nuevo puede tener mejores metadatos. Parchea los campos buenos en el elemento existente, luego ELIMINA el tuyo. Nunca elimines el registro más antiguo. (En la limpieza del 2026-08-01 esto recuperó un defecto real: el elemento Kahan del usuario tenía la cadena "10.2307" sentada en su campo issue y ningún DOI.)

Regla de flujo de trabajo (autor, 2026-07-16): resuelve cada fuente de revista jurídica a través de HeinOnline. Hein es la ruta autónoma limpia (§4a: autenticado por IP, sin muro de bots, sin puerta). Una fuente que Hein no tiene y que ningún repositorio abierto sirve se informa como tal (§5) en lugar de añadirse sin un registro verificado.

3. Verificar → añadir → comprobación determinista (no negociable)

Antes de añadir: cada campo que escribas debe provenir de una fuente obtenida — un registro de edición de Open Library (/isbn/<isbn>.json), una página de editorial, un infobox de Wikipedia, un listado de librería. Nunca escribas un ISBN/fecha/editorial plausible de memoria. Cuidado con los registros de edición de OL corruptos (un libro equivocado detrás de un ISBN es posible); verifica cualquier sorpresa contra una segunda fuente.

Después de añadir, ejecuta el comprobador incluido exactamente sobre lo que ha aterrizado en Zotero:

python3 ${CLAUDE_PLUGIN_ROOT}/skills/build-library/check_source.py --collection <CLAVE>   # colección completa
python3 ${CLAUDE_PLUGIN_ROOT}/skills/build-library/check_source.py --keys K1,K2,K3      # solo elementos nuevos

Resuelve el ISBN de cada elemento a través de cinco catálogos independientes (índice de edición + búsqueda de Open Library, Google Books, Biblioteca de Harvard, Biblioteca del Congreso) o su DOI a través de Crossref, y hace una comparación de cadenas normalizada de título/autores/año. Veredictos: PASS, FAIL (resuelto pero no coincide), UNRESOLVED (identificador no encontrado en ningún catálogo verificado — un aviso para reverificar, no prueba de fabricación: los catálogos están incompletos y a veces caídos), BAD_ISBN (suma de verificación), NO_IDENTIFIER. --stdin acepta un array JSON de elementos con forma de Zotero para pre-verificar candidatos antes de añadirlos.

Cada elemento que añadiste debe terminar PASS. Guía para no-PASS:

• FAIL en una sola fuente → generalmente corrupción del catálogo; el comprobador ya intenta las otras fuentes, por lo que un FAIL persistente generalmente significa que tus datos son incorrectos — reverifica contra una página autorizada abierta y PARCHA el elemento (envía If-Unmodified-Since-Version: <versión del elemento>). Si la página abierta confirma tus datos, regístralo como Verified-URL: y dilo en el informe en lugar de "corregir" metadatos correctos para que coincidan con un catálogo.
• UNRESOLVED/demasiado nuevo para catálogos (libros <~1 año) → añade una página autorizada recuperable como

…

[truncado para traducción]