Pressure-testing Ota on Flowise: fixing Windows truth without weakening the contract

Flowise was a strong pressure repo because it is not just a Node app with one happy path.

It has a documented pnpm contributor workflow, a root CI verification surface, a local production path from built artifacts, and multiple Docker runtime shapes including queue mode and a standalone worker. That is exactly the kind of repo where a contract can look complete while still lying about how execution really behaves on different hosts.

Flowise turned into a useful test for a simple reason:

cross-OS repo readiness only matters if the same contract stays honest on Windows too.

Before the contract was pressure-tested, the repo had the usual setup fragmentation:

• contributor setup lived across docs, package metadata, and pnpm behavior
• the root verify path was real, but not yet encoded as one machine-checkable contract surface
• Docker runtime paths existed, but they needed to stay tied to the repo’s own documented compose story
• Windows truth depended on whether tooling could execute the repo-managed wrapper commands correctly, not just whether the commands existed in theory

That last point mattered more than it sounds. A readiness tool that can parse corepack but cannot probe it correctly on Windows does not have a Windows contract. It has a Linux contract with optimistic branding.

The final Flowise contract is explicit about the surfaces the repo actually supports:

• a native contributor workflow
• a native built-artifact startup workflow
• a CI-equivalent verify workflow
• a containerized verify workflow
• Docker self-host, queue-mode, and worker workflows that stay aligned with the repo docs

The contract also keeps the runtime surfaces separate:

• api
• app
• dev-ui
• worker

That separation matters because “the app is up” is not one thing in Flowise. Development UI, API, and worker truth are different operating surfaces.

Flowise closed three real Windows gaps in Ota.

1. Windows wrapper tools were not probed correctly in doctor

On GitHub Windows runners, Corepack resolves through wrapper scripts like:

corepack.CMD

Older Ota probing tried to treat that too much like a Unix command path. The result was false failure in doctor even when the repo and runner were otherwise valid.

2. Resolved wrapper paths were still not being used consistently

Fixing wrapper execution alone was not enough. Ota also had to choose the resolved wrapper path instead of falling back to the bare command name during Windows version probing.

Without that, the contract looked fine and the probe still lied.

3. The run/backend-fulfillment path still disagreed with doctor

After doctor was fixed, Flowise still surfaced a second-order trust problem:

• pre-run gates could pass
• actual execution could still fail later when backend fulfillment tried to probe Corepack differently

That is exactly the kind of mismatch pressure testing should catch. If doctor and run do not agree on what a valid tool path is, the contract is not trustworthy.

Flowise drove platform fixes, not repo-local glue.

Ota now:

• probes Windows .cmd and .bat tools correctly in doctor
• uses the resolved wrapper path instead of the unresolved command name when probing those tools
• applies the same Windows wrapper truth on the run/backend-fulfillment path, not just in diagnosis

That is the right fix shape. The answer was not “teach Flowise a Windows workaround.” The answer was “make Ota tell the truth on Windows.”

The Flowise contract is useful because it stays operationally specific without pretending every path is the same.

• verify is the CI-equivalent validation surface
• app is the contributor development path
• app:prod is the built-artifact local production path
• app:docker, app:docker:queue, and worker:docker stay tied to the documented compose/runtime shapes

That produces a contract a contributor, CI job, and agent can all use without guessing which runtime they actually mean.

It also preserves a clean boundary:

• the core contributor and verification slice is straightforward
• the packaged-runtime Docker lanes are broader claims and should only be upstreamed if the repo wants to claim them explicitly

That boundary is not bureaucracy. It is how you keep a repo readiness contract from turning into vague command inventory.

The final matrix does concrete, contract-shaped work:

• Ubuntu, macOS, and Windows all run the same pre-run contract gates:

ota validate, ota tasks, ota execution topology, ota run verify:ci:full --dry-run, and ota up --dry-run

• Ubuntu executes the verify workflow in both native and container modes
• macOS and Windows execute a representative native smoke lane instead of pretending they prove the heavier Docker-backed runtime path
• Ubuntu dry-runs every non-internal native and container-capable task to widen coverage beyond the single headline workflow
• Ubuntu runs ota proof runtime --workflow app:docker for the real Docker-backed runtime proof lane

Most importantly, it now proves that the Windows lane is not decorative. It exercises the same Corepack-backed contract truth that previously failed.

Flowise was a useful reminder that Windows support is not just “the command exists on PATH.”

For a repo-readiness system, Windows support means:

• wrapper tools are resolved correctly
• version probes are truthful
• diagnosis and execution agree
• the matrix proves the same path the contract claims

That is execution governance, not command listing.

After this pressure pass, Flowise is not just a repo with an ota.yaml that parses. It is a repo whose native, container, and Docker runtime claims are backed by a contract and matrix that stay honest across operating systems.

Links:

• Contract: Flowise ota.yaml
• Matrix workflow: test-ota-contract-matrix.yml
• Green matrix run: #26985182156