Skip to content

Releases: XAGI-Lab/melra

v0.3.0-alpha.18

v0.3.0-alpha.18 Pre-release
Pre-release

Choose a tag to compare

@github-actions github-actions released this 22 Oct 15:26
97d6ca5

Added

  • A semantic question can be answered (#54). The twelfth MCP tool, melra_task_judge, takes a waiting task's taskId and one of its judgementIds, a verdict of yes, no or cannot_tell, an optional rationale for people (stored redacted, never read by MELRA) and a required identity. A judge that declares the task's own principal, or a non-human link it acts for, is refused (semantic_judge_is_actor); the person the work was for may judge it. The check compares claims, so it stops one agent loop grading itself, not a harness that declares someone else. In enforced mode, and on a task that ran enforced, a verdict sent over MCP is refused (judgement_in_band_refused), and an operator answers with melra judge <task-id> --judgement <id> --verdict yes|no|cannot_tell [--rationale <text>], recorded as cli:<MELRA_APPROVER>: out_of_band when both that command and the task's run are enforced, and in_band when neither is or only the command is; a developer-mode melra judge on a task that ran enforced is refused (judgement_in_band_refused). Each answer is recorded once as judgedBy (verdict, judge, channel, time, rationale) on task.judgements and on the certificate's semantic item. A verdict writes only the task and, when it settles it, its certificate: no receipt, grant draw, breaker record or idempotency commit. The TypeScript SDK gains judge().

Changed

  • Twelve MCP tools instead of eleven, seven of them task tools. melra conformance still requires the eleven kernel tools, so a server without the judge tool passes. A yes on every question makes the task verified_success. The first no ends it partial, which now also means "a semantic question was answered no" (error semantic_judgement_no); a change answered no stays in place, and fixing it takes a new plan. cannot_tell ends a change recovery_required and a read partial (semantic_judgement_cannot_tell). A task whose questions expire keeps any yes already given on its certificate. Nothing breaks: every new field is optional, there is no migration, and a task left waiting by 0.3.0-alpha.17 can be answered after an upgrade until it expires. An alpha.17 runtime sharing the home still settles an expired wait as alpha.17 did, so a yes given on one of several questions before expiry stays in task.judgements but not on the certificate; rerun melra setup to move pinned clients up. (#54)

  • A governed action commits to SQLite six times instead of nine, and runs 4-8% faster on a Mac (M4, medians of 30 rounds interleaved with 0.3.0-alpha.17): file.write 2.19 ms to 2.10 ms, file.read 1.10 ms to 1.01 ms, an HTTP GET 1.14 ms to 1.07 ms, and a ten-step workflow 18.4 ms to 17.4 ms (151 commits to 111). Everything that records a task's outcome after verification (its idempotency commit, its grant's draw, its receipt, its status and its certificate) commits in one transaction, so a crash leaves the task as it was during verification or finished, never with part of its outcome written. A task is still recorded before its adapter runs, and the adapter's result before it is verified. The database schema is unchanged, so a client melra setup pinned to 0.3.0-alpha.17 can keep running on the same home beside this release. (#351)

Fixed

  • The web console tells an expired compensation step of a failed run to melra workflow advance <workflow-id>, where it pointed at melra workflow inspect: that advance cancels the expired challenge and asks again. A forward step of a failed run is still pointed at inspect, since an advance there unwinds the run and never offers the step again. /api/tasks/<id>/approval-state adds compensation: true when the run names the task from a compensation node, which WorkflowController's new read-only isCompensation(workflowId, taskId) tells from the run's sealed definition. (#303)

v0.3.0-alpha.17

v0.3.0-alpha.17 Pre-release
Pre-release

Choose a tag to compare

@github-actions github-actions released this 22 Oct 00:28
c6cd2c6

Changed

  • A workflow checkpoint node is recorded in the same commit as the advance that reached it, instead of in a commit of its own, so a workflow that checkpoints after each step runs about 9% faster. (#354)

  • Secret redaction runs three to six times faster, so recording a large terminal output costs much less. The password-name, token-name and URL-userinfo patterns in SECRET_PATTERNS now start each match at their keyword instead of trying every position. What they redact, and the redaction kinds a record lists, are unchanged byte for byte. (#353)

  • Governed file and terminal actions spend less time keeping MELRA's own files out of reach: a file.write verified by file_hash takes 1.5 ms instead of 2.0 ms on a Mac, and a terminal command's checks about 0.7 ms less. The identities of the reserved files are looked up once per file action, terminal command or verification instead of once per path checked, and lookups that do not depend on each other run together. A reserved file made or replaced after one call is still caught by the next. (#352)

  • melra version, doctor, init, setup, clients, policy test and help start in about a third of the time they took (0.08 s against 0.21 s on a Mac): they no longer load the MCP SDK, the HTTP server or Playwright. serve, console, conformance, tasks, watch and status load the MCP and HTTP parts when they run, and @melra/browser-runtime loads Playwright when it first connects to a browser rather than on import. The new @melra/server/kernel export is @melra/server without its MCP and HTTP interfaces, for embedders that want the same. (#368)

v0.3.0-alpha.16

v0.3.0-alpha.16 Pre-release
Pre-release

Choose a tag to compare

@github-actions github-actions released this 21 Oct 16:40
63eecdc

Security

  • Breaking: a capability grant's maxOperations and provider.dailyMax are drawn down whenever the adapter may have done the work, whatever the evidence then says, so grants run out sooner. A task that ends partial, one whose adapter ran and reported failure, a change left recovery_required by an outcome-unknown error or an interruption, and a read cut off mid-flight or retried after an attempt whose outcome is unknown are each charged once, as a verified task or one waiting on a semantic question already was, reads included. verified_success stays the evidence verdict only, and a grant now counts the effects that ran, not only the ones that verified. A charge stands if reconciliation later finds the effect did not happen, and a read charged when recovery parks it is not run again once its grant is at its limit. One gap remains: running that same read again draws nothing more, so each such interruption can let one read past the limit. A policy refusal, a cancel before the adapter ran, an adapter error saying nothing went out, and a duplicate stopped before it ran still cost nothing. Upgrading: a grant sized for verified effects alone may need a larger maxOperations or dailyMax. A workflow's compensations draw on the same grants as its forward steps, so a forward step that ends partial now spends what an unwind may need, and the compensation is what gets refused, leaving the run recovery_required with the effect it was to undo in place. Size a grant for every forward step that may run plus its compensations, or cover compensations with a grant of their own that the forward steps do not match.

  • Breaking: a browser action without a url now has the target element: followed by its target's selector or name (active-page, as before, when it has neither), in every mode. The selector or name used to be the target as written, in the same namespace as page URLs, so a capability grant scoped to one site's pages could also cover an action on whatever page was active. A grant now covers such an action only if its target pattern matches the element: form: a grant written for the selector or name alone (#submit) becomes element:#submit. Enforced mode already required a url on the actions that drive a page; this change also covers its url-less reads of an element (inspect, wait, scroll, screenshot).

  • Breaking: deniedTraits now fails closed for package managers and git. Traits were assigned only to the subcommand spellings policy recognised, so other spellings of an install or a remote operation carried no trait, escaped a package-install or network deny, and reached an approver with no trait shown. Now every call to a package manager or package runner (npm, npx, pnpm, yarn, corepack, pip with or without a version such as pip3.12 or pip-3.12, uv, cargo, go and its go1.22.0-style and gotip wrappers, gem, brew, apt, ...) carries package-install and network, and every git call carries network, unless its first argument is, exactly as spelled, a subcommand known to do neither: an npm package script (npm run, npm test, npm start, ...) or a local git subcommand (status, diff, add, commit, switch, ...; not config, rebase or grep, each of which can be told to run another program). wget2, slogin, dbclient, rsync-ssl, netcat, nc.openbsd, nc.traditional, inetutils-telnet, telnet-ssl, inetutils-ftp, tnftp, tftp and PuTTY's plink, pscp and psftp carry network too, as curl, ssh and the other network programs did, and a git read must name its subcommand in that same spelling. Under a policy that denies a trait, calls such as cargo build, go build, uv run, pnpm test, git -C dir status, git rebase and git --version are now refused; without one they need the same approval as before, at high risk for a package manager. What a package script, a hook, or the repository's own git configuration goes on to fetch is still not classified. The traits table in docs/INSTALLATION.md lists exactly what carries each.

  • Breaking: a terminal call whose argument, or an option's value, is a Windows network path (\\host\share, //host/share) now carries the network trait, whatever the program. Opening such a path connects to that host, but only reads were checked for one, so under a policy that denies network any other call given one still ran once approved. It is now refused there; without such a policy it needs the same approval as before, with the trait shown.

  • Breaking: no npm call is classified as a read any more, so none runs without approval. npm ls, npm view, npm outdated, npm why and npm config get were reads unless an argument redirected npm's log, but npm also takes that setting, and others that make it write outside the workspace, from .npmrc files in the workspace, which policy never sees. They are now mutations like every other package manager's calls: they need an approval and, like any mutation, declared evidence (an exit_code predicate will do), or planning refuses them with mutation_requires_evidence.

  • Breaking: the programs no allowlist entry can admit now match what docs/CAPABILITIES.md promised, and that page names each one. Besides sh, bash, zsh, fish, cmd, powershell, pwsh, sudo, su and osascript, the other common POSIX shells (ash, dash, ksh, mksh, csh, tcsh, yash, ..., and the names packages install them as, such as lksh, mksh-static, bash-static, rzsh and bsd-csh), the busybox and toybox multi-call binaries, wsl, powershell_ise, pwsh-lts and pwsh-preview, the programs that run another as a different user (doas, pkexec, run0, systemd-run, runuser, sudoedit, sudo-rs, su-rs, ksu, pfexec, runas, gsudo) and the Windows script hosts (wscript, cscript, mshta) are refused with command_not_allowlisted even when allowedCommands names them, where before they only needed an approval. Remove such an entry from a policy; the request it allowed is no longer possible outside --unsafe-local.

v0.3.0-alpha.15

v0.3.0-alpha.15 Pre-release
Pre-release

Choose a tag to compare

@github-actions github-actions released this 21 Oct 13:18
7c6fa7b

Added

  • A semantic evidence predicate (#54): a yes/no question about meaning, with artifacts naming result paths, for a judge outside MELRA. The kernel runs no model and never answers it; its item has strength semantic and fails as inconclusive. Once the effect has run and every other predicate has held, the task waits in waiting_user, its judgements saying what it waits on and until when (approvalTtlMs). Nothing can answer a judgement in this release, so at expiry the task settles closed: recovery_required for a change, whose effect did happen, partial for a read, error semantic_judgement_expired, settled by the startup pass and the 30 s recovery sweep, or as soon as one cut off after its effect is recovered: one that committed its idempotency key, or a change whose other evidence is all file_* and still holds. A destructive effect whose evidence has a semantic predicate but nothing at the state or independent level is refused at planning outside unsafe-local mode (semantic_only_destructive). semantic is refused beside reconciliation (semantic_evidence_not_reconcilable), which cannot settle a question about meaning, and in any workflow node (workflow_semantic_evidence_unsupported:<node>) until a workflow can wait on a verdict. pnpm evals has two new scenarios (54).

  • ComputerRuntimeOptions.ocrProgram names the OCR program for a library embedder whose tesseract is outside its usual install paths; naming it makes reading the screen available wherever screenshots are. The server and CLI do not set it. (#251)

  • Each GitHub release attaches the single executable (Node inside, no Node install needed) for linux-x64, linux-arm64, darwin-arm64 and win-x64, built and smoke-tested by the same workflow every pull request runs, and covered by the release's SHA256SUMS and provenance attestation. The binaries are not code-signed: macOS quarantines a downloaded copy and Windows SmartScreen warns, and docs/INSTALLATION.md shows how to verify one first. (#76)

  • A release dry run (.github/workflows/release-dry-run.yml): on demand, and on any pull request that touches the release files, it builds the binaries and every release file through the same steps a v* tag runs (now one shared release-artifacts action), checks the versions, npm publish --dry-runs every package and checks the GitHub release's asset list (each name once) and checksums, with read-only permissions throughout. (#204)

  • melra console approves in a browser, with the same authority as melra approve. Run in a terminal, it starts a loopback server of its own, with no MCP endpoint and no client registration, that ignores MELRA_HTTP_TOKEN, and opens a page; the first page to use the one-time code in its URL fragment, normally that one, pairs with it once. The code is never printed, and the session it buys is held in memory only, by the console and that page, so reloading or leaving the page ends the pairing, as does any change to its URL the page did not make: it picks the task from the operator's clicks, never from the URL. The page hands the session back as it goes, and the console refuses it from then on. Approve and Deny act only once the page has been visible, focused and unscrolled for a second, and show as not yet active until then; in a browser MELRA's runtime is attached to, Playwright's focus emulation hides raises from the page, so there the hold restarts only on scroll and resize. The page shows the screen melra approve shows, with MELRA's summary right above Approve, a decision bound to the task and the digest it drew, and Deny, which cancels the task; the full contract sits folded above the summary, and hidden characters in anything the agent sent, and combining marks stacked past two on one character, are spelled out as \uXXXX. The terminal approval screen (melra approve, melra run) now spells out such marks the same way, and wherever the CLI spells out hidden characters it now spells out unassigned code points too, which a terminal may draw as nothing. Receipts name the approver as console: plus MELRA_APPROVER. Run it with the MELRA_HOME, MELRA_WORKSPACE and mode the agent's server uses. It refuses to start without a terminal (console_needs_a_terminal) or a browser opener (console_needs_a_browser). The server an agent connects to still has no approval route. @melra/server exports approvalScreen, approvalSummary and printable, and serveHttp takes approver, onPaired and onApproved, refused on a socket or off loopback (approval_console_loopback_only) on every platform and in every mode.

Changed

  • A grant is now drawn down, and an idempotency key committed, when a task's every kernel check has held: when it is verified, as before, and also when it enters waiting_user on a semantic question, since its effect ran. A key that ran does not run again, and a grant does not fund a second effect while the first waits. (#54)

  • Breaking: semantic is now a built-in verifier type, so createMelraRuntime refuses an evidenceVerifiers entry of that type (verifier_type_taken:semantic) and the runtime does not start. Rename such a verifier, and the custom predicates that name it. (#54)

  • Breaking: SqliteStore.getWorkflowDefinition in @melra/storage-sqlite returns a RedactedWorkflowDefinition: the redacted copy kept for reading, of which only id and version are checked, since redaction may have rewritten a node id or a URL in it. The definition a run uses is the sealed payload. createWorkflow takes that redacted copy as unknown. (#278)

  • The eleven MCP tools describe themselves fully: each says what it does, when to use it instead of its siblings, what it returns and how its parameters relate, and every top-level parameter now carries a description (most had none). The server's instructions add that no tool lists all tasks or runs, so an agent keeps the ids it is given, and that melra_workflow_control halts a run while melra_workflow_cancel ends it.

  • Breaking: in enforced mode, a browser action that drives a page (click, type, fill_form, select, press, upload, download, close, tab_switch) must name it with url, or it is refused at planning with browser_action_requires_url, ahead of any grant check. The operator approving it always sees which page it lands on, and a grant always has a page to match. A harness in enforced mode sends the page's url, from tabs or the last inspect, with each of these actions; the harness tools browser_click and browser_type take a url for it. Developer mode does not require one. In every mode, the url of close and tab_switch names the tab, which can be about:blank or off the allowlist, since neither loads anything. (#196)

  • Node.js 22.13 is the stated and declared minimum, the first 22.x where node:sqlite needs no flag (23.4 on the 23 line). @melra/cli, @melra/server, @melra/storage-sqlite, and @melra/memory and @melra/runtime-core, which work only with a SQLite store, declare it in engines, so npm and pnpm warn, and Yarn 1 refuses, on an older Node; their docs say 22.13 where they said 22. (#218)

  • The hardened deployment recipes name Docker Desktop and WSL2 as the way to get OS isolation on Windows, and melra doctor's isolation line on native Windows says so instead of mentioning a Job Object. A Job Object limits processes and memory but not file access, so no native Windows recipe is offered. (#52)

  • Breaking: only melra serve --socket <path> moves serve off stdio. MELRA_SOCKET no longer does: exported in a shell profile, it moved every stdio MCP client launched from that shell onto a socket it never connects to, and the client hung waiting for a reply. It still names the socket melra doctor checks and melra status probes. A service that relied on it passes --socket "$MELRA_SOCKET" instead. The stderr warning serve printed in that case is gone with it. (#105)

  • Breaking: melra setup and melra init show the workspace they give the agent, as a Workspace row and as workspace in the JSON, and no longer make it the home directory, a directory holding it (/Users, /home, C:\Users) or a filesystem root (/, or a drive root on Windows) unasked. The workspace is the current directory unless MELRA_WORKSPACE is set or a MELRA_POLICY file's workspaceRoot pins it, so the README's npx @melra/cli@alpha setup run in a fresh terminal gave the agent the whole home directory, with nothing printed to say so. In a terminal they now say so and ask, defaulting to no; elsewhere (piped, captured, --json) they refuse with workspace_too_broad and write nothing. Either way they say to set MELRA_WORKSPACE to the project directory or run from there; when a MELRA_POLICY file set the workspace, to make the project that file's workspaceRoot instead of running from it. A script that means it sets MELRA_WORKSPACE, which is never questioned. Directories are compared by identity, so a symlinked home and macOS's /System/Volumes/Data/... spelling of it count.

  • Each GitHub release's notes are its version's CHANGELOG.md section, so a breaking change is called out in them as GOVERNANCE.md asks, instead of a list of pull request titles. Wrapped lines are joined, since a release body shows every newline as a line break. pnpm docs:check fails while package.json's version has no section or an empty one, so a version bump without notes fails its pull request rather than the tag release. The container takes the tags npm does: the version, the release channel (:alpha, :beta, :rc, or :latest for a stable version) and, before 1.0, :latest on every release, instead of always :alpha. :latest follows every release, while :alpha stays on the last alpha once betas begin, as npm's @alpha does. scripts/release-channel.mjs picks the channel for the release and its dry run alike, and a prereleas...

Read more

MELRA v0.3.0-alpha.14

MELRA v0.3.0-alpha.14 Pre-release
Pre-release

Choose a tag to compare

@dhe-eraj-s dhe-eraj-s released this 16 Oct 09:21
f176ee2

Fixed

  • Use the canonical XAGI-Lab owner casing in MELRA's official MCP Registry identifier and server metadata.

Install

npx @melra/cli@0.3.0-alpha.14 setup

Requires Node.js 22+. This is alpha software; start in a throwaway workspace.

v0.3.0-alpha.12

v0.3.0-alpha.12 Pre-release
Pre-release

Choose a tag to compare

@github-actions github-actions released this 14 Oct 19:22
fa329c5

What's Changed

New Contributors

Full Changelog: v0.3.0-alpha.11...v0.3.0-alpha.12

v0.3.0-alpha.11

v0.3.0-alpha.11 Pre-release
Pre-release

Choose a tag to compare

@github-actions github-actions released this 11 Aug 13:14

MELRA is the layer an agent asks to change the world through: it types an effect
against a strict schema, classifies it, authorises it against policy, gates it on
an exact approval phrase, records it durably before anything runs, deduplicates
it, runs it under a budget and a cancel signal, verifies it against declared
evidence, and receipts it. Nothing in it reasons.

This release closes out three roadmap phases.

MELRA can now be the only door. MELRA_MODE=enforced is the operator
asserting the harness has no second path to the same systems. MELRA cannot verify
that from inside its own process and does not pretend to — it closes the doors it
owns: --unsafe-local refused, loopback binds only, no self-registering OAuth
client, and mode stamped on every receipt so an auditor never has to ask which
deployment produced it. developer stays the default, because trying MELRA in
thirty seconds is why anyone reads further.

HTTP and API calls are a first-class effect. Same nine stages as a file
write: classification, policy, approval, idempotency, budget, verification,
receipt. A mutation whose reply never arrived is reported as unknown, not
failed — failed means the effect did not happen, and after an unanswered
request that is a claim nobody holds.

Agents receive capabilities, not credentials. The kernel holds the secret,
scopes it by host and by capability, and adapters never see the value. Grants
carry a size as well as an expiry: call counts and declared spend, drawn down
durably, refused rather than assumed when nothing can meter them.

Evidence says how it is known. Every item carries a strength — execution,
state, independent, semantic — stamped in one place from the predicate type,
so a re-read of the target is never confused with the adapter's own word. The new
http_resource_matches predicate executes through one request and verifies
through another: POST /refunds does the work, GET /refunds/rf_1 decides
whether it counts.

Get it

npx -y @melra/cli@alpha doctor          # check the machine
npx -y @melra/cli@alpha setup           # policy, client config, verified in one command
npx -y @melra/cli@alpha conformance     # prove the pipeline against a real transport

Or docker run --rm ghcr.io/xagi-lab/melra:v0.3.0-alpha.11.

Verified against the published package

The installed job on ubuntu, macOS and Windows installs this exact tarball from
npm and drives a real stdio session: version 0.3.0-alpha.11, 11 tools,
verified_success, VERIFIED_SUCCESS. Conformance level 3, 14/14.

Still honest about

Pre-stable: alpha minor releases may change MCP schemas. No independent security
review yet. The OS isolation around the harness is the operator's, not MELRA's —
#52 tracks MELRA's side of it.


What's Changed

  • feat(verifier): say how every evidence item is known by @dheeraj-codingdesk in #43
  • feat(protocol): publish the execution guarantee on every contract by @dheeraj-codingdesk in #44
  • feat(http): govern HTTP and API calls as a first-class effect by @dheeraj-codingdesk in #46
  • feat(policy): hold credentials in the kernel, hand agents capabilities by @dheeraj-codingdesk in #47
  • feat(verifier): confirm an effect through a channel that did not perform it by @dheeraj-codingdesk in #48
  • feat(policy): give capability grants a size, not just an expiry by @dheeraj-codingdesk in #49
  • feat(runtime): reconcile unanswered mutations and unwind cross-provider sagas by @dheeraj-codingdesk in #50
  • feat(server): add enforced deployment mode by @dheeraj-codingdesk in #51

Full Changelog: v0.3.0-alpha.10...v0.3.0-alpha.11

v0.3.0-alpha.9

v0.3.0-alpha.9 Pre-release
Pre-release

Choose a tag to compare

@github-actions github-actions released this 08 Aug 19:56

v0.3.0-alpha.8

v0.3.0-alpha.8 Pre-release
Pre-release

Choose a tag to compare

@github-actions github-actions released this 08 Aug 15:27

v0.3.0-alpha.6

v0.3.0-alpha.6 Pre-release
Pre-release

Choose a tag to compare

@github-actions github-actions released this 08 Aug 14:41