majiayu000 Context
Use this when host, services, and web UI are being built in parallel and the team wants an honest readiness verdict instead of placeholder optimism.
Pattern
- Verify the toolchain first: if the solution does not build or tests cannot run, the batch is not review-complete.
- Compare the host and Web UI message vocabulary directly: request names, response names, capability labels, and seeded constants must agree exactly.
- Separate placeholder seams from integrated seams. A scaffold page or stub handler is useful, but it does not satisfy a vertical-slice success criterion.
- Check the first failure contract, not just the happy path. Empty input, unsupported messages, and unplaced-reason codes should already be stable enough to assert against.
- Trace each claimed success criterion to one real code path, not just prose or helper tests.
Good signs
- One real request can leave the UI, cross the bridge, hit application logic, and return shaped data without a placeholder response.
- Seeded material/settings values match across host, services, and web contracts.
- Review evidence includes at least one runnable verification command, not just static inspection.
Anti-patterns
- Declaring a vertical slice complete while file-open/import/nesting still return
not-ready - Letting host and UI invent different bridge names during parallel work
- Treating spec-helper tests as proof that the implemented seam already works