# Core Capabilities and Public Evidence

[中文版](IMPLEMENTATION_STATUS.md)

This index separates **ownership, release availability, public evidence, and limitations** for BailingHub Core. Source implementation, test coverage, a formal release, and real business adoption are distinct facts, not a progression of maturity labels. This page is not a third-party certification, a complete security guarantee, or evidence of production adoption.

## Version and evidence conventions

- Formal release baseline: [v0.10.1](https://github.com/bailinghub/bailinghub/releases/tag/v0.10.1), with the [v0.10.1 source Tag](https://github.com/bailinghub/bailinghub/tree/v0.10.1). The table's mechanisms are included in this release; versioned fixes retain their first-release identities. This does not mean that every optional feature is enabled by a default installation.
- Historical baseline: [v0.9.0](https://github.com/bailinghub/bailinghub/releases/tag/v0.9.0), commit [`dae5260ede6565080d21e94ae63d52f3a7d23556`](https://github.com/bailinghub/bailinghub/tree/dae5260ede6565080d21e94ae63d52f3a7d23556). Its asynchronous shutdown gap remains documented below. Verify source, npm, images, and deployments separately; updated documentation does not fix old artifacts.
- Test links identify **public test source and the conditions it checks**, not passing runs newly produced by this page. Unit tests, simulated provider responses, MySQL integration tests, and the complete demo have different scopes. Skipped or unexecuted tests are not passing evidence, and do not make an existing mechanism a planned feature.
- Use the [v0.10.1 release notes](RELEASE_NOTES_v0.10.1.en.md) and [upgrade guide](UPGRADE_v0.10.1.en.md) for release contents and prerequisites. Compatible clients, application migrations, provider credentials, storage, and business authorization still require their own configuration and acceptance.

## Ownership and release availability

Core defaults to one organization's management and audit domain. Clients, routes, and tool providers are not organization isolation boundaries. ACC is an independent capability-declaration specification; the business system retains final identity, permission, and business-rule checks. See [Architecture](ARCHITECTURE.en.md), the [wire contract](CONTRACT.en.md), and the [ACC specification repository](https://github.com/agent-capability/agent-capability-contract).

| Capability and owner | Release availability | Public implementation and evidence | Scope and limitations |
|---|---|---|---|
| Explicit declaration values: business SDKs serialize; Core resolves precedence | Corrected in Core v0.10.1 | [Generator/Core upgrade](UPGRADE_v0.10.1.en.md); [Core matrix](../src/core/contracts/explicit-capability-values.test.ts); [PHP7 generator matrix](../sdk/php7/tests/declaration-serialization.php) / [PHP8 generator matrix](../sdk/php/tests/declaration-serialization.php); [actual archive verifier](../scripts/check-php-sdk-artifacts.mjs) | Explicit false and low are retained; omitted values retain their defaults. Review changed effective risk and refresh declarations. Source tests do not prove a downstream package or deployment was updated. |
| Declarations, tool discovery, and governed calls: Core parses/governs; the business system executes | Included in Core v0.10.0 | [Tool model](TOOLS_MODEL.en.md); [tool-index source](../src/services/tools-index.ts) / [tests](../src/services/tools-index.test.ts); [execution governance tests](../src/core/runtime/execution-runtime.test.ts) | Discoverability is not permission to call. The receiving API must verify the signature and recheck the subject, tenant, permissions, and business state. A declaration cannot create authority the caller did not have. |
| Agent Auth: Core binds client sessions; the business authorization page supplies trusted identity | Included in Core v0.10.0 | [Agent Auth contract](AGENT_AUTH_API.en.md); [route source](../src/routes/agent-auth.ts); [lifecycle HTTP tests](../src/routes/agent-auth-lifecycle-http.test.ts) / [race tests](../src/infrastructure/config/config-agent-auth-lifecycle-race.test.ts) | PKCE, authorization binding, refresh, and revocation are implemented. They do not replace business login, role management, or final authorization, or let the model choose a trusted principal through text. |
| Agent Client Runtime: Core exposes workspaces, turns, discovery, and tool invocation | Included in Core v0.10.0 | [Runtime API](AGENT_CLIENT_RUNTIME_API.en.md); [runtime source](../src/app/agent-client-runtime.ts) / [tests](../src/app/agent-client-runtime.test.ts); [invocation tests](../src/app/agent-tool-invocations.test.ts) | The local Agent host owns model selection, its reasoning loop, and tool orchestration. Core's existing `/run` pipeline is a separate public integration path; the two must not be presented as one client execution mode. |
| Approvals, original invocation snapshots, and read-only receipts: Core governs; the business system owns the outcome | Included in Core v0.10.0 | [Receipts versus recovery](INVOCATION_RECEIPTS.md); [invocation source](../src/app/agent-tool-invocations.ts) / [tests](../src/app/agent-tool-invocations.test.ts); [approval-ledger tests](../src/infrastructure/config/config-approval-ledger.test.ts) | Reading an original receipt differs from resume, which may continue execution. Unknown outcomes do not permit replaying a write, and missing historical arguments must not be invented. Approval does not prove business success or guarantee rollback of a distributed business transaction. |
| Cross-turn task controls: Core persists original members, write-call allowance, and concurrency occupancy | Included in Core v0.10.0 (introduced in v0.8.0) | [Task control contract](AGENT_TASK_CONTROL.en.md); [runtime source](../src/core/runtime/agent-task-control.ts) / [tests](../src/core/runtime/agent-task-control.test.ts); [MySQL journal integration tests](../src/infrastructure/config/config-agent-task-control-journal-mysql.test.ts) | These controls govern business invocations, not model-turn subscriptions. Write-call counts are not refund amounts, successful transactions, or Tokens. Pause/cancel cannot undo a permitted or completed business effect. |
| Visible conversation audit: the client explicitly uploads; Core validates members and persists events | Included in Core v0.10.0 | [Conversation audit contract](AGENT_CONVERSATION_AUDIT.en.md); [runtime tests](../src/core/runtime/agent-conversation-audit.test.ts) | Hidden reasoning is not collected. Membership confirmation and a write API do not prove all history was uploaded. Audit archives do not merge authorization, sessions, or runtime memory. Cross-binding use retains the same-Hub and individual-identity boundaries. |
| Current-thread context and optional rolling summaries: Core route/thread mechanisms | Included in Core v0.10.0 | [Memory configuration/rendering](../src/core/runtime/memory.ts); [thread injection source](../src/core/runtime/memory-runtime.ts) / [tests](../src/core/runtime/memory-runtime.test.ts); [summary tests](../src/core/runtime/summary-runtime.test.ts) | Summaries are disabled by default and still read from the original thread when enabled. This is not a complete user-level memory system across new conversations. Visible audit archives do not automatically enter model context. |
| Attachment space: the host supplies approved images; Core uploads and returns usable URLs | Included in Core v0.10.0 (introduced in v0.8.0) | [Image attachment contract](GENERATED_ARTIFACTS.en.md); [artifact source](../src/app/agent-artifacts.ts) / [tests](../src/app/agent-artifacts.test.ts) | The first increment accepts PNG/JPEG/WebP, not documents or video. Operators configure storage and retention. Core cannot read the client's filesystem. Uploading an image and changing a business record with its URL are separate actions. |
| Optional model gateway and USD allowance settlement: Core connects/meters; the client host orchestrates | Included in Core v0.10.0 | [Model billing contract](MODEL_BILLING.en.md); [gateway source](../src/modules/usage/model-gateway.ts); [model-gateway MySQL tests](../src/modules/usage/model-gateway.mysql.test.ts); [ledger unit tests](../src/modules/usage/billing-ledger.test.ts) | Shared USD allowances use a uniform multiplier and separate periodic price from allowance. They do not restore turn/step billing. Reference prices are not provider invoices; raw Tokens are not the allowance denominator. Missing authoritative usage does not permit inventing Tokens or fees. |
| Model-tool directory, text-to-image, and original-request lookup: optional Core gateway extensions | Included in Core v0.10.0 | [Tool-description source](../src/modules/usage/model-tools.ts) / [tests](../src/modules/usage/model-tools.test.ts); [provider adapter tests](../src/modules/usage/model-tool-provider.test.ts); [asynchronous-image MySQL tests](../src/modules/usage/model-tool-gateway.mysql.test.ts) | Executable adapters include Alibaba-compatible Images, native DashScope, and OpenRouter Images. A video, voice, or custom-service directory declaration does not provide an execution adapter. The completion/shutdown boundary is described below. |
| Kernel Host API, explicit migrations, and managed lifecycle: Core provides an embedding entry point; the Host manages processes and isolation | Included in Core v0.10.0 | [Kernel Host API](KERNEL_HOST_API.en.md); [Kernel source](../src/app/kernel.ts) / [tests](../src/app/kernel.test.ts); [artifact-manifest tests](../src/kernel-api/v1/artifact.test.ts); [migration tests](../src/infrastructure/schema/core-schema-migrator.test.ts) | Separate MySQL schemas/runtimeRoots, trusted instanceKeys, explicit migrations, and Host-owned tick/close calls are prerequisites. The API does not provide tenant signup, platform plans, cluster directories, or multi-replica upgrade orchestration. The optional usage gateway is not the Host's platform billing product. |
| Installation, smoke checks, and optional operational metrics: Core provides entry points; operators configure and accept deployments | Included in Core v0.10.0 | [Quickstart](QUICKSTART.en.md); [installer](../scripts/install.sh); [smoke script](../scripts/smoke.ts); [OpenMetrics tests](../src/core/observability/openmetrics.test.ts); [independent reproduction task](INDEPENDENT_VALIDATION.en.md) | A health response does not establish that all business operations/providers are available. Metrics require explicit enablement and access protection. Installation/diagnostic entry points do not establish continuous monitoring, staffed alerts, or acceptance of a particular deployment. |

## What the public validation paths establish

### Unit, simulated-provider, and database tests

The linked tests check mechanisms such as authorization, frozen arguments, idempotency, unknown outcomes, allowances, and lifecycle behavior. Database integration tests require their public fixtures' dedicated test configuration. For example, usage MySQL tests explicitly require `BAILING_USAGE_TEST_MYSQL=1`. A default test run that skips them does not establish database acceptance.

Simulated provider responses establish adapter/protocol behavior for the specified inputs, not live-provider availability, pricing, model quality, or production performance. Tests using real MySQL are still not acceptance of a real business integration.

### Public demo and independent reproduction task

The [Docker demo](DEMO.en.md) and [independent validation task](INDEPENDENT_VALIDATION.en.md) provide a public path from installing v0.10.1 through smoke checks and `npm run demo:e2e`. Orders, tickets, refunds, and failure tools use repository demo data. Real model keys, customer APIs, and production credentials are unnecessary.

The task requires concrete results for service startup, console access, anonymous-preview boundaries, smoke checks, and the complete business loop. The README's images and animation show that same public fixture, not customer adoption. Publishing a task card does not establish that an external developer completed it. Reports should retain the actual version, environment, checks, and failure scope.

### Asynchronous model-tool shutdown limitation in formal v0.9.0

The v0.9.0 [model-tool gateway source](https://github.com/bailinghub/bailinghub/blob/dae5260ede6565080d21e94ae63d52f3a7d23556/src/modules/usage/model-gateway.ts) persists provider dispatch, starts background completion/settlement through `void complete().then(...)`, and promptly returns the original request state. The [Kernel close implementation](https://github.com/bailinghub/bailinghub/blob/dae5260ede6565080d21e94ae63d52f3a7d23556/src/app/kernel.ts) explicitly waits for initialization, managed maintenance, HTTP, InHub, execution queues, and resource closure, but does not explicitly register this usage model-tool continuation as a separate drain participant.

Asynchronous-image/original-ID recovery tests in v0.9.0 therefore do not establish that every provider completion is covered by Kernel shutdown acceptance. The public main commit before the fix, [`728899e`](https://github.com/bailinghub/bailinghub/tree/728899e88d89f0ec333684a56640c12154970327), retains the same boundary. This page does not infer observed data loss or duplicate business effects.

### Core v0.9.1 shutdown fix and evidence scope

Core v0.9.1 adds a [background-work tracker](../src/modules/usage/background-work.ts) owned separately by each `UsageRepository`, and drains it before resource closure in the [Kernel close path](../src/app/kernel.ts). Actual registration covers model-tool completion and its late settlement child, settlement after ordinary model responses, traffic-triggered response cleanup/usage reconciliation, and reference-price refresh through persistence. See the [Kernel Host API](KERNEL_HOST_API.en.md) for stopped admission, the shared deadline, and same-instance retry after a timeout. Original HTTP 202 delivery and recovery identifiers remain unchanged. Waiting for close does not issue a new provider request or alter business approval authority.

The new [tracker unit tests](../src/modules/usage/background-work.test.ts) check registration before execution, dynamic children, stopped maintenance, timeout/retry, owner isolation, and failure-diagnostic boundaries. Owner unit tests are not actual multi-Kernel acceptance. The public [Kernel + MySQL lifecycle tests](../src/app/kernel-usage-lifecycle.mysql.test.ts) use actual Kernels, separate test schemas, and synthetic providers to assert delayed completion/late settlement, SQL-lock waits, resource preservation and same-instance retry after timeouts, original-ID/resource isolation between two Kernels, settlement blocking close after ordinary text-model delivery, and standalone shutdown draining before exit. Separate cases cover cleanup and usage reconciliation independently blocking close; reference-price refresh is checked through persistence and stopped new maintenance. Further assertions cover failed settlement retaining the original result/durable pending, later reconciliation without redispatch, diagnostics excluding raw errors, one original dispatch, and one settlement-ledger record. The database tests explicitly require `BAILING_USAGE_TEST_MYSQL=1`. Source/assertions do not substitute for actual results or establish live-provider, process-crash recovery, or production-deployment acceptance.

This fix is available from **Core v0.9.1**, without rewriting the historical guarantees of the v0.9.0 Tag or establishing that a host has been upgraded or deployed. Failed background work may retain durable pending/unknown evidence. Completed drain does not mean every billing record is settled, or provide complete failure-recovery or security assurance.

## General security governance included in v0.9.1

Compared with v0.9.0, v0.9.1 includes prior main-branch additions/updates to the [security self-assessment](https://github.com/bailinghub/bailinghub/blob/v0.9.1/SECURITY_SELF_ASSESSMENT.md), its [Chinese companion](https://github.com/bailinghub/bailinghub/blob/v0.9.1/SECURITY_SELF_ASSESSMENT.zh-CN.md), [Security Insights metadata](https://github.com/bailinghub/bailinghub/blob/v0.9.1/security-insights.yml), the [dependency audit script](../scripts/dependency-audit.mjs) and [tests](../scripts/dependency-audit.test.mjs), plus CI, dependency-update, and package/image exclusion settings. These are public repository governance evidence, not new business-runtime features or a claim that every control passes. Assessments/security metadata are excluded from npm runtime packages and Docker build contents; the assessments retain their stated evaluation baselines.

A version field or this page does not substitute for artifact checks. Evaluate npm, images, and source Tags against their own commit, artifact, and validation evidence. A Core version also does not establish an independent adapter's or host's release status.

## Independent components and non-Core responsibilities

- The [MCP Server and Agent Client SDK](https://github.com/bailinghub/bailinghub-mcp-server), [DeepSeek Harness community plugin](https://github.com/bailinghub/bailinghub-dsh-plugin), [n8n community node](https://github.com/bailinghub/bailinghub-n8n-node), and [executor/OpenClaw adapter](https://github.com/bailinghub/bailinghub-openclaw-skill) are independent projects or adapters consuming public Core interfaces. They have their own versions, configuration, and validation, are excluded from Core artifacts, and do not imply upstream certification, endorsement, or adoption.
- A local host owns its model loop, client credential storage, UI, and approved file sources. Business systems own real execution, permissions, and business invariants. An independent Host owns its platform identity, tenant directory/isolation, and process/upgrade orchestration. Use the [Agent Client guide](AGENT_CLIENT_QUICKSTART.en.md) and [Kernel Host API](KERNEL_HOST_API.en.md) to assess interface responsibilities; Core tests do not prove these external implementations are complete or deployed.
- Complete user-level long-term memory, media tools without executable adapters, and real providers/business systems not accepted through the public paths listed here are not validated capabilities of this index. This page creates no new product timetable for them.

Keep this page and its Chinese companion aligned. Retain the distinction between formal Tags and main, and update a capability's availability or validation scope only when its corresponding public evidence changes.

## Additional process-recovery regressions in Core v0.9.2

[Process crash and lost acknowledgements](MODEL_PROCESS_RECOVERY.en.md) use real SIGKILL, replacement PIDs and withheld MySQL COMMIT acknowledgements to check original requests, provider call counts, results and USD ledgers. These opt-in tests are included in Core v0.9.2, not in the historical v0.9.1 Tag. The link states coverage, not a new execution, real-provider or production-crash acceptance claim.

## Reliability fixes in Core v0.9.2

[Installation secrets, settlement maintenance and approval continuation](CORE_RELIABILITY.en.md) covers failing closed without secure installation randomness, settlement without new traffic and durable continuation of approval decisions. It adds incremental migrations 065/066. Public checks include [installer failure tests](../scripts/install-secrets.test.mjs), [settlement MySQL acceptance](../src/modules/usage/billing-reconciliation.mysql.test.ts), [approval continuation tests](../src/app/approval-continuations.test.ts) and [approval MySQL/process acceptance](../src/app/approval-continuations.mysql.test.ts). These describe Core v0.9.2 implementation and coverage; they do not expand the historical v0.9.1 artifact guarantees.

## Core v0.9.3 body and notification fixes

The [HTTP and notification fixes](CORE_RELIABILITY.en.md#core-v093-http-and-notification-fixes) index public source and synthetic regression entry points for bounded bodies, UTF-8 views, graceful notification drain, original executor notification DLQ admission deduplication and migration 067. [Operational metrics](OPERATIONS.en.md) document read-only maintenance snapshots. These changes are available from Core v0.9.3, not in historical v0.9.2 artifacts. Graceful-close and storage-interruption tests do not establish complete crash recovery of all notification intents or production receipt. Verify Tag, npm, images and each deployment separately.

## Core v0.9.4 dependency and notification changes

Core v0.9.4 adds [DOCX dependency remediation](DOCX_DEPENDENCY.en.md) and [durable notifications](NOTIFICATION_DURABILITY.en.md), including bundled console management and incremental migration 068. Public source and synthetic tests cover built-in persistence and recovery, not actual receipt in every deployment. Webhook receivers deduplicate stable event IDs; native uncertain receipt requires operator verification. Historical v0.9.3 evidence is unchanged, and independent consumers require their own upgrades. See the [upgrade guide](UPGRADE_v0.9.4.en.md).

## Core v0.10.0 compatible additions and fixes

This release adds [Agent on-demand knowledge](AGENT_KNOWLEDGE_API.en.md), [named tool guidance](AGENT_CLIENT_RUNTIME_API.en.md) and [explicit model budgets](MODEL_OUTPUT_BUDGET.en.md), with console onboarding, draft protection and diagnostics improvements. Old clients retain inline delivery, old model configuration is not changed automatically and bundled chat context stays intact. Larger arguments remain bounded with full approvals and original-call deduplication. [Host continuation](MODEL_CONTINUATION.en.md) is a client responsibility, not a new Hub model loop. The [upgrade guide](UPGRADE_v0.10.0.en.md) covers read-only planning and actual-resource readiness; there is no new SQL from 0.9.4.

## Core v0.10.1 explicit-value correction and package evidence

Seven business-side SDK generators preserve explicit readonly/idempotent true/false and low/medium/high risk; unspecified fields remain omitted. Core preserves boolean false and applies explicit values before the GET fallback. See the [release notes](RELEASE_NOTES_v0.10.1.en.md) and [upgrade guide](UPGRADE_v0.10.1.en.md). ACC remains at 1.0.6 with declaration version: 1; MCP / Agent Client SDK 0.8.0 and DSH 0.8.0 do not receive a separate release for this patch.

The [PHP7](../sdk/php7/tests/declaration-serialization.php) and [PHP8](../sdk/php/tests/declaration-serialization.php) drivers run the actual builders and JSON serialization across 24 readonly/risk combinations, six idempotency combinations and preserved approval/subject requirements. The [Core regression](../src/core/contracts/explicit-capability-values.test.ts) checks consumer precedence; [PHP package verification](../scripts/check-php-sdk-artifacts.mjs) compares complete file sets, per-file hashes and actual regressions against extracted packages. These links identify reproducible checks, not a claim that every runtime, production deployment or downstream business has passed them.

The correction changes the interpretation of declarations previously discarded or overridden: explicit low writes may move from medium to low, GET readonly=false defaults to medium when risk is omitted, and GET idempotent=false is retained. Business owners review their declarations, including custom readers of intermediate SDK objects such as nullable PHP8 risk. Updating only one side does not repair the other side. Preserve original invocation and approval records; do not replay business for acceptance. The patch adds no SQL or new authority. Old version guarantees remain unchanged.