OpenScript roadmap

Agent brief: paste this into your agent

Task OS-N1 in marketcalls/openscript: add issue forms, a pull request template and a setup guide.
Read CLAUDE.md, CONTRIBUTING.md, RELEASING.md, package.json (engines) and engine/pyproject.toml first. Then read spec/conformance.md section 2, so the bug form asks for what a case needs.
Build:
1. .github/ISSUE_TEMPLATE/bug.yml: the script; bars as CSV (time,open,high,low,close,volume) with a placeholder symbol; the npm or PyPI package and its version; the bar and output that is wrong, what was expected and what came back. Tell the reporter to remove account data.
2. .github/ISSUE_TEMPLATE/roadmap-task.yml: the task id from the OpenScript roadmap page, a plan of three to five lines, agent assisted yes or no, and the expected finish.
3. .github/ISSUE_TEMPLATE/config.yml turning off blank issues.
4. .github/pull_request_template.md with the fields this task lists.
5. CONTRIBUTING.md: a Setup section (Node 22 or newer, Python 3.12 or newer, npm install, npm test, git config core.hooksPath .githooks) and a Working with an agent section that links to the rules instead of copying them.
6. AGENTS.md: a few lines pointing to CLAUDE.md and CONTRIBUTING.md.
Rules: plain text; no emoji; no em or en dashes; name no other product or company; call a run that sends no real order sandbox mode, and use no other name for it. Do not change any rule, workflow or code.
Done when node scripts/check-names.mjs and npm test pass on a clean clone set up by following your Setup section. Paste both summary lines. Put the label list in the pull request description: roadmap, size: S, size: M, size: L, needs decision, eval, and area: spec, compiler, engine, python engine, conformance, editor, docs.

Agent brief: paste this into your agent

Task OS-N2 in marketcalls/openscript: bring the status pages back in line with the numbers, and renumber the second 0018 record.
Read CLAUDE.md and CONTRIBUTING.md. Then read docs/integrating/README.md (the status note), ROADMAP.md (Phase 6 and Phase 7), docs/integrating/architecture.md (Where it stands, and the two sentences that call the live runner planned), and both files named 0018 in issues/.
Steps:
1. Run node scripts/check-matrix.mjs, npm run suite:agree and a count of cases/*/*/case.json. Replace each stale figure with the measured one and name the version it was read at. The values channel has existed since 0.6.0. The live runner is built in the first host, not in this repository: say so without naming anything else.
2. Rename the plot style record (closed 2026-09-24) to 0022 and add a line saying it was filed as 0018.
3. Run grep -rn 0018 over the repository (skip .git, dist and CHANGELOG.md). Read each hit and decide which record it means. Update only the ones that mean the plot style record. Comments only: no code behaviour changes.
Rules: change only sentences that are false today; leave CHANGELOG.md alone; no emoji; no em or en dashes; name no other product.
Done when npm run check:site, node scripts/check-names.mjs and npm test pass. In the pull request, paste each command's output next to the figure it supports, and the grep output before and after.

Agent brief: paste this into your agent

Task OS-N3 in marketcalls/openscript: split the three test files that are over the 500 line cap.
Read CLAUDE.md and spec/modularity-exceptions.json first. Each longFiles entry names the seam to split along: tests/engine/library.test.ts (move the surveys out), tests/engine/objects.test.ts (move the ceiling cases out), tests/emit/format.test.ts (split along compiled-program.md section 3.5).
Before you start, count the test( calls under tests/ and record the number.
Move tests; do not rewrite, rename, weaken or delete any. Shared setup goes into an existing support file if one fits. Do not create a helper that has only one caller.
Remove each row from longFiles once its file is under 500 lines.
Rules: no code file over 500 lines; no emoji; no em or en dashes; do not touch src/ or engine/.
Done when node scripts/check-modularity.mjs and npm test pass and the test( count is unchanged. Paste the before and after counts and both summary lines.

Agent brief: paste this into your agent

Task OS-N4 in marketcalls/openscript: write the upgrade page from 0.5.0, and add it to the release steps.
Read CLAUDE.md (the Every release list), RELEASING.md (how the package version and the format version differ) and every CHANGELOG.md entry after 0.5.0.
Build docs/integrating/upgrading.md. Write one short entry for each change that alters a computed value, a diagnostic, a refusal, the compiled format, the run record or the host surface. Each entry says what changed, the version it arrived in, who notices (the host or the script author) and what to check. Link to the CHANGELOG entry instead of copying it, and group the entries by version, then by who notices.
Add one line to the Every release list in CLAUDE.md: add the release's user-visible changes to docs/integrating/upgrading.md. Mark that line for my approval in the pull request.
Rules: state each fact once and link for detail; no emoji; no em or en dashes; name no other product or company; call a run that sends no real order sandbox mode, and use no other name for it. Change no code.
Done when npm run check:site, node scripts/check-names.mjs and npm test pass. In the pull request, list every CHANGELOG entry after 0.5.0 and say whether it is on the page, with a reason for each one left off.

Agent brief: paste this into your agent

Task OS-N5 in marketcalls/openscript: check the chart adapter against a real charts 2.6.0 build.
Start only once openalgo-charts 2.6.0 is on npm. Read CLAUDE.md, src/adapters/charts/contract.ts, capabilities.ts, descriptor.ts and index.ts, scripts/check-chart-surface.mjs, spec/chart-narrowings.json, and the 2.6.0 entry of the charts changelog.
Steps:
1. In a scratch directory outside the repository, install openalgo-charts@2.6.0 and the tarball from npm pack of this branch.
2. Write a probe .ts file that builds a descriptor with the adapter for a few examples and hands it to the chart's typed API. Run tsc --noEmit on it and keep the output.
3. Write a smoke page that loads the 2.6.0 script-tag build and draws each example in examples/ that draws. Record one screenshot per example and the browser console.
4. If anything breaks, fix it in src/adapters/charts. Update the peer range to what you tested. Touch capabilities.ts only if the adapter now depends on something 2.6.0 added.
Rules: add no dependency; commit neither the probe nor the scratch directory; no code file over 500 lines; name no other product; no emoji; no em or en dashes; do not tag or publish (the maintainer releases both packages under one version).
Done when npm run check:chart and npm test pass. Paste the tsc output, attach the screenshots, and write the rerun steps into the pull request.

Agent brief: paste this into your agent

Task OS-N6 in marketcalls/openscript: raise OS7015 when a strategy has no order destination.
Read CLAUDE.md, CONTRIBUTING.md and spec/README.md. Then read spec/host-interface.md section 7 (its opening, 7.1, 7.4 and 7.6), the OS7015 entry in spec/errors.json and its section in spec/errors.md, spec/conformance.md sections 2 to 4, scripts/lib/raise-documents.mjs, and engine/openscript/run.py.
Goal: both engines stop with OS7015 the moment a strategy places an order and the host wired no destination.
1. If the spec does not say exactly on which bar and with which span OS7015 is raised, write that sentence first and show me the diff before any code.
2. Implement it in src/ and engine/openscript/ in the same pull request.
3. Edit the OS7015 entry by hand in both spec/errors.json and spec/errors.md: they state the same facts and are compared. npm run generate:errors writes only the generated TypeScript and does not touch spec/errors.md.
4. Run grep -rn 'Not raised yet' spec docs and remove or trim every note that names OS7015. Leave OS7014's half of the shared note in place.
5. Add a test in each engine that asserts the code and the span, not the message.
6. Add a case under cases/order/ if the case format can express a missing destination. Derive its expected output by reading the spec, and say how you did it.
Rules: no eval or code built from text; no dependency (Python standard library only); no code file over 500 lines; do not edit an existing case's expected values, a tolerance or an exceptions file under spec/; name no product; no emoji; no em or en dashes; do not tag or publish.
Done when npm test, node scripts/check-raises.mjs, npm run check:errors and npm run check:examples:compile pass. Paste their summary lines and the grep output.

Agent brief: paste this into your agent

Task OS-N7 in marketcalls/openscript: write down how a tick becomes the moving bar, then replay ticks.csv in both adapters.
Read CLAUDE.md, spec/conformance.md section 3 (Intrabar updates) and section 7, spec/language.md 7.2 and 7.5 (rollback) and 8.2 (live var), docs/integrating/running-the-suite.md (what each adapter does not reach), scripts/adapter.mjs, engine/adapter.mjs, and the feature-matrix rows whose identifiers are bar/rollback, bar/rollback-array, bar/updates and persist/live-var.
1. Draft the sentence that says how a ticks.csv row becomes the newest bar's open, high, low, close and volume. Show me the diff. Write no adapter code until I approve it on the issue.
2. Implement the replay in both adapters using each engine's existing update and rollback path. If the spec needs new engine surface, ask me first.
3. Add four cases at exactly the reserved identifiers: cases/bar/rollback, cases/bar/rollback-array, cases/bar/updates and cases/persist/live-var. The live var case asserts values only, because no adapter reports the OS8011 compile warning yet. Derive every expected output from the spec, not from an engine.
4. In the pull request, show that removing the rollback in either engine fails a case. Do not commit that probe.
5. Flip the four rows and update running-the-suite.md.
Rules: no eval; Python standard library only; no code file over 500 lines; do not edit existing cases; no emoji; no em or en dashes; do not tag or publish.
Done when npm run suite, npm run suite:engine, node scripts/check-matrix.mjs and npm test pass with the four cases answered. Paste the summaries.

Agent brief: paste this into your agent

Task OS-N8 in marketcalls/openscript: prove ten rows of the language core.
Read CLAUDE.md, CONTRIBUTING.md, spec/README.md, spec/feature-matrix.md 'Test identifiers' (the difference between a unit: identifier and a case identifier), and spec/conformance.md sections 2, 4 and 7. Then read the section of spec/feature-matrix.md you picked (sections 1, 2 (version), 3 and 6 have no implemented row) and the spec sections its rows cite.
For each of up to ten specified rows:
1. Read the cited spec sentence and write the smallest script that exercises it.
2. If the identifier starts with unit:, write a test under tests/ whose name carries that exact identifier. Otherwise create the case directory the identifier names under cases/.
3. Write the expected output from the spec sentence, not from running an engine. A lexical row usually expects a code and a span.
4. Break the behaviour on purpose (for example, disable the check in the compiler) and show the test or case failing. Do not commit that change.
5. Flip the row to implemented.
6. If an engine disagrees with the spec, do not change the expected output. Leave the row as it is and open an issue with the script.
Rules: never compute an expected value with either engine; do not edit any existing case; no code file over 500 lines; name no product; no emoji; no em or en dashes.
Done when node scripts/check-matrix.mjs, npm run suite:agree and npm test pass. Paste the matrix summary line from before and after, and the failing output of each probe.

Agent brief: paste this into your agent

Task OS-N9 (maintainer) for marketcalls/openscript: record where evals live and how they are run.
Read the eval section of this roadmap, spec/conformance.md section 4, RELEASING.md and docs/integrating/the-editor-half.md (what diagnose returns).
Draft these for me, and create nothing: (1) a README for a public eval repository that holds the harness and the train cases; (2) the layout of a private repository for test cases and reference programs; (3) a dependency-free digest check that fails if any private case appears in the public repository; (4) a one-page decision covering the pinned grading build, the candidate build rule (npm pack of the branch, both digests recorded), the docs version a model is shown, who may write test cases, the vendor terms for anyone who receives test cases, the train-only rule for a second vendor, rotation only on suspected leakage, the model and effort per campaign, and the spend limit, with blanks where I decide.
Rules: no secrets or keys in any file; name no product or vendor; no emoji; no em or en dashes. Do not create repositories, set limits or push.

Agent brief: paste this into your agent

Task OS-N10 for the OpenScript fix-from-diagnostic eval: write the first 50 mistakes, each with the program that was meant.
Read spec/errors.json (codes, stages, causes and fixes), docs/integrating/the-editor-half.md (diagnose), docs/first-study.md, docs/first-strategy.md, the AI assistants page on openalgo.in/script (the mistakes assistants make), and the eval decision from OS-N9.
First, in openscript: add a --root option to scripts/check-names.mjs so it can scan a directory that is not this repository. Keep the default unchanged, add a test, and open it as its own small pull request.
Then work with me one case at a time, only on codes whose stage is lex, parse or check. First, a request a trader would make. Second, the program that does it (I write it or approve it). Third, a realistic broken version containing one mistake a person learning the language would make. Bars are a random walk with a placeholder symbol, never a sine wave.
For each case, check with the pinned build that diagnose returns the stated code for the broken script and that the intended program compiles and runs clean. Write meta.json with the code, why a person finds it hard, and the source.
Rules: do not copy any before or after block from spec/errors.json; do not pick a mistake because a model fails it; do not run any model on the cases; test cases go only to the private repository and I write or rewrite each of them; name no product, broker or real instrument; no emoji; no em or en dashes.
Done when all 50 cases pass the compile checks, the overlap check against the catalogue and check-names --root. Paste their summaries.

Agent brief: paste this into your agent

Task OS-N11 for the OpenScript fix-from-diagnostic eval: build the grader, the runner and the first baseline.
Read the eval decision from OS-N9, docs/integrating/the-editor-half.md (diagnose), docs/integrating/architecture.md, and the case format from OS-N10.
Build, in the eval repository only:
1. grade: compile the candidate with the pinned grading build. Fail on any error, or on a warning the intended program does not raise. Run both on the case bars and compare every named output bar by bar, exactly unless the case declares a tolerance.
2. run: take a build path (the pinned build, or a tarball from npm pack of a branch) and send the model only the broken script and that build's diagnose output (code, message, fix, span), with no docs and no tools. Three runs per case. Record tokens, time, verdict and the digest of both builds. A package or network failure is an infrastructure error: retry it once and report it separately.
3. report: the test pass rate with a 95 percent bootstrap interval over cases, the difference between two full baseline runs (the noise floor), the smallest effect the test set can detect, cost and latency per task, and failures grouped by the original code.
Prove the grader first: every intended program passes, every broken script fails, ten fixes that simply delete the feature fail, and a second grading gives identical verdicts.
Rules: never put reference programs or test cases anywhere the model under test can read them; keep API keys out of files and logs; name no product or vendor in case text; no emoji; no em or en dashes. Only the maintainer runs the test split.
Done when the grader checks pass and the baseline report is written. Paste the report summary.

Agent brief: paste this into your agent

Task OS-S1 (maintainer) in marketcalls/openscript: settle the four decisions the order path and the backtest wait on.
Read spec/README.md; spec/decisions.md decision 38 (its Still open paragraph); the deferred text of OS7005, OS7011, OS7014, OS7018 and OS7019 and the entry for OS7017 in spec/errors.json; spec/stdlib.md 17.1 to 17.4 and 17.7 to 17.10; spec/host-interface.md 7.4 and 7.6; spec/conformance.md sections 4 and 10; src/core/accounting/equity.ts (its note on where charges land); src/core/backtest/record.ts (run record versions); cases/order/ended-unfilled; and docs/integrating/architecture.md (Where it stands).
Draft for my review, with no code, one decision each: (1) order validation with the lot size; (2) a diagnostic that does not stop the run, and the unknown-intent frame; (3) what a bracket does before its level stands, and the single-leg subset of 17.9 to build now; (4) when a charge lands on the equity curve, and when running equity updates. For each: the options, what each costs both engines and a host, the spec sentences it changes, the matrix rows and case identifiers it reserves, and a recommendation. Do not choose for me.
Also draft: the correction of order/ended-unfilled that decision 2 implies, with the reasoning conformance.md section 10 asks for; bar-by-bar hand derivations for the four bracket scenarios; and the implementation tasks re-cut to five days or less.
Rules: cite 17.10 rather than deciding again what it settles; spec wording only; state each fact once; no emoji; no em or en dashes; name no other product.
Done when node scripts/check-matrix.mjs and npm test pass on the reserved identifiers. List every question you could not settle.

Agent brief: paste this into your agent

Task OS-S2 in marketcalls/openscript: refuse a quantity off the lot size (OS7005) and implement order.roundToLot.
Read CLAUDE.md, CONTRIBUTING.md, spec/README.md, the order validation decision from OS-S1, the OS7005 entry in spec/errors.json and spec/errors.md, spec/stdlib.md 17.1 to 17.3, spec/host-interface.md 4.1 (instrument facts), scripts/lib/fix-sentence.mjs and spec/conformance.md sections 2 to 4.
Goal: the ledger knows the lot size its leg trades in, both engines refuse a quantity that is not a multiple of it with OS7005, and order.roundToLot works as stdlib.md 17.3 says.
1. Implement it in src/ and engine/openscript/ in one pull request, exactly as the decision fixes it. If the decision leaves a question open, stop and ask on the issue.
2. Implement order.roundToLot in both engines and add a library vector if check-library-vectors asks for one.
3. Edit the OS7005 entry by hand in spec/errors.json and spec/errors.md (npm run generate:errors does not touch errors.md). Remove or trim every Not raised yet note naming OS7005 (grep -rn 'Not raised yet' spec docs).
4. Write tests in each engine on the code and span, and boundary cases under cases/order/: an exact multiple passes and one unit off refuses. Derive each expected output from the spec and say how.
Rules: no eval; Python standard library only; no code file over 500 lines; do not edit an existing case's expected values, a tolerance or an exceptions file under spec/; placeholder symbols only; name no product, broker or real instrument; no emoji; no em or en dashes; do not tag or publish.
Done when npm test, node scripts/check-raises.mjs, npm run check:errors, node scripts/check-matrix.mjs and npm run check:examples:compile pass. Paste the summary lines.

Agent brief: paste this into your agent

Task OS-S3 in marketcalls/openscript: refuse an order outside the session (OS7012) and implement session.isOpen.
Read CLAUDE.md, CONTRIBUTING.md, spec/README.md, the OS7012 entry in spec/errors.json and spec/errors.md, spec/language.md 13.3 and 15.2, spec/stdlib.md 12.4, spec/host-interface.md 4.3 (the session), docs/data/sessions-and-time.md, scripts/lib/fix-sentence.mjs, and the feature-matrix rows order/session-flatten and session/flags.
Goal: both engines refuse, with OS7012, an order placed while the instrument is outside its session, and session.isOpen reads the same predicate.
1. If the spec does not fix the bar, the span and whether the run stops, write that first and show me the diff.
2. Implement the refusal and session.isOpen in src/ and engine/openscript/ in the same pull request.
3. Edit the OS7012 entry by hand in spec/errors.json and spec/errors.md, and remove the Not raised yet notes that name it. Move order/session-flatten from deferred to specified (closeOnSessionEnd flattening stays unbuilt) and update session/flags for isOpen.
4. Write tests in each engine on the code and span, and boundary cases: the last bar inside the session passes and the first bar outside refuses. Derive each expected output from the spec and say how.
Rules: no eval; Python standard library only; no code file over 500 lines; do not edit existing cases; placeholder symbols only; no emoji; no em or en dashes; do not tag or publish.
Done when npm test, node scripts/check-raises.mjs, npm run check:errors, node scripts/check-matrix.mjs and npm run check:examples:compile pass. Paste the summaries.

Agent brief: paste this into your agent

Task OS-S4 in marketcalls/openscript: report refusals that come back in frames (OS7014, OS7018 and OS7019).
Read CLAUDE.md, CONTRIBUTING.md, spec/README.md, the non-stopping diagnostic decision from OS-S1, spec/host-interface.md 7.2 to 7.6, spec/stdlib.md 17.8, the three entries in spec/errors.json and spec/errors.md, spec/conformance.md sections 3 (frames.csv), 4 and 10, and cases/order/ended-unfilled.
Goal: when a frame carries a rejection, names an intent this strategy never placed, or reports a fill with no price, both engines report the catalogue's code on the channel the decision defined, and the run continues where the decision says it does.
1. Implement the channel in src/ and engine/openscript/ and in the run record, exactly as decided. Do not change what the fold does to the ledger.
2. Raise the three codes. Edit their entries by hand in spec/errors.json and spec/errors.md, and remove the Not raised yet notes that name them.
3. Write the correction of order/ended-unfilled that the decision approved, with notes.md explaining why the old expectation was not what the spec says. Post it on the issue and wait for my approval before committing it.
4. Write tests on the code and span in each engine, plus three strategy cases whose frames.csv carries each shape, with expected output derived from the spec.
Rules: no eval; Python standard library only; no code file over 500 lines; no other existing case is edited; no emoji; no em or en dashes; do not tag or publish.
Done when npm test, node scripts/check-raises.mjs, npm run check:errors and node scripts/check-catalogue-tests.mjs pass. Paste the summaries.

Agent brief: paste this into your agent

Task OS-S5 in marketcalls/openscript: fill a bracket's stop and target at the level in both engines.
Read CLAUDE.md, CONTRIBUTING.md, spec/README.md, the bracket decision and derivations from OS-S1, spec/stdlib.md 17.9 and 17.10, spec/conformance.md sections 2 to 4, and the code in src/core/backtest/ and engine/openscript/strategy/ that appends orders to the ledger.
Goal: a bracket's stop and target append order rows and fill at the level as the spec now says, identically in both engines.
1. Implement it in src/ and engine/openscript/ in one pull request.
2. Turn the four derivations from OS-S1 into strategy cases (bars.csv, backtest.json and expected output) under the reserved identifiers.
3. Remove the bracket sentence from docs/integrating/architecture.md and flip the matrix rows.
Rules: the derivations are the expected values, and no expected value comes from running an engine; no eval; Python standard library only; no code file over 500 lines; if an existing case's output changes, stop and ask me; no emoji; no em or en dashes; do not tag or publish.
Done when npm test, npm run suite:agree, npm run check:reproducible and node scripts/check-matrix.mjs pass. Paste the summaries.

Agent brief: paste this into your agent

Task OS-S6 in marketcalls/openscript: fold the equity curve from fills, and correct the strategy cases it moves.
Read CLAUDE.md, CONTRIBUTING.md, spec/README.md, the charge timing decision from OS-S1, spec/stdlib.md 17.4 and 17.7, spec/conformance.md section 10, src/core/accounting/equity.ts, engine/openscript/accounting/equity.py, src/core/backtest/record.ts (run record versions) and the eight strategy cases: order/buy, order/sell, order/ended-unfilled, order/fold-after-terminal, order/partial-fill, perf/money-digits, perf/report-window and input/host-values.
Goal: in both engines, the equity curve is built from each fill as it happens, with charges landing as decided, not from a trade's final size.
1. Implement it in src/ and engine/openscript/ together. Move the run record version only if its shape changes.
2. For each of the eight cases, list every figure that moves. Derive each new figure from the case's fills with a small calculation that does not use either engine, and put the derivation in notes.md. Post the list on the issue and wait for my approval before committing any correction.
3. Add a case that scales in over three entries in one direction. Derive its curve by hand, bar by bar.
4. Update the gap sentence in docs/integrating/architecture.md and the shape list in running-the-suite.md.
Rules: never produce an expected value by running an engine; no eval; Python standard library only; no code file over 500 lines; no emoji; no em or en dashes; do not tag or publish.
Done when npm test, npm run suite:agree and npm run check:reproducible pass. Paste the summaries and the approved list of corrections.

Agent brief: paste this into your agent

Task OS-S7 in marketcalls/openscript: keep a running equity, size by cash or percent of equity, raise OS7011, and implement pos.equity, pos.netProfit and pos.tradeCount.
Read CLAUDE.md, CONTRIBUTING.md, spec/README.md, the running equity decision from OS-S1, spec/stdlib.md 17.1, 17.2 and 17.4, the OS7011 entry in spec/errors.json and spec/errors.md, scripts/lib/fix-sentence.mjs, the equity change from OS-S6, and spec/conformance.md sections 2 to 4.
Goal: the backtest keeps a running equity, sizes orders given in cash or as a percent of equity against it, raises OS7011 when an order needs more capital than the strategy has, and lets a script read the three running totals.
1. Implement running equity and sizing in src/ and engine/openscript/ together, as decided. If the plan shows more than five days of work, say so on the issue before starting, and split the pos reads into a second claim.
2. Implement pos.equity, pos.netProfit and pos.tradeCount in both engines and move the pos/equity row.
3. Add cases for cash sizing, percent-of-equity sizing, the OS7011 boundary and the three reads, with hand-derived values.
4. Edit the OS7011 entry by hand in spec/errors.json and spec/errors.md, remove its Not raised yet notes, and remove the sizing and equity sentences from docs/integrating/architecture.md.
Rules: no eval; Python standard library only; no code file over 500 lines; do not edit existing cases; placeholder symbols only; no emoji; no em or en dashes; do not tag or publish.
Done when npm test, npm run suite:agree, npm run check:reproducible, node scripts/check-raises.mjs, npm run check:errors and npm run check:examples:compile pass. Paste the summaries.

Agent brief: paste this into your agent

Task OS-S8 (maintainer), across marketcalls/openscript and the first host: triage the host's reports, then run five strategies through a full session in sandbox mode.
Start only after the first host ships the current package. Read ROADMAP.md Phase 6 (the session gate OS-S9 wrote), docs/integrating/upgrading.md, docs/integrating/running-a-strategy.md, docs/running/sandbox-and-live.md, and the host's runner.
Part 1, triage: write a small documented command that runs gh issue list --repo marketcalls/openalgo --state all --search for each of: openscript, 'script editor', 'compile error', and every code in spec/errors.json as its own term. For each hit, write the smallest script and bars that show it, run them on the current package, and record issue, result and outcome in one tracking issue. Open an openscript issue with the bug form for each defect still present.
Part 2, session: pick five strategies that between them cover a stop, a bracket, lot sizing, a session close and a reversal, using the shipped examples where they fit. Run each in sandbox mode for one full session, recording the bars the runner saw and its orders and fills. Backtest the same programs over the recorded bars and draw them on the chart over the same bars. Write the report into ROADMAP.md Phase 6: for each strategy, orders and trades from the runner, the backtest and the chart side by side, with every difference explained or filed.
Rules: sandbox mode only; no account data, order ids or real symbols anywhere; name no broker; no emoji; no em or en dashes.
Done when the tracking issue holds the first triage run and the report is in ROADMAP.md Phase 6 with each difference explained or filed.

Agent brief: paste this into your agent

Task OS-S9 (maintainer) in marketcalls/openscript: write down what 1.0 means, and the Phase 6 session gate.
Read ROADMAP.md (Phase 6, The adoption bar, and Promises that hold from version 1), docs/integrating/architecture.md (Where it stands), docs/integrating/the-documentation-site.md, RELEASING.md and spec/conformance.md section 12 (the badge).
Draft for my review: (1) a ROADMAP.md section listing the 1.0 criteria this task proposes, each followed by the command or file that proves it; (2) a replacement for the architecture.md sentence that ties 1.0 to an outside engine, presenting the outside engine as the separate standard milestone with the badge reserved for it; (3) the session gate paragraph for ROADMAP.md Phase 6; (4) the options for which package version the site docs track (the latest published package, or the version the first host ships), with what each costs.
Rules: no dates; state each fact once and link to it; no emoji; no em or en dashes; name no other product.
Done when npm run check:site and npm test pass. List any criterion you could not tie to a command.

Agent brief: paste this into your agent

Task OS-S10 in marketcalls/openscript: record the public surface of both packages, and fail on any unapproved change.
Read CLAUDE.md, RELEASING.md, package.json (exports), scripts/check-format-additive.mjs and scripts/check-python.mjs (how Node runs Python here), engine/openscript/__init__.py and docs/integrating/the-python-engine.md.
1. Draft the list of public Python modules for docs/integrating/the-python-engine.md. It must include openscript.adapter.serving, adapter.sessions, adapter.spellings, civil, contracts, dates, hours, inputs, run, strategy, strategy.intents, verify and zones. Show it to me on the issue and wait for approval.
2. Build scripts/check-api.mjs. Read every entry of the exports map from the built dist/ declaration files and record each exported name with its declaration text. Read each listed module's public names and signatures through Python's inspect module, the way check-python.mjs runs Python. Compare with a committed snapshot: exit 1 naming any removal or any changed declaration or signature, and print additions.
3. Add an npm script and run it from npm test.
Rules: no dependency; under 500 lines; no eval or code built from text; do not change any public surface in this task; no emoji; no em or en dashes.
Done when npm test passes and the pull request shows the check failing on a removed export, a changed declaration and a renamed keyword argument (no probe committed).

Agent brief: paste this into your agent

Task OS-S11 in marketcalls/openscript: fuzz the compiler and the compiled-program loader in both engines.
Read CLAUDE.md, ROADMAP.md Phase 1 (production bar), tests/editor/support.ts (MALFORMED), tests/engine/fuzz.test.ts, spec/compiled-program.md (load-time checks), the OS6xxx entries in spec/errors.json, scripts/check-python.mjs and engine/adapter.mjs (how Node drives the Python engine).
Build:
1. A source fuzzer: a seeded generator that mutates examples/ and the malformed corpus by grammar-aware edits (drop, duplicate or swap tokens, deepen nesting, insert a line). Assert the compiler never throws, finishes within a time budget, and emits only codes in spec/errors.json.
2. A program fuzzer: mutate the spec/corpus/ programs (drop fields, change types, reorder, truncate) and load each in both engines. Assert each is refused with an OS6xxx code or loads and runs, and that both engines give the same verdict and code. Send the whole batch to one Python process rather than one process per program.
3. A fixed seed in npm test that takes a few seconds, and a longer range behind an environment variable for CI.
For every crash or disagreement, add a named regression test and fix it, in both engines where it applies.
Rules: no dependency; no code file over 500 lines; no eval or code built from text; do not weaken an existing test; no emoji; no em or en dashes.
Done when npm test passes and the pull request shows a planted throw being found. Paste the summaries and the fixed-seed run time.

Agent brief: paste this into your agent

Task OS-S12 in marketcalls/openscript: give the Python engine a benchmark with budgets.
Read CLAUDE.md, tests/bench/workloads.ts, tests/bench/budgets.ts, tests/bench/timing.ts, scripts/bench.mjs, engine/tools/run_tests.py and engine/openscript/run.py.
Build:
1. A Node step that compiles the programs the TypeScript workloads use and writes them, with their bars, to a temporary directory. Commit no compiled JSON.
2. A bench under engine/ that runs the history, update, light and heavy workloads on those programs, with budgets taken the same way as tests/bench/budgets.ts: the median of several runs, a headroom factor, and a rerun in a fresh process before failing.
3. Call both from npm test.
Rules: Python standard library only; no code file over 500 lines; do not raise any existing TypeScript budget; no emoji; no em or en dashes.
Done when npm test passes, git status shows no new file after it, and the pull request shows a planted slowdown failing the bench. Paste the measured medians and the budgets.

Agent brief: paste this into your agent

Task OS-S13 for the OpenScript evals: build the overlap guard.
Read the eval decision from OS-N9 and the case format from OS-N10.
Build a dependency-free Node script, check-overlap. Its input is a unified diff and a directory of cases. It fails when any added line shares any of these with a test request or reference program: a run of eight or more words (normalised for case and spacing), a script identifier, a plot title, or a number with four or more significant digits. It prints the case id and the length of the match.
Write unit tests for each rule, including a clean diff that must pass. Use made-up cases in the tests; you never see the real test set.
Rules: no dependency; the guard never prints test content, only the case id and the length of the match; no emoji; no em or en dashes.
Done when the tests pass and a run over 250 generated cases takes under ten seconds. Paste the timing.

Agent brief: paste this into your agent

Task OS-S14 for the OpenScript fix-from-diagnostic eval: write 25 train cases.
Read the public eval repository's README and case format, spec/errors.json (codes, stages, causes and fixes), docs/first-study.md, docs/first-strategy.md and the AI assistants page on openalgo.in/script.
For each case: write a request a trader would make and the program that does it; then a broken version with one mistake a person learning the language would make, raising a code whose stage is lex, parse or check. Bars are a random walk with a placeholder symbol, never a sine wave.
Check each case with the pinned build: diagnose returns the stated code for the broken script, and the intended program compiles and runs clean. Write meta.json with the code, why a person finds it hard, and the source.
Rules: do not copy any before or after block from spec/errors.json; do not pick a mistake because a model fails it; do not run any model on the cases; name no product, broker or real instrument; no emoji; no em or en dashes.
Done when the compile checks, the overlap check and node scripts/check-names.mjs --root pass. Paste their summaries.

Agent brief: paste this into your agent

Task OS-S15 (maintainer) for the OpenScript fix-from-diagnostic eval: grow the private test set to 20 cases in each targeted family.
Read the eval decision from OS-N9, the case format from OS-N10, the baseline report from OS-N11, the triage issue from OS-S8 if it exists, and spec/errors.json.
1. Propose 3 to 5 families of compile-time codes, ranked by how often people hit them. Give the evidence for each. Do not use the baseline's failure rates to choose.
2. With me, draft cases for each family in the OS-N10 format until each holds at least 20 test cases. I write or rewrite every test case, and I approve the set.
3. Rerun the baseline on the grown set and report the interval, the noise floor and the smallest detectable effect for each family.
Rules: test cases go only to the private repository; never copy a train case or a catalogue block; do not run any model before I approve the set; no emoji; no em or en dashes.
Done when each family holds 20 approved test cases, the digest check passes and the rerun report is written.

Agent brief: paste this into your agent

Task OS-S16 for marketcalls/openscript: hillclimb the fix text of one code family per round.
Read CLAUDE.md (Diagnostics), scripts/lib/fix-sentence.mjs, scripts/lib/raise-documents.mjs, the entries in spec/errors.json and spec/errors.md for the family you are given, and the rerun baseline from OS-S15. You get train transcripts and verdicts only; you never see test cases.
Each round:
1. Group the train failures for the family by root cause.
2. Propose one change to the message, cause or fix of that family's codes that addresses one cause. Edit spec/errors.json and spec/errors.md together, by hand. The text must stay true of the actual program for every case the code covers.
3. Run the overlap guard, pack a candidate build with npm pack, and hand both to the campaign tooling, which scores train, the family's test cases and the pooled test set, and decides keep or revert.
Stop after two or three rounds in which nothing is kept, and write the remaining causes into the log.
Rules: one family per round and one cause per patch; never quote a transcript, case or reference program; do not change codes, spans or behaviour; no emoji; no em or en dashes; name no other language or product. The maintainer approves every wording change and runs the website check at release.
Done when each kept change passes npm test, npm run check:examples:compile, npm run check:errors and the overlap guard, and the log is written.

Agent brief: paste this into your agent

Task OS-S17 in marketcalls/openscript: package the suite so it runs without this repository.
Read CLAUDE.md, spec/conformance.md sections 9 and 11, scripts/run-suite.mjs and the scripts/lib files it imports (including conformance-page.mjs, which reads spec/conformance.md), scripts/adapter.mjs, engine/adapter.mjs, docs/integrating/your-own-engine.md and RELEASING.md.
Build a script that writes an archive containing cases/, the runner and exactly the files it imports, spec/conformance.md, adapter copies that import the engines from the installed openalgo-script npm package and the openscript PyPI package, an adapter template with a README, and the revision digest. Do not add it to a release workflow; show me the archive.
Prove it: create an empty directory, install Node 22, Python 3.12 and both packages at the same version, unpack the archive, run it against both adapters, and compare the result with npm run suite and npm run suite:engine.
Update your-own-engine.md to start from the archive.
Rules: no dependency; no code file over 500 lines; no eval; do not tag, publish or dispatch a workflow; no emoji; no em or en dashes.
Done when both runs match, the digest matches section 11, and npm test passes. Paste the results.

Agent brief: paste this into your agent

Task OS-S18 (maintainer) in marketcalls/openscript: write the rules a new engine is built under, and how a clean room works with an agent.
Read ROADMAP.md Phase 7 in full (the gate and the third engine item), spec/conformance.md sections 8 to 11, spec/decisions.md (the format of a decision), docs/integrating/your-own-engine.md, docs/integrating/the-python-engine.md and RELEASING.md.
Draft, for my approval before any file changes:
1. Where a new engine lives, and why.
2. The rules every engine keeps, stated so a reviewer can check each one in Go and in Java.
3. The clean-room protocol: what the builder and their agent may read, how a question becomes a spec change in public, and what session log is published with a result.
4. Two or three options for whether an agent-built engine can meet the Phase 7 gate, each with what it would prove and what it would not. Recommend one.
5. The profile ladder and the lockstep rule.
After approval, write the decision into spec/decisions.md and the page docs/integrating/new-engines.md, and link it from ROADMAP.md Phase 7 and your-own-engine.md.
Rules: change no engine code; no emoji; no em or en dashes; name no other product.
Done when the acceptance checks pass and npm test passes. Paste the summary line.

Agent brief: paste this into your agent

Task OS-S19: a Go engine for OpenScript, first step: read, verify and refuse a compiled program.
The clean room: work in a directory that holds only the suite archive (OS-S17), spec/ and the published docs. Do not open src/ or engine/ in marketcalls/openscript, and do not let your agent fetch them. Ask every question you have on the engine's issue; the answer is a change to spec/, never a pointer to code. Keep the session log the OS-S18 protocol asks for.
Read docs/integrating/new-engines.md (OS-S18), spec/compiled-program.md sections 1, 2, 9, 10 and 13, and spec/conformance.md sections 1, 8 and 9.
Plan first and post it on the issue: the packages you will create, the order you will build them in, and the first failing case you will make pass.
Build: canonical text in, a verified program or a documented refusal out. The adapter answers --describe (engine-only), <case-directory> and --actual <case-directory> exactly as section 9 says. Write the failing test first for every refusal.
Rules for every engine: the compiled program is data, so no eval, no code built from text, no dynamic loading and no reflection used to dispatch instructions; the standard library only; no code file over 500 lines; no emoji; no em or en dashes; name no other product.
Done when go vet and go test pass, go.mod has no requirements, and the runner reports every program category case as pass. Paste the result document summary and the list of spec questions you raised.

Agent brief: paste this into your agent

Task OS-S20: a Go engine for OpenScript, second step: run the machine.
The clean room: work in a directory that holds only the suite archive (OS-S17), spec/ and the published docs. Do not open src/ or engine/ in marketcalls/openscript, and do not let your agent fetch them. Ask every question you have on the engine's issue; the answer is a change to spec/, never a pointer to code. Keep the session log the OS-S18 protocol asks for.
Read spec/compiled-program.md sections 3 to 8 and 12, and spec/conformance.md sections 4, 8 and 10.
Plan first and post it on the issue. Then build the machine one section at a time, making one failing case pass before the next. Answer any library call you have not implemented as unsupported with the call named.
Rules for every engine: the compiled program is data, so no eval, no code built from text, no dynamic loading and no reflection used to dispatch instructions; the standard library only; no code file over 500 lines; no emoji; no em or en dashes; name no other product.
Done when go vet and go test pass, every semantics, runtime and limits case that needs no missing call passes, and the --against run shows no disagreement. Paste both summaries.

Agent brief: paste this into your agent

Task OS-S21: a Go engine for OpenScript, third step: the library the core cases call.
The clean room: work in a directory that holds only the suite archive (OS-S17), spec/ and the published docs. Do not open src/ or engine/ in marketcalls/openscript, and do not let your agent fetch them. Ask every question you have on the engine's issue; the answer is a change to spec/, never a pointer to code. Keep the session log the OS-S18 protocol asks for.
Read spec/stdlib.md section 20 in full (20.10 fixes the portable kernels; 20.11 lists what no case may assert), the stdlib.md sections for each entry you implement, docs/integrating/library-vectors.md and spec/conformance.md section 11.
List the entries the core cases call and post the list on the issue. Implement them one at a time, each against its library vectors, and never through the host's own math where section 20 fixes a portable algorithm.
Rules for every engine: the compiled program is data, so no eval, no code built from text, no dynamic loading and no reflection used to dispatch instructions; the standard library only; no code file over 500 lines; no emoji; no em or en dashes; name no other product.
Done when every implemented entry matches its vectors bit for bit, the engine-only profile reports zero failures and zero unsupported at a named revision, and the --against run shows no disagreement. Paste the result document.

Agent brief: paste this into your agent

Task OS-L1 in marketcalls/openscript: define the six surface channel shapes, then answer markers, bar colours and background in both adapters.
Read CLAUDE.md, spec/conformance.md section 4 (expected.csv and expected.json) and section 7, docs/integrating/running-the-suite.md, scripts/adapter.mjs, engine/adapter.mjs, src/adapters/charts/ (what each output looks like when drawn), and sections 23, 24 and 28 of spec/feature-matrix.md.
1. Draft the element shape of markers, fills, levels, barColors, background and alerts for section 4, including whether each is per bar in expected.csv or a list in expected.json. Show me the diff and wait for approval on the issue.
2. Project markers, barColors and background from the run's output in both adapters, in the approved shapes.
3. Add two or three cases per channel, including one with an absent bar, under the identifiers the matrix rows reserve. Read expected output from the spec.
4. Prove that an empty channel cannot pass a non-empty expectation: show it failing in the pull request, then remove the probe.
5. Update running-the-suite.md and flip the rows the cases prove.
If the plan shows more than five days, say so before step 2, and the three channels become two claims.
Rules: no eval; Python standard library only; no code file over 500 lines; do not edit existing cases; no emoji; no em or en dashes; do not tag or publish.
Done when npm run suite, npm run suite:engine, npm run suite:agree, node scripts/check-matrix.mjs and npm test pass. Paste the summaries.

Agent brief: paste this into your agent

Task OS-L2 in marketcalls/openscript: answer the fills, levels and alerts channels in both adapters.
Read CLAUDE.md, spec/conformance.md sections 4 and 7 (with the shapes OS-L1 added), docs/integrating/running-the-suite.md, the channel code OS-L1 added to scripts/adapter.mjs and engine/adapter.mjs, and sections 24 and 28 of spec/feature-matrix.md.
Goal: both adapters answer fills, levels and alerts the way OS-L1 answers the other surface channels, reusing its helpers.
1. Project the three channels in both adapters.
2. Add cases: a fill across an absent bar, a level with a moving value, and an alert that fires once per confirmed bar. Derive expected output from the spec under the reserved identifiers.
3. Remove the list of unanswered channels from running-the-suite.md and flip the rows.
Rules: reuse before adding; no eval; Python standard library only; no code file over 500 lines; do not edit existing cases; no emoji; no em or en dashes; do not tag or publish.
Done when npm run suite, npm run suite:engine, npm run suite:agree, node scripts/check-matrix.mjs and npm test pass. Paste the summaries.

Agent brief: paste this into your agent

Task OS-L3 in marketcalls/openscript: fill the empty categories and the missing frame and charge schedule shapes.
Read CLAUDE.md, spec/conformance.md sections 3 (frames.csv and backtest.json), 4, 7 and 8, docs/integrating/running-the-suite.md (What no case has yet), spec/host-interface.md 7.4, and spec/compiled-program.md section 9.
Goal: every category in section 7 holds a case, and a repeated frame, frames out of order and a host-supplied charge schedule are tested on both engines.
1. For any shape whose outcome the spec does not state, write the sentence first and show me.
2. Make the TypeScript adapter report compile warnings, so a warning case can pass.
3. Add one case each for warning, program (round trip, identical output), rejection, a repeated frame, two frames out of order, and a strategy that declares no commission run with a host-supplied schedule. Derive expected output from the spec.
4. Update running-the-suite.md.
Rules: compiler cases are skipped by the Python adapter by design; no eval; Python standard library only; no code file over 500 lines; do not edit existing cases; no emoji; no em or en dashes; do not tag or publish.
Done when npm run suite:agree, node scripts/check-matrix.mjs and npm test pass. Paste the summaries.

Agent brief: paste this into your agent

Task OS-L4 (maintainer) in marketcalls/openscript: write the Phase 8 decisions down while the build waits for the Phase 7 gate.
Read ROADMAP.md Phase 7 and Phase 8 in full (What this phase delivers, What has to be decided, Gate, Why it is after Phase 7 and not before), spec/stdlib.md 17.6 and 17.9 to 17.12, spec/host-interface.md section 9 (9.3 and 9.4 in particular), section 29 (the leg.fixed and leg.relative rows and the unresolvable description row) and section 35 of spec/feature-matrix.md.
1. Draft the ordering decision for spec/decisions.md and ROADMAP.md: decisions may be written before the Phase 7 gate, and the build waits for it.
2. For each of the four questions, draft a decision: the options, what each would cost both engines and a host, the cases it implies, and a recommendation. Do not choose for me. Keep the host and engine split of host-interface.md 9.3: the host resolves; the engine hands the description over before bar 0, records the resolved identity and refuses with OS6007.
3. Turn the ROADMAP.md build order into task drafts of five days or less, each with acceptance commands, marked as waiting for the gate.
Rules: spec wording only; no code; no dates; no emoji; no em or en dashes; name no broker or exchange.
Done when the drafts are ready for my review and node scripts/check-matrix.mjs passes on any reserved identifiers.

Agent brief: paste this into your agent

Task OS-L5 in marketcalls/openscript: build the language server message handler on the six editor functions.
Read CLAUDE.md, ROADMAP.md Phase 4, docs/integrating/the-editor-half.md, src/editor/ and its index, scripts/check-layering.mjs (the LAYERS table) and tests/editor/support.ts.
Goal: a pure function in a new module under src/editor that takes one language server message plus the handler's state, and returns the reply and any notifications. It is built only on highlight, complete, diagnose, hover, signature and format.
1. Cover initialise, open, change, diagnostics, completion, hover, signature help and formatting.
2. Add a golden test: for every script in examples/ and every MALFORMED entry, the published diagnostics equal diagnose's output.
3. Export it through the editor index only after I approve it on the issue.
Rules: no runtime-namespace import and no change to the LAYERS table; no dependency; no code file over 500 lines; no eval; name no editor product; no emoji; no em or en dashes; do not build the stdio wrapper.
Done when npm test and node scripts/check-layering.mjs pass. Paste the summaries.

Agent brief: paste this into your agent

Task OS-L6 (maintainer) for the OpenScript evals: build the authoring eval.
Read the eval decision from OS-N9, the grader and runner from OS-N11, docs/first-study.md, docs/first-strategy.md, docs/integrating/running-a-strategy.md, and spec/conformance.md section 3 (bars).
With me, write at least 40 test requests a trader would make. Fix every parameter (lengths, sources, entry and exit rules) and name every output, for example a plot titled Signal. An ambiguous request is a defect in the case. For each request I write or approve the reference script. Test requests go only to the private repository.
Make three bar sets as random walks with placeholder symbols: trend, chop, and gaps across sessions.
Extend the grader to compare named plots bar by bar with exact warmup indices, and, for a strategy, the trade list from the run record (entry and exit bars, side, quantity). Give the model under test one tool: compile, which returns diagnose output, and the pinned docs.
Prove the grader: the references pass, 40 seeded wrong scripts fail, and a second grading gives identical verdicts. Then run the baseline twice.
Rules: do not pick requests because a model fails them; the 12 published examples are train only; keep references out of the model's reach; name no product, broker or real instrument; no emoji; no em or en dashes.
Done when the grader checks pass and the baseline report is written. Paste its summary.

Agent brief: paste this into your agent

Task OS-L7 for OpenScript: generate an agent skill and hillclimb it on the authoring eval.
Read the library manifest and spec/errors.json, the AI assistants page on openalgo.in/script, the write-a-script baseline from OS-L6, and the campaign rules on the roadmap page.
1. Write a generator that produces the skill: the language rules, every library entry with its signature and one line, the planned names marked as refused, and the ten most common error codes with their fixes. Every fact comes from the manifest or the catalogue.
2. Write a coverage check that fails on any name not in the manifest.
3. Run the campaign on the hand-written guidance section only: one root cause per round, from train failures only, with each patch passing the overlap guard before it is scored. Start only when the spend cap is set.
4. Report the test score and the tokens per task for the skill against the full reference.
Rules: never quote a test request, reference script or transcript; generated sections are never edited by hand; name no other language or product; no emoji; no em or en dashes.
Done when the coverage check passes, the log is written and the comparison report is published.

Agent brief: paste this into your agent

Task OS-L8 (maintainer) in marketcalls/openscript: bring the Go engine into the release lockstep.
Read docs/integrating/new-engines.md (OS-S18), RELEASING.md, .github/workflows, scripts/run-suite.mjs and the agreement check in package.json (suite:agree).
Plan the CI lane and the release steps and show me before changing any workflow.
Build the lane (non-blocking until the Go engine's profile passed, blocking after), extend the agreement check to three engines, and update RELEASING.md. Do not tag, publish or dispatch a workflow.
Rules: no emoji; no em or en dashes; name no other product.
Done when a deliberate one-case disagreement fails CI on a draft pull request, the release dry run shows one version for all three engines, and npm test passes.

Agent brief: paste this into your agent

Task OS-L9: a Go front end for OpenScript, so the Go engine claims the core profile.
The clean room: work in a directory that holds only the suite archive (OS-S17), spec/ and the published docs. Do not open src/ or engine/ in marketcalls/openscript, and do not let your agent fetch them. Ask every question you have on the engine's issue; the answer is a change to spec/, never a pointer to code. Keep the session log the OS-S18 protocol asks for.
Read spec/language.md in full, spec/errors.md for every code the lexical, syntax, static and warning categories raise, spec/compiled-program.md sections 2 and 9, and spec/conformance.md sections 8 and 11.
Plan first and post it on the issue: lexer, parser, checker and emitter, and the first failing case for each.
Build one stage at a time. Test every diagnostic on its code and span, never on its message text.
Rules for every engine: the compiled program is data, so no eval, no code built from text, no dynamic loading and no reflection used to dispatch instructions; the standard library only; no code file over 500 lines; no emoji; no em or en dashes; name no other product.
Done when go vet and go test pass, the core profile reports zero failures and zero unsupported at a named revision, and every emitted program matches ours byte for byte or has a settled section 10 issue. Paste the result document.

Agent brief: paste this into your agent

Task OS-L10: a Java engine for OpenScript, first step: read, verify and run the machine.
The clean room: work in a directory that holds only the suite archive (OS-S17), spec/ and the published docs. Do not open the source of any other OpenScript engine, and do not let your agent fetch it. Ask every question on the engine's issue; the answer is a change to spec/, never a pointer to code.
Read docs/integrating/new-engines.md, spec/compiled-program.md in full and spec/conformance.md sections 1, 4 and 8 to 10.
Plan first and post it on the issue. Build the boundary first (canonical text, verification, refusals), then the machine one section at a time, making one failing case pass before the next. Use no script engine, no reflection to dispatch instructions and no dynamic class loading.
Rules for every engine: the compiled program is data, so no eval, no code built from text, no dynamic loading and no reflection used to dispatch instructions; the standard library only; no code file over 500 lines; no emoji; no em or en dashes; name no other product.
Done when the build and tests pass, every program, semantics, runtime and limits case that needs no missing call passes, and the --against run shows no disagreement. Paste both summaries.

Agent brief: paste this into your agent

Task OS-L11: a Java engine for OpenScript, second step: the library, the engine-only result and the lockstep lane.
The clean room rules of OS-L10 still apply to the engine code.
Read spec/stdlib.md section 20 in full, the stdlib.md section for each entry you implement, docs/integrating/library-vectors.md, spec/conformance.md section 11 and RELEASING.md.
List the entries the core cases call and post the list on the issue. Implement them one at a time against their vectors, never through the host's own math where section 20 fixes a portable algorithm. Then draft the CI lane and the RELEASING.md steps for the maintainer; do not tag, publish or dispatch a workflow.
Rules for every engine: the compiled program is data, so no eval, no code built from text, no dynamic loading and no reflection used to dispatch instructions; the standard library only; no code file over 500 lines; no emoji; no em or en dashes; name no other product.
Done when every implemented entry matches its vectors, the engine-only profile reports zero failures and zero unsupported at a named revision, and the lane fails on a deliberate disagreement. Paste the result document.