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

[Alanxtl]

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.

[DongYao0]

Hi maintainers, I'd like to work on the hook-ordering part of this issue.

I verified against the current master (673d44d6) that runRecallPreStep() still calls recallThenCapture() before the downstream next() decision. As a result, Scope resolution, context preparation, and prompt capture can occur even when the downstream hook later rejects or fails the step.

I plan to first add a regression test proving that rejected and failed downstream steps perform no PowerContext requests, then move the PowerContext side effects after admission while preserving the final downstream message batch, cancellation behavior, fail-open behavior, and single-snapshot injection.

Would a focused PR for this part be acceptable? If so, please assign the issue to me. Thanks!

[DongYao0]

I'll continue with the MCP catalog diagnosis part of this issue in a separate focused PR.

The hook-ordering fix has been merged in #1856. For this next part, I'll add regression coverage showing that /pc doctor can currently report healthy HTTP/API status without confirming the native mcp__powercontext__* tool catalog, then update the diagnostic output to report MCP catalog availability separately from HTTP health.