LocalFlow's Workflow Validator: Cycle Detection, and a Compatibility Check That Always Says Yes

LocalFlow is a TypeScript monorepo of mine under github.com/yethikrishna with packages for core, mux, tools and ui. I read two files in packages/core: validator.ts and registry.ts.

What the validator checks

Each step has an id, a tool, params and an optional dependsOn list. A table called TOOL_SCHEMAS lists required and optional params for seven tools: ollama_chat, ollama_list_models, appflowy_read_page, appflowy_update_page, nocodb_query_data, browser_navigate and storm_research. A step with a missing required param is an error, and an unexpected param is only a warning.

For the graph it finds missing dependencies and runs a depth-first search with a recursion stack to find cycles. A cycle is reported as a path such as a to b to a. It also reports duplicate step ids. This is textbook and correct as far as I can read.

The placeholder

checkCompatibility(outputStep, inputStep) always returns compatible: true. The comment in the file says so: it is a placeholder for type checking tool outputs against parameters. So the validator proves a workflow is well formed, and does not prove one step can feed the next.

A mismatch with the registry

registry.ts defines three built-in workflows. Their step tools are web-search, ollama-summarize, appflowy-save, nocodb-query, ai-summarize, appflowy-update, browser-navigate, storm-research and file-save. The validator's table uses underscores and different names, and the registry types tool as a plain string. By my reading, the built-in workflows would fail validation with Unknown tool errors for most steps. I did not run it, so that is a reading of the code and not a test result.

What I would do

My opinion: make the registry import the same tool name type as the validator, and run validateWorkflow on every built-in in a test. Then give checkCompatibility a real answer for even two or three tool pairs. A check that always passes is worse than none, because it looks like safety.