The day the canvas claim flipped: README, site, deck, DX-9/10/11

Every judge-facing surface said the workflow does not exist on the canvas.
That was true until 2026-09-11 08:06 UTC and false after. Rewritten with
the dated facts — 7 canvas runs, 2 executions, 2 refusals, 1 GS026 loss,
Marketplace listing gavel-drain at $0.05 with zero external paid calls —
and a correction row so the flip is readable without git log. The frozen
DoraHacks Q2 answer still carries the old claim and cannot be edited.

Three findings from the first canvas day, in DX-REPORT.md:
- DX-9  matchesRegex is documented, generated, and rejected by the validator
- DX-10 create stores workflowType=read regardless of nodes; PATCH derives
- DX-11 failOnError:false reports a reverted write as success: true

Author: edycutjong

DX-REPORT.md

@@ -317,3 +317,83 @@ records what executed structurally cannot record what did not.
 failed runs with enough identity to be counted even without a transaction hash. If retention is
 plan-dependent, say which plan buys what — this is the one endpoint whose whole value is that it
 remembers.
+
+## DX-9 · `matchesRegex` is documented, generated by the builder, and rejected by the validator
+
+**Severity:** medium — a documented Condition operator cannot be used at all; the error message
+points somewhere else.
+**Date:** 2026-09-11 · execution `4y5c1zst9hoegqkybyhvj`
+
+`docs/workflows/creating.md` lists `matchesRegex` among the Condition operators. Our address gate
+used it: `{{@trigger-1:Webhook.safeAddress}} matchesRegex ^0x[0-9a-fA-F]{40}$`. The first canvas
+run failed at that node with *"Cannot index "0x[...]". Reference step outputs with the
+{{@nodeId:Label.field}} template format…"* — advice about template syntax, for an expression
+whose template syntax was fine.
+
+Reading `lib/workflow/nodes/condition/validator.ts` explains why no spelling works:
+
+- `checkBracketExpressions` matches `(\w+)\s*\[` anywhere in the raw expression, **inside string
+  literals included**, so any character class preceded by a word character (`0x[`, `a-f[`) is
+  rejected as bare indexing.
+- The builder compiles the operator to `new RegExp("…").test(String(…))`
+  (`condition/expression.ts:120`), but `DANGEROUS_PATTERNS` contains `/\bnew\s+\w/` and
+  `ALLOWED_METHODS` has no `test`. The compiled form is banned twice.
+
+So the operator exists in the docs and the UI, and every expression it produces fails validation.
+The tests in `tests/unit/condition-builder-utils.test.ts` cover generation and parsing, never
+evaluation.
+
+**Workaround:** `startsWith("0x") && .length === 42`, with the strict regex in the Code node.
+**Suggested fix:** mask string literals before the bracket and dangerous-pattern checks, and either
+allowlist `new RegExp(...)`/`.test` for this operator or evaluate `matchesRegex` natively instead of
+compiling it to JS. Until then, remove it from the operator list — an operator that is documented
+and unusable costs more than one that is absent.
+
+## DX-10 · `workflows/create` stores `workflowType: read` regardless of nodes; only `PATCH` derives
+
+**Severity:** medium — combined with #2227's freeze-at-listing, it is a trap with a misleading
+warning in front of it.
+**Date:** 2026-09-11 · workflow `7v0qwhcp5gcex58gjugyg`
+
+`POST /api/workflows/create` with a graph containing a `web3/write-contract` node returned a row
+with `workflowType: "read"`. `validate_workflow` then warned `write-action-on-read-workflow` —
+"confirm this is intentional" — on a workflow nobody had classified. A no-op
+`PATCH /api/workflows/{id}` with the same nodes flipped it to `write`, because the PATCH route
+derives from node content (#2227) and the create route does not.
+
+Why it matters: #2227 freezes `workflowType` at the listing PATCH. A workflow created and listed
+without an intermediate save — the obvious agent flow, `create_workflow` → `list_workflow` — lists
+as `read`, and the Marketplace call then routes to `handleReadWorkflow`: the server executes with
+the **owner's** wallet and returns results, instead of returning calldata for the caller to sign.
+For a workflow whose whole point is that the caller executes, that is the wrong contract, frozen.
+
+**Suggested fix:** derive on create exactly as on PATCH, or have `validate_workflow` say *"stored
+type was never derived — save once"* rather than asking the author to confirm a classification
+they did not make.
+
+## DX-11 · `failOnError: false` turns a reverted write into `success: true` at every level
+
+**Severity:** high for observability — the one outcome an executor most needs to see is the one
+that reports as success.
+**Date:** 2026-09-11 · executions `819zav3gl3fkd89n7cb42` (won) and `j9g0a58oxem50jct5qpt7` (lost)
+
+Two concurrent triggers of the same workflow against the same Safe nonce. One broadcast and moved
+the money; the other's `execTransaction` reverted with `Error(GS026)`. The loser's `exec-1` node
+log reads:
+
+```
+{"error": "Contract call failed: Error(GS026)", "success": true,
+ "rejection": {"kind": "contract-custom", "name": "Error"}}
+```
+
+— `success: true` beside an `error`, node status `success`, execution status `success`,
+`transactionHashes: []`. The workflow's own reporting cannot distinguish "drained the Safe" from
+"reverted against it" without opening the node output and reading the error string. `failOnError:
+false` is the right setting here — a Safe revert is a named outcome, not a dead run — but the flag
+should suppress *abort*, not *truth*.
+
+**Suggested fix:** keep `success` meaning the call succeeded; surface the swallowed error as a
+distinct node status (`failed-continued`, or `status: success` + `error` populated at the
+execution level), and count the run in `analytics/runs` with a `revertReason` even though it has
+no hash. DX-8 already notes that a failed run leaves no row; this is the same gap from the other
+side.