[keithpk]

Summary

• Add negotiated public PaseoAgentHandle.config() readback bound to the exact agent ID and persisted AgentManager revision.
• Return canonical secret-free fingerprints for launch env, MCP servers, provider options, tool policy, feature values, and prompt; never return raw values.
• Reject old daemons before sending the request when the server capability is absent.
• Add protocol/client/server tests and SDK docs.

Validation

• Focused Vitest: protocol wire schema, server readback, client negotiation/identity, and AgentConfigSession: 145 passed.
• Typecheck: protocol, client, server passed.
• No daemon reload/update, live agent action, or runtime config mutation.

Source prerequisite for ORCH-202 only; live provider switching remains held behind later operational gates.

[keithpk]

ORCH-202 Paseo config-readback bounded source finding from requested exact head 71ad410c7819dce8f622a23e442e4cc24b7994c5 over fa93c4290eaa87ae58452ab6e2012f85ae6e0c6b. The PR advanced during review to 897aae697aac59b45d3e1e05c44f4b654d9a9670; this is not a current-head verdict or CI clearance. The intervening diff appears formatting/test-only for the affected projection, but needs its own exact-head review.

Capability negotiation, inbound/outbound permission mapping, exact requested-agent response checks, generic errors, and narrow wire schema look sound; I found no raw env/MCP/prompt value in the response. One material scope mismatch remains: createAgentConfigReadback(agent) hashes agent.config (the normalized stored config), whereas AgentManager.prepareSessionConfig produces a distinct launchConfig by injecting the runtime Paseo MCP server and daemonAppendSystemPrompt, passes providerLaunchConfig to create/resume, then registers storedConfig. The existing agent-manager.test.ts “createAgent injects daemon append system prompt at runtime only” explicitly proves the provider receives daemonAppendSystemPrompt while snapshot/record omit it. Thus changing daemon-appended instructions can change the provider-facing prompt without changing systemPromptSha256; runtime MCP injection likewise is not represented by mcpServersSha256. The aggregate configSha256 mixes hashes of stored config with a final launch-environment hash, rather than binding one exact launch projection. The SDK prose currently calls it the daemon's “managed/resolved launch configuration,” which is stronger than the source proves.

For ORCH-202, this readback may be useful as a stored managed-config fingerprint, but cannot independently attest exact provider launch settings or effective auto-review/MCP/prompt behavior. Either persist/hash the exact provider-launch projection at successful create/resume/reload and distinguish it from stored config (without returning secret bytes), or narrow the contract/docs and make ORCH-202 require separate exact-session launch/runtime evidence. Plant same stored config with changed daemon append prompt and runtime MCP policy: the intended launch fingerprint must change, or the response must explicitly say those dimensions are unobserved. Also retain old-daemon, wrong-ID, no-secret, and legacy env-null negatives.

No daemon/agent/live effect, merge, or release authority from this finding. Hosted PR checks were still running at the initial exact-head readback.

[keithpk]

ORCH-202 independent source review — NOT CLEAR as an exact launch-config readback prerequisite at head 897aae6 over fa93c42.

The prior bounded finding persists at this exact head. createAgentConfigReadback() hashes agent.config for systemPromptSha256, mcpServersSha256, and aggregate configSha256. But AgentManager.prepareSessionConfig() creates a distinct launchConfig with the runtime Paseo MCP server and daemon-appended system prompt, then sends the resolved provider launch config to createSession/resumeSession while registering the stored config. The existing “createAgent injects daemon append system prompt at runtime only” test proves the provider receives daemon instructions absent from the stored record. Changing the daemon append (or runtime MCP projection) can therefore change what launches without changing these readback digests. The new-head delta from 71ad410 is formatting only in these paths.

This is not a raw-secret exposure finding: capability gating and secret-free fingerprints appear scoped. A safe resolution is to fingerprint the actual resolved provider launch projection, or explicitly narrow this contract to stored managed config and require separate launch/runtime attestation for ORCH-202. Plant a same-stored-config/different-daemon-append control so the attested field changes or explicitly reports launch as unobserved.

git diff --check passes. Exact-head hosted format, lint, typecheck, SDK tests and Ubuntu server tests were green at readback; other build/Windows checks were still running. No live/merge authority is inferred.

[keithpk]

ORCH-202 Paseo dependency review — SOURCE CLEAR, hosted-gate pending, at exact draft head 9e1705c over fa93c42.

The prior stored-versus-launch finding is closed by an explicit, machine-readable projection: agent-manager-stored-config is required in the response schema and included in the identity digest. Server, client, and public SDK docs consistently say that the fingerprints describe stored ManagedAgent.config, with the recorded last-session-open environment hash as a distinct field; they explicitly exclude daemonAppendSystemPrompt, runtime-injected Paseo MCP, final providerLaunchConfig, and live provider behavior. The new server control demonstrates that those launch-only overlays do not change the labelled stored projection. The public createPaseoClient/FakeWebSocket test exercises the capability-advertised request/response and exact agent ID; existing client and protocol guards reject unsupported capability, wrong identity, and malformed digest. I found no new secret-bearing response field in the changed source. git diff --check passes.

This is a narrow source verdict, not ORCH-202 activation/readiness: consumers must not use these digests as proof of exact launch overlays, effective MCP/tool behavior, or a live provider session. Those require the separately specified runtime/launch evidence. At final readback the PR head remained unchanged and draft; hosted build, typecheck, SDK, and Linux/Windows server jobs were still in progress. No publish, merge, install, or live action authorized.