- separate application-owned data from model-visible text, image, and file content
- map rich results across built-in adapters and preserve them through recovery
- retain backward compatibility for string tools and text-only errors
Closes#466
`docs/tool-configuration.md` described the automatic `runTeam()` route as
Hybrid by default and told readers to set
`executionRouting: { strategy: 'deterministic' }` to restore no-profiler
behavior. Both halves are inverted, and they contradict the 1.14.0
Compatibility note in the changelog, `docs/execution-routing.md`, and the
core README.
The text is a leftover from before e0e4cf6 ("fix(core): make hybrid routing
opt-in"), which updated `docs/execution-routing.md`,
`packages/core/README.md`, and `docs/evaluation.md` but not this file.
The implementation agrees that Hybrid is opt-in:
- `types.ts` documents `deterministic` as the `strategy` default.
- The orchestrator resolves `strategy ?? 'deterministic'` for both the
constructor config and the per-run override.
- Semantic profiling is gated on `strategy === 'hybrid'`, so the default
path makes no profiler call.
- `semantic-routing.test.ts` asserts that an orchestrator configured with no
`executionRouting` produces no `semanticRoutingAssessment`.
Point the corrected sentence at `docs/execution-routing.md`, which already
owns the strategy details, and rewrap the paragraph that the stale edit left
broken mid-sentence.
A repository-wide scan found no other occurrence of the inverted claim.
1.14.0 raised the engines floor to Node 20 and moved openai from v4 to v6,
but shipped as a minor with no breaking-change notice. The conventional
commits `!` marker on the dependency upgrade never reached the changelog or
the release, so a `^1.x` caller on Node 18 received it with only an
EBADENGINE warning.
- CHANGELOG.md opens 1.14.0 with a Breaking changes section, collecting the
Node floor, the openai major, and the newly rejected plans that were
scattered across Changed and Compatibility.
- RELEASING.md gains a breaking-change decision step that runs before the
release commit, and records that release bodies are rendered with GFM hard
line breaks, so changelog text pasted at 80 columns renders as truncated
lines.
The root README put its first line of code roughly four screens down and the
snippet a reader lands on could not be run as written.
Lower the cost of the first run:
- State that `OPENAI_API_KEY` is required, and link to the provider docs. The
snippet declared `defaultProvider: 'openai'` but never said which credential
to set.
- Read the model from `process.env.OMA_MODEL ?? 'gpt-5.4'`, matching the core
README, the scaffolder templates, and the examples. The root copy was the
only one pinning a bare model id.
- Print the task graph the coordinator generated at runtime, so the "describe
the goal, not the graph" claim has evidence in the one place readers look.
Reduce the distance to that snippet:
- Move Get started above Why OMA.
- Flatten Why OMA from three bullet levels to two, 298 to 241 words.
- Tighten the Built with OMA entries, 295 to 259 words, order unchanged.
- Drop the stars, forks, and hardcoded TypeScript badges, 7 down to 4. GitHub
renders the first two natively just above the README, and the third needed a
manual bump on every TypeScript upgrade.
- Align the English commercial support section with the Chinese one, and stop
duplicating the scaffolder flags that the core guide owns.
Measured on the rendered page with main as the control, same viewport and
content width: the first code block moves from 1569px to 730px relative to the
README body, which is screen 4.2 to screen 3.1 at a 720px viewport.
Both snippets type-check against the built core package types.
The root `npm audit --omit=dev` reported two `fast-xml-builder` advisories,
GHSA-5wm8-gmm8-39j9 (high) and GHSA-45c6-75p6-83cc (moderate), reached through
`@aws-sdk/client-bedrock-runtime@3.1040.0`.
Consumers were never exposed. The Bedrock SDK is an optional peer dependency,
so a plain `@open-multi-agent/core` install resolves four packages, contains no
`@aws-sdk` directory, and audits clean. The advisories only ever sat in this
repository's own development tree.
`packages/core/package.json` already declares `^3.1040.0`, which permits the
fixed version, so only the lockfile pin held the vulnerable chain in place.
Refresh it to 3.1101.0, whose dependency tree no longer contains
`@aws-sdk/xml-builder`'s `fast-xml-parser` chain at all. No manifest changes.
Bump the three published packages for the coordinated npm release of the work
merged after v1.13.0, pin every generated starter to core 1.14.0, and finalize
the 1.14.0 changelog.
Core ships adaptive plan recovery, opt-in hybrid semantic execution routing,
DeepSeek V4 Flash reasoning controls, globally enforced task requirements, and
fail-closed validation for task DAGs and coordinator plans. The engines floor
moves from Node 18 to Node 20 across all three packages, so otel is republished
to carry that change; its core dependency range stays ^1.11.0.
#453 retargeted OpenAI to v6 and retained Node 20, and lowered the AI SDK
development dependencies in the same pass. Core still declares
`ai: ^5.0.0 || ^6.0.0 || ^7.0.0` as an optional peer range, so the AI SDK 7
support added in #348 was left without any test coverage.
Restore `ai` to ^7.0.0 and `@ai-sdk/openai` and `@ai-sdk/provider` to ^4.0.0
so the adapter is exercised against the newest range the package advertises.
These are development dependencies only, so no published bytes change.
`ai@7` declares `engines: node >=22` while core supports Node 20, so the
Node 20 leg now logs EBADENGINE warnings. The repository sets no
`engine-strict`, so installation still exits 0 and the full suite passes.
Refs #348, #453
* ci(release-smoke): verify the published OTel adapter against the released core
@open-multi-agent/otel rides its own version track and carries no git tag, so
the post-publish smoke test covered core and create-oma-app but never otel.
Add an otel-consumer job that reads the otel version from the release commit,
installs it alongside the released core in a clean consumer, asserts npm
resolved the core we just published rather than quietly falling back to an
older one the dependency range still allows, and exports a span through
createOtelTraceSink.
When otel did not change in a release, its version is already live from an
earlier one and the job still proves the pairing holds against the new core.
* docs(release): document the three-package release process
The repository publishes three packages with independent version tracks, a
fixed publish order, and template pins that must move with the core version.
None of that was written down, so it had to be reconstructed from package
manifests, git tags, and the workflows each time.
Record what ships, the ordered steps and why each depends on the previous one,
what a release commit must contain, and what CI proves before merge versus what
release-smoke proves after publish.
* docs(agents): sharpen the architecture map and link the release guide
Replace the per-area entry point table with the directory layout plus the
published export surface, which stays accurate as subsystems move. Mark the
subsystem documentation table as a curated selection rather than a complete
index of docs/, and add the routing, scheduling, consensus, recovery, and
replay docs to it.
Link the new release guide, and add the Claude Code shim next to the existing
packages/create-oma-app/AGENTS.md so package-level rules load there the same way
they do at the repository root.
Map OMA thinking controls to DeepSeek's native request shape, keep the provider-specific max effort isolated from other OpenAI-family adapters, and refresh model guidance and canary coverage.
* chore(deps)!: upgrade OpenAI SDK to v7
Require Node.js 22 across packages, starters, and CI. Add real SDK boundary coverage and reject unsupported custom tool calls explicitly.
Refs #391
* fix(core): classify OpenAI user aborts as cancellation
Use the SDK error constructor name because OpenAI v7 APIUserAbortError retains the default Error name. Cover retry and observability classification with the real SDK class.
* chore(deps)!: target OpenAI v6 and retain Node 20
* docs: simplify Node runtime guidance
Pins the four recovery cases from the #312 discussion against the
current task-level checkpoint granularity, each with its expected
idempotency outcome stated inline:
- case 1, clean resume: a completed task's committed effect replays as
data, never re-executes
- case 2, documented gap: a committed effect inside an unfinished task
re-executes on resume (['B','B'] pinned; per-call commit records
should flip this expectation to ['B'] deliberately)
- case 3, missing result: an in-flight call that never committed is
safely re-run (must survive #312 unchanged)
- case 4, duplicate replay: restoring a final checkpoint twice performs
no new work
Plus a field-loss report: the persisted snapshot carries the completed
task's result but has no field that could carry a per-call commit, so
resume cannot distinguish committed-then-crashed from crashed-before-
commit. That absence, stated as a passing test, is the gap #312 closes.
No production code changes. checkpoint.test.ts: 26/26 passing.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The eval CLI tests and the two example smoke scripts located tsx with a
fixed number of `..` segments, assuming a hoisted install directly above
the workspace. A git worktree has no local node_modules and resolves
upwards to the main checkout, and a non-hoisted install keeps
node_modules inside the workspace, so the path pointed at nothing:
spawnSync failed to launch and 12 tests reported `status: null` instead
of a CLI exit code.
Resolve `tsx/cli` through Node's own module resolution behind a shared
tests/helpers/tsx-cli.ts, and spawn it with process.execPath rather than
executing the node_modules/.bin shim, which is a .cmd wrapper on Windows
that spawnSync cannot launch without a shell. `.bin/tsx` already links
to the same dist/cli.mjs, so the spawned command is unchanged.
Contributors can now run the full core suite directly from a worktree
without hand-linking tsx.
Jack Chen