bug: DSH integration cannot diagnose missing MCP tools and runs automatic hook side effects before step admission #1785

Describe the bug

Related to #1450.

The DSH integration has three related reliability and observability gaps:

1. /pc doctor checks HTTP health and API routes, but does not verify whether the native DSH MCP client connected or registered the expected mcp__powercontext__* catalog. HTTP health can therefore appear healthy while the model has no PowerContext MCP tools.

2. The runtime acceptance tests do not yet form a complete dsh-context observation loop. They inspect proxy traffic, model requests, and persisted snapshot messages separately, but do not correlate MCP calls/results with PowerContext injection through DSH session events.

3. The agent/pre-step hook performs Scope resolution, context preparation, and prompt capture before calling downstream next(). If a later hook rejects or rewrites the step, PowerContext requests may already have been performed using the original message batch.

Steps to reproduce

Hook ordering

1. Start the DSH automatic-path test fixture with successful Scope, prepare, and capture responses.

2. Invoke runRecallPreStep with a downstream handler returning:

   { kind: 'reject' }

3. Inspect the PowerContext requests made during the invocation.

The current implementation enters recallThenCapture() before calling next(), so Scope resolution, prepare_context, and possibly Source capture happen before the step is known to be accepted.

MCP catalog diagnosis

1. Start a PowerContext Server where the HTTP API and health endpoints are available.
2. Make the /mcp endpoint unavailable or cause MCP discovery to fail.
3. Start DSH with the PowerContext plugin.
4. Run /pc doctor.

The current doctor output does not report MCP connection or catalog state, so it cannot distinguish a healthy HTTP Server from a usable MCP integration.

Runtime observation

1. Enable the dsh-context observer.
2. Run a prompt that triggers automatic PowerContext recall and a native MCP operation.
3. Inspect the resulting trace.

The current acceptance suite does not produce one correlated record containing the tool/call, tool/result, snapshot injection, session, turn, step, and call identifiers.

Expected behavior

• /pc doctor reports MCP connection and catalog status separately from HTTP health.
• Missing or incomplete MCP discovery is reported explicitly.
• Runtime observation correlates:
  • native mcp__powercontext__* tool calls;
  • corresponding tool results;
  • PowerContext snapshot injection;
  • session, turn, step, and call identifiers.
• The pre-step hook calls downstream next() before performing PowerContext side effects.
• Rejected or failed downstream steps do not trigger prepare or capture.
• Accepted steps use the final downstream message batch and append at most one snapshot.
• Existing cancellation, fail-open behavior, Scope isolation, and diagnostic redaction remain unchanged.

Actual behavior

• /pc doctor can report healthy HTTP/API state without confirming that MCP tools are available.
• The existing tests do not provide a complete dsh-context acceptance trace.
• PowerContext lifecycle requests happen before downstream step admission.
• A downstream rejection skips injection, but earlier PowerContext requests may already have completed.

Environment

• OS: Windows
• PowerContext commit: be27ce0c
• DSH plugin version: 0.0.2
• DSH SDK: @deepseek-ai/dsh-sdk-client@0.1.2-rc.1
• Python: 3.14.0
• Node.js: v26.1.0
• Shell: PowerShell

Relevant validation commands:

pnpm --dir integrations/dsh/plugins/powercontext test:all
pnpm --dir integrations/dsh/plugins/powercontext/tests/runtime test

Are you willing to submit a PR to fix this bug?

• Yes, I would like to submit a PR.