@mcptoolshop/research-os 0.3.0 → 0.3.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -2,6 +2,220 @@
2
2
 
3
3
  All notable changes to `research-os` are documented here.
4
4
 
5
+ ## [0.3.2] — 2026-05-09
6
+
7
+ Tight release. One real, tested, dogfooded improvement: normalized
8
+ accepted-claim accounting for `pack publish` admission. Earned by
9
+ Experiment 3 XRPL pack Session K — frozen-pack admission refused on
10
+ a closure-ledger seam disagreement (Section 07 had 24 raw
11
+ `accepted_for_synthesis` rows but only 19 unique `claim_id`s due to
12
+ overlapping reviewer windows). The strict equality check between
13
+ `claim-reviews.jsonl` count and `pack-audit.json::accepted_claims`
14
+ was overcounting duplicates as a refusal trigger. Fix is structural:
15
+ a single canonical "effective accepted set" definition, applied at
16
+ admission, with the legacy audit count preserved (Law 15) but
17
+ demoted from refusal to soft warn when it disagrees with the
18
+ effective set. F-35 (cross-section-map waiver-dependency mismatch)
19
+ deferred to its own scoped release; the helper's normalization
20
+ shape doesn't naturally generalize to operator-authored waiver
21
+ entries.
22
+
23
+ ### Added
24
+
25
+ - **`getEffectiveAcceptedClaimIds(reviews)` helper** at
26
+ [`src/closure-ledger/effective-accepted.ts`](src/closure-ledger/effective-accepted.ts)
27
+ — pure-function module. Also exports `getEffectiveDecisionMap` and
28
+ `findIncompatibleDecisions` for downstream consumers that need the
29
+ latest decision per `claim_id` or want to detect incompatible
30
+ duplicate decisions at the same timestamp. The product rule
31
+ (advisor-locked): *Accepted claims = unique `claim_id`s whose
32
+ latest canonical review decision is `accepted_for_synthesis`.*
33
+ Latest-decision-wins precedence per `claim_id` (ISO-8601
34
+ timestamps compare lexicographically). Pattern mirrors
35
+ `cowork/derive.ts`'s active-blocker derivation (Pattern 2:
36
+ latest-status-wins).
37
+
38
+ ### Fixed
39
+
40
+ - **Pack publish admission contract: normalized accepted-claim
41
+ accounting (F-36).** When `claim-reviews.jsonl` contains
42
+ overlapping reviewer windows, the same `claim_id` can legitimately
43
+ receive multiple `accepted_for_synthesis` records. Pack publish
44
+ admission now derives the effective accepted set per section using
45
+ latest-decision-wins precedence per `claim_id`, instead of strict
46
+ equality against the legacy `pack-audit.json::accepted_claims` raw
47
+ count. Frozen packs whose legacy audit count differs from the
48
+ effective set now admit with a warning rather than refusing — the
49
+ legacy audit file is preserved (Law 15 immutability) while the
50
+ archive manifest reflects the normalized count. Refusal cases kept
51
+ hard: phantom `claim_id` (accepted but absent from `claims.jsonl`),
52
+ incompatible duplicate decisions (same `claim_id` + same
53
+ `created_at` with different decision values), and section gate not
54
+ synthesis-eligible.
55
+
56
+ The new soft-warn line:
57
+
58
+ ```
59
+ section <id>: legacy pack-audit.json accepted_claims (...) differs
60
+ from effective accepted set (...). Using effective count in
61
+ manifest. Legacy audit count preserved in pack/audits/pack-audit.json
62
+ (immutable per Law 15).
63
+ ```
64
+
65
+ This is **not** a publish failure when the effective accepted set
66
+ is valid. It means pack publish is preserving the frozen audit
67
+ file while normalizing the archive manifest.
68
+
69
+ ### Tests
70
+
71
+ - 540 → **558 passing** (+18). All 57 test files green; lint clean;
72
+ typecheck clean; build clean.
73
+ - 9 helper unit tests at
74
+ `test/closure-ledger/effective-accepted.test.ts` covering empty
75
+ input, duplicate-row dedup, latest-wins precedence in both
76
+ directions, out-of-order resolution, decision-map exposure,
77
+ incompatible-decision detection (with and without timestamp
78
+ collisions), and identical-timestamp agreement.
79
+ - 9 admission integration tests at
80
+ `test/pack-publish/f36-admission.test.ts` covering duplicate
81
+ accepted dedup, soft-warn (not refuse) on legacy mismatch,
82
+ effective-count manifest write, phantom-claim refusal,
83
+ incompatible-decision refusal, non-synthesis-eligible-gate
84
+ refusal, claims.jsonl-absent warn, repair-then-accept resolution,
85
+ later-rejected removal from accepted set, and tiny-fixture
86
+ regression.
87
+
88
+ ### Validated against frozen packs
89
+
90
+ - **XRPL creator-token durability** (Experiment 3 pack #2 of 3):
91
+ smoke test admits cleanly. Section 07 surfaces the expected single
92
+ warning (legacy=24, effective=19). Total
93
+ `accepted_claims = 251`. `verify-pack` PASS.
94
+ - **ComfyUI workflow durability** (Experiment 1 pack):
95
+ regression PASS, sha256 fingerprint stable.
96
+ - **research-os self-dogfood** (Experiment 0 pack):
97
+ regression PASS, sha256 fingerprint stable.
98
+
99
+ The fix is a strict superset of prior admission discipline. Packs
100
+ whose effective count already matched legacy admit identically.
101
+ Only XRPL hits the new soft-warn path.
102
+
103
+ ## [0.3.1] — 2026-05-09
104
+
105
+ Tight release. One real, tested, dogfooded improvement: section-scoped
106
+ source-floor waivers + reviewer-side acknowledgement. Earned by Experiment 3
107
+ XRPL pack Session 2 — canonical-protocol sections (XRPL XLS standards,
108
+ single-foundation chain documentation, walled-garden API specs) inverted
109
+ the assumption that publisher diversity is a proxy for truth quality. No
110
+ other v0.3.x candidates shipped — F-01 (init version-stamp), F-02
111
+ (packs-dir docs), F-05 (discover --query example), F-08 (Windows process
112
+ recovery), F-16 (unused SectionSchema fields), F-17 (sections/<id>/gates.yaml
113
+ runtime wiring) are deferred to their own scoped releases.
114
+
115
+ ### Added
116
+
117
+ - **`primary_source_waiver.section_waivers[]`** — section-scoped source-floor
118
+ waivers. Each entry carries `section_id`, `scope` (`min_independent_publishers`
119
+ or `primary_sources_required`), `reason` (non-empty), and
120
+ `compensating_controls[]` (at least one entry). Schema enforcement: empty
121
+ `reason` or empty `compensating_controls[]` fail validation. Pack policy
122
+ `gates.source_floor.primary_source_waiver_allowed: false` blocks both
123
+ pack-level and section-scoped waivers — operators cannot smuggle a waiver
124
+ past pack policy by rerouting it to section scope.
125
+
126
+ Multiple entries can target different sections, or the same section with
127
+ different scopes. Pack-level `primary_source_waiver` semantics unchanged;
128
+ the new `section_waivers[]` is additive and defaults to `[]` for backward
129
+ compatibility. Existing packs unaffected. Full reference:
130
+ [`docs/section-scoped-waivers.md`](docs/section-scoped-waivers.md).
131
+
132
+ - **Reviewer-side acknowledgement** — when a section has a matching
133
+ `min_independent_publishers` waiver in effect, the calibrated reviewer's
134
+ section-wide `source_cluster_monopoly` finding remains visible in the
135
+ findings ledger but does NOT, by itself, route claims to
136
+ `needs_source_repair`. The finding is annotated as
137
+ `(severity, waived)` in the claim-review's reason string so operators
138
+ reading the ledger can see the finding is present but neutralised. Other
139
+ source-quality findings (per-claim `source_quality_problem`,
140
+ `scope_widening`, `overgeneralized_claim`, etc.) continue to drive their
141
+ own routing normally.
142
+
143
+ - **Audit-side disclosure** — `weak-sources.{json,md}` and
144
+ `source-diversity-gaps.{json,md}` rollups annotate waived rows with
145
+ `waived: true` and `waiver_reason: <verbatim>` when a matching section
146
+ waiver is active. Rows are NOT removed (Law 16: waivers do not hide
147
+ evidence). The publisher-monopoly fact is still surfaced in the rollup;
148
+ it's disclosed as deliberately accepted rather than as an open blocker.
149
+
150
+ - **13 new tests** in `test/section-scoped-waivers.test.ts` covering
151
+ schema validation (valid shape, missing reason, empty compensating
152
+ controls, invalid scope enum, bad section_id regex), gate-side
153
+ conversion (section_id match, section_id mismatch, primary_sources_required
154
+ scope, pack-level regression, pack-policy refusal, multiple sections,
155
+ multiple scopes for same section, disclosure in WaiverApplication),
156
+ reviewer-side acknowledgement (waived monopoly → accepted, per-claim
157
+ quality still routes, regression without waiver), and audit-side
158
+ annotation.
159
+
160
+ - **`docs/section-scoped-waivers.md`** — full operator reference: schema,
161
+ behavior contract, valid-cases / invalid-cases enumeration, required
162
+ operator discipline (synthesis-time disclosure beyond the schema), and
163
+ the release thesis. Opens with the canonical phrasing:
164
+ *"Use section-scoped source waivers when publisher diversity is
165
+ structurally incompatible with the section's truth source, not when a
166
+ section merely failed to find enough sources."*
167
+
168
+ - **Handbook page** at `/handbook/section-scoped-waivers` — condensed
169
+ reference matching the docs page.
170
+
171
+ ### Changed
172
+
173
+ - **Pack-level `min_independent_publishers: 0` workaround DEPRECATED**
174
+ in the canonical `research-packs/docs/operator-playbook.md` and the
175
+ research-os handbook mirror. The pack-level pattern remains valid for
176
+ already-frozen packs (e.g., `packages/comfyui-workflow-durability/`)
177
+ whose freeze receipts are unchanged; new packs should prefer the
178
+ section-scoped pattern. Forward notes added to
179
+ [`docs/experiment-1-proof.md`](docs/experiment-1-proof.md) at the
180
+ references to the deprecated workaround — historical content
181
+ preserved, not rewritten.
182
+
183
+ ### Documentation
184
+
185
+ - README status block updated to v0.3.1; version badge updated.
186
+ - `docs/roadmap.md` Experiment 3 progress: section-scoped source waivers
187
+ shipped in v0.3.1; pack #2 of 3 (XRPL) earned both v0.3.0 and v0.3.1
188
+ fixes. Two more external-domain packs required for closure.
189
+ - **Cross-repo:** `research-packs/docs/operator-playbook.md` updated in
190
+ the same release window. Adds the section-scoped waiver pattern as the
191
+ canonical guidance with the same anti-misuse framing as the research-os
192
+ docs page (public guidance is consistent across the surface by design).
193
+ Deprecates the `min_independent_publishers: 0` pack-level workaround.
194
+
195
+ ### Tests
196
+
197
+ - **540 total** (527 at v0.3.0 → 540 at v0.3.1, +13 from
198
+ `test/section-scoped-waivers.test.ts`).
199
+
200
+ ### Migration notes
201
+
202
+ No code-level migration required. Existing packs continue to work
203
+ unchanged — `section_waivers` defaults to `[]`. Frozen packs' freeze
204
+ receipts remain valid (the schema addition is additive).
205
+
206
+ For new canonical-protocol packs: prefer section-scoped waivers over the
207
+ deprecated pack-level `min_independent_publishers: 0` workaround. The
208
+ section-scoped pattern preserves the publisher-diversity floor on every
209
+ section that doesn't waive it explicitly.
210
+
211
+ For operators with packs already using the deprecated pack-level
212
+ workaround: the pattern remains valid; no migration is required. If you
213
+ want to tighten the global default and waive specific sections instead,
214
+ that's a clean per-section migration — set
215
+ `min_independent_publishers` back to its non-zero pack default and add
216
+ section_waivers entries for the sections that need them, with
217
+ `reason` and `compensating_controls[]` documented.
218
+
5
219
  ## [0.3.0] — 2026-05-09
6
220
 
7
221
  Tight release. One real, tested, dogfooded improvement: `--detector` flag on
package/README.es.md CHANGED
@@ -7,7 +7,7 @@
7
7
  </p>
8
8
 
9
9
  <p align="center">
10
- <a href="https://github.com/mcp-tool-shop-org/research-os/releases/tag/v0.1.0"><img src="https://img.shields.io/badge/version-0.1.0-blue" alt="version 0.1.0"></a>
10
+ <a href="https://github.com/mcp-tool-shop-org/research-os/releases/tag/v0.3.2"><img src="https://img.shields.io/badge/version-0.3.2-blue" alt="version 0.3.2"></a>
11
11
  <a href="https://github.com/mcp-tool-shop-org/research-os/actions/workflows/ci.yml"><img src="https://github.com/mcp-tool-shop-org/research-os/actions/workflows/ci.yml/badge.svg" alt="CI"></a>
12
12
  <a href="LICENSE"><img src="https://img.shields.io/badge/license-MIT-green" alt="MIT License"></a>
13
13
  <img src="https://img.shields.io/badge/node-%E2%89%A520-brightgreen" alt="Node ≥20">
@@ -16,80 +16,37 @@
16
16
 
17
17
  # research-os
18
18
 
19
- Una herramienta de línea de comandos (CLI) que transforma un tema abierto en un **paquete de investigación estructurado**, un repositorio organizado donde Claude, Cowork o un conjunto de herramientas pueden trabajar durante horas sin generar información falsa ni distorsionar la investigación.
19
+ Una herramienta de línea de comandos (CLI) que transforma un tema amplio en un "**paquete de investigación**" estructurado: un repositorio organizado donde Claude, Cowork o un conjunto de herramientas pueden trabajar durante horas sin generar información falsa ni distorsionar la investigación.
20
20
 
21
21
  ## ¿Qué es?
22
22
 
23
- `research-os` es la capa de control entre "quiero investigar X" y una base de evidencia sólida y verificable. Separa las pistas de descubrimiento de la recopilación de evidencia, la extracción de datos de la validación de afirmaciones, la detección de contradicciones de la resolución de contradicciones, y las decisiones de revisión de las conclusiones. Cada paso se registra en un registro de solo escritura; cada decisión se calcula a partir de esos registros, no se afirma arbitrariamente.
23
+ `research-os` es la capa de control entre "quiero investigar X" y una base de evidencia estructurada y verificable. Separa las ideas iniciales de la recopilación de evidencia, la extracción de datos de la evaluación de la información, la detección de contradicciones de la resolución de contradicciones, y las decisiones de revisión de la síntesis. Cada paso escribe en un registro de solo escritura; cada decisión sobre la validez se calcula a partir de esos registros, no se afirma directamente.
24
24
 
25
- No es un generador de informes. No es un marco de orquestación de modelos de lenguaje (LLM). No escribe la síntesis por usted. Impone las condiciones bajo las cuales la síntesis puede comenzar.
25
+ No es un generador de informes. No es un marco de orquestación de modelos de lenguaje grandes (LLM). No escribe la síntesis por usted. Impone las condiciones bajo las cuales la síntesis puede comenzar.
26
26
 
27
- **La versión 0.1 se ha utilizado exactamente una vez: por sí misma, sobre sí misma.** Ese único uso reveló siete errores en `research-os`, cada uno corregido antes de esta versión. El registro de pruebas, que incluye siete sesiones, dos patrones de integración, 463 casos de prueba `vitest` y un paquete finalizado, se encuentra en [`docs/dogfood-proof.md`](docs/dogfood-proof.md). Manual de usuario: <https://mcp-tool-shop-org.github.io/research-os/handbook/>.
27
+ Los paquetes finalizados se archivan en [`mcp-tool-shop-org/research-packs`](https://github.com/mcp-tool-shop-org/research-packs). Están disponibles, con dos paquetes iniciales. Consulte [`docs/roadmap.md`](docs/roadmap.md) para conocer la hoja de ruta de la versión 1.0.
28
28
 
29
- ## Las 16 leyes fundamentales
29
+ La versión 0.1 se ha sometido a pruebas exhaustivas en dos proyectos piloto. El primero, "research-os investigando su propia especificación", encontró siete errores antes del lanzamiento de la versión 0.1.0, cada uno de los cuales requirió una corrección de código y la creación de una regla o patrón de integración. El segundo (Experimento 1: Durabilidad del flujo de trabajo de ComfyUI, 11 sesiones, un dominio sin superposición de vocabulario con research-os) se completó el 9 de mayo de 2026: el paquete se finalizó, el archivo está disponible, y la regla 2 se implementó mediante el commit `22b5dba`. La documentación del proyecto piloto 0.1 se encuentra en [`docs/dogfood-proof.md`](docs/dogfood-proof.md); la documentación del Experimento 1 se encuentra en [`docs/experiment-1-proof.md`](docs/experiment-1-proof.md). Manual de usuario: <https://mcp-tool-shop-org.github.io/research-os/handbook/>.
30
30
 
31
- | # | Ley |
32
- |---|-----|
33
- | 1 | No hay síntesis antes de la verdad de la fuente. |
34
- | 2 | La recopilación es evidencia; la extracción es interpretación. |
35
- | 3 | Los modelos pueden interpretar fragmentos de la fuente; no pueden crear fragmentos de evidencia. |
36
- | 4 | La extracción puede generar demasiada información; la síntesis no puede heredar esa abundancia. |
37
- | 5 | El mapeo de contradicciones revela tensiones; no resuelve, sintetiza ni decide qué afirmación es correcta. |
38
- | 6 | Las restricciones deciden si una sección es elegible para la síntesis. No sintetizan ni ocultan los fallos. |
39
- | 7 | La revisión crítica evalúa la integridad de la investigación. No sintetiza ni reescribe la verdad de la fuente. |
40
- | 8 | La indexación hace que la verdad de la investigación sea consultable. No crea nueva verdad ni se convierte en la fuente oficial. |
41
- | 9 | La transferencia a Cowork genera instrucciones operativas a partir de la verdad de la investigación. No crea verdad ni evita las restricciones. |
42
- | 10 | El espacio de trabajo de síntesis organiza la verdad de la investigación aceptada para Cowork. No crea síntesis ni evita el modo de transferencia. |
43
- | 11 | La auditoría del paquete agrega la verdad de la investigación existente. No crea nueva verdad ni oculta la evidencia a nivel de sección. |
44
- | 12 | El descubrimiento propone pistas; solo la recopilación produce evidencia. |
45
- | 13 | Un revisor no es confiable hasta que las pruebas de fallos demuestran su capacidad de recuperación. |
46
- | 14 | La abundancia de afirmaciones no es sinónimo de calidad de la investigación. Las afirmaciones deben ser validadas antes de poder competir para la síntesis. |
47
- | 15 | La congelación fija la verdad de la investigación completada. No completa la investigación inconclusa ni convierte el estado de reparación en evidencia. |
48
- | 16 | Las exenciones relajan las restricciones de la fuente; no pueden crear evidencia. |
49
-
50
- **Ley 3** — el modelo de lenguaje nunca crea texto de evidencia. `research-os` crea un registro de extractos determinista (con identificadores estables como `ex_<id_hex_de_la_fuente>_001`); el modelo de lenguaje elige los identificadores de los extractos; `research-os` copia el texto literal. La clase de error "parafrasear como cita" es estructuralmente imposible.
51
-
52
- **Ley 14** — entre la extracción y la revisión, `research-os claim triage` elimina duplicados, limita la contribución por fuente y reserva los candidatos de bajo rendimiento. El triage NO modifica `claims.jsonl`; las afirmaciones reservadas permanecen en el registro canónico.
31
+ ## Instalación
53
32
 
54
- ## La cadena de flujo de trabajo de la versión 0.1
33
+ **Requisitos:** Node.js 20.
55
34
 
56
- ```
57
- discover
58
- → gather
59
- → claim extract
60
- → claim audit-density
61
- → claim triage
62
- → contradict map
63
- → contradict resolve
64
- → review
65
- → review-promote
66
- → gate
67
- → section report
68
- → audit
69
- → index build
70
- → cowork handoff
71
- → synth workspace
72
- → freeze
35
+ ```bash
36
+ npm install -g @mcptoolshop/research-os
73
37
  ```
74
38
 
75
- Cada paso es un comando de la interfaz de línea de comandos (CLI). Cada paso escribe en archivos que solo se pueden añadir, no modificar. Ningún paso sintetiza, resuelve o crea nueva información verificable; esos invariantes se aplican, no se confían. La revisión acepta, rechaza o solicita correcciones para las afirmaciones propuestas; el proceso de "gate" utiliza estas decisiones de revisión para calcular la elegibilidad para la síntesis; la fase de "freeze" es el bloqueo final de integridad que impide marcar un paquete como completado a menos que todas las capas estén de acuerdo. Consulte [docs/dogfood-proof.md](docs/dogfood-proof.md) para la prueba de la versión 0.1 que demuestra la integridad de la cadena de principio a fin.
76
-
77
- Esta es la alternativa estructural a *búsqueda → resumen → informe detallado*. La cadena es el producto.
78
-
79
- ## Instalación
80
-
81
- **Requisitos:** Node.js ≥ 20.
39
+ Para los colaboradores que construyen desde el código fuente:
82
40
 
83
41
  ```bash
84
- # From source (v0.1.0 is not yet published to npm)
85
42
  git clone https://github.com/mcp-tool-shop-org/research-os.git
86
43
  cd research-os
87
44
  npm install
88
45
  npm run build
89
- npm link # makes `research-os` available on your PATH
46
+ npm link
90
47
  ```
91
48
 
92
- ## Inicio rápido
49
+ ## Comienzo rápido
93
50
 
94
51
  ```bash
95
52
  # Create a new research-pack
@@ -119,41 +76,112 @@ research-os index build --all
119
76
  research-os cowork handoff
120
77
  research-os synth workspace # only if handoff returned synthesis_ready
121
78
  research-os freeze
79
+
80
+ # Export to the research-packs archive
81
+ research-os pack publish \
82
+ --to <research-packs>/packages/<name>
122
83
  ```
123
84
 
124
- **Para un ejemplo práctico**, consulte el paquete de prueba en `research-os-packs/research-os-spec/`: cada archivo, cada registro, cada disposición, cada huella digital de la fase de "freeze", todo almacenado en el disco en registros de solo escritura. Ese paquete es el que generó `docs/dogfood-proof.md`.
85
+ **Para un ejemplo práctico**, consulte el paquete de demostración en `research-os-packs/research-os-spec/`: cada elemento, cada registro, cada evaluación, cada huella digital de la versión final, todo en el disco en registros de solo escritura. Ese paquete es el que generó `docs/dogfood-proof.md`.
125
86
 
126
- **Requiere [ollama-intern-mcp](https://github.com/mcp-tool-shop-org/ollama-intern-mcp) ejecutándose localmente** para la extracción, clasificación, revisión y descubrimiento de modelos de lenguaje. El modelo predeterminado es `hermes3:8b`; puede cambiarlo con `OLLAMA_INTERN_MODEL=<modelo>`. Establezca `OLLAMA_HOST` si Ollama no se ejecuta en el puerto predeterminado `localhost:11434`.
87
+ **Requiere [ollama-intern-mcp](https://github.com/mcp-tool-shop-org/ollama-intern-mcp) ejecutándose localmente** para la extracción, la evaluación, la revisión y el descubrimiento de información mediante modelos de lenguaje. El modelo predeterminado es `hermes3:8b`; cámbielo con `OLLAMA_INTERN_MODEL=<modelo>`. Establezca `OLLAMA_HOST` si Ollama no se ejecuta en el valor predeterminado `localhost:11434`.
88
+
89
+ ## Las 16 reglas fundamentales
90
+
91
+ | # | Regla |
92
+ |---|-----|
93
+ | 1 | No se puede realizar una síntesis sin una fuente verificada. |
94
+ | 2 | La recopilación es evidencia; la extracción es interpretación. |
95
+ | 3 | Los modelos pueden interpretar fragmentos de la fuente; no pueden crear fragmentos de evidencia. |
96
+ | 4 | La extracción puede generar demasiada información; la síntesis no puede heredar esa abundancia. |
97
+ | 5 | El mapeo de contradicciones revela tensiones; no resuelve, sintetiza ni decide qué afirmación es correcta. |
98
+ | 6 | Las restricciones deciden si una sección es elegible para la síntesis. No realizan la síntesis ni ocultan los fallos. |
99
+ | 7 | La revisión crítica evalúa la integridad de la investigación. No realiza la síntesis ni reescribe la fuente verificada. |
100
+ | 8 | La indexación permite buscar información verificada. No crea nueva información ni se convierte en la fuente oficial. |
101
+ | 9 | La transferencia a Cowork genera instrucciones operativas a partir de la información verificada. No crea información ni evita las restricciones. |
102
+ | 10 | El espacio de trabajo de síntesis organiza la información verificada para Cowork. No crea la síntesis ni evita el modo de transferencia. |
103
+ | 11 | La auditoría del paquete recopila la información verificada existente. No crea nueva información ni oculta la evidencia a nivel de sección. |
104
+ | 12 | El descubrimiento propone ideas; solo la recopilación produce evidencia. |
105
+ | 13 | Un revisor no se considera confiable hasta que se demuestran fallos y se verifica su capacidad de recuperación. |
106
+ | 14 | La abundancia de afirmaciones no garantiza la calidad de la investigación. Las afirmaciones deben ser evaluadas antes de poder ser consideradas para su síntesis. |
107
+ | 15 | La función de "congelación" asegura la integridad de la investigación finalizada. No completa investigaciones incompletas ni convierte un estado de reparación en evidencia. |
108
+ | 16 | Las exenciones relajan las restricciones de origen; sin embargo, no pueden generar evidencia. |
109
+
110
+ **Ley 3** — El modelo de lenguaje (LLM) nunca genera texto de evidencia. `research-os` crea un registro determinista de extractos (con identificadores estables como `ex_<id_hex_de_la_fuente>_001`); el LLM selecciona los identificadores de los extractos; `research-os` copia el texto literal. La clase de error "parafraseo como cita" es estructuralmente imposible.
111
+
112
+ **Ley 14** — Entre la extracción y la revisión, `research-os claim triage` elimina duplicados, limita la contribución por fuente y reserva los candidatos de bajo valor. El triage NO modifica `claims.jsonl`; las afirmaciones reservadas permanecen en el registro canónico.
113
+
114
+ ## La cadena de flujo de trabajo v0.1
115
+
116
+ ```
117
+ discover
118
+ → gather
119
+ → claim extract
120
+ → claim audit-density
121
+ → claim triage
122
+ → contradict map
123
+ → contradict resolve
124
+ → review
125
+ → review-promote
126
+ → gate
127
+ → section report
128
+ → audit
129
+ → index build
130
+ → cowork handoff
131
+ → synth workspace
132
+ → freeze
133
+ ```
134
+
135
+ Cada paso es un comando de la interfaz de línea de comandos (CLI). Cada paso escribe en archivos que solo se pueden añadir. Ningún paso sintetiza, resuelve o crea nueva verdad; estos invariantes se aplican y no se confían en ellos. La revisión acepta, rechaza o solicita correcciones para las afirmaciones candidatas; la función de "puerta" utiliza estas decisiones de revisión para calcular la "elegibilidad para la síntesis"; la función de "congelación" es el último control de integridad que se niega a marcar un paquete como completado a menos que todas las capas estén de acuerdo. Consulte [docs/dogfood-proof.md](docs/dogfood-proof.md) para la prueba de la cadena v0.1 que garantiza la integridad de extremo a extremo.
136
+
137
+ Esta es la alternativa estructural a *búsqueda → resumen → informe detallado*. La cadena es el producto.
127
138
 
128
139
  ## Glosario
129
140
 
130
141
  | Término | Significado |
131
142
  |------|---------|
132
- | `research-os` | El plano de control / CLI / mecanismos de control / ley de orquestación (este repositorio) |
133
- | `research-pack` | El archivo generado para un esfuerzo de investigación. |
143
+ | `research-os` | El plano de control / CLI / puertas / ley de orquestación (este repositorio) |
144
+ | `research-pack` | El artefacto de repositorio generado para un esfuerzo de investigación. |
134
145
  | `research section` | Una unidad de investigación delimitada dentro de un paquete. |
135
- | `research receipt` | Prueba de que una sección ha superado las comprobaciones de origen/afirmación/mecanismo de control. |
146
+ | `research receipt` | Prueba de que una sección ha superado las comprobaciones de origen/afirmación/puerta. |
136
147
 
137
148
  ## Seguridad
138
149
 
139
- `research-os` es una herramienta de línea de comandos que funciona principalmente localmente. Lee y escribe archivos dentro del directorio del paquete de investigación al que la apunta, y (cuando se utiliza `gather`) realiza solicitudes HTTP salientes para obtener las URL de origen que proporciona. No: ejecuta un servidor, acepta conexiones entrantes, almacena credenciales ni envía datos de telemetría. No se escriben secretos en los archivos del paquete. Consulte [SECURITY.md](SECURITY.md) para la política de notificación de vulnerabilidades.
150
+ `research-os` es una herramienta de línea de comandos que funciona principalmente de forma local. Lee y escribe archivos dentro del directorio del paquete de investigación al que se le indica, y (cuando se utiliza `gather`) realiza solicitudes HTTP salientes para obtener las URL de origen que se proporcionan. No: ejecuta un servidor, acepta conexiones entrantes, almacena credenciales ni envía datos de telemetría. No se escriben secretos en los artefactos del paquete. Consulte [SECURITY.md](SECURITY.md) para obtener la política de notificación de vulnerabilidades.
140
151
 
141
152
  ## Estado
142
153
 
143
- **v0.1.0** — Congelado el 08 de mayo de 2026. El paquete de prueba en `research-os-packs/research-os-spec/` (repositorio relacionado) alcanzó la fase de "freeze" con 296 afirmaciones aceptadas en 8 secciones, 17 dispuestas, 30 modificadas por el operador, 0 bloqueadores de corrección activos, 0 contradicciones sin resolver, y todos los mecanismos de control con `synthesis_eligible=true`. 463/463 pruebas de vitest superadas. Dieciséis leyes fundamentales acumuladas. Consulte [`docs/dogfood-proof.md`](docs/dogfood-proof.md) para conocer los siete hallazgos y las huellas digitales de la fase de "freeze".
154
+ **v0.3.2** — Publicada en npm como `@mcptoolshop/research-os@0.3.2`, el 9 de mayo de 2026. Incluye una normalización de las reclamaciones aceptadas, teniendo en cuenta la admisión para la publicación de paquetes. La verificación estricta de igualdad entre `claim-reviews.jsonl` y `pack-audit.json::accepted_claims` ha sido reemplazada por una comparación de conjuntos efectivos: las reclamaciones aceptadas son los identificadores únicos (`claim_id`) cuya última decisión de revisión canónica es "aceptada para síntesis" (la última decisión prevalece para cada `claim_id`). Los paquetes congelados cuya cuenta de auditoría heredada difiere del conjunto efectivo ahora se admiten con una advertencia en lugar de ser rechazados; el archivo de auditoría heredado se conserva tal cual (Ley 15), mientras que el manifiesto del archivo refleja la cuenta normalizada. El rechazo sigue siendo absoluto para los identificadores de reclamación fantasma, las decisiones duplicadas incompatibles y las condiciones que no son elegibles para la síntesis. Obtenido a través del Experimento 3 XRPL pack Session K: la publicación del paquete fue rechazada debido a una discrepancia real en el registro de cierre (la Sección 07 tenía 24 filas "aceptadas para síntesis", pero solo 19 identificadores únicos (`claim_id`) debido a ventanas de revisión superpuestas). 558/558 pruebas de vitest superadas. Consulte [CHANGELOG.md](CHANGELOG.md) y [`docs/pack-publish.md`](docs/pack-publish.md).
144
155
 
145
- ### Lo que la versión 0.1 no es
156
+ **v0.3.1** Publicado en npm como `@mcptoolshop/research-os@0.3.1`, 9 de mayo de 2026. Incluye exenciones de origen con ámbito de sección (`primary_source_waiver.section_waivers[]`) y un reconocimiento por parte del revisor, de modo que una detección de "monopolio de la fuente" a nivel de sección se convierte en una advertencia visible en lugar de redirigir automáticamente todas las afirmaciones a "necesita reparación de la fuente". Obtenido mediante el experimento 3 del paquete XRPL, sesión 2: las secciones de protocolo canónico (cadenas de una sola base, especificaciones de API de jardín vallado, documentos de organismos de normalización) invirtieron la suposición de que la diversidad de editores es un indicador de la calidad de la verdad. 540/540 pruebas de vitest superadas. Consulte [CHANGELOG.md](CHANGELOG.md) y [`docs/section-scoped-waivers.md`](docs/section-scoped-waivers.md).
146
157
 
147
- - No ha sido probada por usuarios externos. La única ejecución de prueba encontró siete errores.
148
- - Todavía no está disponible en npm. Instale desde el código fuente hasta que se publique en npm.
149
- - No es un generador de contenido. El comando `synth workspace` genera el espacio de trabajo estructurado; los humanos (o Cowork) escriben el contenido en función de los ID de las afirmaciones aceptadas.
150
- - No tiene una API estable según las convenciones de versiones semánticas. La versión 1.0.0 se lanzará después de que los usuarios externos hayan validado la interfaz a lo largo del tiempo.
158
+ **Exenciones de origen con ámbito de sección** — Utilícelas cuando la diversidad de editores es estructuralmente incompatible con la fuente de verdad de la sección, no cuando una sección simplemente no ha logrado encontrar suficientes fuentes. Incluye un campo "razón" con control de esquema y una lista no vacía de "controles compensatorios". La política del paquete `primary_source_waiver_allowed: false` bloquea tanto las exenciones a nivel de paquete como las exenciones con ámbito de sección. El truco anterior a la v0.3.1 de `min_independent_publishers: 0` a nivel de paquete está ahora obsoleto; los paquetes congelados existentes siguen siendo válidos según sus recibos existentes. Consulte [`docs/section-scoped-waivers.md`](docs/section-scoped-waivers.md) y el [manual de operación de los paquetes de investigación](https://github.com/mcp-tool-shop-org/research-packs/blob/main/docs/operator-playbook.md).
159
+
160
+ **v0.3.0** — publicado el 2026-05-09. Se incluyó la opción `--detector <auto|heuristic|ollama-intern>` en `contradict map` (corrección F-09 de bloqueo de cadena del Experimento 3, Sesión 1, paquete XRPL). 527/527 pruebas vitest superadas. La selección del detector ahora es una opción explícita para el operador, en lugar de una variable de entorno dependiente del estado; el modo se muestra claramente en cada ejecución. Consulte [`docs/contradict-map.md`](docs/contradict-map.md).
161
+
162
+ **v0.2.0** — publicado el 2026-05-09. Se incluyeron el paquete `research-os pack publish` (Experimento 2) y la corrección del predicado de preparación del Patrón 2. 515/515 pruebas vitest superadas. Consulte [CHANGELOG.md](CHANGELOG.md). Los paquetes congelados se exportan al archivo canónico `research-packs` con un solo comando; el contrato de admisión se aplica mediante código, no mediante una lista de verificación. Consulte [`docs/pack-publish.md`](docs/pack-publish.md).
163
+
164
+ **v0.1.0** — paquete de prueba interna congelado el 2026-05-08. El paquete en `research-os-packs/research-os-spec/` (repositorio hermano) alcanzó el estado de congelación con 296 afirmaciones aceptadas en 8 secciones, 17 gestionadas, 30 anuladas por el operador, 0 bloqueadores de reparación activos, 0 contradicciones sin resolver, y todas las condiciones (`synthesis_eligible=true`) cumplidas. Seis leyes fundamentales acumuladas. Consulte [`docs/dogfood-proof.md`](docs/dogfood-proof.md) para obtener los siete hallazgos y las huellas digitales de la recepción de la congelación.
165
+
166
+ **Repositorio monorepo de paquetes de investigación** — disponible en [`mcp-tool-shop-org/research-packs`](https://github.com/mcp-tool-shop-org/research-packs) con dos paquetes iniciales. `comfyui-workflow-durability` (Experimento 1, 302 afirmaciones aceptadas, 8 secciones) y `research-os-self-dogfood` (relleno de la versión 0.1 de la prueba interna, 296 afirmaciones aceptadas, 8 secciones). Ambos paquetes PASAN `verify-pack.mjs`.
167
+
168
+ **Experimento 1 de la versión 1 (Durabilidad del flujo de trabajo de ComfyUI)** — CERRADO el 2026-05-09. Todas las 8 secciones en Terminal A, paquete congelado, archivo disponible. Consulte [`docs/experiment-1-proof.md`](docs/experiment-1-proof.md) y [`docs/roadmap.md`](docs/roadmap.md).
169
+
170
+ ### Lo que la versión 0.3 no es
171
+
172
+ - No ha sido probada en condiciones reales por usuarios externos. Dos ciclos de pruebas internas han finalizado: uno autoreferencial y otro de dominio externo, y el Experimento 3 (estabilidad de la API bajo presión externa) está en curso: el paquete #2 de 3 (durabilidad del token de creador de XRPL) está congelado con 251 reclamaciones aceptadas en 7 secciones, a la espera de la admisión para la publicación del paquete en npm v0.3.2. Este ciclo ha cumplido con la bandera v0.3.0 `--detector` (bloqueador de cadena F-09), las exenciones de origen específicas de la sección (F-10/F-11, presión del protocolo canónico) y la normalización de la cuenta de reclamaciones aceptadas (F-36, borde del registro de cierre). Se necesita un ciclo más de dominio externo para completar el Experimento 3.
173
+ - No es un generador de síntesis. El comando `synth workspace` genera el espacio de trabajo estructurado; los humanos (o Cowork) escriben el contenido basándose en los identificadores de reclamación aceptados.
174
+ - No es estable en la API según la semántica de versiones. La versión v1.0.0 es un estado alcanzado, no una fecha en el calendario; consulte [`docs/roadmap.md`](docs/roadmap.md) para ver los seis experimentos que cierran esta brecha.
151
175
 
152
176
  ### Limitaciones conocidas
153
177
 
154
- - **La información sobre el origen del extractor no es visible en la costura de la puerta.** Una sección puede superar el umbral de aceptación si se utilizan criterios de evaluación alternativos cuando el extractor calibrado (Ollama con el modelo configurado) no está disponible. Se ha registrado como una debilidad conocida; en el futuro, se informará sobre las reclamaciones aceptadas por el extractor y se requerirá un número de reclamaciones aceptadas equivalente al umbral desde la ruta calibrada.
155
- - **La selección del modelo de revisión, más allá de la línea de base calibrada `hermes-two-pass`, no está resuelta.** El ciclo de pruebas internas validó una configuración de revisión; otros modelos necesitan su propia calibración para detectar fallos antes de que puedan ser considerados fiables.
156
- - **El paquete de pruebas internas utilizó `mistral-nemo:12b` para la extracción (el valor predeterminado estándar es `hermes3:8b`).** El sistema generó resultados incorrectos para nombres de secciones que se referían a mismos; esto se corrigió mediante la precisión de las consultas (ver manual) y mediante URLs predefinidas por el operador para temas ambiguos.
178
+ - **El origen del extractor no es visible en la interfaz de la condición.** Una sección puede pasar la prueba de afirmaciones aceptadas mientras se basan en afirmaciones heurísticas cuando el extractor calibrado (Ollama con el modelo configurado) no está disponible. Se registra como el Experimento 4 en el plan de trabajo; la futura optimización informará las afirmaciones aceptadas por extractor y requerirá la cantidad de afirmaciones aceptadas del camino calibrado.
179
+ - **La selección del modelo de revisión más allá de la línea de base calibrada de `hermes-two-pass` no está resuelta.** El ciclo de prueba interna validó una configuración de revisor; los modelos alternativos necesitan su propia calibración de recuperación de fallos simulados antes de que puedan ser confiables. Experimento 5 en el plan de trabajo.
180
+ - **El paquete de prueba interna de la versión 0.1 utilizó `mistral-nemo:12b` para la extracción (el valor predeterminado canónico es `hermes3:8b`).** `hermes3:8b` no estaba disponible en esta plataforma durante el ciclo de la versión 0.1. La divulgación de la sustitución permanece vigente hasta que se produzca una recepción basada en hermes3; Experimento 6 en el plan de trabajo. Para los operadores en plataformas que no tienen `hermes3:8b`, establezca `OLLAMA_INTERN_MODEL` en un modelo disponible; las URL preconfiguradas para el operador y la disciplina de precisión de la consulta (consulte el manual) mitigan las alucinaciones de descubrimiento en temas ambiguos.
181
+
182
+ ## Hoja de ruta para la versión 1.0
183
+
184
+ La versión 1.0 es un estado alcanzado, no una fecha de lanzamiento. Seis experimentos están pendientes entre la versión 0.1 y la 1.0: un sistema de pruebas internas ("dogfood") que no se refiere a sí mismo (actualmente en desarrollo como el paquete de durabilidad de ComfyUI), un comando `research-os pack publish` que automatiza la exportación al repositorio centralizado `research-packs` (Experimento 2, limitado por el Experimento 1 y que requiere su finalización manual), estabilidad de la API bajo presión externa, la resolución de la brecha de trazabilidad del extractor, la generalización de la calibración de los revisores más allá de `hermes-two-pass`, y una ejecución de referencia limpia en `hermes3:8b`. El Experimento 1 no estará finalizado cuando se "congele" el paquete; se completará cuando el paquete congelado se publique como el primer paquete en el repositorio centralizado `research-packs`, junto con la versión 0.1 del sistema de pruebas internas. El plan completo se encuentra en [`docs/roadmap.md`](docs/roadmap.md). La arquitectura permanece constante; la versión 1.0 profundiza en lo que la versión 0.1 demostró, en lugar de volver a abrir temas ya tratados.
157
185
 
158
186
  ## Licencia
159
187