Version Packages

[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@boardstate/broker@0.2.0

Minor Changes

• #50 e96a33f Thanks @100yenadmin! - New package @boardstate/broker — the MCP CLIENT manager (M5a-1, epic #37). It connects
  outward to the external MCP servers an operator declares in a boardstate.connectors.json
  config, discovers their tools into a namespaced ToolManifest, and calls them behind a
  narrow API the host/server layers consume.

  • Config is operator-authored only: loadConnectorsConfig(path) + a programmatic
    new McpBroker(config). A connector name not in the config is inert. env values are
    process-env var NAMES (references), never literal secrets — validated up front and never
    echoed into errors or logs.
  • Transports: StdioClientTransport for local servers, StreamableHTTPClientTransport
    with SSE fallback for remotes. Lazy connect on first use, warm/pooled clients, capped
    exponential-backoff reconnect, clean close.
  • listTools() → ToolManifest: connector:tool ids AND provider-safe
    connector__tool names (both inside a 64-char budget, collisions fail loud), input
    schemas, readOnlyHint honored (absent ⇒ treated as a mutation — fail-safe), and a
    stable manifest hash over sorted (id + canonical input-schema) pairs — the anti-rug-pull
    snapshot the grant lifecycle (M5b-2) pins to.
  • callTool(id, args, { timeout }): resolves the client, strips the namespace,
    enforces a hard timeout, and normalizes isError: true results into a typed
    BrokerToolError.

  Depends only on @modelcontextprotocol/sdk and @boardstate/server (types only). Ships
  an in-repo fake MCP server fixture (stdio child + in-process HTTP) so CI needs no network.

• #53 a0feba7 Thanks @100yenadmin! - M5 trust layer (M5b-2 + M5b-3, epic #37): the grant lifecycle for external MCP tools
  and the server-enforced pending-action engine — closes #40 and #41.

  Grant lifecycle + both-direction anti-rug-pull (SPEC §17.1, #40)

  • installBrokerActions (@boardstate/server/node) registers each configured connector's
    discovered tools as a requested tools-only grant (explicit methods: []/streams: [],
    a tools id snapshot, and a subset-scoped toolsHash), mirroring installConnector's
    request-on-install. An already-granted grant survives a restart; real manifest drift is
    caught at invoke time.
  • Server-side anti-rug-pull: on every granted-tool call the live manifest hash is compared
    to the stored toolsHash; a mismatch re-pends the grant to requested BEFORE any call
    succeeds.
  • Agent-side anti-rug-pull: reconcileReplaceApproval now forces a granted grant back to
    requested on ANY tools/toolsHash mutation (not just status flips) — closing the
    red-team hole where an agent could append a tool id to a granted grant through
    workspace.replace or import.
  • Partial grants: dashboard.capability.approve gains an optional tools subset; the
    decision applies to the intersection with the requested set and the granted subset gets
    its OWN hash (McpBroker.hashToolSubset, injected as capabilityToolsHash).
  • Approvals console: capability rows surface their requested tool ids for per-tool selection
    (approve-all = one click); the core transform + lit renderer + strings render it.

  Pending-action engine (SPEC §18, #41)

  • In-memory pending-action registry. dashboard.action.invoke AND-gates a call (granted at
    invoke time + connector configured + hash unchanged): a readOnly granted tool executes
    directly; a mutation parks as a PendingActionRecord and returns { pending: true, id, expiresAt }. dashboard.action.confirm/dashboard.action.deny are operator-only
    (OPERATOR_ONLY_METHODS) — a networked client can directly execute only readOnly tools.
  • TTL expiry (~5 min), single-shot terminal states (a replay of a terminal id errors),
    server-side invoke rate limiting (prompt-gate discipline), an audit entry per invoke +
    decision, and lifecycle broadcasts on dashboard.action.changed.
  • confirmAndExecute(id) is exposed as the awaitable an agent-mediated call (M5c-1) blocks
    on: it resolves with the tool result on confirm and rejects on deny/expiry.

  The engine consumes the broker through the narrow structural ActionBroker interface —
  @boardstate/broker never enters @boardstate/server (no dependency cycle); the real
  McpBroker fits it structurally. SPEC §17.1/§18 normative text filled where the schema
  train (#39) left implementation-pending markers.

Patch Changes

• Updated dependencies [c895241, a0feba7]:
  • @boardstate/server@1.2.0

@boardstate/core@1.2.0

Minor Changes

• #51 b05c7cd Thanks @100yenadmin! - feat(schema): SPEC §17 v2 tool grants + all M5 schema surface (one schema train, M5b-1)

  The single S5-1 schema train — all M5 (Operational Workspace) schema surface rides
  one release so later sprints consume a released schema. Fully additive: boards using
  none of the new surface validate + normalize byte-identically (regression-tested).

  • Tool grants (SPEC §17 v2): DashboardCapabilityGrant gains tools?: string[]
    (namespaced connector:tool ids, shape-validated — NOT against
    DATA_READ_RPC_ALLOWLIST) and toolsHash?. methods/streams/tools are
    optional-in / always-array-out.
  • Pending-action record: PendingActionRecord type + validatePendingAction
    shape guard for the #41 engine (type + validation only).
  • builtin:action-button kind + props validator {connector, tool, args?, label?}.
  • action-form mode:"tool": mode/connector/tool/argsFrom extend the
    fixed key-set; prompt mode stays the default and byte-identical.
  • source:"mcp" binding: {source:"mcp", connector, tool, args?} (shape only;
    host resolution is #45).
  • dashboard.connector.list added to DATA_READ_RPC_ALLOWLIST (broker status read).
  • WIDGET_CATALOG: action-button entry + action-form tool-mode example (honesty-gate valid).

• #53 a0feba7 Thanks @100yenadmin! - M5 trust layer (M5b-2 + M5b-3, epic #37): the grant lifecycle for external MCP tools
  and the server-enforced pending-action engine — closes #40 and #41.

  Grant lifecycle + both-direction anti-rug-pull (SPEC §17.1, #40)

  • installBrokerActions (@boardstate/server/node) registers each configured connector's
    discovered tools as a requested tools-only grant (explicit methods: []/streams: [],
    a tools id snapshot, and a subset-scoped toolsHash), mirroring installConnector's
    request-on-install. An already-granted grant survives a restart; real manifest drift is
    caught at invoke time.
  • Server-side anti-rug-pull: on every granted-tool call the live manifest hash is compared
    to the stored toolsHash; a mismatch re-pends the grant to requested BEFORE any call
    succeeds.
  • Agent-side anti-rug-pull: reconcileReplaceApproval now forces a granted grant back to
    requested on ANY tools/toolsHash mutation (not just status flips) — closing the
    red-team hole where an agent could append a tool id to a granted grant through
    workspace.replace or import.
  • Partial grants: dashboard.capability.approve gains an optional tools subset; the
    decision applies to the intersection with the requested set and the granted subset gets
    its OWN hash (McpBroker.hashToolSubset, injected as capabilityToolsHash).
  • Approvals console: capability rows surface their requested tool ids for per-tool selection
    (approve-all = one click); the core transform + lit renderer + strings render it.

  Pending-action engine (SPEC §18, #41)

  • In-memory pending-action registry. dashboard.action.invoke AND-gates a call (granted at
    invoke time + connector configured + hash unchanged): a readOnly granted tool executes
    directly; a mutation parks as a PendingActionRecord and returns { pending: true, id, expiresAt }. dashboard.action.confirm/dashboard.action.deny are operator-only
    (OPERATOR_ONLY_METHODS) — a networked client can directly execute only readOnly tools.
  • TTL expiry (~5 min), single-shot terminal states (a replay of a terminal id errors),
    server-side invoke rate limiting (prompt-gate discipline), an audit entry per invoke +
    decision, and lifecycle broadcasts on dashboard.action.changed.
  • confirmAndExecute(id) is exposed as the awaitable an agent-mediated call (M5c-1) blocks
    on: it resolves with the tool result on confirm and rejects on deny/expiry.

  The engine consumes the broker through the narrow structural ActionBroker interface —
  @boardstate/broker never enters @boardstate/server (no dependency cycle); the real
  McpBroker fits it structurally. SPEC §17.1/§18 normative text filled where the schema
  train (#39) left implementation-pending markers.

Patch Changes

• Updated dependencies [b05c7cd, a0feba7]:
  • @boardstate/schema@1.2.0

@boardstate/lit@0.4.0

Minor Changes

• #53 a0feba7 Thanks @100yenadmin! - M5 trust layer (M5b-2 + M5b-3, epic #37): the grant lifecycle for external MCP tools
  and the server-enforced pending-action engine — closes #40 and #41.

  Grant lifecycle + both-direction anti-rug-pull (SPEC §17.1, #40)

  • installBrokerActions (@boardstate/server/node) registers each configured connector's
    discovered tools as a requested tools-only grant (explicit methods: []/streams: [],
    a tools id snapshot, and a subset-scoped toolsHash), mirroring installConnector's
    request-on-install. An already-granted grant survives a restart; real manifest drift is
    caught at invoke time.
  • Server-side anti-rug-pull: on every granted-tool call the live manifest hash is compared
    to the stored toolsHash; a mismatch re-pends the grant to requested BEFORE any call
    succeeds.
  • Agent-side anti-rug-pull: reconcileReplaceApproval now forces a granted grant back to
    requested on ANY tools/toolsHash mutation (not just status flips) — closing the
    red-team hole where an agent could append a tool id to a granted grant through
    workspace.replace or import.
  • Partial grants: dashboard.capability.approve gains an optional tools subset; the
    decision applies to the intersection with the requested set and the granted subset gets
    its OWN hash (McpBroker.hashToolSubset, injected as capabilityToolsHash).
  • Approvals console: capability rows surface their requested tool ids for per-tool selection
    (approve-all = one click); the core transform + lit renderer + strings render it.

  Pending-action engine (SPEC §18, #41)

  • In-memory pending-action registry. dashboard.action.invoke AND-gates a call (granted at
    invoke time + connector configured + hash unchanged): a readOnly granted tool executes
    directly; a mutation parks as a PendingActionRecord and returns { pending: true, id, expiresAt }. dashboard.action.confirm/dashboard.action.deny are operator-only
    (OPERATOR_ONLY_METHODS) — a networked client can directly execute only readOnly tools.
  • TTL expiry (~5 min), single-shot terminal states (a replay of a terminal id errors),
    server-side invoke rate limiting (prompt-gate discipline), an audit entry per invoke +
    decision, and lifecycle broadcasts on dashboard.action.changed.
  • confirmAndExecute(id) is exposed as the awaitable an agent-mediated call (M5c-1) blocks
    on: it resolves with the tool result on confirm and rejects on deny/expiry.

  The engine consumes the broker through the narrow structural ActionBroker interface —
  @boardstate/broker never enters @boardstate/server (no dependency cycle); the real
  McpBroker fits it structurally. SPEC §17.1/§18 normative text filled where the schema
  train (#39) left implementation-pending markers.

Patch Changes

• Updated dependencies [b05c7cd, a0feba7]:
  • @boardstate/schema@1.2.0
  • @boardstate/core@1.2.0
  • @boardstate/host@1.2.0

@boardstate/schema@1.2.0

Minor Changes

• #51 b05c7cd Thanks @100yenadmin! - feat(schema): SPEC §17 v2 tool grants + all M5 schema surface (one schema train, M5b-1)

  The single S5-1 schema train — all M5 (Operational Workspace) schema surface rides
  one release so later sprints consume a released schema. Fully additive: boards using
  none of the new surface validate + normalize byte-identically (regression-tested).

  • Tool grants (SPEC §17 v2): DashboardCapabilityGrant gains tools?: string[]
    (namespaced connector:tool ids, shape-validated — NOT against
    DATA_READ_RPC_ALLOWLIST) and toolsHash?. methods/streams/tools are
    optional-in / always-array-out.
  • Pending-action record: PendingActionRecord type + validatePendingAction
    shape guard for the #41 engine (type + validation only).
  • builtin:action-button kind + props validator {connector, tool, args?, label?}.
  • action-form mode:"tool": mode/connector/tool/argsFrom extend the
    fixed key-set; prompt mode stays the default and byte-identical.
  • source:"mcp" binding: {source:"mcp", connector, tool, args?} (shape only;
    host resolution is #45).
  • dashboard.connector.list added to DATA_READ_RPC_ALLOWLIST (broker status read).
  • WIDGET_CATALOG: action-button entry + action-form tool-mode example (honesty-gate valid).

Patch Changes

• #53 a0feba7 Thanks @100yenadmin! - M5 trust layer (M5b-2 + M5b-3, epic #37): the grant lifecycle for external MCP tools
  and the server-enforced pending-action engine — closes #40 and #41.

  Grant lifecycle + both-direction anti-rug-pull (SPEC §17.1, #40)

  • installBrokerActions (@boardstate/server/node) registers each configured connector's
    discovered tools as a requested tools-only grant (explicit methods: []/streams: [],
    a tools id snapshot, and a subset-scoped toolsHash), mirroring installConnector's
    request-on-install. An already-granted grant survives a restart; real manifest drift is
    caught at invoke time.
  • Server-side anti-rug-pull: on every granted-tool call the live manifest hash is compared
    to the stored toolsHash; a mismatch re-pends the grant to requested BEFORE any call
    succeeds.
  • Agent-side anti-rug-pull: reconcileReplaceApproval now forces a granted grant back to
    requested on ANY tools/toolsHash mutation (not just status flips) — closing the
    red-team hole where an agent could append a tool id to a granted grant through
    workspace.replace or import.
  • Partial grants: dashboard.capability.approve gains an optional tools subset; the
    decision applies to the intersection with the requested set and the granted subset gets
    its OWN hash (McpBroker.hashToolSubset, injected as capabilityToolsHash).
  • Approvals console: capability rows surface their requested tool ids for per-tool selection
    (approve-all = one click); the core transform + lit renderer + strings render it.

  Pending-action engine (SPEC §18, #41)

  • In-memory pending-action registry. dashboard.action.invoke AND-gates a call (granted at
    invoke time + connector configured + hash unchanged): a readOnly granted tool executes
    directly; a mutation parks as a PendingActionRecord and returns { pending: true, id, expiresAt }. dashboard.action.confirm/dashboard.action.deny are operator-only
    (OPERATOR_ONLY_METHODS) — a networked client can directly execute only readOnly tools.
  • TTL expiry (~5 min), single-shot terminal states (a replay of a terminal id errors),
    server-side invoke rate limiting (prompt-gate discipline), an audit entry per invoke +
    decision, and lifecycle broadcasts on dashboard.action.changed.
  • confirmAndExecute(id) is exposed as the awaitable an agent-mediated call (M5c-1) blocks
    on: it resolves with the tool result on confirm and rejects on deny/expiry.

  The engine consumes the broker through the narrow structural ActionBroker interface —
  @boardstate/broker never enters @boardstate/server (no dependency cycle); the real
  McpBroker fits it structurally. SPEC §17.1/§18 normative text filled where the schema
  train (#39) left implementation-pending markers.

@boardstate/server@1.2.0

Minor Changes

• #53 a0feba7 Thanks @100yenadmin! - M5 trust layer (M5b-2 + M5b-3, epic #37): the grant lifecycle for external MCP tools
  and the server-enforced pending-action engine — closes #40 and #41.

  Grant lifecycle + both-direction anti-rug-pull (SPEC §17.1, #40)

  • installBrokerActions (@boardstate/server/node) registers each configured connector's
    discovered tools as a requested tools-only grant (explicit methods: []/streams: [],
    a tools id snapshot, and a subset-scoped toolsHash), mirroring installConnector's
    request-on-install. An already-granted grant survives a restart; real manifest drift is
    caught at invoke time.
  • Server-side anti-rug-pull: on every granted-tool call the live manifest hash is compared
    to the stored toolsHash; a mismatch re-pends the grant to requested BEFORE any call
    succeeds.
  • Agent-side anti-rug-pull: reconcileReplaceApproval now forces a granted grant back to
    requested on ANY tools/toolsHash mutation (not just status flips) — closing the
    red-team hole where an agent could append a tool id to a granted grant through
    workspace.replace or import.
  • Partial grants: dashboard.capability.approve gains an optional tools subset; the
    decision applies to the intersection with the requested set and the granted subset gets
    its OWN hash (McpBroker.hashToolSubset, injected as capabilityToolsHash).
  • Approvals console: capability rows surface their requested tool ids for per-tool selection
    (approve-all = one click); the core transform + lit renderer + strings render it.

  Pending-action engine (SPEC §18, #41)

  • In-memory pending-action registry. dashboard.action.invoke AND-gates a call (granted at
    invoke time + connector configured + hash unchanged): a readOnly granted tool executes
    directly; a mutation parks as a PendingActionRecord and returns { pending: true, id, expiresAt }. dashboard.action.confirm/dashboard.action.deny are operator-only
    (OPERATOR_ONLY_METHODS) — a networked client can directly execute only readOnly tools.
  • TTL expiry (~5 min), single-shot terminal states (a replay of a terminal id errors),
    server-side invoke rate limiting (prompt-gate discipline), an audit entry per invoke +
    decision, and lifecycle broadcasts on dashboard.action.changed.
  • confirmAndExecute(id) is exposed as the awaitable an agent-mediated call (M5c-1) blocks
    on: it resolves with the tool result on confirm and rejects on deny/expiry.

  The engine consumes the broker through the narrow structural ActionBroker interface —
  @boardstate/broker never enters @boardstate/server (no dependency cycle); the real
  McpBroker fits it structurally. SPEC §17.1/§18 normative text filled where the schema
  train (#39) left implementation-pending markers.

Patch Changes

• c895241 - Security: the dashboard_workspace_replace agent tool now passes the structural
  replace gate (reconcileReplaceApproval), so an agent can no longer self-grant a
  capability by writing status: "granted" into capabilitiesRegistry. Only
  dashboard.capability.approve (operator-only) grants. The RPC replace path was
  already gated; this closes the agent-tool path.
• Updated dependencies [b05c7cd, a0feba7]:
  • @boardstate/schema@1.2.0
  • @boardstate/core@1.2.0

@boardstate/conformance@0.1.11

Patch Changes

• Updated dependencies [c895241, b05c7cd, a0feba7]:
  • @boardstate/server@1.2.0
  • @boardstate/schema@1.2.0
  • @boardstate/core@1.2.0

@boardstate/agent@0.2.8

Patch Changes

• Updated dependencies [c895241, b05c7cd, a0feba7]:
  • @boardstate/server@1.2.0
  • @boardstate/schema@1.2.0

@boardstate/host@1.2.0

Patch Changes

• #53 a0feba7 Thanks @100yenadmin! - M5 trust layer (M5b-2 + M5b-3, epic #37): the grant lifecycle for external MCP tools
  and the server-enforced pending-action engine — closes #40 and #41.

  Grant lifecycle + both-direction anti-rug-pull (SPEC §17.1, #40)

  • installBrokerActions (@boardstate/server/node) registers each configured connector's
    discovered tools as a requested tools-only grant (explicit methods: []/streams: [],
    a tools id snapshot, and a subset-scoped toolsHash), mirroring installConnector's
    request-on-install. An already-granted grant survives a restart; real manifest drift is
    caught at invoke time.
  • Server-side anti-rug-pull: on every granted-tool call the live manifest hash is compared
    to the stored toolsHash; a mismatch re-pends the grant to requested BEFORE any call
    succeeds.
  • Agent-side anti-rug-pull: reconcileReplaceApproval now forces a granted grant back to
    requested on ANY tools/toolsHash mutation (not just status flips) — closing the
    red-team hole where an agent could append a tool id to a granted grant through
    workspace.replace or import.
  • Partial grants: dashboard.capability.approve gains an optional tools subset; the
    decision applies to the intersection with the requested set and the granted subset gets
    its OWN hash (McpBroker.hashToolSubset, injected as capabilityToolsHash).
  • Approvals console: capability rows surface their requested tool ids for per-tool selection
    (approve-all = one click); the core transform + lit renderer + strings render it.

  Pending-action engine (SPEC §18, #41)

  • In-memory pending-action registry. dashboard.action.invoke AND-gates a call (granted at
    invoke time + connector configured + hash unchanged): a readOnly granted tool executes
    directly; a mutation parks as a PendingActionRecord and returns { pending: true, id, expiresAt }. dashboard.action.confirm/dashboard.action.deny are operator-only
    (OPERATOR_ONLY_METHODS) — a networked client can directly execute only readOnly tools.
  • TTL expiry (~5 min), single-shot terminal states (a replay of a terminal id errors),
    server-side invoke rate limiting (prompt-gate discipline), an audit entry per invoke +
    decision, and lifecycle broadcasts on dashboard.action.changed.
  • confirmAndExecute(id) is exposed as the awaitable an agent-mediated call (M5c-1) blocks
    on: it resolves with the tool result on confirm and rejects on deny/expiry.

  The engine consumes the broker through the narrow structural ActionBroker interface —
  @boardstate/broker never enters @boardstate/server (no dependency cycle); the real
  McpBroker fits it structurally. SPEC §17.1/§18 normative text filled where the schema
  train (#39) left implementation-pending markers.

• Updated dependencies [b05c7cd, a0feba7]:

  • @boardstate/schema@1.2.0
  • @boardstate/core@1.2.0

@boardstate/mcp@0.2.4

Patch Changes

• Updated dependencies [c895241, b05c7cd, a0feba7]:
  • @boardstate/server@1.2.0
  • @boardstate/schema@1.2.0
  • @boardstate/core@1.2.0
  • @boardstate/lit@0.4.0

@boardstate/react@0.1.8

Patch Changes

• Updated dependencies [b05c7cd, a0feba7]:
  • @boardstate/schema@1.2.0
  • @boardstate/core@1.2.0
  • @boardstate/lit@0.4.0
  • @boardstate/host@1.2.0

boardstate-example-app@0.0.12

Patch Changes

• Updated dependencies [c895241, b05c7cd, a0feba7]:
  • @boardstate/server@1.2.0
  • @boardstate/schema@1.2.0
  • @boardstate/core@1.2.0
  • @boardstate/lit@0.4.0
  • @boardstate/host@1.2.0
  • @boardstate/agent@0.2.8

boardstate-example-standalone@0.0.12

Patch Changes

• Updated dependencies [c895241, b05c7cd, a0feba7]:
  • @boardstate/server@1.2.0
  • @boardstate/schema@1.2.0
  • @boardstate/core@1.2.0
  • @boardstate/lit@0.4.0
  • @boardstate/host@1.2.0

[evaos-code-review-bot]

evaOS review status: stale head

PR: #52 - Version Packages
Head: 990bb6ce78a2418dd8a9544ef5ffe6c91abc3507
Updated: 2026-07-10T14:05:15.654Z

evaOS review stopped because this queued head is no longer the live PR head.

Automation note: agents should wait for this comment to reach completed, stale_head, closed_or_merged_before_review, skipped, or failed before treating evaOS review as settled for this head. provider_deferred means evaOS still intends to retry.

PR URL: #52

[evaos-code-review-bot]

evaOS review status: completed

PR: #52 - Version Packages
Head: e04bca370b7de678ccbf8878120c980218e819af
Updated: 2026-07-10T14:11:53.442Z

evaOS review completed for this PR head.

Automation note: agents should wait for this comment to reach completed, stale_head, closed_or_merged_before_review, skipped, or failed before treating evaOS review as settled for this head. provider_deferred means evaOS still intends to retry.

PR URL: #52

Review URL: #52 (review)

[evaos-code-review-bot]

Walkthrough

PR: #52 - Version Packages
Head: e04bca370b7de678ccbf8878120c980218e819af into main. Review event: COMMENT.
Provider: GLM/Z.ai through ZCode (zcode-glm, zcode, model GLM-5.2).

Estimated review effort: 5/5 (~70 min)

Changed Files

File	Status	Churn	Purpose	Risk
.changeset/agent-replace-grant-gate.md	removed	+0/-9	Documentation	Low
.changeset/broker-mcp-client-manager.md	removed	+0/-27	Documentation	Low
.changeset/m5-schema-train.md	removed	+0/-24	Documentation	Low
conformance/CHANGELOG.md	modified	+9/-0	Documentation	Low
conformance/package.json	modified	+1/-1	Configuration	Low
examples/app/CHANGELOG.md	modified	+12/-0	Documentation	Low
examples/app/package.json	modified	+1/-1	Configuration	Low
examples/standalone/CHANGELOG.md	modified	+11/-0	Documentation	Low
examples/standalone/package.json	modified	+1/-1	Configuration	Low
packages/agent/CHANGELOG.md	modified	+8/-0	Documentation	Low
packages/agent/package.json	modified	+1/-1	Configuration	Low
packages/broker/CHANGELOG.md	added	+34/-0	Documentation	Low
packages/broker/package.json	modified	+1/-1	Configuration	Low
packages/core/CHANGELOG.md	modified	+29/-0	Documentation	Low
packages/core/package.json	modified	+1/-1	Configuration	Low
packages/host/CHANGELOG.md	modified	+8/-0	Documentation	Low
packages/host/package.json	modified	+1/-1	Configuration	Low
packages/lit/CHANGELOG.md	modified	+9/-0	Documentation	Low
packages/lit/package.json	modified	+1/-1	Configuration	Low
packages/mcp/CHANGELOG.md	modified	+10/-0	Documentation	Low
packages/mcp/package.json	modified	+1/-1	Configuration	Low
packages/react/CHANGELOG.md	modified	+10/-0	Documentation	Low
packages/react/package.json	modified	+1/-1	Configuration	Low
packages/schema/CHANGELOG.md	modified	+24/-0	Documentation	Low
packages/schema/package.json	modified	+1/-1	Configuration	Low

2 additional changed files omitted from this walkthrough.

Review Signal

No validated inline findings.
Dropped findings before posting: 0. High-severity findings: 0.

Risk Taxonomy

No finding categories.

Validation and Proof

1 required validation/proof recommendation(s) selected from changed files.

• required: TypeScript/web build or CI proof - Runtime TypeScript/web files or package/config files changed. Proof: npm run build; typecheck; focused Vitest; green GitHub check.
  Proof status: missing - 1 required validation/proof recommendation(s) missing from PR metadata.
  Profile validation hints: Prefer correctness, security, data-loss, release, and regression findings over style-only feedback.
  Profile proof expectations: Look for focused validation, rollback notes, and evidence appropriate to the changed surface.

Related Context

Related issues/PRs: #50, #37, #51, #41, #45.
Suggested labels: docs.
Suggested reviewers: 100yenadmin.

Review Settings Preview

• Profile: assertive
• Enabled sections: Review summary (inline_review); Walkthrough (inline_review); Changed-files table (walkthrough); Effort estimate (walkthrough); Related issues/PRs (walkthrough); Review status comment (sticky_status)
• Path instructions: none
• Label suggestions: none
• Reviewer suggestions: none
• Suggestion behavior: suggestions only; labels and reviewers are not auto-applied.
• Roadmap-only settings: auto-apply labels; auto-request reviewers; required status checks

Pre-merge checklist

• Inline comments target current RIGHT-side diff lines.
• No secret-like content survived into posted inline comments.
• REQUEST_CHANGES is only used when eligible P0/P1 findings survive validation.
• Required behavior proof is present or not applicable.
• Labels and reviewers are suggestions only; the bot did not auto-apply them.