Power view: inline technical depth for advanced users (one digest, two depths)

Context

Specs 01/08 tune the digest for the mainstream (and explicitly the non-technical)
user: clean, scannable, act-vs-aware. But the people most likely to push a digital
twin hard — developers, power users — want the opposite: provenance, confidence
scores, why-this-was-classified, the real signal IDs, and why something did NOT
auto-execute. Burying that in /settings makes it undiscoverable. This spec adds a
power view: the same digest, with technical depth one click away inline — a
per-item "Details" expander plus a persistent "Power view" toggle in the digest
header. One digest, two depths; the clean view stays default so grandma is
unaffected.

It surfaces data SkyTwin already produces (no new computation): ActionProvenance
(spec 06/11), confidence (specs 02/04/05 candidates), the deadline rawPhrase
(spec 03), the scope/tier block-reasons (spec 11 scope gate), the coverage matrix
(spec 13), and the ExplanationRecord.

Current State

Verified 2026-06-07.

• Technical depth EXISTS but is siloed on #/decisions (expandable explanations)
  and #/capabilities (audit) — a power user must leave the digest to see why.
• The digest (spec 08, twin-briefing.js) shows text + source chips + citations;
  no provenance, confidence, urgency-reason, or why-not-auto-executed.
• All the underlying data is already computed: provenance on every
  DecisionObject/candidate, confidence on commitments/clusters/entities, the
  deadline rawPhrase stamped by enrichDeadline, scope-gate block reasons
  (scope-gate.ts parameters.reason), and computeCoverage (spec 13).
• ABSENT: any inline, discoverable way to see it from the digest; any power-user
  default preference.

Proposed Change

1. Per-item "Details" expander — each digest row gets a small affordance that
   reveals an inline detail panel: provenance (human-labeled), confidence %,
   urgency reason (the deadline phrase or the per-type default), the real source
   refs, and — for to-dos — why it wasn't auto-executed (scope/tier/policy).
2. "Power view" toggle in the digest header — flips all items to expanded and
   shows the coverage panel. Persisted (localStorage v1; server pref is a
   follow-up) so a power user keeps depth on by default. Discoverable, NOT buried.
3. Coverage panel (spec 13 data) in power view — "what I can / can't see and
   why," which is power-user transparency AND doubles as cold-start guidance.
4. View-model builder buildDigestItemDetail — pure mapping from the raw
   technical fields to a human-readable detail object, so the UI stays dumb.

Implementation Details

1. packages/decision-engine/src/digest-detail.ts:

   export interface DigestItemDetailInput {
     provenance?: ActionProvenance;
     confidence?: number;          // 0..1
     deadlinePhrase?: string | null;
     domain?: string | null;
     sourceRefs: string[];
     requiresApproval?: boolean;
     blockedReasons?: string[];    // e.g. ['missing_write_scope:gmail.send','trust_tier:observer']
     explanation?: string | null;
   }
   export interface DigestItemDetail {
     provenanceLabel: string;      // "From you" | "From your twin" | "Inbound — untrusted"
     confidencePct: number | null;
     urgencyReason: string;        // 'Deadline: "in 2 days"' | "Default for email"
     sourceRefs: string[];
     whyNotAutoExecuted: string[]; // human reasons, [] when it would auto-run
     explanation: string | null;
   }
   export function buildDigestItemDetail(input: DigestItemDetailInput): DigestItemDetail;

   Provenance → label and block-reason codes → human strings live here (one place).
2. UI (twin-briefing.js): data-action="toggle-item-detail" per row;
   data-action="toggle-power-view" in the header (persists to localStorage
skytwin.digest.powerView). Power view renders all detail panels + the coverage
   panel. Follows the singleton-delegator/hash-gate/data-action conventions.
3. CSS: a compact digest-detail panel (monospace-ish refs, muted labels) so
   depth reads as "advanced," not noise.
4. Payload: the digest item payload (spec 01 structured) carries the optional
   detail fields so the UI can build the panel; absent → the expander is hidden.

Acceptance Criteria

1. buildDigestItemDetail maps each provenance to the right human label; unknown →
   "Inbound — untrusted" (fail-safe wording).
2. confidence 0..1 renders as a 0–100% integer; absent → null (no chip).
3. urgencyReason is the deadline phrase when present, else the per-type default text.
4. whyNotAutoExecuted lists human reasons for each block code; empty when the
   item would auto-run.
5. Power-view toggle persists across reloads (localStorage) and defaults OFF (clean
   view stays the default — grandma unaffected).
6. Per-item detail expands/collapses inline; no inline event handlers; delegator
   hash-gated.
7. Coverage panel renders in power view from computeCoverage output.
8. Tests for the view-model; full suite green.

Testing Plan

Rollback Plan

Additive + flag-free: power view defaults OFF, so the clean view is unchanged.
Detail fields are optional on the payload; absent → expander hidden. Remove by not
rendering the toggle. No schema change (localStorage pref).

Effort Estimate

• buildDigestItemDetail + tests: ~3h
• UI toggle + per-item expand + coverage panel + CSS: ~5h

Total: ~1 day.

Files Reference

Out of Scope

• Server-synced power-view preference (localStorage v1; cross-device is a follow-up).
• A full raw-JSON/debug inspector (decisions page + capabilities audit cover deep
  forensics).
• Mobile power view (web first).

Related

• Surfaces data from specs 03/06/11/13 + ExplanationRecord; renders in spec 08.
• The non-technical default is spec 01/08; this is the opt-in depth on top.