[zengchuang-hw]

Governing issue and delivery slice

Refs #371, step 6. Uses the fixed attempt reader from #449 for status, HTML report, offline and loopback dashboard, and JSON trace. Each command accepts the same --record-ref and --storage-config files, with optional --assessment-ref tied to that exact revision. The live Dashboard page and its state endpoint serve the snapshot pinned at startup.

trace projects recorded steps, checks and error codes without synthesizing timestamps. Report and Dashboard present the same execution facts and archived claim outcomes. Their HTML output uses the existing atomic writer and overwrite checks. Legacy paths are covered by the existing CLI and Dashboard regressions.

Verification

• Exercised all fixed surfaces against the same record and assessment, then compared the offline Dashboard with the live HTML and state response.
• On the submitted head, 134 Windows tests and 2 subtests passed across Apps, CLI, Dashboard, campaign records and module boundaries, including a fresh-process SQLite read of the older pinned revision.
• 21 Codex/WorkSwarm/DSH plugin and bundle checks passed. DSH exercised the local standalone bundle; Python reported one tarfile deprecation warning.
• The PR merges cleanly on main after Adapt Knowledge context to a Harness delivery draft #446 and Expose explicit Apps access to candidate stores #448. The exact integrated tree 86306cfd passed 75 tests and 2 subtests across Apps assessment, context, Knowledge, the live Dashboard and CLI.
• Local Ruff and staged diff checks passed.

Production CPU integration still tracks Harness #429/#447 and Benchmark #430/#434.

[amy-why-3459]

LGTM

PR review verdict — PASS
Reviewed base 1373ef8 and head d4c2936 (full review, new PR).

Verified:

• Scope matches #371 step 6: status / trace / report / offline and --live dashboard all go through the single read_attempt_view from #449; include_trace only adds the trace projection, status output is unchanged.
• trace projects steps / checks / errors field-by-field inside the existing integrity try, so missing fields surface as ArtifactIntegrityError; unknown step times stay null.
• attempt_html.render_attempt escapes every value and the title, ships a default-src 'none' CSP and exposes no log or artifact paths.
• _write_view_document reuses the atomic writer and symlink / overwrite checks, with the generator marker scoped per document kind.
• DashboardServer requires exactly one of source / fixed attempt, deep-copies the pinned view, and the profile-events route is disabled without a source.
• CLI argument guards: I checked locally that trace requires --record-ref, report --run-id ... --output, missing --storage-config, fixed report without --output and dashboard --input plus --storage-config all fail with clear errors.
• I ran tests/test_apps_*, test_cli_catalog, test_dashboard_* and test_module_boundaries locally on this head (Linux, Python venv with [skills] deps) and all passed. All CI checks on the head are green, including full-check 3.10/3.11, installed-package and dashboard-browser.

Accuracy/performance comparison: not applicable (read-only presentation/CLI wiring, no numeric or runtime-path change).

[cursor]

LGTM

PR review verdict — PASS
Reviewed base 1373ef8ee2a67947cd2503ab527a3b252728611c and head d4c2936584e84498bc9220b4bb338f5c93234237.

Verified:

• Scope matches #371 step 6 surfaces: status / trace / report / offline and --live dashboard share read_attempt_view; include_trace only adds the projection; status output remains without trace.
• Trace projection field-selects steps / checks / errors inside the integrity try; missing keys raise ArtifactIntegrityError; null step times preserved.
• attempt_html.render_attempt escapes values/title, uses restrictive CSP, and does not expose log/artifact paths.
• Atomic HTML writer retains symlink/overwrite guards with per-kind generator markers.
• Live DashboardServer requires exactly one of directory source or fixed attempt; deep-copies the pinned view; profile-events route gated on source.
• CLI mutual-exclusion and guards for fixed vs legacy paths are coherent; docs/operations notes the shared refs.
• Local pytest on this head: test_apps_assess, test_cli_catalog, test_module_boundaries, test_dashboard_live, test_dashboard_data, test_dashboard_external all passed; ruff clean on touched paths. Ready CI on the head is all success.

Accuracy/performance comparison: not applicable (read-only presentation/CLI wiring).