Date: 2026-10-04 (Europe/Kiev). Bounded UI integration pass. No new weights, training or promotion.

Change and purpose

V28 qualified a persistent staged executable API, but it remained difficult to inspect without writing API requests. V29 adds /workflow-demo, linked from the laboratory navigation, so a person can demonstrate the same supported workflow from the application.

The workbench starts a bounded generated project, advances one stage at a time, changes its environment, runs remaining steps and displays the verified conclusion. It shows acquired source hashes, inspected receipts, execution packets, member/subprocess/comparison counts and the chronological event journal. Unknown evidence is visibly absent before acquisition. The page clearly labels the deterministic workflow policy and the absence of model training or candidate promotion.

The task ID is saved in the page URL. Reloading that URL fetches persisted backend state rather than starting another project. Manual task-ID restoration is also supported. Busy controls are disabled; errors are shown; completed tasks cannot be changed. Source/receipt invalidation remains the V28 backend's responsibility.

Browser evidence

Three Playwright tests passed against the actual isolated create_app FastAPI backend and Next development server using the installed Edge browser. Browser responses were not mocked.

1. Start fresh, acquire sources, reload while paused, inspect the receipt, change input before comparison, continue, observe INVALIDATE, refresh once and conclude VALID. Task subprocess count equals1.
2. Change irrelevant notes and retain VALID with zero task subprocess calls. Then run separate disagreement, worker-failure and missing-input scenarios and display INVALID, EXECUTION_FAILED and UNRESOLVED respectively.
3. Restore a nonexistent task and display the actual API error while allowing a new task to start.

These tests exercise five bounded scenario types and explicit causal changes. They do not constitute an independently authored agent-task benchmark or new learned-policy evaluation.

Initial test setup could not find Playwright's bundled Chromium; installed Edge was used without changing dependencies. Browser testing led to explicit select labels and a test assertion scoped to the workbench alert rather than Next's separate route announcer. Visual inspection found low-contrast labels, which were corrected to use the existing theme palette. No weight fitting was repeated.

Checks

• TypeScript type checking: PASS.
• Targeted browser checks: 3/3 PASS, final run6.3 seconds.
• Next production build: PASS; /workflow-demo is included in generated routes.
• Desktop1365px and mobile390px screenshots inspected; no mobile horizontal overflow.
• All 178 previous research weight artifacts unchanged; zero new weight binaries.
• No active registry change or V27 candidate promotion.

The browser tests used development serving; the production bundle was built but not separately browser-qualified. Temporary test servers were stopped after verification. Test task IDs live in an isolated test runtime directory and are not silently admitted to the normal project's task state, G or Memory.

Scope and remaining gaps

This makes the bounded V28 workflow demonstrable in the app. It does not improve its neural capability or qualify learned orchestration, open-ended planning, Foundation reasoning, full parallel Context integration or autonomous learning. V27's failed learned-advantage gate remains unchanged. The underlying executor still accepts only bounded generated workers; no arbitrary external program is executed.

The next research work should use independently authored executable tasks with meaningful staged acquisition and verify available policy headroom before fitting. Avoid another unchanged inspection-flag classifier or an extended series of UI-only milestones. Connecting verified runtime outcomes to controlled Memory/experience admission remains a distinct integration task.