Build, Then Verify

How the Canvas Artifact Viewer earned trust

Users kept leaving Canvas to open VS Code just to read their files

Epic 16, the Artifact Viewer, brings a VS-Code-style tabbed file browser directly into the Canvas workspace — a unified viewer that "lives on the Canvas workspace... like having VS Code's tab system directly in Canvas."

The question isn't whether it can be built. It's whether the build can be trusted.

Epic 16
Artifact Viewer, in microsoft/workspaces2
444
Lines in the epic spec (16-artifact-viewer.md)

It shipped: Epic 16 in microsoft/workspaces2, owned by Chris Park

The Canvas Artifact Viewer was built from a written spec via Amplifier's autonomous workflow. The repo — "Workspaces x Canvas" — is real, the epic is real, the owner is named.

A working feature exists. Now: how big is what the workflow generated?

Chris Park
Epic 16 owner (gh handle cpark4x)
2025-11-14
Repo "Workspaces x Canvas" created

The build is substantial — the V3 component set sums to ~1,513 lines

The V3 handoff review lists four core files: TabsPane, ProjectPicker, WorkspaceFileBrowser, and the project MCP server. That's real generated code at real scale.

But scale is not the same as correctness. Volume alone earns no trust.

775
TabsPane.tsx
312
WorkspaceFileBrowser.tsx
238
ProjectPicker.tsx
188
projectMcpServer.ts
The Complication

Generated code that nobody has checked is code nobody can trust

Volume is not the same as correctness. A feature that looks finished — that compiles and renders — is only half done. The other half is proving it actually works.

So the workflow needs an answer: how does the build carry proof forward?

The workflow's answer is the handoff

A written HANDOFF.md records exactly what was checked and whether it passed. It's the artifact that carries verification forward instead of leaving "does it work?" as an open question.

And for V3, that handoff had something to report.

# docs/ai_working/artifact_viewer/HANDOFF.md Status: VERIFIED All 4 bug fixes confirmed working # the handoff records what was # checked, and whether it passed

V3 didn't just build — it ran the checks

Smoke tests, end-to-end tests, and an API-level security check all passed, and four bug fixes were confirmed. This is the build passing through the verification loop instead of stopping at "it compiles."

That passing loop is what turns a diff into something shippable.

10/10
Smoke tests pass
5/5
E2E artifact viewer tests pass
403
API-level security test
4
Bug fixes confirmed working

PR #297 lands stamped VERIFIED — and merges to main

"Epic 16 Artifact Viewer V3 with verified bug fixes" merged on 2026-01-31. Epic 16 went into main via PR #329 (2026-02-03) and was later refactored into a plugin. The verified half is what made it shippable.

So what's the lesson to carry out of the room?

#297
"V3 with verified bug fixes" — merged 2026-01-31
#329
Epic 13 + Epic 16 merged to main, 2026-02-03
#338
Refactored into a plugin, 2026-02-06
The Takeaway

Build and verify are two halves of one job

Ship the handoff, not just the diff. An autonomous workflow can generate a working feature — but the verification loop is what converts generated code into trusted, merged code. The missing half is non-optional.

Feature status: Shipped & iterated
Sources

Research Methodology

Data as of: February 13, 2026 (independently re-checked in a fresh session via live gh/git/grep against microsoft/workspaces2).

Feature status: Shipped and iterated — V3 merged (PR #297), merged to main (PR #329), refactored into a plugin (PR #338).

Research performed:

Gaps: The "built blind at 1,538 lines," a 1,021-line CANVAS-ARTIFACT-VIEWER-SPEC.md, a 528-line prompt with 19 features, a 35-deep recursion loop, and a forgotten SESSION-HANDOFF.md could NOT be traced to any surviving file or commit and are treated as unverified. The nearest verifiable analogue is the V3 component set summing to 1,513 lines, which was VERIFIED rather than unverified. The named repo bkrabach/claude-trace-viewer is an unrelated claude-trace log viewer and contains no Artifact Viewer.

Primary contributor: Chris Park (cpark4x) — Epic 16 owner; authored/merged PR #297 and PR #329.

More Amplifier Stories