specrails-desktop 2.46.0 → 2.48.0

package/docs/plans/implementation-efficiency-evaluation.md

@@ -0,0 +1,41 @@
+# Implementation efficiency evaluation
+
+Mode: offline. synthetic-fixture-usage; no actual AI savings measured.
+
+Monetary target: 20% lower aggregate cost per independently accepted output. Conclusion: inconclusive.
+
+{
+  "full": {
+    "samples": 5,
+    "independentlyAccepted": 5,
+    "costPerAcceptedUsd": null,
+    "medianActiveDurationMs": 10173,
+    "minActiveDurationMs": 9718,
+    "maxActiveDurationMs": 13922,
+    "standardDeviationMs": 1624.2063415711687
+  },
+  "optimized": {
+    "samples": 5,
+    "independentlyAccepted": 5,
+    "costPerAcceptedUsd": null,
+    "medianActiveDurationMs": 10103,
+    "minActiveDurationMs": 9566,
+    "maxActiveDurationMs": 14355,
+    "standardDeviationMs": 1781.4247107301503
+  }
+}
+
+Correction prompt comparison: [{"caseId":"verification-correction","repeat":0,"fullBytes":4859,"optimizedBytes":1777,"reduction":0.6342868903066474}]
+
+- static-tetris, full: succeeded; independent acceptance true; 9764 ms
+- static-tetris, optimized: succeeded; independent acceptance true; 9964 ms
+- local-tested-feature, full: succeeded; independent acceptance true; 9718 ms
+- local-tested-feature, optimized: succeeded; independent acceptance true; 9566 ms
+- cross-repository-contract, full: succeeded; independent acceptance true; 10173 ms
+- cross-repository-contract, optimized: succeeded; independent acceptance true; 10103 ms
+- verification-correction, full: succeeded; independent acceptance true; 11920 ms
+- verification-correction, optimized: succeeded; independent acceptance true; 11917 ms
+- review-correction, full: succeeded; independent acceptance true; 13922 ms
+- review-correction, optimized: succeeded; independent acceptance true; 14355 ms
+
+No paid benchmark has established monetary savings.

package/docs/plans/implementation-efficiency-progress.md

@@ -0,0 +1,48 @@
+# Implementation efficiency — verification record
+
+The local implementation is on `codex/implement-efficiency-runtime` in both repositories. This record supersedes the earlier in-progress notes. Core owns graph semantics and evidence; Desktop owns configuration, presentation, runtime retention and delivery. No additional AI verifier was introduced. Official OpenSpec remains mandatory for architect, developer and reviewer.
+
+## Completeness
+
+The paired OpenSpec task lists record completed local work individually. Remaining unchecked tasks are distribution gates: native OS/Node release validation, publishing a new authorized Core version, updating both exact Desktop pins and testing that pinned production bundle. A development tarball with package version 5.3.0 is **not** a new published release and must not overwrite the existing one. Do not archive the paired changes before these gates are resolved.
+
+## Correctness and implementation mapping
+
+| Plan area | Implementation | Evidence |
+| --- | --- | --- |
+| C0 / D0 capabilities and original runtimes | Core capabilities/runtime-identity/core-host; Desktop loader/package retainer | Actual original v4 tarball continuation through Desktop, unchanged saved fingerprints; retained dependency closure and nested versions; absent/corrupt provenance recovery; installed CLI/API checks |
+| C1 context and review | repository-context, review-context, role-state, graph/roles | Fair bounded multi-repository packets, explicit truncated/deleted sources, confirmed-session deltas, narrow fresh-session fallback, complete acceptance recertification |
+| C2 role routing | role-routing, transport executors, graph/roles | Two failed candidates counted once each; maxAttempts2 cannot add an attempt; maxAttempts3 routes third candidate; sessionless bounded repair/deepen; requested effort admission |
+| C3 persisted checks | verification-plan, pipeline-state, scoped API/MCP tools | Immutable baseline and harness history, pre-write manifest bounds, source and plan fingerprints, paged output/source access, redaction, pending evidence integrity, installed standalone harness |
+| C4 reuse and scheduling | pipeline-state | Host-only exact snapshot reuse, ignored dependency changes invalidate, external resources ineligible, contiguous independent waves, process-close/cancellation barriers and no successful partial receipt |
+| C5 accounting | workflow ledger, efficiency-summary; Desktop metrics/events/history | Invocation IDs persisted before dispatch, replay deduplication, unknown measurements stay unknown, newer failed/cancelled projections supersede old success, built Core fixtures parsed without sibling checkout |
+| C6 evaluation | evaluation/evaluation-corpus and runtime evaluate CLI | Five frozen cases, full/optimized pairs, independent acceptance and defective variants; opt-in real mode is not executed |
+| D1 / D2 controls | effective-config, bridge, settings router and role controls | Selected launch provider applies to all roles (user clarification); frozen provenance; key/label/cwd/env/timeout/policy survive edits and reordering; actual effort capability gates; eight locales |
+| D3 shared evidence and narration | RuntimeExecutionEvidence, AgentRuntimeRuns, narration-model | Repository-attributed check activity, requested versus reported selection, lazy historical sources/output, bounded pagination, replay-safe narration, real Chromium wheel/keyboard tests in Mission and Board |
+
+## Actual validation
+
+- Core full CI test stage: **62 files, 883 passed, 1 skipped**, coverage passed. Its expanded package smoke initially exposed an incorrect standalone import; corrected and package gate passed separately.
+- Desktop full `npm run ci`: **8,367 server tests passed (8 skipped)** and **4,897 client tests passed**; coverage, scripts, compatibility, build and package gates passed.
+- Follow-up changes were revalidated with focused suites rather than repeating every unrelated slow suite: Core workflow/metrics/plan/pipeline group **103 passed**; API/MCP/CLI/Kimi group **71 passed**; final pipeline/plan group **63 passed**; pending-evidence/event/cancellation group **13 passed**. Desktop settings/loader **48 passed**, controls/metrics **43 passed**, final settings/evidence/narration **70 passed**.
+- Core and Desktop typechecks/builds passed after their respective final source edits. The installed Core package checks two CLI entries, a symlinked CLI entry, four provider assemblies, four frozen journals, and a persisted multi-file harness/evidence resolver. Desktop production npm package checks passed again after final UI changes.
+- Final compiled Desktop + isolated npm-installed Core smoke: **passed** failure/correction, configured reviewer escalation, persisted harness, reuse and invalidation, archive approval, fresh nonterminal recertification and zero replay on terminal continuation. The source sibling was not selected.
+- Directory-alias retention regression: **5 passed, 1 optional sibling integration skipped**; the actual installed-package paired smoke above independently covers the distribution path.
+- Actual v4 continuation: passed through original retained runtime. Actual retained current runtime/dependency-closure boot: passed. No saved request/checksum was rewritten to make a fixture pass.
+- Real Chromium short-viewport evidence smoke: **Mission and Board passed** wheel scrolling and keyboard access to long lists and output. All eight locale key sets match.
+- Both changes pass `openspec validate implementation-efficiency --strict`; both repositories pass `git diff --check`.
+
+The full suites preceded small final fixes; the focused checks above are the final-change evidence, not a claim that every full suite was rerun after every edit. Native Windows/macOS release jobs cannot be certified from this local development run. Existing script/parity/package tests passed; native distribution remains a release gate.
+
+## Coherence and explicit limits
+
+- Five graph phases remain; deterministic verification does not call a model. Acceptance and host delivery gates were not relaxed.
+- API metadata is cached by runtime content identity. Transport/model capability probes are deduplicated within a query and refreshed across queries, deliberately avoiding stale installed-provider/configuration evidence.
+- Context and check reuse fail closed when compatibility or identities cannot be proven. Requested models/efforts are never reported as provider-observed values.
+- The offline report measures fixed fixture mechanics, not actual AI billing or production throughput. No paid model benchmark has run, and economic tiers remain opt-in.
+- Local Core artifact identity and downstream handoff are recorded in `implementation-efficiency-artifact.json`. Its source commit is the branch baseline because these development changes are uncommitted; content integrity identifies the actual artifact. Commits made afterwards do not retroactively change that build-time manifest.
+- No npm release or new production pin has been created. The user subsequently authorized new branches, commits and paired pull requests.
+
+## Archive assessment
+
+Local implementation and regression evidence are recorded here. **Release-blocking incomplete tasks remain**: Core 8.2 (native matrix portion), Desktop 5.4 (native matrix portion), 6.1 (published package/pins) and 6.2 (pinned production bundle). Complete those explicit release steps before archive. The unrun paid experiment is a measurement limitation, not an implementation blocker.

package/docs/plans/implementation-efficiency-release.md

@@ -0,0 +1,41 @@
+# Implementation efficiency — operator and release handoff
+
+The paired change lives on `codex/implement-efficiency-runtime` in Desktop and Core. Core owns graph semantics, transport support, checks, receipts and evidence; Desktop owns provider connections, role settings, launch intent, original-runtime retention and delivery. There is no additional verifier model.
+
+## User-facing behavior
+
+- Project role settings remain authoritative. A selected rail/Mission provider applies to **all three roles**; explicit launch model/effort applies to all three as well. Without a selected provider, project role assignments remain authoritative. Provider-specific model defaults apply only where a model is absent. New runs record the resolved selections and origins; resume retains the original request.
+- Effort is optional and is offered from the actual installed model/transport response. An unconfirmed saved value remains visible, and admission rejects it until it is supported or replaced by provider default. Base and optional same-provider escalation models are queried separately. Provider/model edits invalidate displayed compatibility.
+- Advanced efficiency settings control context, review, planning, developer-proposed checks and a one-to-four concurrency limit. They do not fabricate reusable or independent checks. Higher-tier routing is unset by default and cannot create additional attempts.
+- Board and Mission use the same implementation/evidence section. Sources and stdout/stderr load on demand with bounded pagination. Wheel and keyboard scrolling are independently available in the list and output panes.
+- Results identify the repository, check origin and executed/reused/not-run disposition. Requested role configuration is separate from observed values, which stay unknown unless reported. A later failed continuation replaces the current projection even if it lacks optional metrics. Older usage remains historical; Core settlement gates remain authoritative.
+- Removing the worktree or original runtime disables continuation and delivery. Validated historical projections can still show the recorded result; evidence remains readable while its original retained runtime and evidence files exist. Historical success is not proof that a current candidate remains valid.
+
+## Compatibility and recovery
+
+New runs retain their Core package **and production dependency closure**, fingerprinted by contents. Replacing the active package cannot redirect existing jobs. Restore the retained package on integrity failure; do not substitute a similarly versioned runtime. Legacy requests without recorded provenance are intentionally not guessed or rewritten. The v4 compatibility fixture was created with the original runtime and continued through Desktop's actual retainer without changing its frozen request/checksums.
+
+To roll back new-run behavior, select the prior released Core for new admissions. Keep referenced retained runtimes and state. Do not delete `runtime-packages` while saved jobs refer to them. The efficiency controls require a matching capability-enabled Core; old API1 remains usable without requesting new fields.
+
+## Reproducible local checks
+
+```sh
+# Core
+npm run ci
+node bin/specrails-core.mjs runtime evaluate --output /tmp/specrails-efficiency-evaluation
+
+# Desktop, after building both repositories
+npm run ci
+node scripts/smoke-agent-runtime-pair.mjs --core /absolute/path/to/core/dist/agent-runtime/index.js
+node scripts/smoke-runtime-evidence.mjs
+```
+
+The paired smoke uses an isolated deterministic local HTTP provider and real OpenSpec, including a failed check and developer correction, a bounded reviewer escalation, a persisted harness, evidence discovery, conservative reuse, archive approval, fresh verification on nonterminal continuation and zero model replay on terminal reads. Browser smoke uses the actual shared React section, built client CSS, synthetic data and a short viewport; it reads no user database and calls no AI provider.
+
+Core ships generated schema1 summary fixtures for ordinary success, correction, failure, reuse, invalidation, incomplete metrics and unavailable evidence. Desktop keeps an exact test copy so parser tests do not require a sibling checkout. The paired package check compares the shipped fixture when available.
+
+## Release boundary
+
+The working Core package is still version 5.3.0 with a different content identity; it is **not** a newly published 5.3.0. Do not overwrite that release or update Desktop to a guessed version. Publish a new authorized Core version, record its npm integrity, then update `scripts/assemble-bundled-core.lock.json` and `.github/workflows/desktop-release.yml` together. Assemble and smoke that exact production bundle separately from source-build checks. Run the existing Windows and macOS release matrix before distribution.
+
+No real-provider benchmark has been authorized or run. The final offline fixture accepted 5/5 cases in each mode and reduced the fixed correction prompt by 63.4%; this is not a monetary or speed claim. Real model selections, aggregate spend and any decision to enable economic routing remain explicit experiment inputs.

package/docs/plans/implementation-efficiency.md

@@ -0,0 +1,124 @@
+# Implementación de agentes: eficiencia y calidad
+
+Estado: **plan preparado; implementación pendiente**. Fecha: 13 de septiembre de 2026.
+
+La siguiente fase se realizará con **GPT-6 Astra y esfuerzo de razonamiento medium**. Esa elección corresponde al asistente que implementará estos cambios. No asigna Astra a los roles que ejecutan los usuarios dentro de Specrails.
+
+## Objetivo y medida de éxito
+
+Reducir el coste total y el tiempo necesarios para obtener una implementación que cumpla sus criterios de aceptación, conservando o mejorando la detección de defectos. Contarán también los intentos fallidos, reparaciones, reanudaciones y rescates; optimizar únicamente una llamada ocultaría el coste real del trabajo.
+
+No hay ahorro de IA demostrado todavía. La validación local comprobará la mecánica y las regresiones. Un experimento posterior, con modelos y presupuesto explícitos, medirá el ahorro real.
+
+## Documentos que guían la implementación
+
+| Documento | Uso |
+|---|---|
+| [Core: propuesta](../../../specrails-core/openspec/changes/implementation-efficiency/proposal.md) | Alcance y motivación |
+| [Core: diseño](../../../specrails-core/openspec/changes/implementation-efficiency/design.md) | Decisiones del runtime, reanudación, evidencias y evaluación |
+| [Core: contrato compartido](../../../specrails-core/openspec/changes/implementation-efficiency/contracts.md) | Fuente única de campos, versiones, herramientas y semántica entre repositorios |
+| [Core: tareas](../../../specrails-core/openspec/changes/implementation-efficiency/tasks.md) | Bloques C0–C7 y pruebas de aceptación |
+| [Desktop: propuesta](../../openspec/changes/implementation-efficiency/proposal.md) | Alcance del producto |
+| [Desktop: diseño](../../openspec/changes/implementation-efficiency/design.md) | Configuración, logs, historial y compatibilidad |
+| [Desktop: tareas](../../openspec/changes/implementation-efficiency/tasks.md) | Bloques D0–D5 y pruebas de aceptación |
+
+Los requisitos verificables viven en los directorios `specs/` de ambos cambios OpenSpec. Las tareas permanecen sin marcar hasta implementar y comprobar su resultado. Este documento orienta el trabajo; no sustituye ni duplica el contrato de Core.
+
+Base preparada desde `main` después de hacer pull:
+
+- Core: `2427141b`.
+- Desktop: `d8d8597a`.
+- Rama de ambos: `codex/implementation-efficiency`.
+
+Antes de implementar se revisará si main ha avanzado, conservando estos documentos y cualquier trabajo local. No se reinicia desde cero ni se vuelven a implementar correcciones que ya están en main.
+
+## Decisiones de producto y arquitectura
+
+El flujo seguirá siendo **arquitecto → developer → verificación automática → reviewer → archivo**. La verificación ejecuta código y comandos; el reviewer interpreta si el cambio satisface el ticket y detecta problemas de diseño. Un test fallido vuelve al developer antes de gastar otra llamada del reviewer. No se añade un agente verifier.
+
+El arquitecto seguirá utilizando el procedimiento oficial de OpenSpec para preparar el cambio, y el developer ejecutará OpenSpec apply. Se conservan los procedimientos y herramientas oficiales para cada proveedor. La optimización no reemplaza OpenSpec por plantillas simuladas ni permite eliminar sus obligaciones desde prompts personalizados.
+
+| Cambio | Cómo contribuye | Condición que protege la calidad |
+|---|---|---|
+| Contexto compartido por repositorio | Evita reenviar datos sin cambios en continuaciones reales | Primera llamada y proveedores sin continuidad reciben contexto completo; fuentes eliminadas se revocan explícitamente |
+| Revisión incremental | Orienta al reviewer a las correcciones desde su revisión anterior | Debe recertificar todos los criterios; cambios transversales fuerzan contexto completo |
+| Plan proporcional | Reduce explicación redundante en cambios locales claros | Mismos artefactos oficiales; contratos públicos, seguridad, migraciones y varios repos exigen planificación completa |
+| Escalado configurado | Permite reservar un modelo superior para intentos que lo necesitan | Un solo tier, mismo proveedor, sin intentos adicionales ni selección automática por precio |
+| Checks propuestos por developer | Convierte pruebas útiles en evidencias reproducibles | Se añaden al mínimo obligatorio; no pueden rebajarlo ni autodeclararse aprobados |
+| Harness persistente | Permite revisar y repetir pruebas incluso sin package.json | Core guarda fuente, ejecución y hashes fuera de la entrega; agentes leen por herramientas acotadas |
+| Reutilización de verificaciones | Evita ejecutar de nuevo pruebas cuyo resultado sigue siendo aplicable | Desactivada por defecto; requiere garantías explícitas del host e identidad completa |
+| Paralelismo de checks | Reduce tiempo en repositorios independientes | Concurrencia 1 por defecto, máximo 4, grupos declarados y barreras sin reordenar el plan |
+| Evidencias y rutas visibles | Permite entender qué se hizo, por qué y cuánto costó | Misma vista en misión/board; desconocido no se convierte en cero ni en éxito |
+
+## Escalado concreto
+
+Los modelos base continúan siendo los configurados por el usuario. El escalado es opcional y queda vacío por defecto.
+
+- Arquitecto: el único deepen permitido puede utilizar el modelo superior.
+- Developer: tras dos candidatos fallidos, contando el inicial, el siguiente intento ya autorizado utiliza el superior. Con tres intentos, puede escalar en el tercero. Con dos, termina sin inventar un tercero.
+- Reviewer: rechazar una implementación no escala el modelo. El tier superior puede sustituir su única reparación de respuesta inválida.
+- Autenticación, falta de permisos/capacidad, cancelación, integridad o presupuesto agotado no provocan escalado.
+
+Cambiar modelo o esfuerzo abre una sesión compatible con contexto completo. La decisión queda persistida antes de invocar al proveedor y se conserva al reanudar. Los límites lógicos de una reparación y un deepen no dependen de que el proveedor permita continuar una sesión; una llamada sin sesión recibe también el resultado anterior y su diagnóstico, acotados.
+
+## Responsabilidad por repositorio
+
+Core implementa la política de ejecución, capacidades del transporte, contexto, sesiones, rutas, checks, evidencias y validez. Desktop configura, presenta y conserva proyecciones; no decide por su cuenta que una prueba sigue siendo válida.
+
+Se corregirá la precedencia actual de selección: una asignación explícita por rol prevalece sobre defaults incidentales del lanzamiento. Aclaración del usuario (2026-09-13): el proveedor seleccionado para un lanzamiento afecta a arquitecto, developer y reviewer, con procedencia registrada; un modelo o esfuerzo explícito del lanzamiento se aplica igualmente a los tres. Reanudar siempre usa la configuración congelada de esa ejecución.
+
+Desktop ampliará las filas de roles existentes con esfuerzo compatible y escalado opcional. También conservará todos los campos de los checks al editarlos, incluidos cwd, entorno, timeout y política. No se duplicarán secciones por proveedor ni se trasladarán de nuevo las conexiones globales o los prompts que ya tienen su ubicación.
+
+## Orden de trabajo
+
+| Etapa | Bloques | Entregable y comprobación para avanzar |
+|---|---|---|
+| 1. Compatibilidad y contratos | C0 + D0 | Schema y capacidades probados, runtime original retenido, fixture real v4 que continúa sin reescribir checkpoints |
+| 2. Contexto y configuración | C1 + D1 | Menos contexto repetido con continuidad real, aceptación íntegra y configuración por rol preservada en todos los lanzamientos |
+| 3. Rutas y controles | C2 + D2 | Escalado determinista, esfuerzo soportado, límites y sesión correctos; controles claros |
+| 4. Evidencia reproducible | C3 | Plan aditivo y harness persistente; reviewer API/MCP puede leer fuentes y páginas de logs |
+| 5. Verificación eficiente | C4 | Reutilización conservadora, grupos paralelos declarados y cancelación que espera a los procesos |
+| 6. Observabilidad e interfaz | C5 + D3 | Métricas sin duplicación y mismo panel desplazable en misión/board, también tras limpieza |
+| 7. Evaluación e integración | C6 + C7 + D4 | Corpus offline, defectos sembrados detectados, pruebas del paquete real y del par Desktop/Core |
+| 8. Preparación de release | D5, tras paquete Core disponible | Pins exactos coherentes, bundle de producción validado, reanudaciones antiguas preservadas |
+
+Se puede trabajar en paralelo en Core y Desktop cuando el contrato correspondiente esté fijado. No se delegarán cambios simultáneos en los mismos archivos. Cada bloque terminará con pruebas focalizadas; la batería completa se ejecutará sobre el resultado integrado, evitando repeticiones costosas sin cambios que las justifiquen.
+
+## Casos que tienen que quedar demostrados
+
+1. Codex/Claude/Gemini con continuidad comprobada reciben el seguimiento adecuado; API y Kimi ACP sin continuidad reciben contexto completo. Un transporte que ignora resume no puede ejecutar un prompt incompleto.
+2. Varios repositorios mantienen identidad y contexto legible. La eliminación de un AGENTS.md no deja sus instrucciones presentadas como vigentes.
+3. Corregir una parte del cambio no hereda aprobaciones antiguas. Alterar scope congelado bloquea aunque se envíe contexto completo.
+4. Un proyecto estático sin manifiesto puede producir un harness que el reviewer inspecciona y Core conserva. Una declaración inválida no escribe fuentes ni lanza comandos.
+5. Cambiar pruebas, entorno, fuente o dependencias invalida la evidencia aplicable. Un éxito anterior no oculta un fallo posterior. Cambiar node_modules con el mismo lockfile tampoco permite reutilización.
+6. Reanudar un workflow no terminado no evita la política de checks: antes de reviewer/archive se repiten los no reutilizables y se recertifica la autorización. Leer un resultado ya archivado no ejecuta nada de nuevo.
+7. Un check paralelo fallido detiene la cola y espera la terminación de los procesos activos. El timeout respeta el tiempo restante del workflow.
+8. Un job que falla y luego termina muestra el resultado actual y conserva el fallo histórico sin duplicar coste. Una continuación posterior sin métricas no hereda el éxito antiguo como actual.
+9. La limpieza del worktree conserva el resumen histórico. Si las evidencias detalladas desaparecen, la UI lo explica sin inventarlas ni permitir una continuación incompatible.
+10. El paquete publicado y el bundle soportan lo mismo que se validó en desarrollo. Los tests no dependen de tener un checkout hermano para no ser omitidos.
+
+## Evaluación del ahorro
+
+Habrá cinco casos congelados: lógica estática tipo Tetris, mejora local con tests existentes, cambio entre repositorios, verificación que falla y corrección tras rechazo del reviewer. Cada caso tendrá aceptación independiente y variantes defectuosas que el evaluador debe rechazar.
+
+La prueba offline exigirá reducir al menos un 40% el prompt de corrección de un caso fijo con contexto largo, sin añadir invocaciones ni perder requisitos. Eso demuestra una reducción de payload en ese caso, no un 40% de ahorro real de IA.
+
+El experimento con proveedores reales separará dos comparaciones: mismos modelos para medir la orquestación, y modelos configurados con escalado para medir la política. Se parte de tres réplicas emparejadas por caso, con orden aleatorio, sesiones/workspaces nuevos y estado de caché registrado.
+
+Objetivo experimental: al menos un 20% menos de coste agregado por implementación aceptada independientemente, menor mediana de tiempo activo, sin caída observada de aceptación ni nuevos defectos altos/críticos. Si faltan costes, no hay resultados aceptados o la muestra no permite concluir, se declara inconcluso. No se cambia el criterio de aceptación para conseguir una cifra favorable.
+
+Implementar el runner offline y el modo opt-in forma parte del alcance. **Ejecutar el experimento de pago requiere elegir los modelos y aportar un presupuesto explícito**; no se lanzará durante esta preparación ni por defecto en CI.
+
+## Instrucción para iniciar la siguiente fase
+
+Configurar el asistente de implementación como **GPT-6 Astra / medium** y continuar con esta instrucción:
+
+> Implementa los cambios OpenSpec `implementation-efficiency` en specrails-core y specrails-desktop siguiendo el plan de `docs/plans/implementation-efficiency.md`. Empieza por C0 + D0 y respeta el contrato compartido de Core. Usa OpenSpec apply, conserva los cambios locales y la rama preparada, implementa por bloques verificables y marca tareas solo tras comprobarlas. Mantén OpenSpec oficial y los cinco pasos actuales; no añadas otro agente verifier, no debilites aceptación ni inventes soporte de proveedores. Completa código, pruebas offline e integración local. Conserva la compatibilidad de las ejecuciones guardadas y separa el paquete publicado/bundle de las pruebas con fuente local. No ejecutes benchmarks con proveedores de pago sin modelos y presupuesto explícitos. Reporta cualquier gate de release que dependa de publicar primero Core; no lo marques como probado con un bundle de desarrollo.
+
+El cambio de modelo se realiza al iniciar esa fase; escribir esta instrucción no modifica el modelo de la conversación ni el de los roles de Specrails.
+
+## Comprobación de esta preparación
+
+Ambos cambios pasan `openspec validate implementation-efficiency --strict --json`, sin incidencias. OpenSpec reconoce propuesta, diseño, specs y tareas completos. Hay 44 tareas pendientes en Core y 30 en Desktop; no se han marcado como implementadas.
+
+Se revisaron por separado ejecución por roles, verificación y Desktop, y se incorporaron las correcciones al contrato y a los escenarios. Los enlaces locales y el formato de los 15 archivos de planificación están comprobados. Los cambios de esta preparación son únicamente documentación; las pruebas de producto y el benchmark pertenecen a la siguiente fase.