The CLI binary is `oma` and the scaffolder is `create-oma-app`, but the README headline still reads "Open Multi-Agent". This leads with OMA and keeps the full name in the first descriptive sentence, so it stays tied to the `@open-multi-agent/core` scope a reader is about to install.
Both language versions of both READMEs move together, and `CONTRIBUTING.md` follows. The historical CHANGELOG entry and the example catalog schema title are deliberately left alone.
No identifiers change: the organization, repository, package names, CLI binary, and every URL stay exactly as they are. Documentation only, so `git diff --check` is the applicable check and it is clean.
Lead both root READMEs with the self-hosted runtime, durable approvals,
and verifiable run records instead of the coordinator. Keep the H1 and
logo block, replace only the tagline block, and add the no-telemetry,
no-hosted-control-plane paragraph after the badges.
Give durable approvals, the verifiable journal, and the governance floor
one section each with source, test files, and current case counts.
Demote multi-agent coordination to an "Optional coordinator" section,
keep "Built with OMA" with the three most visible entries and a
collapsed long tail, and drop the intro paragraph, the framework
comparison pointer, the listing call to action, and the separate
commercial support section. The Chinese README states the contact
details in text instead of a WeChat QR image, which is removed.
Sync the tagline block in the core package READMEs, set the same
description on the root and core package.json, and remove the "killer
feature" wording from the orchestrator header comments.
DeepSeek retired the V4-Flash model and named the current generation
`deepseek-flash`, with no version in the name. `deepseek-v4-flash` is still
accepted, but DeepSeek documents it as a temporary compatibility name and
already serves those requests from V4.1-Flash.
The repository handed that name to users in the places most likely to be
copied: the `oma` CLI default for `provider: 'deepseek'`, the adapter JSDoc
that ships in the type declarations, the provider table in docs, the
scaffolder env template, and every DeepSeek example. A copied name that the
vendor calls temporary has an expiry date the reader cannot see.
The provider table and the adapter JSDoc also stated that `deepseek-v4-flash`
resolves to DeepSeek-V4-Flash-0731. That model is retired, so the sentence
described a routing that no longer happens.
Two corrections of the same kind travel with it. The thinking-mode note
claimed the V4 models run at `high` effort, but the adapter forwards whatever
effort the caller passes and sets none itself, so the claim is dropped rather
than restated. Three `examples/basics` headers offered `deepseek-chat`, which
DeepSeek retired outright on 2026-07-24 and which no longer resolves at all.
The release bot moves to the same name. Callers that pass an explicit model
are unaffected, and the old name keeps working for as long as DeepSeek
accepts it.
Left unchanged on purpose: `bench/config.json`, whose values are frozen
controls for an already-run benchmark; the AtlasCloud pages, whose IDs come
from that vendor's own model library; and the changelog history.
Systematic documentation review: 12 new docs pages (coordinator, streaming, budgets and limits, errors, hooks and callbacks, glossary, production checklist, Run Viewer, MCP, sandbox and shell, evaluation in CI, routing evaluation) plus a docs index; the three longest guides split with stub sections that keep existing anchors; observability release records moved to docs/internal; statements re-verified against the code and corrected; READMEs, AGENTS.md, CONTRIBUTING.md, and issue templates synced. Documentation only, no behavior change.
The 2026-09-04 weekly run failed with a structured-output validation error, but
the output ceiling was the real cause. change-analyst spent 19,822 characters of
reasoning against its 4,500-token cap and returned empty text, so there was no
JSON to validate. The single in-run correction that followed emitted malformed
JSON, and both dependent synthesis tasks failed with it.
This is the second time the same defect has broken the weekly cadence. #519 hit
it on release-reviewer at 3,500 tokens with the identical signature, empty text
after the budget went to reasoning, and fixed it by disabling thinking for the
two synthesis agents. That treated the symptom on the wrong axis and left the
two evidence roles carrying the same bug.
Reasoning and the answer are billed against one budget, so the ceiling is now
sized for both: a single 64,000-token limit shared by every role, roughly
fourteen times the reasoning this run actually produced. An unused ceiling costs
nothing, and the run-level token budget cannot stand in for it because it is
only checked after a call returns, never during one.
With the budget no longer the binding constraint, thinking goes back on for the
synthesis agents and every role moves to DeepSeek's max effort.
The three timeouts move as one chain, because raising the token ceiling alone
would have traded a validation failure for a timeout. An evidence role's worst
case is a tool turn, an answer, and one correction, so 3 x 180s fits inside its
600s. The DAG's worst case is the evidence pair in parallel and then both
synthesis agents in series, so 3 x 600s fits inside a 30-minute deadline, raised
from 10. That leaves the job's 45-minute timeout room for checkout, install,
build, and the deterministic PR work that follows the analysis.
The orchestrator test now asserts the per-role thinking config alongside the
token ceiling. #519 removed thinking from two agents with no assertion to record
it, which is part of why the regression stayed invisible.
Refs #574.
`publish.yml` decided whether a commit on main was a release by asking
whether packages/core/package.json and packages/create-oma-app/package.json
had changed at all. Those two files carry more than a version: dependency
specs, `exports`, `files`, `engines`, keywords. Any edit to either one read as
a release.
98516ce was the first commit to hit it. It only pinned dependency specs, and
neither version moved, but both manifests changed, so `detect_release_commit`
reported `is_release=true` and the publish job started. It entered the
`npm-release` environment, minted a contents:write GitHub App token, checked
out, installed, built, and then stopped at the publisher's own guard:
98516ce... is not a release commit: @open-multi-agent/core did not
increment from its first parent.
Nothing was published, tagged, or released, and the registry versions are
untouched, so the safety net did its job. But the outer gate should not have
opened. A dependency bump is the most ordinary maintenance there is, and it
should not cost a write-scoped token and a red Publish run every time.
The detection now reads the `version` field of both manifests at the release
commit and at its first parent and stops unless both moved, which is the same
fact the publisher re-derives later. A manifest that does not exist at the
release commit is a no-op rather than an error, matching what the old file
comparison concluded for the pre-monorepo tags. A manifest that exists but
declares no version fails the job, because that is a broken tree rather than
an ordinary commit.
It also closes a fail-open path found while building the check harness.
`git diff --quiet` exits 1 for "changed" and 128 for "could not run", and the
old step read both as "changed", so any git failure resolved to
`is_release=true`. Reading the version field fails closed instead. Unreachable
in practice, since checkout and the ancestry verification both run first, but
a publish gate should not lean on that.
Checked against every `v*` tag in the repository. All three tags from after
publish.yml existed — v1.16.0, v1.16.1, v1.17.0 — still detect as releases,
as do v1.8.0 through v1.10.0 and v1.13.0 through v1.15.0. v1.11.0 and v1.12.1
now report false because their tagged commits genuinely did not move both
versions; both predate this workflow, and the publisher would have refused
them for exactly that reason, so the gate now agrees with the publisher
instead of deferring the disagreement to a failed job.
A library that gets installed into someone else's backend is judged partly on
what its own install pulls down. Three changes tighten that, and two questions
turned out to need no change at all.
The line this draws is what ships. Every dependency that stays inside the
repository is now pinned to the exact version the lockfile already resolved:
all 27 devDependencies across the four workspaces, plus the private release
bot's own zod. The lockfile change is 28 spec lines with no
resolution moved, no entry added or removed, and all 61 platform-specific
entries intact. A new root .npmrc sets save-exact=true so the next one arrives
pinned rather than as a range nobody notices.
What a consumer installs keeps its range: `dependencies` in packages/core, the
only published runtime block here, every `peerDependencies`, and otel's core
compatibility range. An exact version in those blocks overrides the consumer's
own resolution and stops their `npm audit fix` from reaching a patched build
until we cut a release, which is a worse trade than the install-time drift it
prevents. save-exact will still pin a new dependency added to one of them, so
the package job now asserts all three published manifests and fails when one
is left exact, next to the assertion that already covers otel's range.
min-release-age is deliberately not set. It first shipped in npm 11.10.0, and
the CI matrix runs Node 20 and 22, which bundle npm 10.8.2 and 10.9.8. Those
two accept the key, echo it back from `npm config get`, and never act on it,
so a quarantine window would hold on one leg of the matrix while silently
doing nothing on the other two. It also has no effect on `npm ci`, which
installs the lockfile verbatim.
Every `npm ci` that installs this repository's own tree now passes
--ignore-scripts, so a compromised dependency cannot run an install hook on a
runner that holds release credentials. Only three dependencies declare a
postinstall at all, and the full lint, test, build, scaffold, and example
suites pass on a tree installed that way. The `npm install` calls that stand
in for a real consumer are deliberately left alone: their job is to reproduce
what a user's install actually does, and hardening them would make the smoke
tests prove less than they claim.
A new scheduled Supply chain audit workflow asks two questions about the
dependencies that reach a consumer, an hour before the weekly release bot so a
finding lands before the release PR is drafted. --omit=dev is the point of
running it separately: auditing the full tree reports eighteen advisories,
every one of them in test and fixture tooling that never ships, and a
permanently red job is one nobody reads. The two steps fail differently.
`npm audit` reports into the run summary, because a new upstream advisory is
not this repository misbehaving and may have no fixed version yet.
`npm audit signatures` fails, because it compares served bytes against the
registry's own signature, so a mismatch is tampering rather than churn; all
27 production packages verify today.
Two things needed no change. npm provenance is already live: publish.yml
publishes through npm trusted publishing with id-token: write, which attaches
SLSA attestations on its own, and every version since core 1.16.0, otel 0.1.2,
and create-oma-app 0.8.1 carries one. And .npmrc left .gitignore in #198
because it only restated the default registry; it comes back tracked, with the
ignore rule narrowed so a contributor's own nested .npmrc stays out.
The PR checklist existed twice, in .github/pull_request_template.md and in
CONTRIBUTING's "PR Checklist" section. Both were written in #381 and had
already drifted: four items against five, different wording for the same
four concepts, and "The PR links a relevant issue when one exists" present
only in CONTRIBUTING. Keep the checklist in the template, where the work
happens, add the missing fifth item, and leave CONTRIBUTING pointing at it.
The template also carried no outbound link of any kind, including on the
line that referred to "the package ownership boundaries documented in
CONTRIBUTING". Relative links do not resolve inside a PR body, so the added
links are absolute.
Neither file stated the PR title convention, although every merged PR
follows it. squash_merge_commit_title is COMMIT_OR_PR_TITLE, so on a
multi-commit PR the title becomes the commit subject, and RELEASING.md
reads a conventional-commits `!` marker on a merged commit as a
breaking-change signal. Say it once, at the top of the template.
The issue templates asked reporters for Acceptance criteria, Target paths,
Out of scope, Open decisions, and Blockers. Those are machine-readable
fields added in 098371c for the maintainer issue-to-PR bot; #520 removed
the bot but left the fields, so outside reporters were still asked for
exact repository-relative paths with no globs. Both templates now match
098371c^ byte for byte, which also drops the dangling "Maintainer Bot will
route the issue to manual handling" comment.
The Thanks section fell back to the commit's display name whenever the
author's address was not a GitHub noreply. A display name is not a handle
and can belong to someone else: v1.17.0 credited `s4kura` for #549 when the
author's login is `Iams4kura`, an account another person holds. The previous
release only looked correct because that contributor's commits happened to
carry a noreply address, so correctness rode on an email privacy setting.
Ask GitHub which account claims the commit when the address does not carry a
login. The lookup is best-effort and cached per address, so an unlinked
address or a failed request degrades to the previous behavior rather than
failing a publish over a name.
GitHub never delivered the Friday 2026-08-28 trigger; no run record exists
for it. The daily provider canary shows why: its 03:17 UTC schedule ran
~40 minutes late through 08-26, then 10h50m late on 08-27 and 12h01m late
on 08-28. GitHub delays or drops schedules under load, and the top of the
hour is the most contended slot.
Move the trigger to :23 and update the release order documentation so the
documented time matches the workflow.
The published body was the changelog section and nothing else, so a reader
of a release page could not tell which packages shipped, how to install
them, or who contributed. green3sf landed #536 and #541 in 1.16.1 and the
release page credited nobody.
Three deterministic sections now follow the changelog section:
- `## Packages` names every workspace version and reports the ones this
release left alone, derived by comparing the release commit's manifests
against its first parent.
- `## Thanks` credits contributors from outside the project, resolved from
the commits between the previous release tag and the release commit. Bot
commits and the maintainer's own are excluded, and the section is omitted
when nothing remains. Names are plain rather than mentions, because a
published body that mentions an account notifies it.
- `## Install` is copy-pasteable.
The whole body is still composed before anything reaches the npm registry,
so a malformed changelog or an inconsistent manifest set keeps failing
ahead of publication rather than after it.
The previous tag is resolved from the release commit's first parent rather
than from HEAD. On an idempotent re-run this release's tag already exists,
and describing from HEAD would report an empty range and silently drop
every contributor from the body.
Two consecutive Friday runs failed without anyone noticing, and the one
that was noticed reported only "OMA release analysis failed." with no
cause at all. Both gaps are closed here, with the smaller defects the
same investigation surfaced.
- Name the cause when a run fails without any agent failing. A token
budget stop leaves later tasks skipped and every agent result
successful, so the message degenerated to a bare sentence and sent the
reader to the raw [OMA] progress log. It now carries the run status
with token totals, the run's error kind and flags, and every unfinished
task with its status.
- Report a failed run as a GitHub issue, opening one or commenting on the
open one. A weekly job whose only failure signal is the Actions tab is
a job nobody reads. It uses the built-in token, so it needs no App
permission and no new secret.
- Define what earns a changelog entry in the release contract. The bot
reads .github/RELEASING.md as evidence, so the rule applied by hand in
#523 and again in #543 is now applied by the bot itself.
- Retry the two synthesis tasks once, so a provider timeout or 5xx no
longer ends the run. They carry no tools and read a few thousand
tokens. The evidence tasks stay at zero because a second attempt
re-calls their tools and would trip the exactly-one-call coverage
assertion. Schema failures stay terminal either way.
- Separate comment-only diffs from behavior changes in the compatibility
auditor's instructions. It reported a JSDoc-only edit as a latency and
cost risk in #543.
- Echo the three validation commands. They dominate the step's wall clock
and produced no output at all, so a hang there was indistinguishable
from a slow model call.
The whole-run token ceiling becomes a named, validated option so the
budget-stop path is testable.
* fix(release-bot): map create-oma-app bump to core's breaking nature
Core-only releases previously forced a create-oma-app patch bump regardless of core's bump class. create-oma-app is still 0.x, so its minor position carries the breaking signal: a core major (breaking) bumps create minor, while non-breaking core bumps stay patch.
* fix(release-bot): drop stale Unreleased content from changelog
The planner's changelog is the single source of truth for a release; ## Unreleased already fed it as reference evidence. Re-appending the Unreleased body produced duplicate Added/Changed/Fixed sections.
* fix(release-bot): disable thinking for synthesis agents
The release-reviewer runs with thinking effort high and maxTokens 3500. Its reasoning consumed the whole output budget (two attempts at ~3500 reasoning tokens each, empty text both times), so it never emitted the JSON releaseReviewSchema requires and structured-output validation failed after retry, failing the release closed. Disable extended thinking for the two synthesis agents (planner and reviewer) so they emit structured output directly. The two evidence agents keep high-effort thinking.
* chore: remove maintainer issue-to-PR automation
Removes the maintainer-bot, maintainer-host, maintainer-runtime, and
maintainer-harness-canary workspaces, their GitHub Actions workflows, and
their documentation. This issue-to-Draft-PR automation is removed in favor
of a local maintainer workflow.
Load a narrowly scoped AppArmor profile for /usr/bin/bwrap on Ubuntu 24.04 while preserving the global user namespace restriction and fail-closed diagnostics.
Add a read-only Claude Code and DeepSeek harness canary with deterministic validation, credential isolation, bounded artifacts, and documented promotion gates.
The live maintainer canary showed that IssueComment GraphQL actors expose the App slug without the REST [bot] suffix, causing the strict provenance check to fail after STARTED. Verify the exact Bot database ID and type across workflow and host paths while retaining REST identity and editor checks.
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.
* 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.
* 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
* feat(dashboard): surface per-task model, provider, and cost in Run Viewer
Roll each task's descendant LLM spans up into task-level model/provider/cost via the span parent chain (LLM spans carry these but no taskId), so the task panel shows what a task actually used instead of Not recorded. Also render task UUIDs as 8-char short ids (full id kept in tooltip and data-task-id).
* docs(brand): regenerate hero from a real run with cost; add MP4
Inject real DeepSeek list-price cost onto LLM spans in the hero capture, regenerate the Run Viewer snapshot and GIF, and commit the H.264 MP4 (previously written only to a gitignored dir).
* docs(readme): trial inline MP4 hero via jsDelivr CDN
Branch-only experiment to check whether GitHub autoplays a hand-authored video tag; GIF kept as poster and fallback. Revert to the GIF img if autoplay is stripped.
* docs(readme): keep GIF hero (GitHub strips external-src video)
The trial video tag is dropped by GitHub's sanitizer because its src is not a GitHub-hosted asset, taking the fallback img with it. Restore the original GIF img hero.
* feat(dashboard): show tool-call count on task detail; refresh hero
Task detail shows Tool calls: N instead of an N/A Tool row, so the task panel has no remaining Not recorded fields. Re-record the hero GIF/MP4 and refresh the snapshot HTML.
* feat(brand): swap hero demo to a JWT-auth run built by a specialist team
Replace the generic Express CRUD capture with a JWT (HS256) auth module built by five specialists (architect, backend-dev, qa-engineer, security-analyst, reviewer) in a 3-way parallel fan-out (implement + tests + threat-model) converging on an integration review, so the hero reads as work that needs a team. Harden the agent prompts (pinned filenames, minimal per-role tool grants, node --check only) so the capture runs clean on the first pass.
* docs(readme): list packages instead of a table to stop name wrapping
The two-row Packages table squeezed the Package column in the English README and wrapped the package names across lines. GitHub strips <nobr> and inline style, and non-breaking hyphens would break npm install copy-paste, so switch to a bulleted list where each name sits on a full-width line. Applied to README_zh.md too for parity.
Assert the otel tarball ships only dist/, README.md, LICENSE, and package.json with its entry points present, smoke-test the built entry import, and scan core src for @opentelemetry references since workspace hoisting makes the import-based check toothless.
run a post-release smoke test against create-oma-app and core from the public npm registry
scaffold the recommended PR-review cloud starter and verify both its declared and installed core version match the GitHub Release tag
retry registry propagation with online-preferred resolution, then prove the generated demo reaches the expected missing-key gate
use a fresh project directory per retry so failed attempts cannot contaminate later attempts
Reverts the sponsor content added in #219:
- Drop the 'Provider community offers' section and MiniMax offer bullet
from README.md, README_zh.md, and the packages/core mirrors
- Delete docs/providers/minimax.md (offer-specific setup guide)
- Delete .github/brand/minimax-banner.png (used only by that guide)
MiniMax stays supported as a neutral provider: the provider table in
docs/providers.md, the MINIMAX_BASE_URL note in docs/cli.md, the
examples/providers/minimax.ts sample, and contributor credits are all kept.
Adds an enterprise services (企业服务) section to the Chinese homepage README, placed after the Quick Start section.
What it includes:
One-line offering: AI adoption consulting and commercial support for internet, manufacturing, and traditional enterprises
WeChat QR code for contact (.github/brand/wechat-qr.jpg)
Link to the company site yuanasi.com
Scope: Chinese-only by design, since the WeChat QR targets a Chinese audience. English and package READMEs are unchanged.
Unit tests call scaffold() directly and never exercise the packed tarball.
Add `npm run test:scaffold`: pack the scaffolder, generate a project in an
isolated temp dir, install, and run the demo to the missing-key gate, proving
the published bytes scaffold, install, and load end-to-end. Wire it into CI as
a scaffold-e2e job. Core installs from a local tarball so the test validates
the current commit and stays green during the release window.
Add a build-output import smoke test plus oma help check to the package job; concurrency with cancel-in-progress; contents read-only permissions; per-job 15-minute timeouts; split lint into its own job so the type check no longer repeats across the Node matrix.
npm's package-name similarity protection permanently rejects the
unscoped `create-oma`, so the intended `npm create oma` could never
resolve for users. Rename the package and command to `create-oma-app`
/ `npm create oma-app` so the one-command first run actually works;
the `-app` suffix keeps the OMA name and reads naturally.
Pure rename — package name, bin, directory, the command text in the
scaffolder and READMEs, and the CI workspace/path references. The
generated demo and template are unchanged. Published to npm as
create-oma-app@0.1.0.
Jack Chen