feat(dsh): expose bounded recall and capture status through /pc #1597

Feature description

Implement work package F of #1450: expose bounded, session-local observations of automatic context preparation, Source capture, and host injection through DSH /pc.

The status should answer what actually happened in the current conversation, when it happened, and which stage needs attention. It must distinguish an empty retrieval from a failure and Source acceptance from produced Memory.

Problem and proposed solution

Verified baseline

Inspected master 545b1609ee55a58348e734d2c27919c43b0a5051 on 2026-09-14. A, B, and C are merged. D (#1520 / #1522) is independent and is not an implementation prerequisite.

• The registered /pc command currently shows only the resolved Scope, redacted Server origin, and a Doctor hint (integrations/dsh/plugins/powercontext/src/commands.ts). It does not retain automatic-path results or observation times.
• Context preparation already distinguishes ready and empty, and capture reports some successful/skipped/failed outcomes through logging. Those events are not a queryable per-session status; success logging can be hidden and failures can be rate-limited.
• /pc doctor already checks configuration, service readiness, compatibility, and Scope. Its read-only probe explicitly does not verify actual capture, processing, or injection. Scope failures already have a status fallback and must remain supported.

User-visible scenario and impact

After a normal prompt, /pc cannot tell whether no memory matched, automatic capture was disabled or skipped, a request failed, or no automatic attempt was observed. A healthy Doctor result cannot establish that the previous prompt was captured or recalled. A stale success from another turn or project would also be misleading.

Proposed behavior

• Extend /pc with independent preparation, capture, flush (when attempted), and injection observations. Include the owning attempt/turn, observation age, freshness, and precise safe reason. Start with not_yet_observed; distinguish normal empty/skipped outcomes from unavailable or unconfirmed operations.
• Record outcomes directly at the execution boundaries, independently of logging. A ready PreparedContext is not proof of injection; an appended pre-step message is not proof the model consumed it. Accepted Source evidence is not proof of Memory production. A timed-out write may have an unknown outcome.
• Keep only a bounded in-memory set of recent observations, isolated by session/workspace and the observed Scope. Prevent older asynchronous attempts from replacing newer status. Mark historical or stale results explicitly; restart/eviction restores unobserved status.
• Keep status readable during Scope failure. Reading status must not trigger prepare/capture/flush, change Scope bindings, or overwrite actual observations with Doctor probes.
• Report the failing stage/operation, safe typed classification and HTTP status when known, precise skip reasons, and actionable recovery. Never echo raw exceptions, prompts, recalled content, credentials, or unreviewed response bodies.
• Reuse A–C and the existing diagnostic contract. This does not change tool routing, Skill naming, Server persistence, HTTP contracts, or host approval behavior.

Acceptance and validation

• Fresh sessions report unobserved status; ready, empty, skipped, unavailable, and stale observations are distinguishable.
• Preparation and capture failures remain independent; Source acceptance, flush progress, and actual pre-step insertion are reported without false persistence/injection claims.
• Disabled capture, excluded input, unresolved Scope, cancellation, transport errors, and protocol failures identify the relevant stage and safe reason.
• Concurrent sessions/Scopes and out-of-order attempts do not share or overwrite status; storage is bounded and no content is retained.
• Status remains available during failure and does not execute automatic work; Doctor does not overwrite automatic history.
• Focused registered-plugin tests and real DSH runtime tests verify the displayed observations, redaction, recovery, and existing fail-open behavior.
• English/Chinese documentation describes state meanings, freshness, and limits; relevant quality, package, contract, and CI checks pass.

Implementation and validation: #1600 (head 1620793873ba3d13b6b07d1aaed0096a4f1e9397), with 255 DSH package tests (including 17 real HTTP response-failure regressions), 9 HTTP integration tests, 5 real DSH runtime tests, 38 related Python tests and all 18 CI checks passing. Observed authentication/authorization rejection is distinct from an uncertain write, and response-body failures preserve received HTTP status and validated request ID. These checked items record implementation validation; the child remains open until the PR is merged.

Alternatives considered

• Use Doctor alone: it observes current service health, not the previous automatic attempt.
• Reconstruct status from logs: success visibility and failure throttling lose observations, and logs do not reliably isolate active sessions.
• Persist full history on the Server: unnecessary for this bounded plugin status and risks retaining user content.
• Inject failures into model context: conflicts with the existing diagnostic contract and can disrupt normal Agent work.

Additional context

Parent: #1450, work package F. Reuses A (#1451 / #1452), B (#1457 / #1459), and C (#1493 / #1494). E and D remain separately owned. The implementation PR should close this child issue and reference, not close, #1450.

AI assistance: OpenAI Codex assisted with source inspection, issue preparation, implementation, and validation.

Are you willing to contribute to this feature?

• Yes, I am willing to contribute code, docs, or design feedback.