The wiki is the knowledge base that sits alongside the workflow catalog. The catalog answers "what workflows do we have?"; the wiki answers "what do we know about workflows?" — patterns, integration quirks, common failure modes, repair rules, and framework-specific guidance.
It is meant to be consumed both by humans and by LLMs (during retrieval for prompt-to-workflow generation, repair, and validation).
This pass establishes the structure and seeds each section with a small number of realistic, hand-written entries. The wiki is not comprehensive yet. It will grow as workflows are audited, validated, and (eventually) generated against it.
| Folder | Purpose |
|---|---|
patterns/ |
Reusable workflow patterns — retry, fan-out/fan-in, chunked LLM calls, idempotent webhook handlers, etc. |
integrations/ |
Per-service playbooks — auth model, rate limits, gotchas, recommended node settings. |
repair-rules/ |
Rules used (or proposed) by the repair engine — "if the workflow has X but not Y, propose Z". |
failure-cases/ |
Documented failure modes with root cause and the fix that worked. Feeds repair-rules over time. |
framework-guides/ |
Framework differences — n8n vs Dify vs LangGraph vs Make, IR mapping notes, exporter quirks. |
Each entry is a Markdown file with a short YAML-ish header followed by prose:
---
title: Short title
applies_to: [n8n] # or planned, or multiple
tags: [http, retry, idempotency]
last_reviewed: 2026-05-23
---
## When this applies
...
## What to do
...
## Why
...
## References
...last_reviewed is meaningful: if it is more than ~12 months old and the entry references concrete versions or APIs, treat the content as stale until re-reviewed.
- The wiki is in its first pass. Most patterns and integrations are not documented yet.
- Repair rules listed here are candidates. They are not automatically applied. The repair engine that consumes them is on the roadmap (see ../docs/self-improvement.md).
- Framework guides are partial. Only n8n has practical content. Other frameworks are described at the design level.
- Prompt-to-workflow: the generator retrieves relevant patterns + integration playbooks before assembling a Universal Workflow IR.
- Repair engine: candidate repair rules are matched against detected failures; proposals are written to
reports/for human review. - Learning loop: validated failure-and-fix pairs become
learning-eventrecords, which can be promoted into new repair rules — only after human review.