유대선
프로젝트로
·기술 회고·2

The test was not the product: Work Desk needed a native delivery gate

A green component suite could not prove that an employee assignment reached a real PTY, that a configured provider consumed the task exactly once, or that every protocol adapter failed closed. We added those gates without pretending the final click-through was complete.

We spent too long treating model tests as product proof. They could tell us that a button derived the right state, but not that an employee assignment crossed the native boundary, reached a configured agent process, and was delivered once. They also could not tell us whether adding another protocol adapter quietly changed the lifecycle contract.

The correction was deliberately small.

First, a native delivery test now walks the real employee path: assignment, persona preparation, PTY/ConPTY spawn, start signal, stub consumption, and duplicate-delivery rejection. The stub executable is injected as profile data; the harness does not branch on a vendor name.

Second, one data-driven conformance matrix resolves every registered Managed protocol adapter and asks the same questions: Is the exact profile selected? Is the prompt bound to stdin? Does valid machine output produce a typed task result and terminal lifecycle? Does malformed output fail closed?

Third, both tests run through the existing ops verifier. We did not invent another receipt. The packet requires exact 1 passed; 0 failed output so Cargo's zero-test success cannot masquerade as coverage, and the receipt keeps the existing PASS / FAIL / AMBIGUOUS vocabulary.

We also started the requested task eval with five fixtures, not an eval platform. They attack four workflow boundaries: execution authority, zero changed files, independent verification, and exact employee-run identity.

Rebasing exposed one more test-vs-product trap. The release packet called Cargo directly, but the current Tauri config bundles ui-lab/dist; a clean worktree had no ignored build output and failed with resource path ../../ui-lab/dist doesn't exist before either native test ran. The packet now builds the UI Lab prerequisite itself. A release gate must construct its own declared prerequisites instead of passing only because a developer happened to build them earlier.

The honest result is a candidate, not a product victory. The Rust library and desktop suites passed, the production frontend built, and the native dev app launched. But desktop automation could not attach to the macOS UI in this run, so no robot clicked prepare, start, diff, verify, and restart recovery. Windows is wired into the release workflow but has not run yet. And employee-bound Code Workbench on macOS still cannot borrow Trusted Local evidence and call it Managed authority.

That distinction is the lesson: a harness can prove a boundary. Only a real user flow proves the product.