0.10.0: clearer operations and lighter Agent integration

Release pairing: Core 0.10.0 / MCP and Agent Client SDK 0.8.0 / DSH plugin 0.8.0. ACC 1.0.5 remains an independent specification.

A complete page design should not fail at a small argument limit before reaching the business system. Finding one tool should not load unrelated documents. Version 0.10.0 brings the accumulated console and Agent integration work together while preserving authorization, approval, original results and duplicate-execution protection.

• Console interaction: clearer onboarding, calling examples, permissions, approval reruns and status. Unsaved forms are protected; diagnostics, filters and tabs retain context; routine drawer guidance moves into help icons.
• On-demand guidance and knowledge: Agent clients with retrieval support explicitly negotiate bounded hints, then search and read within their current authorization. Full tool guidance is fetched when needed. Required rules, permissions and tool schemas stay in place. Native and embedded chat keep their existing knowledge assembly.
• Complete bounded arguments: arguments JSON is limited by serialized UTF-8 bytes at 1 MiB, with a 2 MiB HTTP envelope. Business field and storage limits remain independent. Oversized calls report that they were not dispatched, with safe size information.
• Per-model output budgets: the default request budget, service ceiling, supplier parameter and whether reasoning shares the budget are explicit. Legacy services keep their behavior. New policy does not rewrite saved model operations or business calls.
• Continuation and recovery contracts: original finish reasons are preserved, and lost receipts are inspected under the original ID. After confirmed truncation, a host saves progress and prepares a bounded new model step. Completed tools reuse original invocations and results; uncertain writes require reconciliation. Updating Core, SDK or DSH does not mean every host implements automatic continuation.
• Runtime and upgrade diagnostics: readiness checks the actual state/configuration databases and migration checksums. Startup recovery and close retain shared drain boundaries. An offline upgrade plan compares trusted artifacts and sanitized snapshots without migrating or rolling back.

Upgrading

Upgrading public 0.9.4 adds no SQL migrations. Earlier versions still apply outstanding migrations, including 068. State and configuration databases may differ; verify each actual database and migrate a shared database once. Preserve configuration, credentials, attachments, original operations, approvals, notifications and migration history.

Use Core 0.10.0 with SDK/MCP 0.8.0 and DSH 0.8.0 for the new Agent features; older clients retain their compatibility paths. Operators explicitly enable model-budget policy for each supplier route. A custom MySQL state store supplies its actual query resource for readiness; otherwise readiness fails closed.

Pin exact artifacts and commits. Before rollback, stop admission, drain work and validate the code/configuration/data combination in isolation. No new SQL does not make every old client or configuration safe to restore. Deployment and host acceptance remain separate from publication.

Full 0.10.0 notes · Upgrade guide · Agent knowledge API · Output budgets · Continuation and recovery · SDK 0.8.0 upgrade

Historical 0.9.4: DOCX dependency reduction and durable notifications

The original 0.9.4 notes follow. Their 068 requirement for older versions does not mean rerunning the migration when upgrading from 0.9.4 to this release.

Pairing at the time: Core 0.9.4 / MCP and Agent Client SDK 0.7.0 / DSH 0.7.0. ACC 1.0.5 and independent client packages are not bumped for this patch.

When a job finishes before its notification is sent, a process interruption should not silently erase that notification. Version 0.9.4 saves the intent alongside its owning state transition and adds bounded recovery and operator reconciliation.

• DOCX dependencies: Core and its bundled console use the same source-pinned Mammoth 1.12.0 library distribution with the original parsing source and license. The unused CLI and argparse → sprintf-js chain are removed. The time-limited vulnerability exception is retired; source, installed archive and original-package advisories are checked. This does not claim that the upstream vulnerability is fixed.
• Durable intents: built-in MySQL saves job terminal state and notifications in one transaction; approval notifications are committed in the approval’s configuration database. Single-writer JSONL syncs one compound log record. Startup and maintenance recover saved intents with lease-fenced acknowledgements. Historical completed jobs and old approvals are not automatically backfilled.
• Bounded recovery: Webhooks await the actual response and reuse X-Bailing-Event-Id and signed-body notification_event_id. Network failures, 429 and 5xx receive bounded backoff retries; ordinary 4xx stop. Lost acknowledgements can still cause repeat delivery, so receivers should deduplicate event IDs. Partial or unknown native-channel delivery stays uncertain until an operator reconciles it.
• Console and metrics: Tasks → Notification delivery offers filtered summaries and permission-controlled retries. Unknown delivery requires explicit duplicate-risk confirmation. A retry never reruns the business parent. Fixed-source metrics expose persistent state counts, oldest pending age and expired leases without notification bodies, recipients or credentials.

Back up and coordinate old writers, then explicitly apply 068_notification_outbox.sql to the state and configuration databases actually in use. They may be separate databases; startup does not migrate automatically. Older versions also require outstanding migrations. Notification snapshots can contain business content and destination addresses and need corresponding data protection. Third-party stores without durable ports retain their legacy compatibility path without a durability claim.

completed means this notification step completed, which may only mean admission to a durable notification executor; it does not prove receipt or reading. Ordinary monitoring alerts remain best effort, JSONL remains single-writer, and this version adds neither automatic notification-history cleanup nor exactly-once effects across systems.

Before rollback, stop new admissions and notification workers and preserve the outbox, dead letters, migration history and external receipts. Older versions cannot consume the new outbox, and restoring a backup cannot undo messages already sent. Validate a consistent code, configuration and database combination in isolation and reconcile sent events. Deleting records or merely switching old code is not lossless recovery. A Core release does not establish upgrades of commercial Hosts, self-hosted instances or clients.

See the full 0.9.4 notes, patch upgrade guide, notification durability, DOCX dependency provenance, and capability/evidence index.

Historical 0.9.3: bounded downloads, notification drain and dead-letter replay

The following retains the 0.9.3 patch notes. Its lack of a durable outbox describes that version only; its 067 requirements do not replace the 068 migration required by 0.9.4.

Pairing at that release: Core 0.9.3 / MCP and Agent Client SDK 0.7.0 / DSH 0.7.0. ACC 1.0.5 and independent client packages are not bumped for this patch.

This patch bounds tool and attachment downloads, waits for accepted notifications before graceful shutdown, and repairs executor-notification dead-letter replay.

• Bounded downloads: tool HTTP bodies default to 5 MiB; remote files retain max_bytes, and channel attachments are limited to 20 MiB. Declared length is checked early and actual fetch-decoded bytes are checked per chunk. Over-limit bodies are cancelled and partial content is discarded. HTTP 200 headers alone do not confirm a business write; existing unknown-result and deduplication paths remain. Model and audit views have separate UTF-8 byte limits.
• Notification drain: each Kernel tracks the actual completion work for callbacks, notification children, approval webhooks, alerts and DLQ writes within the existing close budget. Standalone first stops and waits for started maintenance producers. A timeout retains the original instance resources so close can be retried on that same instance after its work completes.
• Dead-letter replay: native channels use their original sender; executor dead letters requeue only the validated original notification child, never its business parent. Persistent replay markers and atomic admission prevent duplicate queueing for the same dead letter after concurrent requests, lost acknowledgements or resolve failures. queued confirms admission, not receipt.
• Maintenance metrics: read only the current owner’s in-flight work, failures, drain timeouts and latest settlement/approval page progress. Fixed, low-cardinality labels contain no accounts, job identifiers or business payloads. These counters are not database-wide backlog totals or delivery acknowledgements.

Back up, coordinate old writers, and use the official migrator to apply outstanding 067_delivery_dlq_replay.sql; older versions also need their outstanding migrations. All reads and writes through the new MySQL DLQ require migration 067 first; runtime startup does not migrate automatically. Custom adapters need matching DLQ replay interfaces; executor replay is explicitly unavailable without them. Keep additive structures, migration history, the original queue and replay markers on code rollback. Removing markers and resubmitting is not recovery.

Older artifacts may reject readiness or migration entry points because migration 067 is unknown to their manifest. Before rollback, validate the old artifact with the retained new schema and migration history in an isolated copy. Do not bypass checks by deleting migration records.

This patch covers graceful shutdown and saved dead letters. It does not provide a full persistent notification outbox, promise replay of every direct HTTP notification after SIGKILL, or guarantee exactly-once effects across systems. Client orchestration, commercial Host tenant maintenance and consumer upgrades remain independently maintained.

See the full 0.9.3 notes, patch upgrade guide, reliability mechanisms and limits, maintenance metrics, and capability/evidence index.

Historical 0.9.2: installation secrets, settlement and approval continuation

The following retains the 0.9.2 patch notes. Its 065 and 066 requirements do not replace the 067 migration required by 0.9.3.

Pairing at that release: Core 0.9.2 / MCP and Agent Client SDK 0.7.0 / DSH 0.7.0. ACC 1.0.5 and independent client packages were not bumped for that patch.

This patch fixes three Core reliability gaps: new installations stop if secure credential generation fails; saved model usage continues to settle without incoming requests; recorded approval decisions can continue after audit or queue failures using their original coordinates.

• Installation secrets: six credentials are generated independently. A missing or failed secure random source, or malformed output, stops before partial configuration is written or services start. Existing .env files and administrator passwords are preserved.
• Asynchronous settlement: standalone schedules maintenance after startup and every minute; managed Kernels use their existing tick. Fair paging uses saved metering, reference prices and the original unified multiplier, without contacting providers or redispatching requests. Missing authoritative metering remains pending/unknown.
• Approval continuation: decisions and immutable continuation coordinates are saved in one transaction. Retry the original decision_id after an audit or admission failure; maintenance also scans unfinished continuations. Decision-specific admission markers prevent duplicate queueing after lost acknowledgements. Direct Agent invocations still require explicit local-Agent resume and do not launch a Core model loop.
• Close and evidence: stop new maintenance before draining started persistence work; retain the original instance for retry on timeout. New isolated database and process-recovery regressions document the tested scope alongside the public capability/evidence index.

Back up and coordinate old writers, then use the official migrator to apply outstanding 065_usage_reconciliation_scan.sql and 066_approval_continuations.sql. Runtime startup does not migrate automatically. Custom state/config adapters need matching continuation interfaces; new decisions are explicitly unavailable without them. Keep additive structures, continuation records and deduplication markers on code rollback, then reconcile original decisions and queue state. Removing markers and resubmitting is not recovery.

These mechanisms do not guarantee exactly-once business effects, invent missing metering, or establish production acceptance. Commercial Host tenant maintenance and client orchestration and long-term memory remain independently maintained.

See the full 0.9.2 notes, patch upgrade guide, reliability mechanisms and limits, and capability/evidence index.

Historical 0.9.1: asynchronous model shutdown and public capability evidence

The following retains the 0.9.1 patch notes. Its no-new-SQL statement applies only to that version and does not replace the 0.9.2 upgrade requirements.

Historical pairing: Core 0.9.1 / MCP and Agent Client SDK 0.7.0 / DSH 0.7.0. Independent client packages are not bumped for this patch.

After an image request returns pending, provider completion and settlement may still be running in the background. Before resources close, 0.9.1 registers and drains work owned by the original instance: model-tool completion and late settlement, settlement after ordinary text responses, response cleanup, usage reconciliation, and reference-price refresh through persistence.

• All stages share the original close(drainMs) deadline. A usage-drain-stage timeout preserves dependencies and the closing state for same-instance retry after original work finishes, without redispatch.
• Images still promptly return HTTP 202; ordinary text results also arrive before financial settlement. Original request IDs, business authority, approvals, and separate result/billing states remain unchanged.
• A new Chinese/English capability/evidence index and prior main-branch security governance distinguish source, releases, tests, and limitations. They do not establish host deployment, adoption, or complete security guarantees.
• Relative to 0.9.0, there are no new APIs, SQL migrations, plan rules, or client features. Earlier versions still apply outstanding migrations. Failed work can retain pending/unknown evidence; drain completion does not mean every record is settled or provide process-crash recovery.

Before upgrading, a returned old 0.9.0 close() does not establish usage quiescence. Retain original records and reconcile in-flight operations. See the full 0.9.1 notes, patch upgrade guide, and capability/evidence index.

Historical 0.9.0: model services and shared plan allowances

The following retains features introduced in 0.9.0 and upgrade steps from 0.8.0. They are not additions or patch-upgrade requirements of 0.9.1.

Release pairing: Core 0.9.0 / MCP and Agent Client SDK 0.7.0 / DSH 0.7.0.

An enterprise assistant may choose a conversation model, generate a campaign image, then invoke an authorized business API. Administrators can give these models and generation tools a shared allowance. The local host continues to orchestrate the conversation and task; the Hub records original requests, actual usage and settlement. Existing business permissions and approvals remain in force.

Changes in 0.9.0

Optional model billing

Configure the actual provider connection and model, explicitly map a reference pricing model and endpoint, then create a plan for a personal or shared organization account. Conversation models and model tools have separate catalogs. Unready services stay out of callable entries; hosts can show the reason.

OpenRouter supplies reference prices, not the actual provider invoice. Each request preserves its reference price and plan multiplier; later price changes do not recalculate history. Charges are not based on user turns or task steps.

One plan, one allowance

An enterprise plan may sell for 300 USD and provide 100 USD per month at a 1.5 multiplier. A request with a 0.20 USD reference cost deducts 0.30 USD, leaving an actual allowance ratio of 99.70%.

• Periodic plans separate sale price from allowance. Daily, weekly or monthly resets restore the allowance; customers see a remaining percentage whose denominator is the period allowance.
• Credit packs provide a one-time USD allowance and display Credits at 1000 Credits per USD.
• Validity and reset periods are independent. The final partial period still has its full allowance; expiration stops new requests and unused allowance does not roll over. Template price edits do not reset original grant terms.
• Raw Token counts remain usage evidence. The business application owns payments, currency conversion, refunds and product pricing.

Image results and settlement are separate

Initial adapters support text-to-image through Aliyun’s OpenAI Images-compatible API, native DashScope and OpenRouter Images. Video, voice and custom capabilities may be declared but remain uncallable without an execution adapter.

Image requests persist dispatch records and finish asynchronously. Hosts query the original request ID. Completed results are usable while billing awaits actual metering; missing usage is never an invented zero fee. Late concurrent settlements may create an overage, and depleted balances block new requests.

Connection loss or an unknown result retains the original ID rather than creating another generation. Late usage after cancellation remains accountable and does not revive a finished turn. Image generation and a business update are separate actions; hosts can reuse their existing attachment space when needed.

Administration preserves original records

Removing a plan preserves historical grants, requests and the ledger. Disabled accounts can be archived and restored to the original disabled account without reviving old credentials or replenishing allowance.

Authorized administrators can reset an effective Hub-managed allowance. Periodic plans regain their original allowance with a new period anchor; credit packs regain their original Credits. Expiration stays unchanged and dispatched requests settle against their original pool. External backends retain ownership of the plans they provision.

Upgrade from 0.8.0 to 0.9.0 by role

Role	Action
Hub operator	Back up, upgrade Core and apply unapplied migrations 063 and 064 through the official migrator; optionally configure model connections, pricing, plans and accounts
Client host developer	Upgrade paired SDK/DSH, catalogs, summaries, persistent original requests and asynchronous results; verify resolved dependency versions
Business backend developer	Adopt separate issuer credentials and billing APIs only for provisioning or plan-scoped identity; preserve original idempotency inputs
User	Use an adapted host and retain existing business authorization; a plan grants no additional business write permission

Upgrading public 0.8.0 requires no data purge. Run all unapplied migrations with npm run db:init; startup does not migrate automatically. Preserve configuration, secrets, databases and the migration ledger. Billing-preview installations separately verify their period allowance snapshots. See the paired upgrade guide.

Enable billing as needed; existing business tools, approvals, multi-account conversations, task controls, and archives remain available. After setup, check text streaming, image results, allowance summaries, and original-request recovery with your configured services, then review settlement records.

Model services and plan billing · Full release notes