RAME Code 0.3.0

CHANGELOG.md

@@ -4,6 +4,47 @@ All notable changes to RAME Code are documented in this file.
 
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project follows [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [Unreleased]
+
+## [0.3.0] - 2026-11-11
+
+### Added
+
+- Long Missions can run bounded, resumable work with persistent jobs, progress evidence, host-observed measurements and multi-phase Programmes. A renewable phase lease prevents two VS Code windows from directing the same Programme phase at once and safely permits recovery after an expired owner.
+- Autonomy controls now separate approval policy from command isolation. Full Access can remove routine prompts within its explicit grant, while protected verification always keeps its own mandatory boundary. Long jobs, bounded installs and local process limits have dedicated controls and records.
+- Reinforced functional cases and differential references run one input at a time. Expected answers, future inputs and host records remain outside the evaluated process, and the host performs the comparison.
+- LM Studio can offer a confirmed reload with a larger context after a short-context refusal. Local server errors retain the server's bounded message, distinguish setup failures from an unreachable server, and keep the selected model visible when discovery temporarily omits it.
+
+### Changed
+
+- The user guides (English and Spanish) explain every option of the Mission authorization card, and describe test isolation by level instead of saying that test scripts always run with the user's permissions.
+- Full Access is now the top level of the chat's permission selector (Ask → Safe auto → Workspace full → Full Access). Choosing it asks for its usual confirmation with the parts, validity and environment chosen in Autonomy & Permissions; choosing a lower level turns it off at once. It never raises the profile underneath, so it covers only the parts you granted; when it expires, a notice shows the level you are back to. By default it lasts until you turn it off (no expiry); 1 hour to 30 days remain available in Autonomy & Permissions. The Meta and web pre-authorizations keep their own hours.
+
+### Fixed
+
+- Measured acceptance distinguishes host-observed metrics (`wall_ms`, `exit_code`) from values declared by the frozen project check (for example `p95_ms`, `errors`) through a private per-run channel. Every criterion and result states its class and warns that malicious code in the same process can alter project-declared figures; arbitrary project JSON and printed values have no authority.
+- Protected verification uses an exact filesystem view and closed network on supported Linux, independently of Full Access or the terminal's `Total` setting. Without protected isolation, verification runs with a warning and results are marked unprotected («sin aislamiento protegido, la verificación se ejecuta con un aviso y los resultados se marcan como no protegidos»).
+- Node 24 can load the host-owned case runner inside the protected view without granting access to the surrounding extension tree.
+- Local HTTP 400 responses caused by an undersized LM Studio context now explain the required action instead of looking like a generic runtime failure. The same refusal sent inside a streamed reply (HTTP 200, as LM Studio sends it to Agent) is recognized too: the card says the request does not fit the model's context, offers the reload, and no longer reads «Glimmer answered». When LM Studio reports the context the model is loaded with, RAME now refuses a request that does not fit before sending it: LM Studio would otherwise retry by itself with the conversation cut to fit and stream the answer to the cut conversation. Turning cloud escalation on (or saving a key) after a local failure now offers «Run this request with Spark» on the same card; it still waits for approval. Rows of buttons have space above and below the text around them. The Mission's final report states the isolation each test really ran with, as the host noted it at run time (for example Project for the project's tests and the protected verifier for a frozen acceptance check), instead of a fixed «No sandbox» note that contradicted the host record. In «Web access for this Mission», the checkbox and each limit now sit on their own line. Expired Spark offers disappear instead of leaving an unusable action.
+
+### Known limitations
+
+- Protected verification requires Linux with Landlock ABI 4 or newer and `libseccomp.so.2`. On Windows, macOS, older/no Landlock or missing libseccomp, the check runs without isolation, with a prominent warning and an unprotected label in authorization, progress, result and evidence. Equivalent protected isolation on Windows and macOS remains the goal.
+- Evaluated code necessarily sees its current input and can alter its own behavior or internal clocks. Only the host's external wall time and exit code are official measurements; those observations do not by themselves prove functional quality.
+- Hidden cases provide operating-system-enforced separation of expected answers, future inputs and host evidence, but incomplete cases remain incomplete. Differential verification trusts the frozen original as its behavioral reference, so a defect shared with that original can pass.
+- Programme ownership coordinates VS Code processes that share the same host storage. It is not a distributed lock across different computers or replicated stores.
+- Local model behavior still depends on the server, model and loaded context. The LM Studio short-context path was checked with a real LM Studio server (refusal before sending at 4096, confirmed reload to 32768, then the same request completed). A server that cuts the conversation silently and does not report its loaded context cannot be detected yet; in LM Studio, set «Context Overflow» to «Stop at limit».
+
+### Security
+
+- Official measured acceptance and Programme baselines classify host observations separately from project declarations received only through the frozen check's private per-run channel. Existing Missions and Programmes that use `p95_ms`, `errors` or other valid project metrics continue without re-authorization. Same-process manipulation remains explicitly possible and visible.
+- Protected and reinforced verifiers use the mandatory allowlisted filesystem view whenever it is available. Landlock confines reads and writes; seccomp denies TCP, UDP and Unix sockets plus cross-process inspection; recognized project secret files are excluded. Each functional/reference input runs fresh. Unsupported systems continue unprotected with the warning and label; Full Access/Total never weakens protection when available, and a protected→unprotected transition is recorded rather than stopping silently.
+- Programme phases now use a renewable, machine-wide lease and monotonically increasing fencing token. Concurrent VS Code processes cannot start the same phase twice; expiry permits recovery, while late updates and releases from the previous owner are rejected. The lock is per machine, not distributed across computers.
+
+### Migration
+
+- No re-authorization is required for stored measured acceptance or Programmes naming valid project-declared metrics such as `p95_ms` or `errors`. Protected isolation currently requires Linux with Landlock ABI 4+ and `libseccomp`; elsewhere verification continues with the unprotected warning and label.
+
 ## [0.2.0] - 2026-11-04
 
 Experimental preview release. It introduces a modularized core, governed project memory, autonomous Missions, acceptance and causal verification, and a strict separation between Meta Advisory and Delegated execution. Modularization is not complete: the presentation assets `media/main.js` and `media/i18n.js` remain inherited exceptions.
@@ -191,6 +232,7 @@ The integrated hackathon baseline. It was not yet modular: most of the extension
 - The local audit is bounded but is not tamper-proof.
 - Project test scripts run with the operating-system permissions of VS Code.
 
-[Unreleased]: https://github.com/caimari/rame-code/compare/v0.2.0...HEAD
+[Unreleased]: https://github.com/caimari/rame-code/compare/v0.3.0...HEAD
+[0.3.0]: https://github.com/caimari/rame-code/releases/tag/v0.3.0
 [0.2.0]: https://github.com/caimari/rame-code/releases/tag/v0.2.0
 [0.1.0]: https://github.com/caimari/rame-code/releases/tag/v0.1.0

README.es.md

@@ -202,7 +202,9 @@ Una Mission se verifica en uno de tres niveles, y el nivel queda escrito en sus
 
 - **Convencional (Mission estándar).** Una prueba permitida del proyecto pasa después del último cambio.
 - **Protegido (Mission verificada).** El host ejecuta él mismo la comprobación de aceptación congelada por el usuario, la observa hasta el final y exige que salga con 0. Antes de autorizar, RAME la ejecuta una vez bajo su propia traza y la analiza para encontrar los procesos que ejecuta y los módulos y ficheros que usa, y guarda ese alcance en la autorización junto con una huella de cada fichero del proyecto. Se congelan los auxiliares, los datos y los ficheros de prueba que ejecuta la orden, y se sellan las carpetas de pruebas que ejecuta o lista. Lo que vaya a quedar modificable se muestra en un diálogo modal para que lo confirmes. Una comprobación cuyas dependencias no se pueden determinar no se protege: RAME ofrece la verificación convencional como alternativa. Se rechazan las escrituras que cambiarían un fichero congelado, una carpeta sellada o cómo los resuelve Node. Después de cada ejecución del host, RAME compara todo el proyecto con su propio registro (el SHA-256 de los bytes de cada fichero): un cambio fuera del alcance autorizado nunca cuenta como aprobado. En Linux y macOS, los tiempos de cambio del núcleo muestran además un fichero cambiado y restaurado durante la ejecución; en Windows solo se afirma el estado al inicio y al final, y el informe lo dice.
-- **Reforzado.** Una comprobación protegida más un fichero `*.rame-cases.json` congelado. El ejecutor de casos de RAME llama al código bajo prueba en un proceso aparte y el host compara él mismo cada resultado; los valores esperados no se envían a ese proceso y quedan ocultos para las herramientas del agente. Un `process.exit(0)` prematuro o una salida falsificada no pueden aprobar. Esto no hace secretos los valores esperados: no hay sandbox, y el código que se ejecuta con tus permisos puede encontrar el fichero en disco. En el nivel protegido, una comprobación es tan fiable como su código de salida: el código bajo prueba que se ejecuta en su mismo proceso puede terminarla antes de tiempo.
+- **Reforzado.** Una comprobación protegida más un fichero `*.rame-cases.json` congelado. En Linux compatible, cada caso se ejecuta en un proceso nuevo confinado con Landlock/seccomp que solo recibe esa entrada y el código autorizado: no puede leer el fichero de casos, entradas futuras, valores esperados, registros del host, proyectos vecinos ni secretos reconocibles del proyecto, y no puede abrir sockets TCP, UDP o Unix. El host compara cada resultado, por lo que un `process.exit(0)` prematuro o una salida falsificada no pueden aprobar. La verificación protegida falla de forma cerrada si esta frontera no está disponible y no depende de los permisos de Agent o terminal: Full Access y Total no pueden debilitarla. Unos casos débiles todavía pueden ser insuficientes. En el nivel protegido, una comprobación sigue siendo tan fiable como su código de salida.
+
+La aceptación medida y los **Programmes** distinguen métricas observadas por el host (`wall_ms`, `exit_code`) de métricas declaradas por el proyecto como `p95_ms` y `errors`. Las declaraciones solo cuentan mediante el canal privado de cada ejecución de la comprobación congelada y se etiquetan con menor confianza: código malicioso en ese proceso puede alterarlas. Los registros antiguos siguen siendo válidos sin nueva autorización. Sin aislamiento protegido, la verificación se ejecuta con un aviso y los resultados se marcan como no protegidos; el objetivo sigue siendo un aislamiento equivalente en Windows y macOS.
 
 Cuando RAME no puede demostrar que se cumplieron las condiciones autorizadas, el resultado es **no verificable**: nunca es un aprobado, la Mission se bloquea con el motivo y la aceptación autorizada no cambia.
 
@@ -212,7 +214,7 @@ Estas garantías se ponen a prueba con una batería de sabotaje **SIMULATED** (`
 - un auxiliar que el usuario confirmó como modificable;
 - `process.exit(0)` en el nivel protegido.
 
-La traza de RAME se ejecuta junto al código bajo prueba y se puede falsificar, así que solo es una ayuda para descubrir; lo que decide es lo que comprueba el propio host (los hashes y la huella del proyecto). Separar procesos no es un sandbox. Si VS Code se cierra o se recarga durante una Mission, la ventana antigua no inicia ni escribe nada más. Consulta [Cómo verificarlo](docs/VERIFICATION.es.md). Los resultados se etiquetan como **REAL**, **SIMULATED** o **RECORDED**, y una simulación nunca se presenta como una ejecución real con Glimmer o con Meta.
+La traza de RAME se ejecuta junto al código bajo prueba y se puede falsificar, así que solo es una ayuda para descubrir; deciden las observaciones del host, los hashes, la huella del proyecto y el verificador protegido. Si VS Code se cierra o se recarga durante una Mission, la ventana antigua no inicia ni escribe nada más. Consulta [Cómo verificarlo](docs/VERIFICATION.es.md). Los resultados se etiquetan como **REAL**, **SIMULATED** o **RECORDED**, y una simulación nunca se presenta como una ejecución real con Glimmer o con Meta.
 
 ## Evidencia del modelo (v0.2.0)
 

README.md

@@ -202,7 +202,9 @@ A Mission is verified at one of three levels, and the level is written in its ho
 
 - **Conventional (Standard Mission).** An allowlisted project test passes after the last change.
 - **Protected (Verified Mission).** The host itself runs the user's frozen acceptance check, observes it to its end and requires exit 0. Before authorizing, RAME runs the check once under its own trace and analyses it, to find the processes it runs and the modules and files it uses, and records that scope in the grant together with a fingerprint of every project file. Test helpers, data and the test files the command runs are frozen, and test folders it runs or lists are sealed. Anything that would stay writable is shown in a modal dialog for you to confirm. A check whose dependencies cannot be determined is not protected: RAME offers conventional verification instead. Writes that would change a frozen file, a sealed folder or how Node resolves them are refused. After every host run, RAME compares the whole project with its own record (the SHA-256 of every file's bytes): a change outside the authorized scope is never counted as a pass. On Linux and macOS, kernel change times also show a file changed and restored during the run; on Windows only the start and end state is claimed, and the report says so.
-- **Reinforced.** A protected check plus a frozen `*.rame-cases.json` file. RAME's case runner calls the code under test in a separate process and the host compares every result itself; the expected values are not sent to that process and are hidden from the agent's tools. An early `process.exit(0)` or forged output cannot pass. This does not make the expected values secret: there is no sandbox, and code running with your permissions can find the file on disk. At the protected level, a check is only as trustworthy as its exit code: code under test that runs in the check's own process can end it early.
+- **Reinforced.** A protected check plus a frozen `*.rame-cases.json` file. On supported Linux, every case runs in a fresh Landlock/seccomp-confined process. If that boundary is unavailable, verification still runs, shows the unprotected warning and labels every result accordingly; code under test could then read hidden cases and alter results. Full Access and Total cannot weaken isolation when it is available. Equivalent isolation on Windows and macOS remains the goal.
+
+Measured acceptance and phased **Programmes** distinguish host-observed metrics (`wall_ms`, `exit_code`) from project-declared metrics such as `p95_ms` and `errors`. Declarations count only through the frozen check's private per-run channel and are labelled lower-trust because malicious code in that process can alter them; arbitrary files, output and JSON do not count. Existing records remain valid without re-authorization.
 
 When RAME cannot show that the authorized conditions held, the result is **not verifiable**: never a pass, the Mission is blocked with the reason and the authorized acceptance stays unchanged.
 
@@ -212,7 +214,7 @@ These guarantees are exercised by a **SIMULATED** sabotage battery (`npm run dem
 - a helper the user confirmed as writable;
 - `process.exit(0)` at the protected level.
 
-RAME's trace runs beside the code under test and can be forged, so it is only a discovery aid; what the host checks itself (hashes and the project fingerprint) decides. Process separation is not a sandbox. When VS Code closes or reloads during a Mission, the old window starts nothing and writes nothing more. See [How to verify it](docs/VERIFICATION.md). Results are labelled **REAL**, **SIMULATED** or **RECORDED**, and a simulation is never presented as a real Glimmer or Meta run.
+RAME's trace runs beside the code under test and can be forged, so it is only a discovery aid; what the host checks itself (host observations, hashes, the project fingerprint and the protected verifier) decides. When VS Code closes or reloads during a Mission, the old window starts nothing and writes nothing more. See [How to verify it](docs/VERIFICATION.md). Results are labelled **REAL**, **SIMULATED** or **RECORDED**, and a simulation is never presented as a real Glimmer or Meta run.
 
 ## Model evidence (v0.2.0)
 

docs/JUDGES.es.md

@@ -48,7 +48,7 @@ El paquete público es una **extracción RECORDED de una ejecución REAL**. Se v
 - Fue supervisada y no utilizó Meta Model API.
 - El resumen del host dice 36 inferencias locales respondidas y la vista final contiene 37; se conservan ambas cifras.
 - En Windows se compara el estado inicial y final; no se afirma detectar cambios temporales deshechos.
-- Una comprobación puede ser débil. El ejecutor reforzado reduce algunos ataques, pero no vuelve secretos los valores esperados.
+- Una comprobación puede ser débil. En Linux compatible, el verificador reforzado oculta los valores esperados, entrega una entrada cada vez, deniega sockets y confina lecturas. En hosts no compatibles se ejecuta con aviso y etiqueta de «sin aislamiento»; el código evaluado podría leer casos ocultos y alterar resultados. El aislamiento equivalente en Windows y macOS sigue siendo un objetivo.
 - Chat directo con Meta tiene tres respuestas reales registradas. La matriz completa de privacidad y las rutas Advisory/Delegated/Agent cloud con herramientas siguen probadas con API simulada, no validadas de extremo a extremo contra el servicio real.
 - Es una release preview experimental v0.2.0, no una frontera de seguridad para producción.
 

docs/JUDGES.md

@@ -48,7 +48,7 @@ The public Mission bundle is a **RECORDED extraction from a REAL run**. Its sour
 - The real run required human supervision and did not use Meta Model API.
 - The real run's host summary says 36 answered local inferences while its final evidence view contains 37. Both counts are preserved.
 - On Windows, acceptance integrity compares start and end state; temporary change-and-restore detection is not claimed.
-- A check can be weak. The reinforced case runner narrows some attacks but does not make expected values secret.
+- A check can be weak. On supported Linux the reinforced verifier hides expected values, gives one input at a time, denies sockets and confines reads. On unsupported hosts it runs with a prominent unprotected warning and label; evaluated code could then read hidden cases and alter results. Equivalent Windows/macOS isolation remains a goal.
 - Direct Meta Chat has three recorded real responses. The complete privacy matrix and Advisory/Delegated/cloud-Agent tool paths remain tested against a simulated API rather than validated end to end against the live service.
 - This is a v0.2.0 experimental preview release, not a production security boundary.