@xiaozhiclaw/qlogicagent-core 0.4.1 → 0.6.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -41,9 +41,16 @@ Context comes from the authenticated product, never from a model/browser claim.
41
41
  Skill knowledge is maintained by each product with its module version; MCP may
42
42
  be its tool execution protocol. The core does not install capabilities.
43
43
 
44
- Presentation contracts support choices, tables, diagrams, attachments and
45
- engineering file evidence. Each SaaS renders actual returned content blocks in
46
- its own UI. Tool names and paths do not imply artifacts or business success.
44
+ Presentation payloads are product-defined id/type envelopes. Core preserves
45
+ their fields without defining choice/table/diagram/attachment schemas or parsing
46
+ engineering files. Each SaaS validates and renders its own returned blocks.
47
+ Tool names and paths do not imply artifacts or business success.
48
+ Version 0.6.0 also stops deriving execution identities from wire names.
49
+ Ledger identity is optional and only contains matching product-authored metadata;
50
+ family/category are open product strings. Domain error metadata remains opaque.
51
+ Supplier response parsing, schema adaptation, parameter correction and cache
52
+ accounting belong to the injected transport. Product UI message fields belong to
53
+ product types, which may extend `ChatMessage`. Registry metadata determines publication status.
47
54
 
48
55
  This library has no production dependencies, CLI, desktop host, local tool
49
56
  runtime, native session store or per-process credential/policy discovery.
@@ -57,8 +64,18 @@ require request-bound model-service evidence; acknowledged original responses ca
57
64
  be replayed without another inference. Sensitive response bodies are excluded from
58
65
  progress events. Provider usage is distinct from settlement evidence.
59
66
 
60
- Optional `assistantContext` binds module schema/prerequisites, enterprise configuration
61
- and source state, employee permissions, and versioned platform Skill/examples.
67
+ Optional `assistantContext` is a product-defined JSON object. Core requires no
68
+ organization, employee, brand, knowledge base or Skill. Only its optional
69
+ `instructions` string supplies trusted product guidance; all other fields are
70
+ factual context and are preserved without interpreting their domain schema.
71
+ Products validate their own fields, examples and references, and supply tools
72
+ and independent verifiers. `tenantId` is an opaque data namespace and may identify
73
+ a personal workspace rather than an organization; `actorId` may identify a user
74
+ or service. Nothing creates an enterprise or membership model in Core.
75
+ The `opaque-v1` context projection is checkpoint-bound. An earlier checkpoint
76
+ with a different context projection requires explicit product migration; Core
77
+ does not reinterpret its saved input or tool receipts. Checkpoints without an
78
+ assistant context retain their existing binding protocol.
62
79
  Optional `goal` requires a product `verifyGoal` callback before semantic completion.
63
80
  Products may resolve a user-confirmed goal from receipts with `resolveGoal`, and
64
81
  return independent verification evidence to the same loop through `goalFeedback`.
@@ -69,6 +86,28 @@ Criteria may carry opaque product `parameters`; verification can return `expecte
69
86
  domain rules or declare unsupported criteria satisfied.
70
87
  Context anchors carry explicit revision/supersession/source references through
71
88
  compaction, keeping unresolved conflicts visible. Product tools retrieve material.
89
+ Optional `runtime.prepareContext(messages, context)` asynchronously retrieves and
90
+ projects product task materials before inference. `context` carries the model,
91
+ input token budget, session/turn IDs and cancellation signal.
92
+ The budget is `Infinity` when context-capacity metadata is explicitly disabled;
93
+ retrieval still runs and the provider remains responsible for its actual capacity.
94
+ Return `{ messages, droppedCount, strategy }`; retrieval and fact updates are applied even
95
+ when `droppedCount` is zero. Keep original intent, current user amendments and
96
+ complete tool call/result groups. Source retrieval, conflicts and summaries remain
97
+ product-owned. Checkpoints retain the projected conversation; original tool receipts
98
+ remain complete. Without this callback, the sliding window retains original intent,
99
+ the latest amendment, current facts and the latest complete protocol group, then
100
+ fills remaining capacity with recent history. These essential messages may exceed
101
+ capacity; Core does not silently drop them or pretend an estimate proves model fit.
102
+ Optional `runtime.countMessageTokens(message, model)` supplies model-aware counts
103
+ for the default window. Its fallback is an advisory serialized-message estimate.
104
+ The input budget reserves configured maximum output tokens rather than a fixed
105
+ percentage; provider context errors remain authoritative.
106
+ After retrieving current product facts, call public
107
+ `prepareSlidingWindowContext(messages, context, countMessageTokens?)` to reuse
108
+ the same canonical window implementation. Product retrieval must not accidentally
109
+ disable context-capacity handling. The helper preserves objective/fact anchors
110
+ and complete tool protocol groups without changing the supplied messages.
72
111
  Tool text is complete by default. The removed `maxToolResultChars` option is
73
112
  replaced by optional product-owned `runtime.projectToolResult`; persisted receipts
74
113
  retain the original result. No quality score controls execution.
@@ -76,6 +115,24 @@ Task request/deadline budgets survive resume; products own atomic financial quot
76
115
  reservation through `reserveModelBudget`. Optional delta batching preserves control
77
116
  event order and cursor continuity. These contracts do not create new product stores,
78
117
  business rules, queues or accounting authorities.
118
+ The task ceiling carries an opaque product ID, accounting unit and positive exact
119
+ decimal string. Core does not round it or impose CNY, four-digit precision or an
120
+ amount range. The injected financial authority must accept or explicitly reject
121
+ that contract and enforce the original ceiling atomically; it remains responsible
122
+ for supported currencies, precision and settlement. The model transport supplies
123
+ normalized usage totals; source names in usage records stay opaque to Core.
124
+
125
+ Cloud execution does not invent a round limit, per-response tool-call limit,
126
+ retry-count limit, total presentation-block limit, compaction-count stop or default
127
+ tool timeout. Products may supply per-tool `meta.executionTimeoutMs`; task deadlines
128
+ and caller cancellation still propagate to tool execution.
129
+ Omitted round/tool-call limits remain unbounded; explicit `maxToolCalls: 0`
130
+ allows no tool execution, and `maxRounds: 0` means unbounded rounds.
131
+ Products supply their original request, deadline and financial budgets. A retry
132
+ still requires explicit retryability, proven safety and automatic authorization;
133
+ an unknown request is never retried merely because a connection was lost.
134
+ Products retain their own UI schemas and domain validation. Core validates only
135
+ the presentation envelope and keeps all original receipt fields.
79
136
  `appendInput(context, taskId, {id, messages, data?})` lets a product append an authenticated
80
137
  user amendment to a resolved completed/stopped task. The amendment ID is durable
81
138
  and idempotent; a conflicting repeat is rejected. It preserves the original
@@ -94,3 +151,26 @@ task names and error text cannot authorize another paid inference request.
94
151
  See the repository's `docs/cloud-runtime.md` for detailed contracts, product
95
152
  integration boundaries and acceptance commands. Release status belongs to the
96
153
  source workspace README and package registry; this API guide is version-independent.
154
+
155
+ `createBusinessToolAdapter({port, observe})` adapts a product-owned external job to
156
+ the existing cloud tool wait protocol. `port.submit` deduplicates the original
157
+ invocation; `resolve` calls only `port.query`. Missing/unknown results remain
158
+ external waits, never authorize another submission. Optional `port.cancel`
159
+ returns an authoritative observation rather than assuming cancellation succeeded.
160
+ `observe` persists progress, resource references and outcomes before acknowledgement.
161
+ Forward the immutable `invocation.taskBudget` to paid tools. This adapter owns no
162
+ database, scheduler, polling policy or business condition language.
163
+
164
+ Optional `agent.shouldPause(context, checkpoint)` reads product-owned durable pause
165
+ intent after a saved `model_ready` checkpoint. It finishes the current model or
166
+ atomic tool receipt first; it does not cancel an unknown effect. The task becomes
167
+ `stopped` with `CLOUD_TASK_PAUSED`. `runtime.resume(context, taskId)` queues that
168
+ same safe checkpoint without new input, resetting no budget, deadline or receipt.
169
+ Products must atomically reopen their dispatch projection for this exact transition.
170
+
171
+ Original completed-model replay uses the immutable stored messages and digest.
172
+ Current product retrieval is refreshed for subsequent new rounds only. A digest
173
+ mismatch is reconciliation, never permission to pay for a replacement inference.
174
+ An explicit amendment consumes the previous final no-tool response once before
175
+ advancing the round. Reading a saved final response remains possible after the
176
+ original deadline; any new model request or tool effect still observes that deadline.