@vtxmacro/cli 2026.9.60 → 2026.9.61

package/README.md

@@ -95,11 +95,11 @@ with an uncertain outcome are fenced; same-attempt recovery is not supported.
 An explicitly capable model from a background service listed above can also
 control Main in **Agent** mode using the same VTX OAuth grant and its own local
 adapter-specific vendor credential: ChatGPT, Copilot, or Grok login, or a DeepSeek
-or Pi provider API key. VTX assigns the running bot but does not send a VTX-authored prompt or set
-the analysis cadence. The assigned runtime keeps a durable Agent thread,
-chooses when to wake, requests only the assignment-scoped VTX data it needs (or
-none), and submits the normal structured decision for VTX to validate and
-execute. Review and Screener remain Provider-only.
+or Pi provider API key. VTX assigns the running bot and supplies canonical Agent instructions. The
+assigned runtime keeps a durable thread, requests assignment-scoped data as
+needed, and chooses whether to submit a structured decision. A configured
+observation schedule runs independently of model turns; it never forces HOLD
+or trading JSON. Without a schedule, the model chooses its next wake. Review and Screener remain Provider-only.
 
 Before the first Codex login, enable **Device code authorization for Codex** in
 ChatGPT Security settings. Only enter a device code from a login you initiated,
@@ -167,7 +167,7 @@ vtx inference-host service install --adapter pi --instance pi-1
 
 Pi uses the package-owned SDK and exact provider/model identities. The existing
 Provider / Agent controls apply: Provider receives VTX's prompt and has no
-tools; Main Agent keeps an isolated session and only the three VTX tools.
+tools; Main Agent keeps an isolated session and the canonical VTX assignment tools, including schedule control.
 The initial qualified models use an OpenAI API key; the release embeds VTX's
 configured exact model IDs and SDK capability mappings. API compatibility alone
 does not qualify a provider. Ordinary Pi
@@ -321,6 +321,80 @@ schema plus `provenance` with `source: "external_agent"`, a stable
 `agent-assignment-release` only when intentionally ending the foreground Agent
 session; normal cadence is recorded with `agent-assignment-heartbeat`.
 
+For recurring checks in any supported live Agent harness, configure a schedule
+with `agent-schedule-set --json` after claiming the assignment, then loop
+`agent-check-next --wait-seconds 50 --json`. Keep `agent-run` open: it samples
+markets independently of model reasoning, and the check tool handles waiting.
+When `check_ready` returns, review its observation using your existing
+authorized tools. Finish with `agent-check-complete --json` and stdin
+`{"turn_id":"<returned-id>"}`. No HOLD or trading JSON is required. If you
+choose to submit a decision, include that `turn_id` with the existing
+candidate/provenance fields. A `waiting` response means call check-next again;
+`check_pending` means finish the exact unfinished check first. Resolve an
+uncertain decision through decision-status before completing its check.
+This preserves the original harness session and all its authorized tools
+without writing a harness-specific scheduler. It cannot reopen an exited
+harness session; the managed wrapper below supplies unattended process restart.
+
+## Managed Agent cadence and native tools
+
+A compatible managed wrapper lets the harness keep its own authorized tools
+while VTX handles observation timing, thread handoff, heartbeats and service
+supervision. The packaged `vtx-managed-codex` binary is the native Codex
+reference wrapper. Other harnesses need a compatible wrapper; ordinary
+foreground support alone does not prove unattended managed invocation.
+
+Create a private, current-user-owned local launch file. For example, point Node
+at the installed wrapper JavaScript and the exact local Codex executable:
+
+```json
+{
+  "schema_version": "vtx_managed_harness_launch_v1",
+  "executable": "/absolute/path/to/node",
+  "argv": ["/absolute/path/to/vtx-managed-codex.js", "/absolute/path/to/codex"],
+  "workspace": "/absolute/path/to/agent-workspace",
+  "recovery_marker": "/absolute/private/path/to/agent-turn.json"
+}
+```
+
+Use native absolute paths on Windows. The file must be private to the current
+user. The wrapper creates a dedicated native thread with the user's local
+configuration and tools; it does not adopt a visible conversation or approve
+interactive permission requests. Launch commands come only from this local
+file. The host never accepts executable paths from an assignment or model.
+
+Pass an initial request on stdin, such as
+`{"schedule":{"interval_seconds":60,"objective":"Observe markets; act only when appropriate.","observation":{"capability":"market.snapshot","arguments":{"symbols":["BTC"],"timeframe":"1m"}}}}`.
+This is an example cadence; the server's configured bounds apply. After the
+normal VTX login for this isolated instance, install and start its worker:
+
+```bash
+vtx inference-host service install --adapter codex --instance agent-1 --launch-config /absolute/private/launch.json --model <exact-model-id> --effort <effort> --json < /absolute/private/schedule.json
+```
+
+The existing OS service manager supervises the worker and starts it at login.
+Use the same instance for service status, logs, stop/start and uninstall. The
+foreground alternative is `agent-managed-run` with the same launch/model/effort
+arguments and JSON input; it requires its process to stay open. Neither command
+starts a VTX bot or changes its profile settings. Bind and start the intended
+bot separately through its authorized normal control path.
+
+`agent-schedule-read --instance agent-1 --json` inspects the active assignment.
+`agent-schedule-set --instance agent-1 --json` accepts
+`{"schedule":...}` on stdin; `{"schedule":null}` cancels recurring checks
+without stopping the bot or closing positions. The persisted objective and
+revision travel with the assignment. Saved profile trading interval is separate.
+Long model turns may delay review even while observations continue. Sleep,
+outages and stale sources are recorded as gaps, not successful fresh checks.
+
+`prompt.variables` discovers every canonical trading prompt variable;
+`prompt.context` reads selected names or all names for one owned profile.
+Disabled indicators are available request-locally without settings changes.
+Values share provider calculations, format instructions and unavailable
+semantics, including future variables. Full ordinary Insights MCP access and
+external tools remain separate authorized harness connections; the inference
+grant does not expand into account-wide mutation permission.
+
 ## Exo foreground trading inference
 
 Exo means [exoharness/exo](https://github.com/exoharness/exo). VTX runs a dedicated

package/bin/exo-harness.ts

@@ -16,6 +16,7 @@ type Input = {
   provider: 'openai' | 'venice';
   mode: 'provider' | 'agent'; systemPrompt: string; userPrompt: string;
   outputSchema: Json; decisionSchema: Json; dataContract: { id: string; input_schema: Json }[];
+  toolSpecs: Json[];
   requestedModel: string; providerModel: string; reasoningEffort: string;
   nativeReasoningEffort: string | null; maxRounds: number;
   deadlineAtMs: number;
@@ -155,19 +156,22 @@ const chatRequestMessages = (harness: ExoHarnessModule, events: unknown[]): Mess
   return messages;
 };
 
-const toolsFor = (input: Input): Json[] => input.mode === 'provider' ? [] : [
-  { name: 'vtx_get_data', description: 'Request assignment-scoped VTX data.', parameters: {
-    // Keep the complete branch contract, while exposing its common fields to
-    // Chat tool renderers that enumerate only top-level properties.
-    type: 'object', additionalProperties: false, required: ['capability', 'arguments'],
-    properties: { capability: { type: 'string', enum: input.dataContract.map((entry) => entry.id) }, arguments: { type: 'object' } },
-    oneOf: input.dataContract.map((entry) => ({ type: 'object', additionalProperties: false,
-      required: ['capability', 'arguments'], properties: { capability: { const: entry.id }, arguments: entry.input_schema } })) } },
-  { name: 'vtx_submit_decision', description: 'Submit a canonical VTX decision.', parameters: {
-    type: 'object', additionalProperties: false, required: ['candidate'], properties: { candidate: input.decisionSchema } } },
-  { name: 'vtx_decision_status', description: 'Resolve a VTX decision operation.', parameters: {
-    type: 'object', additionalProperties: false, required: ['operation_id'], properties: { operation_id: { type: 'string', minLength: 1 } } } },
-];
+const toolsFor = (input: Input): Json[] => input.mode === 'provider' ? [] : input.toolSpecs.map((spec) => {
+  const parameters = record(spec.inputSchema);
+  // Chat serializers enumerate common top-level fields; preserve the complete
+  // canonical branch schema supplied by the authenticated local broker.
+  const branches = Array.isArray(parameters.oneOf) ? parameters.oneOf.map(record) : [];
+  const branchProperties = branches.map((branch) => record(branch.properties));
+  const common = branchProperties.length > 0 ? {
+    type: 'object', additionalProperties: false, required: branches[0].required,
+    properties: Object.fromEntries(Object.keys(branchProperties[0]).map((key) => [key,
+      branchProperties.every((properties) => key in properties)
+        ? key === 'capability' ? { type: 'string', enum: branchProperties.map((properties) => record(properties[key]).const) }
+          : { type: 'object' } : {},
+    ])),
+  } : {};
+  return { name: spec.name, description: spec.description, parameters: { ...common, ...parameters } };
+});
 
 export default {
   tools: [],