What Is WorkCanvas Studio?

WorkCanvas Studio is a TypeScript project created on 2026-08-13 and last updated 2026-09-02, hosted on GitHub under the devlesss organization. It is a deliberately small, inspectable collection of realistic business-interface samples built as regression fixtures for browser workflow automation. The public edition ships two applications: a Standard HTML inventory inquiry screen and a React purchase-order screen. Around those two screens sit four public workflow plans (each in English and Korean), a Playwright regression suite, and a design philosophy that prioritizes reliability over convenience.

The project requires Node.js 22 or later. There are no external services, no authentication, and no live backend dependencies — everything runs locally, so a workflow either reproduces cleanly or fails deterministically. Its status as a young (roughly three-week-old) repository means its value is methodological rather than historical: it is a template for how to build agent-evaluable interfaces, not a large existing corpus.

Why Framework-Neutral Browser Automation Matters for AI Agents

The core insight of WorkCanvas Studio is that automation should be expressed in framework-neutral semantics: prefer labels, roles, and observable state changes over generated DOM paths or coordinate-based selectors. A locator like #app > div:nth-child(3) > form > input[type="text"] is brittle — it breaks the moment any developer reorders a div. A semantic reference like input[aria-label="Item code"] or “the field labeled Item code” survives across framework migrations.

This matters because a serious AI automation agent will eventually be pointed at both a React SPA and a plain HTML screen in the same week. If the agent’s approach hard-codes framework assumptions, it will succeed on one and fail on the other. Framework-neutral semantics give the agent a single strategy that works everywhere: resolve a control by its label, role, stable ID, or test ID; act on the visible dialog scope; then verify the observable postcondition.

WorkCanvas Studio demonstrates this by making “equivalent actions testable across frameworks.” The inventory lookup on the Standard HTML screen and the vendor search on the React screen exercise the same underlying interaction pattern — open dialog, type a query, select a result, confirm the dialog closes — using the same semantic approach in two technologies.

The Controls That Break Workflow Agents

WorkCanvas Studio was built specifically to expose the interaction patterns that reliably derail automation agents. Understanding them is the first step to designing interfaces — or agent instructions — that survive them.

• Controlled inputs. In React, an input’s displayed value is governed by component state. If an agent sets a value in a way that bypasses the normal input/change event pipeline, React’s state never updates and the value silently reverts. The purchase-order sample verifies that entered text actually persists after a state update.
• Search dialogs. A modal lookup introduces a second “Query” button that competes with the main form’s “Query” button. Agents must scope their targeting to the visible role=dialog surface, or they will click the wrong control.
• Result selection. After a search returns matches, selecting the exact row is an action with a postcondition — the dialog should close and the selection should be reflected back in the originating form.
• Date fields. Date inputs are format-sensitive and frequently rendered as composite controls. They need normalization and a visible confirmation that the value was accepted.
• Query result tables. Verifying the returned rows requires reading grid state, not just confirming a network call ran.
• Dynamic grid rows. Adding a row must change the table by exactly one row — and detail inputs must be bound to the row the Add action just created, not an earlier one.

These are the exact friction points that turn a “successful click” into a silent failure.

The Two Sample Workflows: Standard HTML Inventory and React Purchase Order

The Standard HTML inventory plan walks an agent through a full workflow: select warehouse Seoul Warehouse, open the item search dialog, query ITEM-001, select the exact result, confirm the dialog closes, verify the selection is reflected in the main form, set item type Raw material, base date 2026-08-04, stock status Available, zero-stock false, run the query, verify the result table, then add one row and confirm the row count increased by exactly one.

The React purchase-order plan mirrors that structure on a modern stack: enter order date 2026-08-04, select account type Raw material, open the vendor search modal, query Wonjin, select the exact V001 · Wonjin result, confirm the modal closes, verify reflection in the read-only vendor field, set procurement type Domestic purchase, enter item/notes and verify React state retains the value, add one detail row, confirm row count +1, then bind PART-001, quantity 10, and urgent false to the new row.

Both plans define judgment rules and stop/report conditions, so an agent knows exactly when to stop and why: a control it cannot identify, a dialog that never appears, an item not reflected, a row count that does not increase by exactly one, or a destructive/external submission requirement.

Evidence Before Completion: Verifying Postconditions

The single most important design principle in WorkCanvas Studio is evidence before completion: never treat a successful click as completion. Each workflow step ends with an observable postcondition that must be verified before the agent reports the step done.

• Opening a lookup must produce a visible dialog.
• Selecting a result must be reflected in the originating form.
• Adding a row must increase the table by exactly one.
• A controlled input must retain its value after a state update.

This converts “the agent clicked the button” — which proves nothing about outcome — into “the agent clicked and the UI state changed as the user intended.” On the query side, the plans make one explicitly valid outcome clear: an empty settled query result is a legitimate zero-result outcome, not a failure. Evidence is about confirming the postcondition that the workflow contract demands, whatever that postcondition happens to be.

How to Run WorkCanvas Studio Locally

Running the project requires Node.js 22 or later and takes a few minutes:

git clone https://github.com/devlesss/WorkCanvas_Studio.git
cd WorkCanvas_Studio
npm install
npx playwright install chromium
npm run dev

Then open http://127.0.0.1:5173/ to reach both sample screens. Both samples include an English/Korean language selector, while the automation-facing IDs, test hooks, and control values remain stable across languages — which makes the project useful for localization testing of agents.

For verification, npm test builds the React sample and runs browser tests against both frameworks, and npm run capture:demos regenerates the public screenshots and source recordings.

Using the Public Workflow Plans (English and Korean)

The repo ships four public workflow plans under plans/: standard-html-inventory and react-purchase-order, each in English and Korean. Because the sample URLs open directly on the target screen, the plans include no login or screen-navigation section — they are pure workflow descriptions.

Each plan separates the same five concerns: inputs, workflow steps, judgment rules, completion evidence, and stop/report conditions. That structure means a plan doubles as both an AI agent prompt and a human QA checklist. The bilingual editions let you compare how the same workflow is expressed in English and Korean for localization testing of agent instruction-following.

All values are synthetic and safe for public testing — warehouse “Seoul Warehouse,” item “ITEM-001,” vendor “Wonjin,” part “PART-001.” Nothing in the repo references real credentials, private URLs, or production memory.

WorkCanvas Studio as a Playwright Regression Fixture Library

Because framework-neutral semantics map cleanly onto Playwright’s selector model (role-based and label-based locators), the two sample apps work as a fixture library even without an AI planner. The design makes them useful for:

• Playwright regression fixtures — the existing suite verifies popup visibility, form state, and exact row-count changes.
• Locator research — testing which selectors survive React state updates and dialog scope changes.
• QA training — teaching testers how to reason about evidence rather than clicks.
• Automation regression testing — a stable, reproducible target to run your agent against after every change.

The judgment rules codified in the plans — resolve controls by label/role/stable ID/test ID before coordinates, scope dialog controls to the visible role=dialog, bind detail inputs to the row created by the current Add action, check postconditions — are exactly the engineering decisions you want your test suite to enforce.

Roadmap and What Comes Next

The WorkCanvas Studio roadmap signals where the project is heading, and each item is a useful hook for future automation planning:

• Vue and Web Components samples — broadening framework coverage beyond Standard HTML and React.
• Popup patterns — handling the window-popup interactions many business apps still rely on.
• Empty query results — formalizing the zero-result outcome as a first-class testable case.
• Nested grids — more complex row/column relationships within dynamic tables.
• Framework-neutral action/evidence schemas — standardizing how actions and their postconditions are described across frameworks.
• Benchmark plans — using the fixtures as a scored evaluation baseline for browser automation agents.

Who Should Use WorkCanvas Studio

WorkCanvas Studio is most valuable for three groups. AI agent developers get a clean, reproducible target to evaluate whether their browser agent truly verifies outcomes rather than just clicking through. QA and automation engineers get a fixture library for locator research and regression testing that covers the exact controls that fail in production. Platform and product teams designing business interfaces get a template for what “agent-friendly” means — stable IDs, semantic labels, clearly scoped dialogs, and observable state changes.

If you are evaluating a browser automation agent, building an evaluation benchmark, or teaching reliable UI automation, WorkCanvas Studio gives you a small, synthetic, framework-neutral playground where a workflow either succeeds with verified evidence or fails for a reason you can actually see.

FAQ

What is WorkCanvas Studio used for?

It is an open-source collection of synthetic business-interface samples — a Standard HTML inventory inquiry and a React purchase-order screen — plus workflow plans and a Playwright regression suite, used to evaluate, test, and regression-check browser automation agents.

Why are the samples framework-neutral?

Because a reliable agent must work across Standard HTML and React (and, eventually, Vue and Web Components). Framework-neutral semantics — labels, roles, and state changes instead of generated DOM paths — give one strategy that works across technologies.

What does “evidence before completion” mean in browser automation?

It means never treating a successful click as success. Every step must verify an observable postcondition — the dialog is visible, the selection is reflected in the form, the row count increased by exactly one — before the step is marked complete.

What are the controls that break workflow agents?

Controlled inputs (React state not receiving updates), search dialogs (competing Query buttons and scope ambiguity), result selection, date fields, query result tables, and dynamic grid rows are the most common failure points covered by the samples.

Do I need an AI planner or credentials to use WorkCanvas Studio?

No. All values are synthetic and public, there is no login, and the apps double as Playwright fixtures even without an AI planner. You only need Node.js 22 or later and a local clone.