Activity

1. jdbencardinop

   added

   enhancementRequested improvement or new capability.Requested improvement or new capability.

   fork-backlogMaintainer backlog for the multi-machine forkMaintainer backlog for the multi-machine fork

   on Oct 4, 2026
2. jdbencardinop commented on Oct 4, 2026

   

   jdbencardinop

   on Oct 4, 2026

   Author

   More actions

   Registered and pushed as requested-only tpatch feature copilot-chat-activity-intent on branch request/copilot-chat-activity-intent, commit ed16e31e8ae9a4fbcba805802c6bd594ec91aae1.

   Versioned request and investigation.

   tpatch next remains analyze; analysis phase and implementation have not been started. No product source change or PR.

   Recorded by GPT-6 Astra using GitHub Copilot CLI; no delegated inference.
3. jdbencardinop commented on Nov 6, 2026

   

   jdbencardinop

   on Nov 6, 2026

   Author

   More actions

   Current-source assessment: SDK 1.0.28 / v0.1.4 architecture

   The old SDK 1.0.8/file-path map in the original description is historical. This assessment uses validated main 0490e7bb2753ee455d58f9832f6ea943af81b0e0, upstream v0.1.4 783581d461dc72cdd8f78fc8abb4ad536dfc4547, and SDK 1.0.28 (official tag commit fa108e71ee3025663e0dac20f2a071055d3a6b14).

   Still available in the SDK schema: assistant.intent has data.intent, ephemeral: true, and optional agentId. It has no turn/message ownership field; its event ID, timestamp, and chronological parent are not a T3 attempt identity.

   Current gap: the Copilot adapter does not normalize this event into a client activity-description signal. The current thread stream carries snapshots and sequenced domain events, not an existing current-intent field. Reusing the old progress-event path would be the wrong architecture.

   The actual presentation points are now web/desktop ThinkingTimelineRow and native ThreadThinkingRow. This remains more than a label replacement.

   Zero-vendor-inference qualification attempted: two disposable SDK/native-CLI loopback sessions used runtime 1.0.105, protocol 3, empty isolated homes, configuration discovery and custom instructions disabled, and deterministic local responses. One used a report_intent-only tool filter with a fixture model; the other used the known gpt-4.1 profile and default offered tools. Both completed one local request with one user message, one idle event, no session error, and unchanged native identity. Neither offered report_intent or emitted assistant.intent. The fixture therefore did not establish live intent availability or cadence. This negative result is configuration-specific, not evidence that the CLI never emits the event. No external tools were executed or paid provider requests made; both native sessions, servers, and temporary homes were cleaned up.

   Recommended definition boundary: one bounded, deduplicated, advisory latest hint; root-agent only; scoped to the destination environment/thread/attempt; invalidated on turn replacement, completion, abort/error, session loss, and reconnect. Keep lifecycle and approval/input precedence, generic fallback labels, existing elapsed-time behavior, and all sidebar/notification/attention labels unchanged. Do not write a durable heartbeat row per hint, synthesize descriptions from reasoning, add polling, or add per-row timers/animation.

   Before implementation, obtain a genuine intent-producing trace and qualify its ordering around abort/steer/resume. Then choose a typed transient transport and shared client-runtime state without corrupting the thread stream's durable cursor. The initial historical request branch is untouched; no hint implementation, UI change, client probe, or deployment was made. The #42 event-ingress candidate is separate hardening, not an activity-description implementation.
4. jdbencardinop commented on Nov 6, 2026

   

   jdbencardinop

   on Nov 6, 2026

   Author

   More actions

   Continued native signal-production qualification

   Assessed the current SDK 1.0.28, bundled native runtime 1.0.105, protocol 3, against disposable loopback-only model fixtures. This used the actual SDK/native CLI, not a fake event emitter or a live conversation. No vendor inference, credentials, client/device work, or product changes were involved.

   The additional tool-cycle fixture completed two local model requests and one host-defined tool callback. The callback deliberately overrode the bash name with an in-memory handler; no shell command or filesystem tool ran. It emitted one user.message, one final session.idle, no session.error, and no assistant.intent. This does not qualify the native bash implementation itself.

   Read-only native metadata also showed:

   • The gpt-4.1 tool listing contained 15 tools, without report_intent.
   • The raw built-in descriptor listing contained 32 tools, also without report_intent.
   • The earlier intent-only and default-offered-tools fixtures likewise produced no intent. These are configuration-specific negative observations, not proof that all runtime modes, authenticated rollouts, models, or platforms lack the event.

   The pinned SDK still documents the ephemeral assistant.intent event. It does not document activation conditions sufficient to obtain a genuine producing trace in the configurations above.

   The separate native steering/queue experiment added an ownership constraint: user.message.data.turnId was "0" for both the original prompt and a later queued follow-up; an interjected prompt used "1". That identifier alone must not be treated as a globally unique T3 turn/attempt key for activity hints. Stable message admission/consumption identity and T3 attempt/session ownership remain distinct.

   Status: requested-only, blocked on a genuine intent-producing native configuration/trace before choosing and implementing the transport. No synthetic descriptions, durable progress rows, label changes, tpatch phase advancement, or lifecycle changes were made. A declaration-only implementation would not establish production availability or safe ownership.
5. jdbencardinop commented on Nov 6, 2026

   

   jdbencardinop

   on Nov 6, 2026

   Author

   More actions

   Explicit-streaming qualification: production signal still unobserved

   One configuration detail needed tightening: the earlier activity probes did not set streaming, whose SDK default is false. T3's Copilot adapter explicitly enables streaming. Those earlier results remain configuration-specific, not a production-equivalence claim.

   I executed another actual SDK 1.0.28 / bundled CLI 1.0.105 / protocol 3 session with streaming: true and includeSubAgentStreamingEvents: false, matching those T3 settings. The model endpoint was deterministic and loopback-only. The sole offered bash tool was overridden with an in-memory handler; no native bash implementation or shell command executed.

   Observed:

   • Two local model requests and one host-tool callback completed.
   • One native assistant.message_delta, one user message, and one final idle were received; native session identity stayed unchanged.
   • Raw delivered assistant.intent count: 0; no session error.
   • The model-specific native tool catalog still contained 15 tools and the raw built-in descriptor catalog 32; neither included report_intent.

   The SDK dispatcher delivers incoming events to both typed and wildcard callbacks; using a wildcard callback does not require a separate typed intent subscription. The probe counts raw intent events before interpreting their payload and propagates malformed intent payloads as fixture failures, rather than relying on an empty collected-description array.

   This rules out the omitted streaming option as the explanation in this specific configuration. It does not establish that authenticated GitHub/Fusion sessions, other models, interactive modes, or other runtime configurations cannot produce intent. No vendor inference, live-conversation writes, client launch, or implementation was performed.

   The request remains open and requested-only. We still need a genuine producing configuration/trace before selecting a production transport and attempt-ownership contract. The event's optional agentId is not itself a T3 attempt key, and native numeric turn IDs can be reused across queued follow-ups. Any eventual hint must remain advisory, bounded and root-scoped, with lifecycle invalidation; reasoning text or tool descriptions must not be substituted for a missing native signal.
6. jdbencardinop commented on Nov 6, 2026

   

   jdbencardinop

   on Nov 6, 2026

   Author

   More actions

   Longer native SDK and plain CLI comparison; activity API cross-check

   The SDK's documented assistant.intent remains the best semantic match for this request: native short current-work/plan text, ephemeral, with optional subagent identity. A documented schema is not evidence that the producer is active in every runtime/model configuration.

   Other declared signals are different:

   • tool.execution_start identifies a tool call and its arguments, not root-agent current intent.
   • tool.execution_progress carries a tool-scoped progressMessage/toolCallId. It may describe a particular tool, but is not documented as the general root brain-row signal.
   • assistant.reasoning/reasoning deltas are reasoning content, not a bounded activity hint.
   • session.info is categorized information, including configuration/status; Fusion phase events describe specialized runtime phases. Neither establishes an interchangeable generic current-intent source.

   No substitute label was generated from these signals.

   Prior coverage and its limit

   Earlier tests used the actual SDK 1.0.28 / native CLI 1.0.105 / protocol 3 against deterministic loopback model responses: intent-only/default-tool profiles, a two-request tool cycle, then explicit streaming enabled. They did not run authenticated model inference or an interactive terminal session. The omitted streaming setting was corrected before concluding it was not the explanation in that specific configuration.

   The negative observations were limited: none demonstrated that production intent was universally unsupported. Model-specific and raw built-in metadata did not list report_intent, but names/catalogs alone do not prove all configurations or feature rollouts behave alike.

   Additional executed coverage

   Profile	Execution	Observed signal
   Longer SDK session, streaming enabled	Three sequential user turns in the same native session; ten in-memory host-tool cycles per turn; 33 loopback model requests, 30 successful tool callbacks, three user messages and three final idles; no session error.	Tool/text streaming delivered; 0 raw assistant.intent, 0 tool.execution_progress, 0 reasoning events. No shell/filesystem tool ran in this SDK profile.
   Plain copilot CLI, no SDK wrapper	CLI 1.0.105, --stream=on --output-format=json, one prompt; 7 loopback requests, six native view tool calls reading six disposable files. Every native tool completion reported success and exactly matched the expected file text; result exitCode 0.	Native JSONL exposed assistant/tool-start/tool-complete/text-delta events; 0 assistant.intent and 0 tool.execution_progress. session.info only described disabled-tool configuration. No shell tool, credentials or vendor inference.

   The direct CLI profile used COPILOT_OFFLINE=true, a loopback custom provider, an empty disposable home/cwd and only the native read-only view tool. All six files belonged to the fixture. This is a genuine plain prompt-mode stream, not interactive CLI/TUI behavior. The SDK profile retained the same native identity across all three turns. Both profiles awaited their owned process/SDK/server shutdown and removed only their exact fixture directory.

   More model/tool iterations did not produce intent in either tested mode. This does not prove that elapsed duration is irrelevant in all configurations; neither fixture used a real model choosing its own reporting behavior. Long artificial delays would not supply the missing production-model/configuration evidence.

   Next evidence needed

   An explicitly approved, tightly bounded pair of actual-model SDK and plain-CLI sessions should use the same account/model/runtime, isolated native storage and a read-only disposable task with several real tool decisions. Capture live events/JSONL before considering any transcript import, because ephemeral intent is not persisted. If the terminal displays a genuine activity description but the event trace does not contain intent, inspect that renderer's actual source/correlated producer rather than assume the SDK event name. Interactive mode may need its own approved terminal capture; authenticated/Fusion behavior is not qualified by these loopback tests.

   Status remains open/requested-only. No runtime, transport, label, lifecycle, SDK upgrade, deployment or live-conversation change was made.
7. jdbencardinop commented on Nov 6, 2026

   

   jdbencardinop

   on Nov 6, 2026

   Author

   More actions

   Authenticated SDK/plain-CLI comparison and a second native activity source

   Completed the authorized bounded real-model comparison in disposable synthetic state, not a live T3 conversation. The account catalog enabled gpt-6-luna; it tied for the lowest declared input/output token-price pair in that catalog. No price currency or actual charge is inferred here.

   Both profiles used the same model and credential source: SDK 1.0.28/native runtime 1.0.105/protocol 3, and the plain CLI's streaming JSON prompt path. Each followed a five-file synthetic chain using only view, made six model calls, read all five exact file contents, and returned the correct total, 62. No shell, subagent, repository-content task, production flag change or client interaction was involved.

   Observed signals in each profile: zero assistant.intent, zero tool.execution_progress, and five nonempty assistant.message.data.toolRequests[].intentionSummary values. These are genuine native per-tool descriptions, not labels reconstructed by T3 from reasoning or tool output. The earlier deterministic plain-CLI trace also contained six such summaries.

   The alternative field is explicitly documented in the pinned SDK 1.0.28 event types: "Resolved intention summary describing what this specific call does." It is tool-scoped, not equivalent to the root agent's current activity/plan hint. The current Copilot adapter consumes assistant text and tool-start events but does not publish these tool-request summaries as root current-intent state.

   Flag investigation

   SDK session configuration does expose host-resolved featureFlags. An isolated, no-inference read of the installed native runtime's experimental internal static catalog returned 152 declared flags. No named general intent/activity producer gate was identified. Fusion and specialized reasoning/compaction flags exist, but that does not establish an intent activation switch.

   This is a bounded catalog/source observation, not proof that no account-, model-, experiment- or interactive-mode-specific gate exists. No flags were forced on, and internal metadata access is not proposed as a production dependency.

   Interpretation and remaining scope

   The longer loopback traces were not simply too short: real authenticated inference also emitted tool intentions without root assistant.intent. We now have a concrete second producer to assess instead of guessing an event name. However, neither prompt-mode JSON nor SDK traces prove what the interactive CLI's brain row displays.

   Keep this issue requested-only. A product decision is still needed on whether a native per-tool intention is an acceptable bounded fallback for the requested root description. Do not turn it into authoritative work/completion state, persist one row per update, scrape the terminal, or synthesize activity from reasoning. Root/subagent ownership, late updates, lifecycle clearing, reconnect and integrated client behavior remain unqualified.

   Raw events, account data and local fixture paths remain private. Disposable state was removed. No UI, adapter, capability, deployment or tpatch lifecycle change was made.