v0.8.0

Linmas 0.8.0

Security and reliability

Linmas 0.8.0 hardens the boundaries around the review and release workflow:

• filesystem containment, uninstall planning, and cleanup preserve ownership
  and fail closed instead of falling back to unsafe lexical path mutation;
• Proof Chain bundles bind every recorded finding to the validated source and
  decision receipt;
• human-review decisions bind to the process-local review reference and exact
  capsule digest, so a caller cannot substitute an unrelated result;
• credentials, review input, raw provider output, and stderr remain redacted
  at the public error boundary;
• provider failures use an explicit taxonomy with transmission state and
  retryability;
• CLI argument, package-entrypoint, and package-surface validation are strict;
  and
• the Codex isolated launch and filesystem checks preserve their
  platform-specific security contract.

These controls improve reliability and evidence integrity without turning a
policy result or model response into automatic approval.

Breaking MCP request contract

The human-review decision flow no longer accepts a caller-supplied
review_result. In 0.8.0, linmas_review_execute returns a bound
reviewReference containing a process-local handle and the SHA-256
capsuleDigest. Pass those values to linmas_review_decide as
review_handle and capsule_digest. The reference must be used by the same
MCP server process and the digest must match exactly.

Before 0.8.0 (caller-supplied result):

{
  "workspace_root": "/work/linmas-demo",
  "review_result": { "schemaVersion": 1, "findings": [] },
  "decision": { "disposition": "manual_review_required" }
}

After 0.8.0 (bound reference returned by execute, then supplied to decide):

{
  "reviewReference": {
    "handle": "demo-review-handle",
    "capsuleDigest": "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef"
  }
}

{
  "workspace_root": "/work/linmas-demo",
  "review_handle": "demo-review-handle",
  "capsule_digest": "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef",
  "decision": { "disposition": "manual_review_required" }
}

The handle and digest above are safe synthetic values only. A real caller must
use the values returned by its own linmas_review_execute call. Human review,
transmission consent, and write consent remain separate gates.

Windows contract

• The deterministic/offline workflow and CLI remain supported on Windows.
• Codex isolated launch preparation is supported on Windows with the same
  authenticated-source safeguards.
• Destructive uninstall and cleanup intentionally fail closed on Windows.
• The repository-defined diagnostic is
  SAFE_FILESYSTEM_OPERATION_UNAVAILABLE because Node.js does not provide the
  handle-relative mutation primitive needed to preserve Linmas's
  anti-substitution invariant there.
• Dry-run uninstall remains available and does not mutate data.

0.8.0 does not claim native destructive Windows parity. Use a supported POSIX
environment for destructive cleanup or wait for a separately reviewed native
implementation; do not replace the guard with a path-based fallback.

Upgrade: 0.7.0 → 0.8.0

For the npm CLI:

npm install --global linmas@0.8.0
npx --yes linmas@0.8.0 list

Codex stores a marketplace source and its ref separately. A moving ref such as
main can be refreshed; an immutable ref such as v0.7.0 does not move when
refreshed. marketplace upgrade never repins an existing source, and a second
marketplace add with a different ref is rejected until the old source is
removed. Verify both the configured ref and the installed plugin version before
starting a new task.

A. Existing moving-ref marketplace

If the configured marketplace follows main (or another moving branch), refresh
that same source and then install or re-enable the plugin:

codex plugin marketplace upgrade linmas
codex plugin add linmas@linmas
codex plugin marketplace list --json
codex plugin list --json

The marketplace entry in the configured Codex config.toml should still show
the intended moving ref, and the plugin list should report the installed
release version. marketplace upgrade alone does not update an already cached
plugin. Restart the Codex desktop/app-server and start a fresh task afterward.

B. Existing marketplace pinned to v0.7.0

When codex plugin list --json shows the installed 0.7.0 plugin and the
marketplace is pinned to v0.7.0, remove the installed plugin first, remove the
old marketplace source, and then add the source again with the new immutable
ref:

codex plugin remove linmas@linmas
codex plugin marketplace remove linmas
codex plugin marketplace add TanKimGwan/linmas --ref v0.8.0
codex plugin add linmas@linmas
codex plugin marketplace list --json
codex plugin list --json

Confirm that the [marketplaces.linmas] section in the configured Codex
config.toml contains ref = "v0.8.0" and that the installed
linmas@linmas entry reports version 0.8.0. Do not treat a successful
marketplace upgrade linmas as proof that a pinned ref changed. Restart the
Codex desktop/app-server and start a fresh task after the verification.

Update MCP callers to the bound review_handle/capsule_digest contract before
using linmas_review_decide with 0.8.0.

Rollback

If a release rollback is required, use a reviewed Git revert or pin the npm
package and Codex marketplace to 0.7.0 / v0.7.0, then restart the
Codex desktop/app-server and verify the tools from a fresh task. Do not use a
destructive reset, mix the 0.7.0 caller contract with a 0.8.0 server, or npm
unpublish a release.