@chainlesschain/session-core

中文文档
0.3.27发布于 2026/11/09MITCommonJS构建来源已验证近 30 天下载 2668

Session lifecycle, trace store, agent definition, idle parker — shared by Desktop and CLI (Managed Agents parity)

原始使用文档
文档目录7 节
  1. Release candidate 0.3.26
  2. Release 0.3.25
  3. Release 0.3.24
  4. Release 0.3.22
  5. Release 0.3.21
  6. Release 0.3.20
  7. Native goal model-output authorization (source-only)

Session Core

Shared session lifecycle, trace, agent definition, memory, approval, sandbox, evolution receipt, and recovery primitives used by ChainlessChain Desktop and the CLI.

Release candidate 0.3.26

Adds controlled task.create proposal/request/v6 connection contracts, transactional draft conversion and recovery, and Memory output-token revalidation within an existing native transaction. Existing description-only grants do not acquire task-creation authority; model-derived drafts still require current Memory authorization and separate native preview/confirmation. Publish and read back this package before CLI 0.166.143 and its paired IDE extensions.

Release 0.3.25

Adds a bounded transactional goal-event journal, signed persistent cursors and read-only retained-history pages through the existing evidence reader. Risk checks and action receipts append with their native business transaction. Retention gaps, corruption and restored-database regression fail explicitly. Publication requires exact-source Linux, Windows and macOS verification and GitHub Actions OIDC; CLI 0.166.142 depends on this version.

Release 0.3.24

Reuses an isolated Windows native ACL worker instead of starting a process for each operation. Every operation still reads the current token and live ACLs, checks path identity, and closes its handles. Requests retain bounded input and output, independent kill deadlines, and request-specific response binding. Failed workers are discarded; permission failures never reuse cached authority. Monotonic deadlines tolerate application clock changes, and a stable child working directory lets callers remove disposable project directories normally. CLI 0.166.123 pins this release. Publication requires exact-source validation on Linux, Windows and macOS before GitHub Actions OIDC publishing.

Release 0.3.22

Restricts Windows PowerShell ACL script module discovery to the built-in Windows module directory. CLI 0.166.117 pins this release for private storage ACL operations.

Release 0.3.21

Fixes Windows PowerShell ACL operations for long local paths by using extended Windows paths internally while preserving the caller-facing paths. CLI 0.166.112 pins this release for signed local Quick Ask evidence storage.

Release 0.3.20

Publishes the governed goal drafting, evidence, extension proposal, and draft import APIs as public package entry points. These exports keep host-owned authorization and completion checks in the calling application.

The 0.3.15 release candidate adds business-object contracts, controlled task description actions and readers, offline risk rules and saved project risk reviews. CLI 0.166.90 pins this exact version. At candidate preparation, npm latest is 0.3.14, which supplies monotonic ApprovalGate policy revisions and synchronous revision events. The release workflow requires exact-commit CI, publishes the child before the CLI and verifies the public archive byte-for-byte.

The package exports its public modules through package.json, including ./runtime-claims, ./evolvable-artifact, ./structured-evolution-memory, and the session, approval, policy, and recovery contracts used by the host products.

The unreleased DMM foundation adds public ./scheduler-contract, ./scheduler-service, ./scheduler-runtime, ./scheduler-store, ./scheduler-source-path, ./private-storage and ./host-storage-environment entry points for CommonJS hosts and ESM consumers. CLI compatibility entries retain their original Graph, configuration, home and native driver assembly. The shared runtime requires live authorization and an injected Graph Authority or explicitly selected legacy Graph mode. The shared store requires a host driver, a separate database file and synchronous storage protection before and after opening. ./scheduler-authority-resolver supplies the shared policy binding, non-mutating availability checks and durable reservations. These entries do not load the CLI Graph or configuration stack.

./goal-contract and ./goal-repository define bounded, versioned goal records and storage adapters with compare-and-swap updates. ./project-goal-service stores personal project goals in the host's existing native SQLite database, rechecking current host identity and project ownership within immediate transactions. Metadata IPC cannot launch work or claim verified completion. Budgets and authorization references describe intent; execution must still use the host's current authorization and usage ledger. Completion verification is disabled unless the host supplies an independent trusted checker. See the implementation progress for the current boundary, legacy compatibility and test evidence.

./project-goal-monitoring provides explicitly enabled personal-project risk checks through the shared scheduler. Native project transactions commit each review, occurrence-bound check evidence and goal usage together. A separate scheduler ledger can recover a committed check without another review or debit. Per-goal run/time limits, current principal policy and current project ownership are rechecked before work and before domain commit. Manual request IDs bind durably to a goal/control/policy version; fresh intents can bind a new policy without changing prior replay identities. Timer periods coalesce after downtime. Historical and terminal results revalidate the saved authorized risk evidence.

The desktop host protects its separate scheduler database, drains work on exit, and derives monitoring identity from successful main-process password/UKey login handlers. Locking or removing a UKey and logging out revoke the relevant session. Loading a default DID does not authenticate a session. The project risk panel exposes explicit start/stop/check/status controls and saved evidence. This first adapter runs deterministic rules with zero model usage; business writes, notifications and independent goal completion remain separate work.

The source also exports ./business-object-contract: immutable references for Project, Task, Document, Person, Decision and ActionRun; version-bound action requests; and action run records containing evidence references. Content versions use SHA-256 over bounded JSON with sorted object keys. Action identity binds the source, scope, target revision and input digest; reuse of an idempotency key with different action content is rejected by assertBusinessActionReplay.

These contracts do not execute actions or grant permissions. Hosts still need authoritative identity, current permission and approval checks, an atomic version comparison, durable idempotency and authorized evidence readers. Matching request digests do not permit replay when the previous outcome is unknown. A structurally valid run record does not authenticate its evidence or prove business success.

./task-description-action-service adds the first concrete business action: TaskDescriptionActionService updates project_tasks.description for pending tasks in personal draft/active projects. The native SQLite host supplies its current DID and a private strict/high ApprovalGate with native user confirmation. The service checks ownership and the complete row version again after approval, then commits the edit and ActionRun evidence atomically. Organization/workspace tasks and non-native database fallbacks are unsupported. Repeated invocations return durable receipts; interrupted running receipts remain unresolved and are never automatically replayed. Receipt reads recheck current ownership.

The service also supplies bounded listTasks, readTask, and listRuns readers for the live project task panel. Metadata and receipt reads do not load large task result payloads. An unresolved run blocks a new action for the same task, even with a new idempotency key; replaying the original request only reads its durable receipt. Workspace resource associations are refused by this personal-only adapter alongside organization fields.

The same module's createTaskDescriptionPreview prepares a request from an offline snapshot and explicitly labels its authority unverified-snapshot. The CLI exposes this preparation path, while the desktop host exposes the live action through separate IPC/preload methods. Existing task editors and legacy CRUD paths are not all converted. See the controlled action guide for the boundary, invocation examples, receipt semantics, and focused host tests.

./project-risk-evaluation exports evaluateProjectRiskSnapshot, a deterministic offline evaluation of complete, bounded project/task snapshots. Its rule version, input digest and content-versioned references support reproducible comparisons. Its risk-specific references are selected-field projections, not the complete database-row versions required by controlled actions. Evaluation neither authenticates the snapshot nor approves an action or predicts project delivery.

./project-risk-review-service adds an authorized desktop reader and durable rule review. ProjectRiskReviewService({ db, getActor }) reads the current owner's personal project in one native SQLite transaction, evaluates selected task fields, and stores the source snapshot and result. evaluate({ projectId }) and getReview({ reviewId }) return { review, sourceSnapshot, evaluation }. Historical reads recheck current ownership and verify stored content against the deterministic evaluator. Missing columns or excessive task counts remain explicitly incomplete; a failed SQL read never becomes an empty successful evaluation. Reviews are not approvals and are not yet bound to action receipts. See the project task workbench guide.

npm test --workspace packages/session-core

The working tree also exports ./goal-extension-proposal-contract and ./project-goal-extension-queue. The shared proposal contract maps SDK task.description.update to native task.update-description explicitly. ProjectGoalExtensionQueue requires a trusted native ProjectGoalWorkflow and a synchronous live admission callback. It stores pending suggestions, binding the current actor, goal revision/control generation, native risk proposal and exact review digest. Repeated request IDs replay the same draft; changed input conflicts. Reads recheck source and admission, including after disable/re-enable.

Trusted hosts can call prepareDraft({ id }) to bind a persisted draft to one immutable conversion, native request and intent ID. Reopening after a crash or retrying a lost response resumes those IDs. Native preview, explicit approval and action evidence retain the exact draft/conversion digests in extensionRef. Install a synchronous verifyExtensionIntent callback on ProjectGoalWorkflow and delegate it to queue.verifyIntentInTransaction(context) before use; missing or asynchronous verifiers cannot admit converted work. Ordinary intent APIs also recheck current grants and source for pending work. Existing running/terminal receipts remain readable after revocation without executing again.

The source adapter accepts description suggestions and task.create drafts. Creation requires an explicit taskType from GOAL_EXTENSION_TASK_TYPES; description proposals reject that field. The type is pinned through SDK authorization, pending storage, conversion and native intent integrity checks. list({ goalRef, type: "task.create" }) requires creation admission and returns only creation drafts; omitting type preserves description-only list behavior. Hosts must authorize each actual proposal type independently. The desktop built-in rule uses separate creation consent and retains the existing description grant identity. These are working-tree additions; the CLI v3 online bridge and v1 description-file adoption contract remain description-only. Source assistant 0.3.0 declares creation capability; it still requires separate native authority. The separate chainlesschain.goal-task-create-request/v1 file contract uses createGoalTaskCreateRequest / validateGoalTaskCreateRequest from ./goal-draft-request-contract. Trusted native importers dispatch through validateGoalDraftImportRequest; the original validateGoalDraftRequest still accepts description files only. ProjectGoalDraftImports separately confirms each creation file and binds it to native-imported-task-create, preserving the original description identity and preventing an old adoption from granting creation. Request identity, full task type/body, original risk source, revocation epoch, native preview and ActionRun remain bound through restart and retry. Plugins receive only the pending enqueue port; the queue has no execution port. Native descriptions are limited to 8192 UTF-8 bytes before conversion; conversion records are limited to 8 KiB. Storage is bounded to 100 drafts per actor/goal/plugin, 48 KiB per record and 20 candidates per page. The desktop's fixed built-in rule uses a separate native consent namespace; it does not establish CLI plugin trust or a live CLI project connection. These exports require a corresponding Session Core child release before downstream CLI or desktop distribution.

The working tree also exports ./project-goal-evidence-reader and ./goal-evidence-contract. ProjectGoalEvidenceReader({ db, getActor, clock }) offers readSummary(goalRef) and read(goalRef) for an exact active personal project goal. It reuses native goal, risk-check and action-receipt integrity validators through an internal read-only SQLite facade. Native statement readonly/reader flags are required; only deferred read transactions run. Construction and reads never initialize schemas, recover actions or settle usage.

Evidence contains the newest persisted check (including incomplete results) and the last 20 real action receipts ordered by native run insertion, with hasMore. Recent drafts cannot hide receipts. Missing stores remain unavailable, unknown risk remains null, and running actions remain unresolved. Projections contain bounded metadata only, explicitly historical, with no task bodies or approvals. The shared contract strictly validates fields and formats bounded plaintext. The working tree additionally adds ProjectGoalEvidenceReader.readEventPage(goalRef, after) and validateGoalEventHistoryPage / parseGoalEventCursor from the existing ./goal-evidence-contract export. Native monitoring and goal actions append compact events in their business transactions, including both running and terminal action states. A failed append rolls back that transaction. The private journal keeps a monotone per-actor/goal sequence, keyed entry integrity, 1000 retained entries and at most 4096 durable duplicate identities. No task, goal or memory body is copied.

Pages are authorized read-only views over an exact active personal goal, at most 20 entries and 16 KiB. Cursors are signed by persistent per-stream keys and bind actor, store, goal revision and control generation; they survive connection/server restart without becoming authorization. Eviction, missing records, corruption or restoring a database behind the cursor fails explicitly. Missing journal storage is unavailable, not empty. Only newly instrumented native transactions enter the journal: old data and writes from older clients are not backfilled. CLI replay and v5 native authorization are distinct from the v4 latest-snapshot observer.

This is an unreleased child-package change. Exact-source cross-platform validation and child-first OIDC publication remain required before downstream CLI/IDE releases.

Hosts must still provide current authenticated identity and explicit evidence consent; the desktop uses a distinct capability-bound connection rather than expanding an existing summary lease. These exports are not yet published.

./goal-draft-request-contract and ./project-goal-draft-imports add explicit offline request handoff. The strict envelope contains a declared plugin label, declaration digest and exact versioned description proposal, with a 16 KiB total and 8192 UTF-8 byte description limit. Neither digest authenticates plugin code. ProjectGoalDraftImports requires a trusted native workflow and confirmation callback. It binds each adoption to the current native actor, source and exact payload; the queue uses a fixed native importer identity with user-edited origin. Metadata cannot select a privileged plugin or grant.

Adoption and pending draft insertion share one native immediate transaction via the queue's trusted enqueueInTransaction composition entry. Reimport is idempotent, conflicting payloads are rejected, and lost responses/restarts reuse the same persisted identity. Revocation advances the per-record epoch and cannot be undone by importing again. Pending conversion/execution verifies the exact adoption payload and epoch; completed history stays available. Native hosts must route verified imported drafts to this verifier and preserve the ordinary native preview/approval flow. The desktop provides explicit import/list/read/prepare/ revoke endpoints; no online write authority is added to existing read leases.

./goal-draft-connection-contract and ./project-goal-external-drafts add the independent v3 online pending-draft capability. ProjectGoalExternalDrafts requires a native ProjectGoalWorkflow; only the trusted host may call grant({ goalRef, access, expectedEpoch }) after native consent. Grants persist across disconnect/restart and bind actor/store/project/goal/full plugin identity, declaration digest and epoch. CAS prevents delayed consent from undoing revoke. Revocation invalidates old pending drafts and converted intents, while completed action history remains readable under existing business permissions.

sourcePage scans at most 20 native proposal IDs with unavailable counts. enqueue inserts pending drafts only, atomically and idempotently; current native source and authorization checks still apply. submissionReceipt validates exact request/digest and current grant epoch without requiring the source to remain fresh. These read operations use deferred transactions and support SQLite query_only; writes use immediate transactions. Unknown/corrupt evidence fails. Native list/read/prepare methods continue the existing conversion and action workflow; no HTTP caller receives prepare, approval or execute authority.

The same modules expose a separate creation profile: validateGoalCreateDraftAccess, validateGoalCreateDraftDescriptor and validateGoalCreateDraftProposal. Access schema is chainlesschain.goal-create-draft-access/v1; the descriptor is chainlesschain.project-goal-connection/v6, capability goal.create-drafts, endpoint /goal-create-drafts. Request/response MACs use independent v6 domains. Existing v3 validators, endpoint and grants remain description-only.

Creation grants use chainlesschain.goal-external-create-grant/v1 with type: "task.create". Their identity hash additionally includes the action, preserving legacy grant IDs and record shapes. Current goal creation scope, grant epoch and source are checked before pending writes and confirmation. Task type is immutable through draft, conversion and intent. Revocation/counts are separate by action; reuse of the same plugin/goal/request identity across actions conflicts. Submission references retain the existing body-free schema, with distinct grant identity and proposal digest binding the creation action. Unknown outcomes require lookup of that identity, without automatic resend.

The contract also validates body-free, credential-free submission references. Clients must persist the exact request identity before dispatch and reconcile unknown outcomes without automatic resend. Metadata hashes ensure consistency, not plugin code authentication. These exports remain unpublished; downstream distribution requires a corresponding child-package release first.

Native goal model-output authorization (source-only)

ProjectGoalMemoryService.revalidateOutputInTransaction(token) repeats the existing exact goal/scope/sink/version/digest/grant/epoch/expiry checks inside a trusted caller's synchronous native transaction. Calling it without a transaction fails. revalidateOutput(token) remains the standalone wrapper; neither accepts cached memory bodies or adds a model sink to persistent memory permissions.

The source desktop uses this guard for an on-demand local Ollama draft pipeline. Each model call requires its own native consent, with the full selected input. Memory is off by default; consent permits only that invocation's local processing. Pending model output is checked again on save, list/read, preview and individual task confirmation. Expired/revoked memory invalidates unconfirmed output; completed business receipts remain historical. Governance input/response evidence is retained under its own lifecycle, so this does not promise physical deletion of prior copies.

The shared GoalUsageLedger reserves before socket dispatch and records unknown usage before the call can leave. Available prompt/completion counts are recorded without inventing cost. The current local adapter cannot reliably reserve a token or monetary upper bound, so finite token/cost budgets refuse dispatch. Existing model identities only query; restart or unknown never automatically calls again. These are unpublished source additions; real model-quality, GUI and business-effect acceptance are separate from synthetic protocol and SQLite tests.

版本与发布记录

@chainlesschain/session-core 共发布 28 个版本,首次发布于 2026/04/16;过去 12 个月发布了 28 个版本。最新版本附带 npm provenance 构建来源证明,可追溯到公开的 CI 构建记录。

版本发布日期距今
0.3.27latest2026/11/09今天
0.3.262026/11/063 天前
0.3.252026/11/054 天前
0.3.242026/10/2614 天前
0.3.232026/10/2515 天前
0.3.222026/10/2317 天前

关于 @chainlesschain/session-core 的常见问题

@chainlesschain/session-core 是什么?

Session lifecycle, trace store, agent definition, idle parker — shared by Desktop and CLI (Managed Agents parity)

如何安装 @chainlesschain/session-core?

在项目目录运行 npm install @chainlesschain/session-core,或使用 pnpm add / yarn add / bun add。

@chainlesschain/session-core 支持 TypeScript 吗?

该包的 package.json 没有声明类型入口。需要类型提示时,可以在 npm 上查找社区维护的 @types/chainlesschain__session-core 是否存在。

@chainlesschain/session-core 支持 ESM 还是 CommonJS?

以 CommonJS 形式发布,可以直接 require();在 ES Module 项目中也可以用 import 引入(Node.js 会把 module.exports 作为默认导出)。

@chainlesschain/session-core 需要什么版本的 Node.js?

package.json 的 engines 字段要求 Node.js >=18.0.0。版本不符时 npm 默认只给出警告,开启 engine-strict 后会拒绝安装。

@chainlesschain/session-core 可以商用吗?

@chainlesschain/session-core 使用 MIT 许可。宽松许可:允许商业使用、修改和再分发,通常只需在分发时保留原版权与许可声明。以上为概括,不构成法律意见,请以许可原文为准。

@chainlesschain/session-core 的下载量有多少?

根据 npm 官方下载统计,@chainlesschain/session-core 在 2026/10/10 – 2026/11/08 这 30 天内被下载 2,668 次,日均约 89 次。下载量会把 CI 构建、镜像同步和作为其他包依赖的安装一并计入,适合横向比较热度,不能直接等同于使用人数。

@chainlesschain/session-core 还在维护吗?

最新版本 0.3.27 发布于 2026/11/09(今天);至今共发布 28 个版本,其中过去 12 个月发布了 28 个;首次发布于 2026/04/16。发布频率只是参考信号:功能稳定的工具可能很少需要更新,建议结合源码仓库的 issue 和提交记录判断。