response_type: consultant_plan_review_response
response_version: 1
responding_to_packet_type: consultant_plan_review
responding_to_packet_version: 1
mode: plan_review
transport: manual_copy_paste

consultant_decision:
  verdict: revise
  confidence: 0.91
  implementation_may_start_after_revision: true
  requires_plan_revision: true
  requires_human_review_before_implementation: false

summary:
  assessment: >
    The Admin Runtime Health Dashboard plan is coherent and well aligned with
    Blueprint Runtime authority boundaries. The proposed five-chunk sequence is
    mostly correct: Runtime snapshot first, backend proxy second, frontend route
    and data access third, dashboard UI fourth, validation/docs fifth. The plan
    should be revised before implementation to make the Runtime health snapshot
    contract explicit, define degraded/unavailable Runtime behavior, enforce
    redaction rules, and prevent the backend from copying the existing shell
    scorecard pattern.
  recommended_strategy: >
    Confirm the five-chunk work package with revisions. Start with a Runtime-owned
    read-only healthSnapshot contract. Then expose it through an admin-guarded
    backend proxy that uses Runtime API/daemon-backed state, not shell wrappers.
    Build the frontend as a render-only dashboard. Keep MVP refresh page-load or
    manual refresh only. Defer polling, live streaming, mutation controls, and
    historical analytics.

major_findings:
  - id: finding-001
    severity: medium
    topic: runtime_health_snapshot_contract
    finding: >
      The plan correctly identifies runtime.healthSnapshot as the required
      canonical surface, but the data contract needs to be made explicit before
      frontend/backend work starts.
    recommendation: >
      Chunk 1 should define a stable versioned schema for runtime.healthSnapshot,
      including summary, gates, operations, leases, validations, human actions,
      consultant checkpoints, daemon freshness, dispatcher state, timeline, and
      optional redacted raw details. The frontend and backend should consume this
      contract rather than reconstruct workflow truth.
  - id: finding-002
    severity: medium
    topic: backend_shell_precedent
    finding: >
      The existing RemoteDevConsoleService.runtimeStatus shelling out to
      ai/tools/runtime-scorecard/scorecard.sh is a real architectural trap.
    recommendation: >
      Chunk 2 must explicitly avoid extending this pattern. The backend Health
      query should call Runtime daemon/API/client-backed state or a narrowly
      reviewed canonical Runtime CLI/API surface. Shell scorecard wrappers may
      remain compatibility-only, but must not become the Health dashboard proof
      surface.
  - id: finding-003
    severity: medium
    topic: deployment_and_daemon_absence
    finding: >
      The plan leaves open whether the admin Health query is local/dev only or
      generally available. This affects UX and backend error handling.
    recommendation: >
      Implement the backend query as generally admin-available, but make Runtime
      daemon absence a first-class degraded/unavailable state. Do not fail the
      whole page when Runtime is absent. Return a safe health snapshot with
      runtime_available: false, status: degraded or unavailable, and a clear
      operator-facing explanation.
  - id: finding-004
    severity: medium
    topic: redaction_and_raw_details
    finding: >
      Raw Runtime details can include local paths, operational internals, or
      sensitive debugging context.
    recommendation: >
      The default Health snapshot should redact or summarize raw local paths and
      unsafe internals. Drill-down raw JSON can exist, but should be explicitly
      marked as admin/debug detail and should use a redacted payload by default.
      If unredacted local-dev detail is needed later, make it a separate explicit
      development-mode behavior.
  - id: finding-005
    severity: low
    topic: refresh_policy
    finding: >
      Polling/live status can easily increase complexity and create accidental
      runtime load.
    recommendation: >
      MVP should use initial page load plus manual refresh. Defer polling,
      streaming, subscriptions, alerting, and live history.
  - id: finding-006
    severity: low
    topic: ui_scope
    finding: >
      The dashboard sections are comprehensive and useful, but the first UI chunk
      could become large.
    recommendation: >
      Keep Chunk 4 as a single UI chunk only if it remains a read-only dashboard
      composed of simple cards/tables/timeline sections. If it grows, split UI
      into summary/gates first and detail panels second.

final_recommendation:
  next_action: revise_plan
  implementation_start_chunk: Runtime Health Snapshot Contract
  notes_for_orchestrator:
    - Keep the five-chunk plan.
    - Revise Chunk 1 to make runtime.healthSnapshot explicit, versioned,
      read-only, bounded, and degraded-state aware.
    - Revise Chunk 2 to avoid shell scorecard canonical access and enforce
      admin guard/redaction/degraded behavior.
    - Keep frontend MVP render-only with page-load/manual refresh.
    - Treat Health as an observability/dashboard surface, not a workflow control
      surface.
    - After plan revision, implementation may begin with the Runtime Health
      Snapshot Contract chunk.
