| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
chore: enable more oxc lint rules (#234) | 22 天前 | |
examples/rlm: Add a structured RLM example (#122) * examples/rlm: Add a structured RLM example Show how Computer Workspaces, generated JavaScript, and a bounded trusted model module can implement map/reduce over long context. Compare direct context, JavaScript-only execution, and Structured RLM on official Oolong tasks with observable scoring and usage. * examples/rlm: Show rejected executor output Keep successful JavaScript executions visible when their returned shape cannot be scored. Sanitize invalid output into a metadata-only summary and explain the semantic capability mismatch in the comparison UI. | 1 个月前 | |
examples/rlm: Add a structured RLM example (#122) * examples/rlm: Add a structured RLM example Show how Computer Workspaces, generated JavaScript, and a bounded trusted model module can implement map/reduce over long context. Compare direct context, JavaScript-only execution, and Structured RLM on official Oolong tasks with observable scoring and usage. * examples/rlm: Show rejected executor output Keep successful JavaScript executions visible when their returned shape cannot be scored. Sanitize invalid output into a metadata-only summary and explain the semantic capability mismatch in the comparison UI. | 1 个月前 | |
examples/rlm: Add a structured RLM example (#122) * examples/rlm: Add a structured RLM example Show how Computer Workspaces, generated JavaScript, and a bounded trusted model module can implement map/reduce over long context. Compare direct context, JavaScript-only execution, and Structured RLM on official Oolong tasks with observable scoring and usage. * examples/rlm: Show rejected executor output Keep successful JavaScript executions visible when their returned shape cannot be scored. Sanitize invalid output into a metadata-only summary and explain the semantic capability mismatch in the comparison UI. | 1 个月前 | |
examples/rlm: Add a structured RLM example (#122) * examples/rlm: Add a structured RLM example Show how Computer Workspaces, generated JavaScript, and a bounded trusted model module can implement map/reduce over long context. Compare direct context, JavaScript-only execution, and Structured RLM on official Oolong tasks with observable scoring and usage. * examples/rlm: Show rejected executor output Keep successful JavaScript executions visible when their returned shape cannot be scored. Sanitize invalid output into a metadata-only summary and explain the semantic capability mismatch in the comparison UI. | 1 个月前 | |
examples/rlm: Add a structured RLM example (#122) * examples/rlm: Add a structured RLM example Show how Computer Workspaces, generated JavaScript, and a bounded trusted model module can implement map/reduce over long context. Compare direct context, JavaScript-only execution, and Structured RLM on official Oolong tasks with observable scoring and usage. * examples/rlm: Show rejected executor output Keep successful JavaScript executions visible when their returned shape cannot be scored. Sanitize invalid output into a metadata-only summary and explain the semantic capability mismatch in the comparison UI. | 1 个月前 | |
examples/rlm: Add a structured RLM example (#122) * examples/rlm: Add a structured RLM example Show how Computer Workspaces, generated JavaScript, and a bounded trusted model module can implement map/reduce over long context. Compare direct context, JavaScript-only execution, and Structured RLM on official Oolong tasks with observable scoring and usage. * examples/rlm: Show rejected executor output Keep successful JavaScript executions visible when their returned shape cannot be scored. Sanitize invalid output into a metadata-only summary and explain the semantic capability mismatch in the comparison UI. | 1 个月前 | |
chore: enable more oxc lint rules (#234) | 22 天前 | |
chore: migrate to oxc tool chain (#228) | 22 天前 | |
computer: Let host module calls wait for an answer (#251) * computer: Let host module calls wait for an answer A host module function can now call ctx.interrupt(payload) to pause a replayable run until someone answers, for example to approve an action the run is about to take. The code being run just calls the function and gets its result, however long the answer takes. The interrupted call is journaled as waiting. The bridge holds new calls, lets the ones in flight finish and be journaled, and the backend then releases the isolate while the run stays running. Waiting runs are left alone by recovery, so they survive a deploy, and their wait doesn't count toward the timeout. workspace.runtime.pending() lists the waiting calls and respond() answers one. Once none are waiting, the run replays to the call, which runs again with the same callId and gets its answer from interrupt() this time. Only a replayable run can wait, since a pause needs the journal, and interrupt() throws elsewhere. Calls that interrupt after the run starts releasing wait once it resumes, so approvals made together are asked one after another. A released attempt's late output is dropped, as it isn't the run's. * docs: Describe waiting for an answer in a replayable run * computer: Let a host module call interrupt only once The journal keeps one answer per call. A function that called ctx.interrupt() twice joined its first wait the second time, losing the second payload, and on resume both calls returned the first answer, so one approval could stand for two. A second interrupt() in the same call now throws. * computer: Test an answer that arrives before the run is released The run resumes only once its isolate is released, so an answer that lands while the run's other calls are still finishing has to wait for the release to end. Nothing checked that it does, and if it didn't the run would stay running without ever resuming. * computer, docs: Mark waiting for an answer experimental ctx.interrupt(), runtime.pending(), runtime.respond() and the pending call type now say in their JSDoc that they may change in any release, as restart and replay already do, and the docs section says so too. * computer: Tell the backend's onWait when a call starts waiting An app had to poll runtime.pending() to learn that a run was waiting, and had to know which object to ask. The JavaScript backend now takes an onWait function, called with the fields pending() lists once a wait is saved, so the app can message whoever answers or index the wait itself. It's called at most once per wait. A crash between saving the wait and calling it loses the call, so pending() stays the source of truth. It runs on its own rather than inside the interrupted call, so a slow or failing hook can't hold up the run's release, and what it throws is logged. * computer: Add pending() and respond() to the runtime stub Approval UIs usually live in a Worker that calls the Durable Object, so without these every app wrote its own RPC methods to list and answer waiting calls. Both pass plain data, so the stub hands out nothing that needs disposing. * computer: Release a run once its calls in flight settle or wait Releasing a run for an interrupt waited for every call that was in flight when the first one interrupted. A call among them that went on to interrupt itself never settled, so the run was never released, its answers never resumed it, and it sat until its timeout failed it. Two host module calls in one Promise.all that each await anything before interrupting did this. quiesce() now waits until each call in flight has been answered or is waiting too, looking again whenever another call starts waiting, so those waits are answered together. * computer: Test that an answer starts a run's attempts again A run resumed after its last wait is answered records its first attempt, since the answer is progress. Without that, a run whose earlier interruptions had used up its attempts could fail on the next one before the answered call was journaled. * computer: Merge the journal's two interrupt() doc comments * computer: Report when each pending call started waiting pending() and onWait gave every waiting call its run's waiting_since, which is when the run's first unanswered call started waiting, so a second call that started waiting later showed the first one's time. The journal now keeps waiting_since for each call, and both report that. The run's own waiting_since still decides how much waiting its timeout leaves out. * computer: Call respond()'s value its answer The docs, the journal column and the ENOTWAITING message all call what respond() is given an answer, so the parameter says so too. It's positional, so callers don't change. | 13 天前 | |
chore: enable more oxc lint rules (#234) | 22 天前 | |
examples/rlm: Add a structured RLM example (#122) * examples/rlm: Add a structured RLM example Show how Computer Workspaces, generated JavaScript, and a bounded trusted model module can implement map/reduce over long context. Compare direct context, JavaScript-only execution, and Structured RLM on official Oolong tasks with observable scoring and usage. * examples/rlm: Show rejected executor output Keep successful JavaScript executions visible when their returned shape cannot be scored. Sanitize invalid output into a metadata-only summary and explain the semantic capability mismatch in the comparison UI. | 1 个月前 | |
examples/rlm: Add a structured RLM example (#122) * examples/rlm: Add a structured RLM example Show how Computer Workspaces, generated JavaScript, and a bounded trusted model module can implement map/reduce over long context. Compare direct context, JavaScript-only execution, and Structured RLM on official Oolong tasks with observable scoring and usage. * examples/rlm: Show rejected executor output Keep successful JavaScript executions visible when their returned shape cannot be scored. Sanitize invalid output into a metadata-only summary and explain the semantic capability mismatch in the comparison UI. | 1 个月前 | |
examples/rlm: Add a structured RLM example (#122) * examples/rlm: Add a structured RLM example Show how Computer Workspaces, generated JavaScript, and a bounded trusted model module can implement map/reduce over long context. Compare direct context, JavaScript-only execution, and Structured RLM on official Oolong tasks with observable scoring and usage. * examples/rlm: Show rejected executor output Keep successful JavaScript executions visible when their returned shape cannot be scored. Sanitize invalid output into a metadata-only summary and explain the semantic capability mismatch in the comparison UI. | 1 个月前 | |
examples/rlm: Add a structured RLM example (#122) * examples/rlm: Add a structured RLM example Show how Computer Workspaces, generated JavaScript, and a bounded trusted model module can implement map/reduce over long context. Compare direct context, JavaScript-only execution, and Structured RLM on official Oolong tasks with observable scoring and usage. * examples/rlm: Show rejected executor output Keep successful JavaScript executions visible when their returned shape cannot be scored. Sanitize invalid output into a metadata-only summary and explain the semantic capability mismatch in the comparison UI. | 1 个月前 | |
examples/rlm: Add a structured RLM example (#122) * examples/rlm: Add a structured RLM example Show how Computer Workspaces, generated JavaScript, and a bounded trusted model module can implement map/reduce over long context. Compare direct context, JavaScript-only execution, and Structured RLM on official Oolong tasks with observable scoring and usage. * examples/rlm: Show rejected executor output Keep successful JavaScript executions visible when their returned shape cannot be scored. Sanitize invalid output into a metadata-only summary and explain the semantic capability mismatch in the comparison UI. | 1 个月前 | |
computer: Polish ws:container module (#213) | 26 天前 | |
examples/rlm: Add a structured RLM example (#122) * examples/rlm: Add a structured RLM example Show how Computer Workspaces, generated JavaScript, and a bounded trusted model module can implement map/reduce over long context. Compare direct context, JavaScript-only execution, and Structured RLM on official Oolong tasks with observable scoring and usage. * examples/rlm: Show rejected executor output Keep successful JavaScript executions visible when their returned shape cannot be scored. Sanitize invalid output into a metadata-only summary and explain the semantic capability mismatch in the comparison UI. | 1 个月前 | |
computer: Add ws:container (#172) * computer: Add ws:container for isolate JavaScript An agent that wants both isolated JavaScript and a full Linux container has so far needed two exec backends, and the model had to pick one per command. This lets JavaScript be the only backend the model sees, with the container as a library it can call. createContainerModule() in @cloudflare/computer/modules/container is a host module factory. Installed as ws:container, its exec(command, options) runs through workspace.runtime.exec on the container backend, so the container shares the Workspace's files through the usual sync bracket. It returns the exit code and bounded output once the command finishes, kills the command when the execution is cancelled, caps the command's timeout at the host call deadline, and refuses to run on a read-only backend, since a container command can write to the Workspace whatever the isolate's access is. Its description tells the model how to call it, and reaches the exec tool through the JavaScript backend's own description. * computer: Pick exec backends with one exec option (#181) * computer: Carry backend information through Workspace clients (#182) * computer: Carry backend information through Workspace clients A WorkspaceClient from getWorkspace() wrapped the runtime with exec, getExec, killExec, and disposeExec only. The exec tool also asks the runtime for backendIds, isCallable, and describe, so a client lost all three: with exec omitted it offered no exec tool, and a callable backend lost its input argument and its module list. Over RPC those calls would be asynchronous, while the tool builds its schema synchronously. Backends are fixed when the Workspace is constructed, so the runtime and its RPC stub now expose one backends() call, and a client takes that snapshot when it is created and answers the three questions from it, locally and remotely alike. CloudflareContainerBackend now describes network access from its egress setting instead of always claiming it, exec takes precedence over the deprecated shell option so exec: {} always means no tool, and the mcp README and think prompt stop implying a default backend. * computer: Answer backend questions with one backends() call The exec tool learned about backends through three runtime methods, backendIds, isCallable, and describe, and every way of reaching a Workspace had to forward all three. It now reads one list from runtime.backends(), each entry carrying the id, whether the backend is callable, and its description. backendIds and describe are gone, and a Workspace client exposes the same backends() from its snapshot. isCallable stays on the runtime for its own check before running. * computer: Freeze the client backend snapshot and test input through it A client returned its backend snapshot array itself, so a caller that edited it changed what later tool sets saw. The snapshot is now frozen once when the client is created. The client tests only checked that the exec schema offered input. They now send structured input through the exec tool on a local and a remote client to a callable backend that echoes it, and check the value comes back as the result. The mcp README no longer calls worker-shell the default. * computer: Describe the new ContainerBackend instead of the legacy one The exec tool's self-description for the container landed on the platform-scheduled backend, which is now LegacyContainerBackend. It moves to ContainerBackend, the backend containers should use, with its network line still following the egress mode. The legacy backend goes back to describing nothing and gets the exec tool's one-line default. * computer: Check ws:container's backend when it connects ws:container found a missing or wrong container backend only on its first exec. Its factory runs when the JavaScript backend connects and can read the Workspace's backends, so it now fails there: with no such backend, or with one that runs modules instead of shell commands. Its description also stopped promising network access. The model only sees the module's text in this setup, and whether the container can reach the network depends on the container backend's egress setting, which the module cannot know when it is built. * docs: Use ContainerBackend for ws:container The ws:container docs, the exec tool docs, and the changesets named the old CloudflareContainerBackend. They now show ContainerBackend, the durable-object-scheduled backend containers should use. * examples/think, examples/mcp: Move to ContainerBackend Both examples ran their container through LegacyContainerBackend, the platform-scheduled backend, which no longer describes itself to the model. They now use ContainerBackend: the durable object schedules the container, the containers block names an image under images.app with scheduling_policy "durable_object", and the backend asks for standard-2 at launch, the size the old block requested. * computer: Check only that ws:container's backend exists ws:container also rejected a backend marked callable, taking that as a sign it runs modules. callable means a backend takes structured input, and a shell backend may do both, so the check refused valid backends and let through a module backend that was not callable. It now checks only that the backend exists. * computer: Tell ws:container's backend kind by protocol ws:container needs a backend that runs shell commands. It first judged that by callable, which describes structured input instead: a shell backend may be callable, and a module backend need not be. Without any check, pointing it at the JavaScript backend would run a shell command as JavaScript, or start a nested run. runtime.backends() now reports each backend's protocol, "command" or "module", and ws:container refuses a module backend when it connects. A callable shell backend is accepted. * computer: Run a single-backend exec tool on its backend for direct calls Import createAITools from its new home in the client test, and cover a direct execute call that names another backend. * computer: Format the exec tool after the rebase onto main * computer: Let the runtime cut ws:container output and say where the rest is ws:container now asks the runtime for at most maxOutputBytes per stream, so a noisy command keeps only its end in memory and its full output in a Workspace file. The result passes on `truncated` with that file's path. A Workspace with output saving off still gets the old cut. * computer: Say where ws:container's saved output can be read The default output directory is outside the JavaScript backend's root, so point isolate code at the agent's read and grep tools, and document setting output.dir under root when code needs the file itself. * computer: Pass isolate capability calls as native RPC values The Dynamic Worker already received a real RPC object, the runtime bridge, but every node:fs and host module call was JSON-encoded on top of it: arguments became a string with a custom codec for bytes, arrays, and objects, and results came back the same way. Bytes travelled as arrays of numbers, roughly four times their size against the capability byte limit, and both sides carried an encoder and a decoder. Arguments and results now cross as Workers RPC values. The isolate passes its argument list straight to host.call, and the bridge answers with { result } or a bounded { error } carrying code and path for node:fs. The bridge stays the single proxy for every call, so its controls are unchanged: cancellation, concurrent and total call counts, per-call deadlines with abort, and draining accepted calls before an execution ends. Byte budgets now measure the values themselves: UTF-8 bytes of strings and keys, raw bytes of byte arrays, and a fixed cost per scalar. The same walk rejects anything that is not plain data, including functions and RPC stubs that Workers RPC would otherwise carry into the host as live callbacks, and cycles. * computer: Keep host bridge responses within their limits - Error responses now count against the cumulative response budget. - An error's path and code are kept only if the whole error still fits the payload limit; the message is cut to what is left. - Every value costs at least one byte, so many empty strings or objects can no longer reach the host past the request limit. - Host module arguments and results follow JSON again: undefined object fields are left out and undefined array items become null, so a host value with an optional field no longer fails the execution. * computer: Keep fitting error paths and own __proto__ fields in host values * computer: Leave concurrent JavaScript executions to the platform WorkerJavaScriptBackend admitted up to 24 executions at once by default. The platform allows 10 concurrent Dynamic Workers per request, so runs 11 through 24 were admitted and then failed with the platform's error anyway, while the backend's own ceiling only added an option and a counter to keep in step. The cap and maxConcurrentExecutions are gone. Executions start until the platform refuses one, and that refusal is the execution's error. The rlm examples drop the option. Starts already in progress still hold close() until they finish, and reusing a running execution id still fails with EEXEC_BUSY. * computer: Mention -C in ws:git's description ws:git accepts a leading -C <path> in cli, but its description for the model did not say so, so a model reading it had no reason to use it. * computer: Leave publish out of tools built from a remote client without assets A remote client's assets getter returned the stub's assets property, which over RPC is always a placeholder, never undefined. createAITools therefore offered publish on a remote client even when the Workspace had no assets publisher, and calling it failed because the receiver did not implement assets. The Workspace stub now exposes a plain hasAssets boolean, which the client reads once when it is created, as it already does for useThink. A client without assets reports undefined, locally and remotely. * computer: Drop undefined result fields and reject cyclic arguments cleanly A run that returned { kept: 1, dropped: undefined } failed with "must be JSON-compatible values", although the result is framed as JSON, which drops undefined fields. Values like that are common in ordinary code, so the check now treats an undefined field as absent. The isolate's early size check walked arguments without tracking what it had seen, so a cyclic argument overflowed the stack. It now stops at a repeated object and reports that values must be acyclic, the same wording the host uses. * computer: Report ws:container's file sync to the caller ws:container returned the exit code and output but dropped the sync result, so code that called exec could not tell whether the container's file changes had reached the Workspace, or which ones the Workspace had refused. exec now also returns sync: its status, the skipped paths, and the error when the pull is still pending. The module's description and the docs also say the sync is last-writer-wins, because a file the isolate writes while the command runs is replaced by the container's version without being reported as skipped. * computer: Cap ws:container's skipped-path list A command that wrote thousands of files into a read-only mount made the sync summary larger than the bridge's response limits allow. exec then failed after the command had already run and its changes had been pulled, losing the exit code and inviting a retry that repeats the side effects. The summary now lists at most 100 skipped paths, adds skippedCount with the full count, and cuts a pending sync's error to 1 KiB. * computer: Expect skippedCount in the ws:container truncation test | 27 天前 | |
examples/rlm: Add a structured RLM example (#122) * examples/rlm: Add a structured RLM example Show how Computer Workspaces, generated JavaScript, and a bounded trusted model module can implement map/reduce over long context. Compare direct context, JavaScript-only execution, and Structured RLM on official Oolong tasks with observable scoring and usage. * examples/rlm: Show rejected executor output Keep successful JavaScript executions visible when their returned shape cannot be scored. Sanitize invalid output into a metadata-only summary and explain the semantic capability mismatch in the comparison UI. | 1 个月前 | |
examples/rlm: Add a structured RLM example (#122) * examples/rlm: Add a structured RLM example Show how Computer Workspaces, generated JavaScript, and a bounded trusted model module can implement map/reduce over long context. Compare direct context, JavaScript-only execution, and Structured RLM on official Oolong tasks with observable scoring and usage. * examples/rlm: Show rejected executor output Keep successful JavaScript executions visible when their returned shape cannot be scored. Sanitize invalid output into a metadata-only summary and explain the semantic capability mismatch in the comparison UI. | 1 个月前 | |
examples/rlm: Add a structured RLM example (#122) * examples/rlm: Add a structured RLM example Show how Computer Workspaces, generated JavaScript, and a bounded trusted model module can implement map/reduce over long context. Compare direct context, JavaScript-only execution, and Structured RLM on official Oolong tasks with observable scoring and usage. * examples/rlm: Show rejected executor output Keep successful JavaScript executions visible when their returned shape cannot be scored. Sanitize invalid output into a metadata-only summary and explain the semantic capability mismatch in the comparison UI. | 1 个月前 | |
examples/rlm: Add a structured RLM example (#122) * examples/rlm: Add a structured RLM example Show how Computer Workspaces, generated JavaScript, and a bounded trusted model module can implement map/reduce over long context. Compare direct context, JavaScript-only execution, and Structured RLM on official Oolong tasks with observable scoring and usage. * examples/rlm: Show rejected executor output Keep successful JavaScript executions visible when their returned shape cannot be scored. Sanitize invalid output into a metadata-only summary and explain the semantic capability mismatch in the comparison UI. | 1 个月前 | |
examples/rlm: Add a structured RLM example (#122) * examples/rlm: Add a structured RLM example Show how Computer Workspaces, generated JavaScript, and a bounded trusted model module can implement map/reduce over long context. Compare direct context, JavaScript-only execution, and Structured RLM on official Oolong tasks with observable scoring and usage. * examples/rlm: Show rejected executor output Keep successful JavaScript executions visible when their returned shape cannot be scored. Sanitize invalid output into a metadata-only summary and explain the semantic capability mismatch in the comparison UI. | 1 个月前 | |
examples/rlm: Add a structured RLM example (#122) * examples/rlm: Add a structured RLM example Show how Computer Workspaces, generated JavaScript, and a bounded trusted model module can implement map/reduce over long context. Compare direct context, JavaScript-only execution, and Structured RLM on official Oolong tasks with observable scoring and usage. * examples/rlm: Show rejected executor output Keep successful JavaScript executions visible when their returned shape cannot be scored. Sanitize invalid output into a metadata-only summary and explain the semantic capability mismatch in the comparison UI. | 1 个月前 | |
chore: enable more oxc lint rules (#234) | 22 天前 | |
examples/rlm: Add a structured RLM example (#122) * examples/rlm: Add a structured RLM example Show how Computer Workspaces, generated JavaScript, and a bounded trusted model module can implement map/reduce over long context. Compare direct context, JavaScript-only execution, and Structured RLM on official Oolong tasks with observable scoring and usage. * examples/rlm: Show rejected executor output Keep successful JavaScript executions visible when their returned shape cannot be scored. Sanitize invalid output into a metadata-only summary and explain the semantic capability mismatch in the comparison UI. | 1 个月前 | |
examples/rlm: Add a structured RLM example (#122) * examples/rlm: Add a structured RLM example Show how Computer Workspaces, generated JavaScript, and a bounded trusted model module can implement map/reduce over long context. Compare direct context, JavaScript-only execution, and Structured RLM on official Oolong tasks with observable scoring and usage. * examples/rlm: Show rejected executor output Keep successful JavaScript executions visible when their returned shape cannot be scored. Sanitize invalid output into a metadata-only summary and explain the semantic capability mismatch in the comparison UI. | 1 个月前 | |
examples/rlm: Add a structured RLM example (#122) * examples/rlm: Add a structured RLM example Show how Computer Workspaces, generated JavaScript, and a bounded trusted model module can implement map/reduce over long context. Compare direct context, JavaScript-only execution, and Structured RLM on official Oolong tasks with observable scoring and usage. * examples/rlm: Show rejected executor output Keep successful JavaScript executions visible when their returned shape cannot be scored. Sanitize invalid output into a metadata-only summary and explain the semantic capability mismatch in the comparison UI. | 1 个月前 | |
examples/rlm: Add a structured RLM example (#122) * examples/rlm: Add a structured RLM example Show how Computer Workspaces, generated JavaScript, and a bounded trusted model module can implement map/reduce over long context. Compare direct context, JavaScript-only execution, and Structured RLM on official Oolong tasks with observable scoring and usage. * examples/rlm: Show rejected executor output Keep successful JavaScript executions visible when their returned shape cannot be scored. Sanitize invalid output into a metadata-only summary and explain the semantic capability mismatch in the comparison UI. | 1 个月前 | |
computer: Configure isolate modules through one modules option (#170) * computer: Configure isolate modules through one modules option WorkerJavaScriptBackend had two ways to add imports: modules for bundled source, and trustedModules for a single call(method, args) host handler reached through one generic call export. On top of those, node:fs, ws:git, and ws:artifacts were always installed, with git and artifacts special-cased in the bridge and gated by allowGitNetwork and allowArtifactNetwork. There is now one modules option, and the value's type says what it is. A string is bundled source, as before. An object of functions is a host module under a ws:* specifier, and each function becomes a named export, so { "ws:weather": { forecast } } lets code write import { forecast } from "ws:weather". A function is a factory the backend calls when it connects, with the Workspace's Git client, Artifacts client, and runtime. Each call gets its access level and a path resolver confined to the backend root alongside the signal and deadline, and may return any JSON-compatible value; the bridge checks it at runtime. Git and Artifacts become prebuilt factories under @cloudflare/computer/modules/*, and nothing under ws: is installed unless configured. Network access moves to allowNetwork on each module. node:fs and node:fs/promises stay built in. Specifiers, source module names, and object export names are checked at construction. The backend also describes its source language and every importable module in a description property, which workspace.runtime.describe(id) returns, built from the same modules option it runs with. The rlm example moves ws:model to a named batch function. * computer: Accept a leading -C in ws:git cli The Git CLI now takes a leading -C <path>, because agents reach for git -C instead of changing directory. ws:git rejected every -C as a path override, so those commands failed inside an isolate. A leading -C now becomes the command's working directory and goes through the same root confinement as cwd. A -C anywhere else, and --git-dir and --work-tree, are still rejected. * computer: Call host module functions on their module A host function that used `this` lost its module when the bridge called it bare. | 28 天前 | |
examples/rlm: Add a structured RLM example (#122) * examples/rlm: Add a structured RLM example Show how Computer Workspaces, generated JavaScript, and a bounded trusted model module can implement map/reduce over long context. Compare direct context, JavaScript-only execution, and Structured RLM on official Oolong tasks with observable scoring and usage. * examples/rlm: Show rejected executor output Keep successful JavaScript executions visible when their returned shape cannot be scored. Sanitize invalid output into a metadata-only summary and explain the semantic capability mismatch in the comparison UI. | 1 个月前 | |
examples/rlm: Add a structured RLM example (#122) * examples/rlm: Add a structured RLM example Show how Computer Workspaces, generated JavaScript, and a bounded trusted model module can implement map/reduce over long context. Compare direct context, JavaScript-only execution, and Structured RLM on official Oolong tasks with observable scoring and usage. * examples/rlm: Show rejected executor output Keep successful JavaScript executions visible when their returned shape cannot be scored. Sanitize invalid output into a metadata-only summary and explain the semantic capability mismatch in the comparison UI. | 1 个月前 | |
computer: Polish ws:container module (#213) | 26 天前 | |
computer: Configure isolate modules through one modules option (#170) * computer: Configure isolate modules through one modules option WorkerJavaScriptBackend had two ways to add imports: modules for bundled source, and trustedModules for a single call(method, args) host handler reached through one generic call export. On top of those, node:fs, ws:git, and ws:artifacts were always installed, with git and artifacts special-cased in the bridge and gated by allowGitNetwork and allowArtifactNetwork. There is now one modules option, and the value's type says what it is. A string is bundled source, as before. An object of functions is a host module under a ws:* specifier, and each function becomes a named export, so { "ws:weather": { forecast } } lets code write import { forecast } from "ws:weather". A function is a factory the backend calls when it connects, with the Workspace's Git client, Artifacts client, and runtime. Each call gets its access level and a path resolver confined to the backend root alongside the signal and deadline, and may return any JSON-compatible value; the bridge checks it at runtime. Git and Artifacts become prebuilt factories under @cloudflare/computer/modules/*, and nothing under ws: is installed unless configured. Network access moves to allowNetwork on each module. node:fs and node:fs/promises stay built in. Specifiers, source module names, and object export names are checked at construction. The backend also describes its source language and every importable module in a description property, which workspace.runtime.describe(id) returns, built from the same modules option it runs with. The rlm example moves ws:model to a named batch function. * computer: Accept a leading -C in ws:git cli The Git CLI now takes a leading -C <path>, because agents reach for git -C instead of changing directory. ws:git rejected every -C as a path override, so those commands failed inside an isolate. A leading -C now becomes the command's working directory and goes through the same root confinement as cwd. A -C anywhere else, and --git-dir and --work-tree, are still rejected. * computer: Call host module functions on their module A host function that used `this` lost its module when the bridge called it bare. | 28 天前 | |
examples/rlm: Add a structured RLM example (#122) * examples/rlm: Add a structured RLM example Show how Computer Workspaces, generated JavaScript, and a bounded trusted model module can implement map/reduce over long context. Compare direct context, JavaScript-only execution, and Structured RLM on official Oolong tasks with observable scoring and usage. * examples/rlm: Show rejected executor output Keep successful JavaScript executions visible when their returned shape cannot be scored. Sanitize invalid output into a metadata-only summary and explain the semantic capability mismatch in the comparison UI. | 1 个月前 | |
examples/rlm: Add a structured RLM example (#122) * examples/rlm: Add a structured RLM example Show how Computer Workspaces, generated JavaScript, and a bounded trusted model module can implement map/reduce over long context. Compare direct context, JavaScript-only execution, and Structured RLM on official Oolong tasks with observable scoring and usage. * examples/rlm: Show rejected executor output Keep successful JavaScript executions visible when their returned shape cannot be scored. Sanitize invalid output into a metadata-only summary and explain the semantic capability mismatch in the comparison UI. | 1 个月前 | |
examples/rlm: Add a structured RLM example (#122) * examples/rlm: Add a structured RLM example Show how Computer Workspaces, generated JavaScript, and a bounded trusted model module can implement map/reduce over long context. Compare direct context, JavaScript-only execution, and Structured RLM on official Oolong tasks with observable scoring and usage. * examples/rlm: Show rejected executor output Keep successful JavaScript executions visible when their returned shape cannot be scored. Sanitize invalid output into a metadata-only summary and explain the semantic capability mismatch in the comparison UI. | 1 个月前 | |
computer: Configure isolate modules through one modules option (#170) * computer: Configure isolate modules through one modules option WorkerJavaScriptBackend had two ways to add imports: modules for bundled source, and trustedModules for a single call(method, args) host handler reached through one generic call export. On top of those, node:fs, ws:git, and ws:artifacts were always installed, with git and artifacts special-cased in the bridge and gated by allowGitNetwork and allowArtifactNetwork. There is now one modules option, and the value's type says what it is. A string is bundled source, as before. An object of functions is a host module under a ws:* specifier, and each function becomes a named export, so { "ws:weather": { forecast } } lets code write import { forecast } from "ws:weather". A function is a factory the backend calls when it connects, with the Workspace's Git client, Artifacts client, and runtime. Each call gets its access level and a path resolver confined to the backend root alongside the signal and deadline, and may return any JSON-compatible value; the bridge checks it at runtime. Git and Artifacts become prebuilt factories under @cloudflare/computer/modules/*, and nothing under ws: is installed unless configured. Network access moves to allowNetwork on each module. node:fs and node:fs/promises stay built in. Specifiers, source module names, and object export names are checked at construction. The backend also describes its source language and every importable module in a description property, which workspace.runtime.describe(id) returns, built from the same modules option it runs with. The rlm example moves ws:model to a named batch function. * computer: Accept a leading -C in ws:git cli The Git CLI now takes a leading -C <path>, because agents reach for git -C instead of changing directory. ws:git rejected every -C as a path override, so those commands failed inside an isolate. A leading -C now becomes the command's working directory and goes through the same root confinement as cwd. A -C anywhere else, and --git-dir and --work-tree, are still rejected. * computer: Call host module functions on their module A host function that used `this` lost its module when the bridge called it bare. | 28 天前 | |
examples/rlm: Add a structured RLM example (#122) * examples/rlm: Add a structured RLM example Show how Computer Workspaces, generated JavaScript, and a bounded trusted model module can implement map/reduce over long context. Compare direct context, JavaScript-only execution, and Structured RLM on official Oolong tasks with observable scoring and usage. * examples/rlm: Show rejected executor output Keep successful JavaScript executions visible when their returned shape cannot be scored. Sanitize invalid output into a metadata-only summary and explain the semantic capability mismatch in the comparison UI. | 1 个月前 | |
computer: Configure isolate modules through one modules option (#170) * computer: Configure isolate modules through one modules option WorkerJavaScriptBackend had two ways to add imports: modules for bundled source, and trustedModules for a single call(method, args) host handler reached through one generic call export. On top of those, node:fs, ws:git, and ws:artifacts were always installed, with git and artifacts special-cased in the bridge and gated by allowGitNetwork and allowArtifactNetwork. There is now one modules option, and the value's type says what it is. A string is bundled source, as before. An object of functions is a host module under a ws:* specifier, and each function becomes a named export, so { "ws:weather": { forecast } } lets code write import { forecast } from "ws:weather". A function is a factory the backend calls when it connects, with the Workspace's Git client, Artifacts client, and runtime. Each call gets its access level and a path resolver confined to the backend root alongside the signal and deadline, and may return any JSON-compatible value; the bridge checks it at runtime. Git and Artifacts become prebuilt factories under @cloudflare/computer/modules/*, and nothing under ws: is installed unless configured. Network access moves to allowNetwork on each module. node:fs and node:fs/promises stay built in. Specifiers, source module names, and object export names are checked at construction. The backend also describes its source language and every importable module in a description property, which workspace.runtime.describe(id) returns, built from the same modules option it runs with. The rlm example moves ws:model to a named batch function. * computer: Accept a leading -C in ws:git cli The Git CLI now takes a leading -C <path>, because agents reach for git -C instead of changing directory. ws:git rejected every -C as a path override, so those commands failed inside an isolate. A leading -C now becomes the command's working directory and goes through the same root confinement as cwd. A -C anywhere else, and --git-dir and --work-tree, are still rejected. * computer: Call host module functions on their module A host function that used `this` lost its module when the bridge called it bare. | 28 天前 | |
examples/rlm: Add a structured RLM example (#122) * examples/rlm: Add a structured RLM example Show how Computer Workspaces, generated JavaScript, and a bounded trusted model module can implement map/reduce over long context. Compare direct context, JavaScript-only execution, and Structured RLM on official Oolong tasks with observable scoring and usage. * examples/rlm: Show rejected executor output Keep successful JavaScript executions visible when their returned shape cannot be scored. Sanitize invalid output into a metadata-only summary and explain the semantic capability mismatch in the comparison UI. | 1 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 22 天前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 22 天前 | ||
| 22 天前 | ||
| 13 天前 | ||
| 22 天前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 26 天前 | ||
| 1 个月前 | ||
| 27 天前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 22 天前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 28 天前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 26 天前 | ||
| 28 天前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 28 天前 | ||
| 1 个月前 | ||
| 28 天前 | ||
| 1 个月前 |