diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index c66ef7dd3b4f27e574b66778d1ed98cd735c0265..aba977368eb4b55fd250701ef59d2e64a47bde5d 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,133 +1,17 @@ -# Contributing to flowzap-workflows +# Contributing -Thank you for your interest in contributing to the FlowZap workflows corpus! This document provides guidelines for adding new workflows or improving existing ones. +This repository is synchronized from the FlowZap application template library. -## Workflow Structure +## Structure -Each workflow must include three files in its own directory: +- `primary-use-case/source-domain/template-slug/` +- `workflow.fz` contains the FlowZap Code source +- `metadata.json` stores machine-readable metadata including primary and secondary Use Cases +- `templates.index.json`, `use-cases.index.json`, and `metadata.csv` are generated artifacts -``` -domain/workflow-name/ -├── workflow.fz # FlowZap Code file -├── README.md # Human-readable documentation -└── metadata.json # Structured metadata -``` +## Sync Expectations -## FlowZap Code Syntax Rules - -### Lane Definition -``` -LaneName { # Display Name - // nodes and edges -} -``` - -### Node Types -- `circle` - Start/End nodes -- `rectangle` - Process/Action nodes -- `diamond` - Decision nodes (must have 2-3 outcomes) - -### Node Syntax -``` -nodeId: nodeType label:"Node Label" -``` - -### Edge Syntax -``` -n1.handle(right) -> n2.handle(left) -n1.handle(bottom) -> OtherLane.n3.handle(top) [label="Edge Label"] -``` - -### Handle Positions -- `top`, `bottom`, `left`, `right` - -## Quality Guidelines - -### Do's -- ✅ Use realistic, domain-specific terminology -- ✅ Include 2-3 outcomes for diamond (decision) nodes -- ✅ Use unique node IDs within the workflow -- ✅ Include cross-lane edges for multi-lane workflows -- ✅ Add meaningful edge labels for decision branches -- ✅ Keep workflows between 7-25 nodes - -### Don'ts -- ❌ Reuse node IDs across lanes -- ❌ Create diamond nodes with only 1 outcome -- ❌ Use generic labels like "Step 1", "Process" -- ❌ Omit lane prefixes on cross-lane edges -- ❌ Create overly complex workflows (>30 nodes) - -## Metadata Schema - -```json -{ - "workflow_id": "kebab-case-id", - "domain": "domain-name", - "complexity": 3, - "num_nodes": 15, - "num_lanes": 3, - "tags": ["tag1", "tag2", "tag3", "tag4", "tag5", "tag6"], - "description": "One-sentence description of the workflow." -} -``` - -### Complexity Scale -- **1** - Simple (5-7 nodes, 1 lane, no decisions) -- **2** - Basic (7-10 nodes, 1-2 lanes, 1 decision) -- **3** - Moderate (10-15 nodes, 2-3 lanes, 2-3 decisions) -- **4** - Complex (15-20 nodes, 3-4 lanes, multiple decisions) -- **5** - Advanced (20+ nodes, 4+ lanes, complex branching) - -## README Template - -```markdown -# Workflow Title - -One-sentence description matching metadata. - -**Domain:** domain-name -**Complexity:** X/5 -**Tags:** [tag1, tag2, tag3, tag4, tag5, tag6] - -## Lanes -- **Lane Name** - Role description -- **Lane Name** - Role description - -## Process Flow -1. First step -2. Second step -... -9. Final step -``` - -## Submitting Contributions - -1. Fork the repository -2. Create a new branch for your workflow -3. Add your workflow files following the structure above -4. Ensure all three files are present and valid -5. Submit a pull request with a clear description - -## Validation Checklist - -Before submitting, verify: - -- [ ] `workflow.fz` parses without errors -- [ ] All node IDs are unique -- [ ] Diamond nodes have 2-3 labeled outcomes -- [ ] Cross-lane edges use `Lane.nodeId` syntax -- [ ] `metadata.json` is valid JSON -- [ ] `num_nodes` and `num_lanes` match the `.fz` file -- [ ] `README.md` follows the template -- [ ] Tags are relevant and kebab-case - -## Questions? - -- Visit [flowzap.xyz](https://flowzap.xyz) for syntax documentation -- Check [examples](https://flowzap.xyz/examples) for reference workflows -- Open an issue for questions or suggestions - ---- - -Thank you for helping grow the FlowZap ecosystem! +- Keep the sitemap-driven template set aligned with `https://flowzap.xyz/sitemap-templates.xml`. +- Preserve one canonical template copy per slug. +- Use `primary_use_case` for folder placement and `use_cases` for the full taxonomy membership. +- Preserve `source_domain` from the app index for traceability. diff --git a/README.md b/README.md index a2a836a8281e025a02ccd793e1594e0dc5f29fab..8a076ba6b69be18fed6d99c6a63f06cf44e75813 100644 --- a/README.md +++ b/README.md @@ -1,188 +1,40 @@ -# flowzap-workflow-sequence-architecture-diagrams - -A production-grade corpus of **200+ expert-crafted FlowZap workflow, sequence and architecture files** designed for LLM training, workflow automation learning, and diagrams-as-code reference. - -[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT) -[![FlowZap](https://img.shields.io/badge/FlowZap-Code-blue)](https://flowzap.xyz) - -## Overview -This repository contains **600 files** organized as a structured training corpus: - -- **200 `.fz` workflow files** - FlowZap Code syntax (diagrams-as-code) -- **200 `README.md` files** - Human-readable workflow documentation -- **200 `metadata.json` files** - Structured metadata for programmatic access - -> **Looking for ready-to-use templates?** Visit the [FlowZap Templates Library](https://flowzap.xyz/templates) — 250+ templates including workflows, sequence diagrams, and architecture diagrams, with downloadable `.fz` files, n8n JSON exports, and Make.com blueprints. - -## What is FlowZap Code? -FlowZap Code is a diagrams-as-code DSL for creating workflow diagrams, sequence diagrams, and architecture diagrams — all from the same code. Learn more: -- [FlowZap Website](https://flowzap.xyz) -- [FlowZap Code Syntax Guide](https://flowzap.xyz/flowzap-code) -- [AI Coding Guidelines](https://flowzap.xyz/flowzap-code-guidelines.md) — instructions for AI assistants generating FlowZap Code -- [Templates Library](https://flowzap.xyz/templates) — 250+ ready-to-use templates -- [Architecture Diagram Templates](https://flowzap.xyz/templates/architecture-diagram-templates) — 50 architecture diagram templates - -### Syntax Example -``` -Warehouse { # Warehouse Team - n1: circle label:"Start" - n2: rectangle label:"Receive shipment" - n3: diamond label:"Inspection passed?" - n4: rectangle label:"Stock inventory" - n5: rectangle label:"Return to vendor" - n6: circle label:"End" - - n1.handle(right) -> n2.handle(left) - n2.handle(right) -> n3.handle(left) - n3.handle(right) -> n4.handle(left) [label="Yes"] - n3.handle(bottom) -> n5.handle(top) [label="No"] - n4.handle(right) -> n6.handle(left) - n5.handle(right) -> n6.handle(left) -} -``` - ---- - -## Repository Structure -``` -flowzap-workflows/ -├── README.md -├── LICENSE -├── CONTRIBUTING.md -├── finance/ # 21 workflows -│ ├── monthly-close/ -│ │ ├── workflow.fz -│ │ ├── README.md -│ │ └── metadata.json -│ ├── invoice-processing/ -│ └── ... -├── hr/ # 20 workflows -│ ├── onboarding/ -│ ├── performance-review/ -│ └── ... -├── logistics/ # 23 workflows -│ ├── shipping-process/ -│ ├── inventory-receipt/ -│ └── ... -├── devops/ # 15 workflows -│ ├── ci-cd-pipeline/ -│ ├── incident-response/ -│ └── ... -├── business-operations/ # 26 workflows -│ ├── subscription-lifecycle/ -│ ├── support-ticket/ -│ └── ... -├── patterns/ # 28 workflows -│ ├── circuit-breaker/ -│ ├── saga-pattern/ -│ └── ... -├── edge-cases/ # Edge case examples -└── syntax-primitives/ # Basic syntax examples -``` - -## Domains Covered -| Domain | Workflows | Description | -|--------|-----------|-------------| -| **Finance** | 21 | Month-end close, AP/AR, treasury, audit, tax | -| **HR** | 20 | Hiring, onboarding, performance, offboarding | -| **Logistics** | 23 | WMS, TMS, shipping, inventory, cold chain | -| **DevOps** | 15 | CI/CD, monitoring, incident response, IaC | -| **Business Operations** | 26 | SaaS lifecycle, billing, GDPR, OAuth | -| **Patterns** | 28 | Microservices, event-driven, resilience | - -## Metadata Schema -Each `metadata.json` follows this structure: - -```json -{ - "workflow_id": "monthly-close", - "domain": "finance", - "complexity": 4, - "num_nodes": 22, - "num_lanes": 4, - "tags": ["month-end-close", "gaap", "reconciliation", "financial-statements", "accruals", "period-close"], - "description": "Month-end financial close workflow with sub-ledger reconciliation, accrual posting, trial balance validation, and financial statement generation." -} -``` - ---- - -## Use Cases - -### LLM Training -This corpus is explicitly designed for training Large Language Models to: -- Generate FlowZap Code from natural language descriptions -- Understand workflow patterns across business domains -- Learn diagrams-as-code syntax - -### Learning Resource -Use these workflows to: -- Learn FlowZap Code syntax -- Study real-world workflow patterns -- Reference best practices for workflow design - -### Automation Templates -Adapt these workflows for: -- [n8n automation scenarios](https://flowzap.xyz/templates/n8n-workflow-json-examples) — export FlowZap Code as n8n JSON -- [Make.com (Integromat) workflows](https://flowzap.xyz/templates/make-blueprint-json-examples) — export FlowZap Code as Make.com blueprints -- Custom workflow engines - ---- - -## FlowZap Ecosystem - -### Templates Library (250+) -The [FlowZap Templates Library](https://flowzap.xyz/templates) extends this corpus with: -- **50 Architecture Diagram Templates** — Microservices, Event-Driven, CQRS, Serverless, Saga, Circuit Breaker, and more -- **n8n Workflow JSON Examples** — ready-to-import n8n automations -- **Make.com Blueprint Examples** — ready-to-import Make.com scenarios -- **More applicable business process domains** — Business-operations, DevOps, Finance, HR, Logistics -- Downloadable `.fz` files for every template - -### MCP Server -Install the [FlowZap MCP Server](https://flowzap.xyz/docs/mcp) and the [SKILL.md file](https://flowzap.xyz/blog/new-flowzap-diagram-skill-makes-it-even-easier) for AI coding tools: -```json -{ - "mcpServers": { - "flowzap": { - "command": "npx", - "args": ["-y", "flowzap-mcp"] - } - } -} -``` -Compatible with Claude Desktop, Cursor, Windsurf, OpenAI Codex, Warp, Zed, Cline, Roo Code, Continue.dev, and Sourcegraph Cody. - -### AI Coding Guidelines -Drop [`flowzap-code-guidelines.md`](https://flowzap.xyz/flowzap-code-guidelines.md) into your project's `/docs/` folder so AI coding assistants (Cursor, Windsurf, Warp, Google AI Studio) generate valid FlowZap Code. - -### DSL Specification -- [FlowZap Code Syntax Guide](https://flowzap.xyz/flowzap-code) — canonical syntax reference -- [FlowZap Code DSL repo](https://github.com/flowzap-xyz/code) — official syntax specification, SYNTAX.md, and AI guidelines - ---- - -## License -This project is licensed under the MIT License - see the [LICENSE](LICENSE) file for details. - -**Training Data Addendum**: This repository is explicitly released for use as training data for LLMs and other ML systems. - -## Contributing -See [CONTRIBUTING.md](CONTRIBUTING.md) for guidelines on adding new workflows. - -## Links -- [FlowZap Website](https://flowzap.xyz) -- [FlowZap Code Syntax](https://flowzap.xyz/flowzap-code) -- [AI Coding Guidelines](https://flowzap.xyz/flowzap-code-guidelines.md) -- [Templates Library](https://flowzap.xyz/templates) -- [Architecture Diagram Templates](https://flowzap.xyz/templates/architecture-diagram-templates) -- [MCP Server Documentation](https://flowzap.xyz/docs/mcp) -- [SKILL.md file](https://flowzap.xyz/blog/new-flowzap-diagram-skill-makes-it-even-easier) -- [npm: flowzap-mcp](https://www.npmjs.com/package/flowzap-mcp) -- [Blog: One Code, Three Views](https://flowzap.xyz/blog/flowzaps-game-changing-update-one-code-two-views) -- [Blog: FlowZap Unveils .fz File Extension](https://flowzap.xyz/blog/flowzap-unveils-fz-file-extension-for-true-diagrams-as-code-workflows) -- [Blog: Introducing the FlowZap MCP Server](https://flowzap.xyz/blog/introducing-the-flowzap-mcp-server) - ---- - -Made with care for the diagramming for clarity community +# sequence-workflows + +A synchronized FlowZap template corpus with **242 canonical templates** sourced from `https://flowzap.xyz/sitemap-templates.xml` and organized by **primary Use Case**. + +## Organization Model + +- Top-level folders are primary Use Cases from the FlowZap Templates dropdown. +- Second-level folders preserve the original source domain from the FlowZap app index. +- Each template keeps all matched Use Cases in `metadata.json` and the generated JSON/CSV indexes. +- Templates that do not match any current dropdown Use Case are placed under `uncategorized/`. + +## Top-Level Folders + +- `handoff/` — Handoff (15) +- `approval/` — Approval (17) +- `incident/` — Incident (10) +- `onboarding/` — Onboarding (6) +- `offboarding/` — Offboarding (1) +- `billing/` — Billing & Payments (8) +- `security/` — Security & Access (13) +- `compliance/` — Compliance (13) +- `delivery/` — Delivery & DevOps (15) +- `support/` — Support (1) +- `agentic/` — Agentic Teams (15) +- `ai-orchestration/` — AI Orchestration (6) +- `mcp/` — MCP Architecture (10) +- `context-management/` — Context Management (6) +- `uncategorized/` — Unmatched canonical templates (106) + +## Generated Indexes + +- `templates.index.json` — Full machine-readable template index +- `use-cases.index.json` — Use Case summary with counts and template paths +- `metadata.csv` — Flat CSV export of core template metadata + +## Sync Source + +- Canonical URL source: `https://flowzap.xyz/sitemap-templates.xml` +- Template metadata source: `FlowZap-App-v5/src/templateLibrary/templatesIndex.json` +- Template file source: `FlowZap-App-v5/public/template-files/*.fz` diff --git a/agentic/architecture/agentic-hierarchical/README.md b/agentic/architecture/agentic-hierarchical/README.md new file mode 100644 index 0000000000000000000000000000000000000000..ad6260b11962db200ccd24af59dc6bf2d323d8ba --- /dev/null +++ b/agentic/architecture/agentic-hierarchical/README.md @@ -0,0 +1,19 @@ +# Agentic Hierarchical Architecture + +A hierarchical multi-agent architecture with multi-level organizational structure. A top-level executive agent manages mid-level team lead agents, who each manage their own pool of specialist workers. Teams within teams — the hierarchy maps to domain separation. + +**Template ID:** `agentic-hierarchical` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** agentic +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 8 +**Lanes:** 7 +**Tags:** [agentic, hierarchical, multi-agent, enterprise, architecture-diagram, ai-team] +**Source path:** `` +**Repo path:** `agentic/architecture/agentic-hierarchical` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/agentic/architecture/agentic-hierarchical/metadata.json b/agentic/architecture/agentic-hierarchical/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..294b6bf9602b6d4568064f9c5f7ac242a3ed2aad --- /dev/null +++ b/agentic/architecture/agentic-hierarchical/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "agentic-hierarchical", + "workflow_id": "agentic-hierarchical", + "title": "Agentic Hierarchical Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "agentic", + "secondary_use_cases": [], + "use_cases": [ + "agentic" + ], + "complexity": 4, + "num_nodes": 8, + "num_lanes": 7, + "tags": [ + "agentic", + "hierarchical", + "multi-agent", + "enterprise", + "architecture-diagram", + "ai-team" + ], + "description": "A hierarchical multi-agent architecture with multi-level organizational structure. A top-level executive agent manages mid-level team lead agents, who each manage their own pool of specialist workers. Teams within teams — the hierarchy maps to domain separation.", + "source_path": "", + "repo_path": "agentic/architecture/agentic-hierarchical" +} diff --git a/agentic/architecture/agentic-hierarchical/workflow.fz b/agentic/architecture/agentic-hierarchical/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..a3634d1c98ccd52f0dab5ff7678ef066270b1818 --- /dev/null +++ b/agentic/architecture/agentic-hierarchical/workflow.fz @@ -0,0 +1,36 @@ +executive_agent {# Executive Agent + n1: rectangle label="Route Master Goal" + n1.handle(bottom) -> research_lead_agent.n2.handle(top) [label="Assign Research"] + n1.handle(bottom) -> content_lead_agent.n5.handle(top) [label="Assign Content"] +} + +research_lead_agent {# Research Lead Agent + n2: rectangle label="Manage Retrieval Team" + n2.handle(bottom) -> web_search_agent.n3.handle(top) [label="Web Task"] + n2.handle(bottom) -> db_retrieval_agent.n4.handle(top) [label="DB Task"] +} + +web_search_agent {# Web Search Agent + n3: rectangle label="Live Web Search" + n3.handle(right) -> research_lead_agent.n2.handle(right) [label="Web Data"] +} + +db_retrieval_agent {# DB Retrieval Agent + n4: rectangle label="Internal Knowledge RAG" + n4.handle(right) -> research_lead_agent.n2.handle(right) [label="Internal Data"] +} + +content_lead_agent {# Content Lead Agent + n5: rectangle label="Manage Production Team" + n5.handle(bottom) -> writer_agent.n6.handle(top) [label="Draft Topic"] +} + +writer_agent {# Writer Agent + n6: rectangle label="Draft Document" + n6.handle(bottom) -> qa_agent.n7.handle(top) [label="Draft Text"] +} + +qa_agent {# QA Agent + n7: rectangle label="Fact Check" + n7.handle(right) -> content_lead_agent.n5.handle(right) [label="Final Content"] +} diff --git a/agentic/architecture/agentic-supervisor-worker/README.md b/agentic/architecture/agentic-supervisor-worker/README.md new file mode 100644 index 0000000000000000000000000000000000000000..90ff88ec0acb84ef4c8452fba329ab714c43ea3a --- /dev/null +++ b/agentic/architecture/agentic-supervisor-worker/README.md @@ -0,0 +1,19 @@ +# Agentic Supervisor-Worker Architecture + +A supervisor-worker multi-agent architecture where an orchestrator agent receives a high-level goal, breaks it into subtasks, delegates each to specialist worker agents (researcher, writer, QA), monitors execution, handles failures, and synthesizes results. The orchestrator manages but does not execute tasks itself. + +**Template ID:** `agentic-supervisor-worker` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** agentic +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 4 +**Tags:** [agentic, supervisor-worker, multi-agent, orchestrator, architecture-diagram, ai-team] +**Source path:** `` +**Repo path:** `agentic/architecture/agentic-supervisor-worker` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/agentic/architecture/agentic-supervisor-worker/metadata.json b/agentic/architecture/agentic-supervisor-worker/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..d4953ed86ebb27883551bde7d13b52c7c74847f2 --- /dev/null +++ b/agentic/architecture/agentic-supervisor-worker/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "agentic-supervisor-worker", + "workflow_id": "agentic-supervisor-worker", + "title": "Agentic Supervisor-Worker Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "agentic", + "secondary_use_cases": [], + "use_cases": [ + "agentic" + ], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 4, + "tags": [ + "agentic", + "supervisor-worker", + "multi-agent", + "orchestrator", + "architecture-diagram", + "ai-team" + ], + "description": "A supervisor-worker multi-agent architecture where an orchestrator agent receives a high-level goal, breaks it into subtasks, delegates each to specialist worker agents (researcher, writer, QA), monitors execution, handles failures, and synthesizes results. The orchestrator manages but does not execute tasks itself.", + "source_path": "", + "repo_path": "agentic/architecture/agentic-supervisor-worker" +} diff --git a/agentic/architecture/agentic-supervisor-worker/workflow.fz b/agentic/architecture/agentic-supervisor-worker/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..115bdc8051c1134ac9f47be61cc7b2cd179f0e37 --- /dev/null +++ b/agentic/architecture/agentic-supervisor-worker/workflow.fz @@ -0,0 +1,29 @@ +orchestrator_agent {# Orchestrator Agent + n1: rectangle label="Decompose & Manage Subtasks" + n5: diamond label="All Passed QA?" + n6: rectangle label="Synthesize Final Result" + + n1.handle(bottom) -> researcher_agent.n2.handle(top) [label="Task: Gather Sources"] + n1.handle(bottom) -> writer_agent.n3.handle(top) [label="Task: Draft"] + n1.handle(bottom) -> qa_agent.n4.handle(top) [label="Task: Review"] + + n5.handle(right) -> n6.handle(left) [label="Yes"] + n5.handle(top) -> writer_agent.n3.handle(top) [label="No (Fix Draft)"] +} + +researcher_agent {# Research Agent + n2: rectangle label="Retrieve Information (Web/RAG)" + n2.handle(right) -> orchestrator_agent.n1.handle(right) [label="Summary"] +} + +writer_agent {# Writer Agent + n3: rectangle label="Generate Text" + n3.handle(right) -> orchestrator_agent.n1.handle(right) [label="Draft"] +} + +qa_agent {# QA Agent + n4: rectangle label="Review Output" + n4.handle(right) -> orchestrator_agent.n5.handle(left) [label="Flags"] +} + +loop [retry loop] writer_agent.n3 qa_agent.n4 orchestrator_agent.n5 diff --git a/agentic/architecture/agentic-swarm/README.md b/agentic/architecture/agentic-swarm/README.md new file mode 100644 index 0000000000000000000000000000000000000000..0d2a88cf13b8fb9c7b794ff8dd3d20c356cbdb7c --- /dev/null +++ b/agentic/architecture/agentic-swarm/README.md @@ -0,0 +1,19 @@ +# Agentic Swarm Architecture + +A swarm multi-agent architecture where multiple agents work on the same or related tasks simultaneously, with no central coordinator. Their outputs are then aggregated, voted on, or merged by a dedicated aggregator node. Agents may compete — the best output wins. + +**Template ID:** `agentic-swarm` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** agentic +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 6 +**Lanes:** 5 +**Tags:** [agentic, swarm, multi-agent, parallel, aggregator, architecture-diagram, ai-team] +**Source path:** `` +**Repo path:** `agentic/architecture/agentic-swarm` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/agentic/architecture/agentic-swarm/metadata.json b/agentic/architecture/agentic-swarm/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..0fd18cd5180a2d217fc722632fd79a24e9a52722 --- /dev/null +++ b/agentic/architecture/agentic-swarm/metadata.json @@ -0,0 +1,27 @@ +{ + "template_id": "agentic-swarm", + "workflow_id": "agentic-swarm", + "title": "Agentic Swarm Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "agentic", + "secondary_use_cases": [], + "use_cases": [ + "agentic" + ], + "complexity": 3, + "num_nodes": 6, + "num_lanes": 5, + "tags": [ + "agentic", + "swarm", + "multi-agent", + "parallel", + "aggregator", + "architecture-diagram", + "ai-team" + ], + "description": "A swarm multi-agent architecture where multiple agents work on the same or related tasks simultaneously, with no central coordinator. Their outputs are then aggregated, voted on, or merged by a dedicated aggregator node. Agents may compete — the best output wins.", + "source_path": "", + "repo_path": "agentic/architecture/agentic-swarm" +} diff --git a/agentic/architecture/agentic-swarm/workflow.fz b/agentic/architecture/agentic-swarm/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..358b119d67c43852aee28ad5bf7842c0e5fd5047 --- /dev/null +++ b/agentic/architecture/agentic-swarm/workflow.fz @@ -0,0 +1,25 @@ +dispatcher_agent {# Dispatcher Agent + n1: rectangle label="Split Goals & Dispatch" + n1.handle(bottom) -> research_agent_a.n2.handle(top) [label="Explore Angle 1"] + n1.handle(bottom) -> research_agent_b.n3.handle(top) [label="Explore Angle 2"] + n1.handle(bottom) -> research_agent_c.n4.handle(top) [label="Explore Angle 3"] +} + +research_agent_a {# Research Agent A + n2: rectangle label="Parallel Search A" + n2.handle(bottom) -> aggregator_agent.n5.handle(top) [label="Findings A"] +} + +research_agent_b {# Research Agent B + n3: rectangle label="Parallel Search B" + n3.handle(bottom) -> aggregator_agent.n5.handle(top) [label="Findings B"] +} + +research_agent_c {# Research Agent C + n4: rectangle label="Parallel Search C" + n4.handle(bottom) -> aggregator_agent.n5.handle(top) [label="Findings C"] +} + +aggregator_agent {# Aggregator Agent + n5: rectangle label="Merge & Deduplicate" +} diff --git a/agentic/architecture/agentic-team-of-rivals/README.md b/agentic/architecture/agentic-team-of-rivals/README.md new file mode 100644 index 0000000000000000000000000000000000000000..0eb0be29faee58a914a80593d7cfd817f287aa57 --- /dev/null +++ b/agentic/architecture/agentic-team-of-rivals/README.md @@ -0,0 +1,19 @@ +# Agentic Team of Rivals Architecture + +The most architecturally sophisticated multi-agent pattern. Agents are assigned not just roles but opposing incentives. A Planner is optimistic about goal completion. A Critic is constitutionally skeptical and holds veto authority. Errors get caught through adversarial pressure rather than trusting a single model's self-assessment. + +**Template ID:** `agentic-team-of-rivals` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** agentic +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 5 +**Lanes:** 3 +**Tags:** [agentic, team-of-rivals, multi-agent, critic, veto, architecture-diagram, ai-team] +**Source path:** `` +**Repo path:** `agentic/architecture/agentic-team-of-rivals` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/agentic/architecture/agentic-team-of-rivals/metadata.json b/agentic/architecture/agentic-team-of-rivals/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..da23475ed3db3ed3fb7ffdadbe8aea120b2fc776 --- /dev/null +++ b/agentic/architecture/agentic-team-of-rivals/metadata.json @@ -0,0 +1,27 @@ +{ + "template_id": "agentic-team-of-rivals", + "workflow_id": "agentic-team-of-rivals", + "title": "Agentic Team of Rivals Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "agentic", + "secondary_use_cases": [], + "use_cases": [ + "agentic" + ], + "complexity": 3, + "num_nodes": 5, + "num_lanes": 3, + "tags": [ + "agentic", + "team-of-rivals", + "multi-agent", + "critic", + "veto", + "architecture-diagram", + "ai-team" + ], + "description": "The most architecturally sophisticated multi-agent pattern. Agents are assigned not just roles but opposing incentives. A Planner is optimistic about goal completion. A Critic is constitutionally skeptical and holds veto authority. Errors get caught through adversarial pressure rather than trusting a single model's self-assessment.", + "source_path": "", + "repo_path": "agentic/architecture/agentic-team-of-rivals" +} diff --git a/agentic/architecture/agentic-team-of-rivals/workflow.fz b/agentic/architecture/agentic-team-of-rivals/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..81dd5f046c90af8f6f0e7beb62cec7c580a7915d --- /dev/null +++ b/agentic/architecture/agentic-team-of-rivals/workflow.fz @@ -0,0 +1,19 @@ +planner_agent {# Planner Agent + n1: rectangle label="Declare Step-by-Step Plan & Acceptance Criteria" + n1.handle(right) -> executor_agent.n2.handle(left) [label="Task Plan + Criteria"] +} + +executor_agent {# Executor Agent + n2: rectangle label="Execute Remote Code & Tools" + n2.handle(right) -> critic_agent.n3.handle(left) [label="Execution Summary"] +} + +critic_agent {# Critic Agent + n3: rectangle label="Validate vs Acceptance Criteria" + n4: diamond label="Passed Gate?" + + n3.handle(bottom) -> n4.handle(top) + n4.handle(top) -> planner_agent.n1.handle(bottom) [label="Veto (Reject & Explain)"] +} + +loop [Rejection Iteration] planner_agent.n1 executor_agent.n2 critic_agent.n3 critic_agent.n4 diff --git a/agentic/architecture/ai-native-event-driven-kafka-architecture/README.md b/agentic/architecture/ai-native-event-driven-kafka-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..326401c250160ab0b4afffe4f658d846a81188ce --- /dev/null +++ b/agentic/architecture/ai-native-event-driven-kafka-architecture/README.md @@ -0,0 +1,19 @@ +# AI-Native Event-Driven Kafka Architecture + +An event-driven agentic AI architecture that replaces the central orchestrator with Kafka/PubSub topics: agents subscribe, react, and publish new events. This aligns multi-agent systems with proven microservices choreography and is ideal for real-time, high-throughput systems and 'agent mesh' setups. + +**Template ID:** `ai-native-event-driven-kafka-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** agentic +**Secondary use cases:** ai-orchestration, mcp +**Complexity:** 3/5 +**Nodes:** 12 +**Lanes:** 5 +**Tags:** [ai-native, event-driven, agentic-ai, kafka, pub-sub, agent-mesh, architecture-diagram] +**Source path:** `` +**Repo path:** `agentic/architecture/ai-native-event-driven-kafka-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/agentic/architecture/ai-native-event-driven-kafka-architecture/metadata.json b/agentic/architecture/ai-native-event-driven-kafka-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..02cb44730d69722b3847c89c52f64818b7ede71b --- /dev/null +++ b/agentic/architecture/ai-native-event-driven-kafka-architecture/metadata.json @@ -0,0 +1,32 @@ +{ + "template_id": "ai-native-event-driven-kafka-architecture", + "workflow_id": "ai-native-event-driven-kafka-architecture", + "title": "AI-Native Event-Driven Kafka Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "agentic", + "secondary_use_cases": [ + "ai-orchestration", + "mcp" + ], + "use_cases": [ + "agentic", + "ai-orchestration", + "mcp" + ], + "complexity": 3, + "num_nodes": 12, + "num_lanes": 5, + "tags": [ + "ai-native", + "event-driven", + "agentic-ai", + "kafka", + "pub-sub", + "agent-mesh", + "architecture-diagram" + ], + "description": "An event-driven agentic AI architecture that replaces the central orchestrator with Kafka/PubSub topics: agents subscribe, react, and publish new events. This aligns multi-agent systems with proven microservices choreography and is ideal for real-time, high-throughput systems and 'agent mesh' setups.", + "source_path": "", + "repo_path": "agentic/architecture/ai-native-event-driven-kafka-architecture" +} diff --git a/agentic/architecture/ai-native-event-driven-kafka-architecture/workflow.fz b/agentic/architecture/ai-native-event-driven-kafka-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..dbebae33a02fa8db27ab1f177daa7728f1a7b195 --- /dev/null +++ b/agentic/architecture/ai-native-event-driven-kafka-architecture/workflow.fz @@ -0,0 +1,35 @@ +Source { # Event Sources +n1: circle label:"Start" +n2: rectangle label:"User action event" +n3: rectangle label:"System alert event" +n1.handle(right) -> n2.handle(left) +n2.handle(bottom) -> Broker.n4.handle(top) [label="Publish event"] +n3.handle(bottom) -> Broker.n4.handle(top) [label="Publish event"] +} +Broker { # Event Broker (Kafka / Pub-Sub) +n4: rectangle label:"Event bus receives event" +n5: rectangle label:"Route to subscribers" +n4.handle(right) -> n5.handle(left) +n5.handle(bottom) -> Orders.n6.handle(top) [label="topic: orders"] +n5.handle(bottom) -> Alerts.n8.handle(top) [label="topic: alerts"] +n5.handle(bottom) -> Analytics.n10.handle(top) [label="topic: analytics"] +} +Orders { # Order Processing Agent +n6: rectangle label:"Parse order event" +n7: rectangle label:"Execute fulfillment" +n6.handle(right) -> n7.handle(left) +n7.handle(bottom) -> Broker.n4.handle(top) [label="Publish: order.completed"] +} +Alerts { # Alert Triage Agent +n8: rectangle label:"Classify severity" +n9: rectangle label:"Route to on-call or auto-resolve" +n8.handle(right) -> n9.handle(left) +n9.handle(bottom) -> Broker.n4.handle(top) [label="Publish: alert.resolved"] +} +Analytics { # Analytics Agent +n10: rectangle label:"Aggregate metrics" +n11: rectangle label:"Update dashboard" +n12: circle label:"Stored" +n10.handle(right) -> n11.handle(left) +n11.handle(right) -> n12.handle(left) +} diff --git a/agentic/architecture/ai-native-generator-critic-architecture/README.md b/agentic/architecture/ai-native-generator-critic-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..0987042e37ac90cb36e47b78cf92b22e9a2a5802 --- /dev/null +++ b/agentic/architecture/ai-native-generator-critic-architecture/README.md @@ -0,0 +1,19 @@ +# AI-Native Generator-Critic Architecture + +A competitive / generator-critic architecture where multiple generators produce independent answers, then an evaluator agent scores and selects the best output. This approach improves quality and reduces single-model brittleness. It's costlier (multiple LLM calls) but pays off when correctness or creativity matters more than latency. + +**Template ID:** `ai-native-generator-critic-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** agentic +**Secondary use cases:** ai-orchestration +**Complexity:** 3/5 +**Nodes:** 9 +**Lanes:** 3 +**Tags:** [ai-native, generator-critic, agentic-ai, tournament-mode, multi-agent, architecture-diagram] +**Source path:** `` +**Repo path:** `agentic/architecture/ai-native-generator-critic-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/agentic/architecture/ai-native-generator-critic-architecture/metadata.json b/agentic/architecture/ai-native-generator-critic-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..4d0163a75492a056f1b733d117b4b58ef7891b58 --- /dev/null +++ b/agentic/architecture/ai-native-generator-critic-architecture/metadata.json @@ -0,0 +1,29 @@ +{ + "template_id": "ai-native-generator-critic-architecture", + "workflow_id": "ai-native-generator-critic-architecture", + "title": "AI-Native Generator-Critic Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "agentic", + "secondary_use_cases": [ + "ai-orchestration" + ], + "use_cases": [ + "agentic", + "ai-orchestration" + ], + "complexity": 3, + "num_nodes": 9, + "num_lanes": 3, + "tags": [ + "ai-native", + "generator-critic", + "agentic-ai", + "tournament-mode", + "multi-agent", + "architecture-diagram" + ], + "description": "A competitive / generator-critic architecture where multiple generators produce independent answers, then an evaluator agent scores and selects the best output. This approach improves quality and reduces single-model brittleness. It's costlier (multiple LLM calls) but pays off when correctness or creativity matters more than latency.", + "source_path": "", + "repo_path": "agentic/architecture/ai-native-generator-critic-architecture" +} diff --git a/agentic/architecture/ai-native-generator-critic-architecture/workflow.fz b/agentic/architecture/ai-native-generator-critic-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..a230fa7089047f0321b273a3f7d940c3b2275d82 --- /dev/null +++ b/agentic/architecture/ai-native-generator-critic-architecture/workflow.fz @@ -0,0 +1,27 @@ +Input { # Input +n1: circle label:"Start" +n2: rectangle label:"Creative brief submitted" +n1.handle(right) -> n2.handle(left) +n2.handle(bottom) -> Generators.n3.handle(top) [label="Brief"] +n2.handle(bottom) -> Generators.n4.handle(top) [label="Brief"] +n2.handle(bottom) -> Generators.n5.handle(top) [label="Brief"] +} +Generators { # Generator Agents +n3: rectangle label:"Agent A: Draft option 1" +n4: rectangle label:"Agent B: Draft option 2" +n5: rectangle label:"Agent C: Draft option 3" +n3.handle(bottom) -> Evaluator.n6.handle(top) [label="Option 1"] +n4.handle(bottom) -> Evaluator.n6.handle(top) [label="Option 2"] +n5.handle(bottom) -> Evaluator.n6.handle(top) [label="Option 3"] +} +Evaluator { # Evaluator Agent +n6: rectangle label:"Score all options" +n7: diamond label:"Quality threshold met?" +n8: rectangle label:"Select best output" +n9: circle label:"Done" +n6.handle(right) -> n7.handle(left) +n7.handle(right) -> n8.handle(left) [label="Yes"] +n7.handle(top) -> Generators.n3.handle(bottom) [label="No - Refine"] +n8.handle(right) -> n9.handle(left) +loop [refine until quality threshold met] n3 n4 n5 n6 n7 +} diff --git a/agentic/architecture/ai-native-hierarchical-architecture/README.md b/agentic/architecture/ai-native-hierarchical-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..ee597667b6c87f63429f88f2bd1c7929a97f6b67 --- /dev/null +++ b/agentic/architecture/ai-native-hierarchical-architecture/README.md @@ -0,0 +1,19 @@ +# AI-Native Hierarchical Architecture + +A hierarchical multi-agent architecture that scales orchestration by stacking supervisors and team leads (a tree structure), which mirrors enterprise org structures and helps partition context. This is the 'enterprise-grade agentic AI architecture' when a single orchestrator cannot manage all workers directly. Ideal for large enterprises and multi-domain workflows. + +**Template ID:** `ai-native-hierarchical-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** agentic +**Secondary use cases:** ai-orchestration +**Complexity:** 4/5 +**Nodes:** 16 +**Lanes:** 4 +**Tags:** [ai-native, hierarchical, agentic-ai, enterprise, multi-agent, architecture-diagram] +**Source path:** `` +**Repo path:** `agentic/architecture/ai-native-hierarchical-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/agentic/architecture/ai-native-hierarchical-architecture/metadata.json b/agentic/architecture/ai-native-hierarchical-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..9f0d1e91c4c8c0ffb2ec417900b10535b54ea0ff --- /dev/null +++ b/agentic/architecture/ai-native-hierarchical-architecture/metadata.json @@ -0,0 +1,29 @@ +{ + "template_id": "ai-native-hierarchical-architecture", + "workflow_id": "ai-native-hierarchical-architecture", + "title": "AI-Native Hierarchical Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "agentic", + "secondary_use_cases": [ + "ai-orchestration" + ], + "use_cases": [ + "agentic", + "ai-orchestration" + ], + "complexity": 4, + "num_nodes": 16, + "num_lanes": 4, + "tags": [ + "ai-native", + "hierarchical", + "agentic-ai", + "enterprise", + "multi-agent", + "architecture-diagram" + ], + "description": "A hierarchical multi-agent architecture that scales orchestration by stacking supervisors and team leads (a tree structure), which mirrors enterprise org structures and helps partition context. This is the 'enterprise-grade agentic AI architecture' when a single orchestrator cannot manage all workers directly. Ideal for large enterprises and multi-domain workflows.", + "source_path": "", + "repo_path": "agentic/architecture/ai-native-hierarchical-architecture" +} diff --git a/agentic/architecture/ai-native-hierarchical-architecture/workflow.fz b/agentic/architecture/ai-native-hierarchical-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..2fd24c0914304b1ad239c18e7d56833f6b2b9908 --- /dev/null +++ b/agentic/architecture/ai-native-hierarchical-architecture/workflow.fz @@ -0,0 +1,45 @@ +User { # User +n1: circle label:"Start" +n2: rectangle label:"Submit enterprise request" +n1.handle(right) -> n2.handle(left) +n2.handle(bottom) -> Supervisor.n3.handle(top) [label="Goal"] +} +Supervisor { # Top-Level Supervisor +n3: rectangle label:"Decompose goal" +n4: rectangle label:"Delegate to team leads" +n5: rectangle label:"Aggregate final output" +n6: circle label:"Done" +n3.handle(right) -> n4.handle(left) +n4.handle(bottom) -> LeadA.n7.handle(top) [label="Sub-goal A"] +n4.handle(bottom) -> LeadB.n10.handle(top) [label="Sub-goal B"] +n5.handle(right) -> n6.handle(left) +n5.handle(top) -> User.n2.handle(bottom) [label="Final report"] +} +LeadA { # Team Lead A +n7: rectangle label:"Plan subtasks for A" +n8: rectangle label:"Dispatch to workers" +n9: rectangle label:"Consolidate A results" +n7.handle(right) -> n8.handle(left) +n8.handle(bottom) -> Workers.n13.handle(top) [label="Task A1"] +n8.handle(bottom) -> Workers.n14.handle(top) [label="Task A2"] +n9.handle(top) -> Supervisor.n5.handle(bottom) [label="Result A"] +} +LeadB { # Team Lead B +n10: rectangle label:"Plan subtasks for B" +n11: rectangle label:"Dispatch to workers" +n12: rectangle label:"Consolidate B results" +n10.handle(right) -> n11.handle(left) +n11.handle(bottom) -> Workers.n15.handle(top) [label="Task B1"] +n11.handle(bottom) -> Workers.n16.handle(top) [label="Task B2"] +n12.handle(top) -> Supervisor.n5.handle(bottom) [label="Result B"] +} +Workers { # Worker Agents +n13: rectangle label:"Worker A1 executes" +n14: rectangle label:"Worker A2 executes" +n15: rectangle label:"Worker B1 executes" +n16: rectangle label:"Worker B2 executes" +n13.handle(top) -> LeadA.n9.handle(bottom) [label="A1 done"] +n14.handle(top) -> LeadA.n9.handle(bottom) [label="A2 done"] +n15.handle(top) -> LeadB.n12.handle(bottom) [label="B1 done"] +n16.handle(top) -> LeadB.n12.handle(bottom) [label="B2 done"] +} diff --git a/agentic/architecture/ai-native-orchestrator-worker-architecture/README.md b/agentic/architecture/ai-native-orchestrator-worker-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..7939f9047d3865c5be3135052e1cc4b62c17c48b --- /dev/null +++ b/agentic/architecture/ai-native-orchestrator-worker-architecture/README.md @@ -0,0 +1,19 @@ +# AI-Native Orchestrator-Worker Architecture + +An orchestrator-worker architecture where an orchestrator agent breaks a goal into subtasks, dispatches to specialized workers, then synthesizes a final response. This is the most common 'agent orchestration' architecture—powerful but the orchestrator can become a bottleneck as the number of workers grows. Frameworks like LangGraph focus on explicit routing/state to manage this. + +**Template ID:** `ai-native-orchestrator-worker-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** agentic +**Secondary use cases:** ai-orchestration +**Complexity:** 3/5 +**Nodes:** 14 +**Lanes:** 4 +**Tags:** [ai-native, orchestrator-worker, agentic-ai, langgraph, multi-agent, architecture-diagram] +**Source path:** `` +**Repo path:** `agentic/architecture/ai-native-orchestrator-worker-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/agentic/architecture/ai-native-orchestrator-worker-architecture/metadata.json b/agentic/architecture/ai-native-orchestrator-worker-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..e86338674e1d543382b508d0ffae2c7fa7032ca3 --- /dev/null +++ b/agentic/architecture/ai-native-orchestrator-worker-architecture/metadata.json @@ -0,0 +1,29 @@ +{ + "template_id": "ai-native-orchestrator-worker-architecture", + "workflow_id": "ai-native-orchestrator-worker-architecture", + "title": "AI-Native Orchestrator-Worker Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "agentic", + "secondary_use_cases": [ + "ai-orchestration" + ], + "use_cases": [ + "agentic", + "ai-orchestration" + ], + "complexity": 3, + "num_nodes": 14, + "num_lanes": 4, + "tags": [ + "ai-native", + "orchestrator-worker", + "agentic-ai", + "langgraph", + "multi-agent", + "architecture-diagram" + ], + "description": "An orchestrator-worker architecture where an orchestrator agent breaks a goal into subtasks, dispatches to specialized workers, then synthesizes a final response. This is the most common 'agent orchestration' architecture—powerful but the orchestrator can become a bottleneck as the number of workers grows. Frameworks like LangGraph focus on explicit routing/state to manage this.", + "source_path": "", + "repo_path": "agentic/architecture/ai-native-orchestrator-worker-architecture" +} diff --git a/agentic/architecture/ai-native-orchestrator-worker-architecture/workflow.fz b/agentic/architecture/ai-native-orchestrator-worker-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..debef4c2a3608894df34cdf7eea713b7892f2566 --- /dev/null +++ b/agentic/architecture/ai-native-orchestrator-worker-architecture/workflow.fz @@ -0,0 +1,40 @@ +User { # User +n1: circle label:"Start" +n2: rectangle label:"Submit complex task" +n1.handle(right) -> n2.handle(left) +n2.handle(bottom) -> Orchestrator.n3.handle(top) [label="Task"] +} +Orchestrator { # Orchestrator Agent +n3: rectangle label:"Receive task" +n4: rectangle label:"Break into subtasks" +n5: rectangle label:"Dispatch subtasks" +n6: rectangle label:"Collect results" +n7: rectangle label:"Synthesize final answer" +n8: circle label:"Done" +n3.handle(right) -> n4.handle(left) +n4.handle(right) -> n5.handle(left) +n5.handle(bottom) -> Research.n9.handle(top) [label="Research subtask"] +n5.handle(bottom) -> Code.n11.handle(top) [label="Code subtask"] +n5.handle(bottom) -> Review.n13.handle(top) [label="Review subtask"] +n6.handle(right) -> n7.handle(left) +n7.handle(right) -> n8.handle(left) +n7.handle(top) -> User.n2.handle(bottom) [label="Response"] +} +Research { # Research Agent +n9: rectangle label:"Search sources" +n10: rectangle label:"Summarize findings" +n9.handle(right) -> n10.handle(left) +n10.handle(top) -> Orchestrator.n6.handle(bottom) [label="Research result"] +} +Code { # Code Agent +n11: rectangle label:"Generate code" +n12: rectangle label:"Run tests" +n11.handle(right) -> n12.handle(left) +n12.handle(top) -> Orchestrator.n6.handle(bottom) [label="Code result"] +} +Review { # Review Agent +n13: rectangle label:"Evaluate quality" +n14: rectangle label:"Flag issues" +n13.handle(right) -> n14.handle(left) +n14.handle(top) -> Orchestrator.n6.handle(bottom) [label="Review result"] +} diff --git a/agentic/architecture/ai-native-single-agent-architecture/README.md b/agentic/architecture/ai-native-single-agent-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..49f97d23d8ca894159b739bfc3ea53c37d73e8b3 --- /dev/null +++ b/agentic/architecture/ai-native-single-agent-architecture/README.md @@ -0,0 +1,19 @@ +# AI-Native Single Agent Architecture + +A single-agent AI architecture where one agent handles everything: parsing requests, reasoning, calling tools via MCP, and generating responses. This is the default architecture for prototypes and simple automations—easy to debug but hits context-window limits quickly and is hard to parallelize. Ideal for MVPs and solo builders shipping fast. + +**Template ID:** `ai-native-single-agent-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** agentic +**Secondary use cases:** ai-orchestration, mcp +**Complexity:** 2/5 +**Nodes:** 11 +**Lanes:** 3 +**Tags:** [ai-native, single-agent, agentic-ai, mcp, architecture-diagram] +**Source path:** `` +**Repo path:** `agentic/architecture/ai-native-single-agent-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/agentic/architecture/ai-native-single-agent-architecture/metadata.json b/agentic/architecture/ai-native-single-agent-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..144def6a9b319726462fd66dd47c5a595ddc69b0 --- /dev/null +++ b/agentic/architecture/ai-native-single-agent-architecture/metadata.json @@ -0,0 +1,30 @@ +{ + "template_id": "ai-native-single-agent-architecture", + "workflow_id": "ai-native-single-agent-architecture", + "title": "AI-Native Single Agent Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "agentic", + "secondary_use_cases": [ + "ai-orchestration", + "mcp" + ], + "use_cases": [ + "agentic", + "ai-orchestration", + "mcp" + ], + "complexity": 2, + "num_nodes": 11, + "num_lanes": 3, + "tags": [ + "ai-native", + "single-agent", + "agentic-ai", + "mcp", + "architecture-diagram" + ], + "description": "A single-agent AI architecture where one agent handles everything: parsing requests, reasoning, calling tools via MCP, and generating responses. This is the default architecture for prototypes and simple automations—easy to debug but hits context-window limits quickly and is hard to parallelize. Ideal for MVPs and solo builders shipping fast.", + "source_path": "", + "repo_path": "agentic/architecture/ai-native-single-agent-architecture" +} diff --git a/agentic/architecture/ai-native-single-agent-architecture/workflow.fz b/agentic/architecture/ai-native-single-agent-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..04a7bce1a9a3a6234e0452f38052dae0611c305a --- /dev/null +++ b/agentic/architecture/ai-native-single-agent-architecture/workflow.fz @@ -0,0 +1,29 @@ +User { # User +n1: circle label:"Start" +n2: rectangle label:"Send request" +n1.handle(right) -> n2.handle(left) +n2.handle(bottom) -> Agent.n3.handle(top) [label="Request"] +} +Agent { # Single AI Agent +n3: rectangle label:"Receive input" +n4: rectangle label:"Reason and plan" +n5: rectangle label:"Decide tool call" +n6: rectangle label:"Process tool result" +n7: rectangle label:"Generate response" +n8: circle label:"Done" +n3.handle(right) -> n4.handle(left) +n4.handle(right) -> n5.handle(left) +n5.handle(bottom) -> Tools.n9.handle(top) [label="MCP request"] +n6.handle(right) -> n7.handle(left) +n7.handle(right) -> n8.handle(left) +n7.handle(top) -> User.n2.handle(bottom) [label="Response"] +loop [retry until goal met] n4 n5 n6 n7 +} +Tools { # Tool Server (MCP) +n9: rectangle label:"Receive MCP call" +n10: rectangle label:"Execute tool" +n11: rectangle label:"Return result" +n9.handle(right) -> n10.handle(left) +n10.handle(right) -> n11.handle(left) +n11.handle(top) -> Agent.n6.handle(bottom) [label="Tool result"] +} diff --git a/agentic/architecture/ai-orchestration-competitive-generator-critic/README.md b/agentic/architecture/ai-orchestration-competitive-generator-critic/README.md new file mode 100644 index 0000000000000000000000000000000000000000..5fb5353d416a5fe9c2fcb6fed3fc9290a550781e --- /dev/null +++ b/agentic/architecture/ai-orchestration-competitive-generator-critic/README.md @@ -0,0 +1,19 @@ +# AI Orchestration - Competitive Generator-Critic + +A tournament-mode architecture where multiple generator agents produce independent outputs in parallel, then an evaluator agent scores and selects the best. Quality threshold checking with refinement loops. Best when correctness or creativity matters more than latency. + +**Template ID:** `ai-orchestration-competitive-generator-critic` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** agentic +**Secondary use cases:** ai-orchestration +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [ai-native, competitive, generator-critic, tournament, multi-agent, architecture-diagram, orchestration] +**Source path:** `` +**Repo path:** `agentic/architecture/ai-orchestration-competitive-generator-critic` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/agentic/architecture/ai-orchestration-competitive-generator-critic/metadata.json b/agentic/architecture/ai-orchestration-competitive-generator-critic/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..6830ba34771d860f17f924446b161d8a4ca3036b --- /dev/null +++ b/agentic/architecture/ai-orchestration-competitive-generator-critic/metadata.json @@ -0,0 +1,30 @@ +{ + "template_id": "ai-orchestration-competitive-generator-critic", + "workflow_id": "ai-orchestration-competitive-generator-critic", + "title": "AI Orchestration - Competitive Generator-Critic", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "agentic", + "secondary_use_cases": [ + "ai-orchestration" + ], + "use_cases": [ + "agentic", + "ai-orchestration" + ], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "ai-native", + "competitive", + "generator-critic", + "tournament", + "multi-agent", + "architecture-diagram", + "orchestration" + ], + "description": "A tournament-mode architecture where multiple generator agents produce independent outputs in parallel, then an evaluator agent scores and selects the best. Quality threshold checking with refinement loops. Best when correctness or creativity matters more than latency.", + "source_path": "", + "repo_path": "agentic/architecture/ai-orchestration-competitive-generator-critic" +} diff --git a/agentic/architecture/ai-orchestration-competitive-generator-critic/workflow.fz b/agentic/architecture/ai-orchestration-competitive-generator-critic/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..4c63eef2b1342d08b128cce177704724efc744f9 --- /dev/null +++ b/agentic/architecture/ai-orchestration-competitive-generator-critic/workflow.fz @@ -0,0 +1,29 @@ +Input { # Input + n1: circle label="Start" + n2: rectangle label="Creative brief submitted" + n1.handle(right) -> n2.handle(left) + n2.handle(bottom) -> Generators.n3.handle(top) [label="Brief"] + n2.handle(bottom) -> Generators.n4.handle(top) [label="Brief"] + n2.handle(bottom) -> Generators.n5.handle(top) [label="Brief"] +} + +Generators { # Generator Agents + n3: rectangle label="Agent A: Draft option 1" + n4: rectangle label="Agent B: Draft option 2" + n5: rectangle label="Agent C: Draft option 3" + n3.handle(bottom) -> Evaluator.n6.handle(top) [label="Option 1"] + n4.handle(bottom) -> Evaluator.n6.handle(top) [label="Option 2"] + n5.handle(bottom) -> Evaluator.n6.handle(top) [label="Option 3"] +} + +Evaluator { # Evaluator Agent + n6: rectangle label="Score all options" + n7: diamond label="Quality threshold met?" + n8: rectangle label="Select best output" + n9: circle label="Done" + n6.handle(right) -> n7.handle(left) + n7.handle(right) -> n8.handle(left) [label="Yes"] + n7.handle(top) -> Generators.n3.handle(bottom) [label="No - Refine"] + n8.handle(right) -> n9.handle(left) + loop [refine until quality threshold met] n3 n4 n5 n6 n7 +} diff --git a/agentic/architecture/ai-orchestration-hierarchical/README.md b/agentic/architecture/ai-orchestration-hierarchical/README.md new file mode 100644 index 0000000000000000000000000000000000000000..feecc38901c341f93645b82c77f26c6c740aaa56 --- /dev/null +++ b/agentic/architecture/ai-orchestration-hierarchical/README.md @@ -0,0 +1,19 @@ +# AI Orchestration - Hierarchical (Org Chart) + +An org-chart architecture with multi-level structure. A top-level supervisor manages team leads, who each manage their own pool of specialist workers. Teams within teams. Best for enterprise-scale automation with 10+ specialized agents spanning multiple domains. + +**Template ID:** `ai-orchestration-hierarchical` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** agentic +**Secondary use cases:** ai-orchestration +**Complexity:** 4/5 +**Nodes:** 17 +**Lanes:** 5 +**Tags:** [ai-native, hierarchical, org-chart, enterprise, multi-agent, architecture-diagram, orchestration] +**Source path:** `` +**Repo path:** `agentic/architecture/ai-orchestration-hierarchical` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/agentic/architecture/ai-orchestration-hierarchical/metadata.json b/agentic/architecture/ai-orchestration-hierarchical/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..d7d025454d3039a737bf582bcc2004253fba2111 --- /dev/null +++ b/agentic/architecture/ai-orchestration-hierarchical/metadata.json @@ -0,0 +1,30 @@ +{ + "template_id": "ai-orchestration-hierarchical", + "workflow_id": "ai-orchestration-hierarchical", + "title": "AI Orchestration - Hierarchical (Org Chart)", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "agentic", + "secondary_use_cases": [ + "ai-orchestration" + ], + "use_cases": [ + "agentic", + "ai-orchestration" + ], + "complexity": 4, + "num_nodes": 17, + "num_lanes": 5, + "tags": [ + "ai-native", + "hierarchical", + "org-chart", + "enterprise", + "multi-agent", + "architecture-diagram", + "orchestration" + ], + "description": "An org-chart architecture with multi-level structure. A top-level supervisor manages team leads, who each manage their own pool of specialist workers. Teams within teams. Best for enterprise-scale automation with 10+ specialized agents spanning multiple domains.", + "source_path": "", + "repo_path": "agentic/architecture/ai-orchestration-hierarchical" +} diff --git a/agentic/architecture/ai-orchestration-hierarchical/workflow.fz b/agentic/architecture/ai-orchestration-hierarchical/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..c529050ec2f54d7685b389705ab301ab122efb02 --- /dev/null +++ b/agentic/architecture/ai-orchestration-hierarchical/workflow.fz @@ -0,0 +1,49 @@ +User { # User + n1: circle label="Start" + n2: rectangle label="Submit enterprise request" + n1.handle(right) -> n2.handle(left) + n2.handle(bottom) -> Supervisor.n3.handle(top) [label="Goal"] +} + +Supervisor { # Top-Level Supervisor + n3: rectangle label="Decompose goal" + n4: rectangle label="Delegate to team leads" + n5: rectangle label="Aggregate final output" + n6: circle label="Done" + n3.handle(right) -> n4.handle(left) + n4.handle(bottom) -> LeadA.n7.handle(top) [label="Sub-goal A"] + n4.handle(bottom) -> LeadB.n10.handle(top) [label="Sub-goal B"] + n5.handle(right) -> n6.handle(left) + n5.handle(top) -> User.n2.handle(bottom) [label="Final report"] +} + +LeadA { # Team Lead A + n7: rectangle label="Plan subtasks for A" + n8: rectangle label="Dispatch to workers" + n9: rectangle label="Consolidate A results" + n7.handle(right) -> n8.handle(left) + n8.handle(bottom) -> Workers.n13.handle(top) [label="Task A1"] + n8.handle(bottom) -> Workers.n14.handle(top) [label="Task A2"] + n9.handle(top) -> Supervisor.n5.handle(bottom) [label="Result A"] +} + +LeadB { # Team Lead B + n10: rectangle label="Plan subtasks for B" + n11: rectangle label="Dispatch to workers" + n12: rectangle label="Consolidate B results" + n10.handle(right) -> n11.handle(left) + n11.handle(bottom) -> Workers.n15.handle(top) [label="Task B1"] + n11.handle(bottom) -> Workers.n16.handle(top) [label="Task B2"] + n12.handle(top) -> Supervisor.n5.handle(bottom) [label="Result B"] +} + +Workers { # Worker Agents + n13: rectangle label="Worker A1 executes" + n14: rectangle label="Worker A2 executes" + n15: rectangle label="Worker B1 executes" + n16: rectangle label="Worker B2 executes" + n13.handle(top) -> LeadA.n9.handle(bottom) [label="A1 done"] + n14.handle(top) -> LeadA.n9.handle(bottom) [label="A2 done"] + n15.handle(top) -> LeadB.n12.handle(bottom) [label="B1 done"] + n16.handle(top) -> LeadB.n12.handle(bottom) [label="B2 done"] +} diff --git a/agentic/architecture/ai-orchestration-orchestrator-worker/README.md b/agentic/architecture/ai-orchestration-orchestrator-worker/README.md new file mode 100644 index 0000000000000000000000000000000000000000..0d7e8a2a011cddd9f4ea2015c14202ad50d600af --- /dev/null +++ b/agentic/architecture/ai-orchestration-orchestrator-worker/README.md @@ -0,0 +1,19 @@ +# AI Orchestration - Orchestrator-Worker + +A conductor-style architecture where one orchestrator agent receives a complex task, breaks it into subtasks, dispatches each to specialist worker agents (research, code, review), collects results, and synthesizes the final answer. Best for complex multi-step tasks with dynamic decomposition. + +**Template ID:** `ai-orchestration-orchestrator-worker` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** agentic +**Secondary use cases:** ai-orchestration +**Complexity:** 3/5 +**Nodes:** 15 +**Lanes:** 5 +**Tags:** [ai-native, orchestrator-worker, conductor, multi-agent, architecture-diagram, orchestration] +**Source path:** `` +**Repo path:** `agentic/architecture/ai-orchestration-orchestrator-worker` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/agentic/architecture/ai-orchestration-orchestrator-worker/metadata.json b/agentic/architecture/ai-orchestration-orchestrator-worker/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..67ebb4191cba72b2cfa5fec7634b9b04c33d406e --- /dev/null +++ b/agentic/architecture/ai-orchestration-orchestrator-worker/metadata.json @@ -0,0 +1,29 @@ +{ + "template_id": "ai-orchestration-orchestrator-worker", + "workflow_id": "ai-orchestration-orchestrator-worker", + "title": "AI Orchestration - Orchestrator-Worker", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "agentic", + "secondary_use_cases": [ + "ai-orchestration" + ], + "use_cases": [ + "agentic", + "ai-orchestration" + ], + "complexity": 3, + "num_nodes": 15, + "num_lanes": 5, + "tags": [ + "ai-native", + "orchestrator-worker", + "conductor", + "multi-agent", + "architecture-diagram", + "orchestration" + ], + "description": "A conductor-style architecture where one orchestrator agent receives a complex task, breaks it into subtasks, dispatches each to specialist worker agents (research, code, review), collects results, and synthesizes the final answer. Best for complex multi-step tasks with dynamic decomposition.", + "source_path": "", + "repo_path": "agentic/architecture/ai-orchestration-orchestrator-worker" +} diff --git a/agentic/architecture/ai-orchestration-orchestrator-worker/workflow.fz b/agentic/architecture/ai-orchestration-orchestrator-worker/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..b52b67246d032f691ac8484ed7d39244245eb27b --- /dev/null +++ b/agentic/architecture/ai-orchestration-orchestrator-worker/workflow.fz @@ -0,0 +1,44 @@ +User { # User + n1: circle label="Start" + n2: rectangle label="Submit complex task" + n1.handle(right) -> n2.handle(left) + n2.handle(bottom) -> Orchestrator.n3.handle(top) [label="Task"] +} + +Orchestrator { # Orchestrator Agent + n3: rectangle label="Receive task" + n4: rectangle label="Break into subtasks" + n5: rectangle label="Dispatch subtasks" + n6: rectangle label="Collect results" + n7: rectangle label="Synthesize final answer" + n8: circle label="Done" + n3.handle(right) -> n4.handle(left) + n4.handle(right) -> n5.handle(left) + n5.handle(bottom) -> Research.n9.handle(top) [label="Research subtask"] + n5.handle(bottom) -> Code.n11.handle(top) [label="Code subtask"] + n5.handle(bottom) -> Review.n13.handle(top) [label="Review subtask"] + n6.handle(right) -> n7.handle(left) + n7.handle(right) -> n8.handle(left) + n7.handle(top) -> User.n2.handle(bottom) [label="Response"] +} + +Research { # Research Agent + n9: rectangle label="Search sources" + n10: rectangle label="Summarize findings" + n9.handle(right) -> n10.handle(left) + n10.handle(top) -> Orchestrator.n6.handle(bottom) [label="Research result"] +} + +Code { # Code Agent + n11: rectangle label="Generate code" + n12: rectangle label="Run tests" + n11.handle(right) -> n12.handle(left) + n12.handle(top) -> Orchestrator.n6.handle(bottom) [label="Code result"] +} + +Review { # Review Agent + n13: rectangle label="Evaluate quality" + n14: rectangle label="Flag issues" + n13.handle(right) -> n14.handle(left) + n14.handle(top) -> Orchestrator.n6.handle(bottom) [label="Review result"] +} diff --git a/agentic/architecture/ai-orchestration-parallel-fan-out/README.md b/agentic/architecture/ai-orchestration-parallel-fan-out/README.md new file mode 100644 index 0000000000000000000000000000000000000000..2d26f8ba1ad18da1ae919252c5770a7f6f1bc56c --- /dev/null +++ b/agentic/architecture/ai-orchestration-parallel-fan-out/README.md @@ -0,0 +1,19 @@ +# AI Orchestration - Parallel Fan-Out (Map-Reduce) + +A map-reduce style architecture where a coordinator fans out tasks to multiple parallel worker agents (style check, security audit, performance analysis), gathers all results, and makes an aggregate decision. Best for PR reviews, code reviews, and multi-dimensional analysis. + +**Template ID:** `ai-orchestration-parallel-fan-out` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** agentic +**Secondary use cases:** ai-orchestration +**Complexity:** 3/5 +**Nodes:** 9 +**Lanes:** 3 +**Tags:** [ai-native, parallel-fan-out, map-reduce, coordinator, multi-agent, architecture-diagram, orchestration] +**Source path:** `` +**Repo path:** `agentic/architecture/ai-orchestration-parallel-fan-out` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/agentic/architecture/ai-orchestration-parallel-fan-out/metadata.json b/agentic/architecture/ai-orchestration-parallel-fan-out/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..9c328eff6421eb0e0f77768043a45d52cc044ff7 --- /dev/null +++ b/agentic/architecture/ai-orchestration-parallel-fan-out/metadata.json @@ -0,0 +1,30 @@ +{ + "template_id": "ai-orchestration-parallel-fan-out", + "workflow_id": "ai-orchestration-parallel-fan-out", + "title": "AI Orchestration - Parallel Fan-Out (Map-Reduce)", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "agentic", + "secondary_use_cases": [ + "ai-orchestration" + ], + "use_cases": [ + "agentic", + "ai-orchestration" + ], + "complexity": 3, + "num_nodes": 9, + "num_lanes": 3, + "tags": [ + "ai-native", + "parallel-fan-out", + "map-reduce", + "coordinator", + "multi-agent", + "architecture-diagram", + "orchestration" + ], + "description": "A map-reduce style architecture where a coordinator fans out tasks to multiple parallel worker agents (style check, security audit, performance analysis), gathers all results, and makes an aggregate decision. Best for PR reviews, code reviews, and multi-dimensional analysis.", + "source_path": "", + "repo_path": "agentic/architecture/ai-orchestration-parallel-fan-out" +} diff --git a/agentic/architecture/ai-orchestration-parallel-fan-out/workflow.fz b/agentic/architecture/ai-orchestration-parallel-fan-out/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..560dd43236284adb1ff42dfa4bf6dd7164a7cba7 --- /dev/null +++ b/agentic/architecture/ai-orchestration-parallel-fan-out/workflow.fz @@ -0,0 +1,31 @@ +Trigger { # Trigger + n1: circle label="Start" + n2: rectangle label="PR submitted for review" + n1.handle(right) -> n2.handle(left) + n2.handle(bottom) -> Coordinator.n3.handle(top) [label="PR payload"] +} + +Coordinator { # Coordinator Agent + n3: rectangle label="Fan out to reviewers" + n4: rectangle label="Gather all reviews" + n5: diamond label="All passed?" + n6: rectangle label="Approve PR" + n7: rectangle label="Request changes" + n8: circle label="Done" + n3.handle(bottom) -> Reviewers.n9.handle(top) [label="Style check"] + n3.handle(bottom) -> Reviewers.n10.handle(top) [label="Security audit"] + n3.handle(bottom) -> Reviewers.n11.handle(top) [label="Perf analysis"] + n4.handle(right) -> n5.handle(left) + n5.handle(right) -> n6.handle(left) [label="Yes"] + n5.handle(bottom) -> n7.handle(top) [label="No"] + n6.handle(right) -> n8.handle(left) +} + +Reviewers { # Parallel Review Agents + n9: rectangle label="Style Agent" + n10: rectangle label="Security Agent" + n11: rectangle label="Performance Agent" + n9.handle(top) -> Coordinator.n4.handle(bottom) [label="Style report"] + n10.handle(top) -> Coordinator.n4.handle(bottom) [label="Security report"] + n11.handle(top) -> Coordinator.n4.handle(bottom) [label="Perf report"] +} diff --git a/agentic/architecture/context-shared-memory/README.md b/agentic/architecture/context-shared-memory/README.md new file mode 100644 index 0000000000000000000000000000000000000000..a82d0b1402d2ed823338ba37a1d98e6221f954ef --- /dev/null +++ b/agentic/architecture/context-shared-memory/README.md @@ -0,0 +1,19 @@ +# Context Management - Shared Memory + +Multi-agent coordination pattern where an orchestrator breaks work into subtasks, specialist agents pull from and push to a shared state store, and the orchestrator composes the final answer from that shared state. Multi-agent setups feel coherent instead of each assistant having its own inconsistent memory. + +**Template ID:** `context-shared-memory` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** agentic +**Secondary use cases:** context-management +**Complexity:** 3/5 +**Nodes:** 9 +**Lanes:** 4 +**Tags:** [context-management, shared-memory, multi-agent, orchestrator, architecture-diagram] +**Source path:** `` +**Repo path:** `agentic/architecture/context-shared-memory` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/agentic/architecture/context-shared-memory/metadata.json b/agentic/architecture/context-shared-memory/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..8890f89080cb0dcb74ddb037bf72e612c2b9782e --- /dev/null +++ b/agentic/architecture/context-shared-memory/metadata.json @@ -0,0 +1,28 @@ +{ + "template_id": "context-shared-memory", + "workflow_id": "context-shared-memory", + "title": "Context Management - Shared Memory", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "agentic", + "secondary_use_cases": [ + "context-management" + ], + "use_cases": [ + "agentic", + "context-management" + ], + "complexity": 3, + "num_nodes": 9, + "num_lanes": 4, + "tags": [ + "context-management", + "shared-memory", + "multi-agent", + "orchestrator", + "architecture-diagram" + ], + "description": "Multi-agent coordination pattern where an orchestrator breaks work into subtasks, specialist agents pull from and push to a shared state store, and the orchestrator composes the final answer from that shared state. Multi-agent setups feel coherent instead of each assistant having its own inconsistent memory.", + "source_path": "", + "repo_path": "agentic/architecture/context-shared-memory" +} diff --git a/agentic/architecture/context-shared-memory/workflow.fz b/agentic/architecture/context-shared-memory/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..d688c6b72e704069c77245b73768103bd38990ad --- /dev/null +++ b/agentic/architecture/context-shared-memory/workflow.fz @@ -0,0 +1,46 @@ +Orchestrator { + n1: circle label="Complex task arrives" + n2: rectangle label="Request shared context" + n3: rectangle label="Create research subtask" + n4: rectangle label="Create action subtask" + n5: rectangle label="Receive findings and results" + n6: rectangle label="Compile final answer" + n1.handle(right) -> n2.handle(left) + n2.handle(bottom) -> SharedMemory.n7.handle(top) [label="Read state"] + n3.handle(right) -> n4.handle(left) + n3.handle(bottom) -> Researcher.n9.handle(top) [label="Research task"] + n4.handle(bottom) -> Operator.n13.handle(top) [label="Action task"] + n5.handle(right) -> n6.handle(left) + Researcher.n12.handle(top) -> n5.handle(left) [label="Finding"] + Operator.n17.handle(top) -> n5.handle(right) [label="Result"] +} + +Researcher { + n9: rectangle label="Receive research task" + n10: rectangle label="Read shared memory" + n11: rectangle label="Analyze with context" + n12: rectangle label="Return finding" + n9.handle(right) -> n10.handle(left) + n10.handle(right) -> n11.handle(left) + n11.handle(right) -> n12.handle(left) + n10.handle(bottom) -> SharedMemory.n7.handle(left) [label="Read state"] +} + +Operator { + n13: rectangle label="Receive action task" + n14: rectangle label="Read shared memory" + n15: rectangle label="Execute with context" + n16: rectangle label="Write result to memory" + n17: rectangle label="Return result" + n13.handle(right) -> n14.handle(left) + n14.handle(right) -> n15.handle(left) + n15.handle(right) -> n16.handle(left) + n16.handle(bottom) -> SharedMemory.n8.handle(left) [label="Write state"] + n15.handle(bottom) -> n17.handle(top) +} + +SharedMemory { + n7: rectangle label="Resolve memory request" + n8: rectangle label="Update shared state" + n7.handle(right) -> n8.handle(left) +} diff --git a/agentic/devops/mcp-agent-mesh/README.md b/agentic/devops/mcp-agent-mesh/README.md new file mode 100644 index 0000000000000000000000000000000000000000..7b100b297c48a553497b70212cf575f9fd4171ce --- /dev/null +++ b/agentic/devops/mcp-agent-mesh/README.md @@ -0,0 +1,19 @@ +# MCP Agent Mesh Architecture + +A multi-agent mesh pattern where agents communicate through a shared context broker backed by MCP. Enables coordinated tool access and state synchronization across multiple specialized agents (planner, coder, reviewer, operator). Supports both orchestrated and choreographed interaction patterns. + +**Template ID:** `mcp-agent-mesh` +**Kind:** architecture +**Source domain:** DevOps +**Primary use case:** agentic +**Secondary use cases:** mcp +**Complexity:** 4/5 +**Nodes:** 10 +**Lanes:** 4 +**Tags:** [mcp, agent-mesh, shared-context, multi-agent, broker, architecture-diagram, production-grade] +**Source path:** `` +**Repo path:** `agentic/devops/mcp-agent-mesh` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/agentic/devops/mcp-agent-mesh/metadata.json b/agentic/devops/mcp-agent-mesh/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..49ca6f95c5e8c4f774d67d8f4b83a1c368c21be2 --- /dev/null +++ b/agentic/devops/mcp-agent-mesh/metadata.json @@ -0,0 +1,30 @@ +{ + "template_id": "mcp-agent-mesh", + "workflow_id": "mcp-agent-mesh", + "title": "MCP Agent Mesh Architecture", + "kind": "architecture", + "source_domain": "DevOps", + "primary_use_case": "agentic", + "secondary_use_cases": [ + "mcp" + ], + "use_cases": [ + "agentic", + "mcp" + ], + "complexity": 4, + "num_nodes": 10, + "num_lanes": 4, + "tags": [ + "mcp", + "agent-mesh", + "shared-context", + "multi-agent", + "broker", + "architecture-diagram", + "production-grade" + ], + "description": "A multi-agent mesh pattern where agents communicate through a shared context broker backed by MCP. Enables coordinated tool access and state synchronization across multiple specialized agents (planner, coder, reviewer, operator). Supports both orchestrated and choreographed interaction patterns.", + "source_path": "", + "repo_path": "agentic/devops/mcp-agent-mesh" +} diff --git a/agentic/devops/mcp-agent-mesh/workflow.fz b/agentic/devops/mcp-agent-mesh/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..0b3b125c893133436ded49e0e207e1b76d4531dc --- /dev/null +++ b/agentic/devops/mcp-agent-mesh/workflow.fz @@ -0,0 +1,41 @@ +Orchestrator { # Orchestrator Agent + n1: circle label="Complex task received" + n2: rectangle label="Decompose into subtasks" + n3: rectangle label="Assign subtask to Agent B" + n4: rectangle label="Receive subtask result" + n5: rectangle label="Request shared context" + n6: rectangle label="Compile final response" + n1.handle(right) -> n2.handle(left) + n2.handle(right) -> n3.handle(left) + n3.handle(bottom) -> Worker.n7.handle(top) [label="Subtask assignment"] + n4.handle(right) -> n5.handle(left) + n5.handle(bottom) -> Broker.n11.handle(top) [label="Context request"] + n6.handle(left) -> n2.handle(bottom) [label="Next iteration"] +} + +Worker { # Worker Agent + n7: rectangle label="Receive subtask" + n8: rectangle label="Fetch shared context" + n9: rectangle label="Call MCP tool" + n10: rectangle label="Return result to orchestrator" + n7.handle(right) -> n8.handle(left) + n8.handle(bottom) -> Broker.n11.handle(left) [label="Context request"] + n8.handle(right) -> n9.handle(left) + n9.handle(bottom) -> MCPServer.n13.handle(top) [label="MCP tool call"] + n10.handle(top) -> Orchestrator.n4.handle(bottom) [label="Subtask result"] +} + +Broker { # Shared Context Broker + n11: rectangle label="Resolve context request" + n12: rectangle label="Return shared state" + n11.handle(right) -> n12.handle(left) + n12.handle(top) -> Orchestrator.n6.handle(bottom) [label="Context to orchestrator"] + n12.handle(left) -> Worker.n9.handle(top) [label="Context to worker"] +} + +MCPServer { # MCP Server + n13: rectangle label="Execute tool" + n14: rectangle label="Return tool output" + n13.handle(right) -> n14.handle(left) + n14.handle(top) -> Worker.n10.handle(bottom) [label="Tool output"] +} diff --git a/ai-orchestration/architecture/ai-orchestration-event-driven-mesh/README.md b/ai-orchestration/architecture/ai-orchestration-event-driven-mesh/README.md new file mode 100644 index 0000000000000000000000000000000000000000..0f79f736ed8d0797e399e3c57041242431fda3e3 --- /dev/null +++ b/ai-orchestration/architecture/ai-orchestration-event-driven-mesh/README.md @@ -0,0 +1,19 @@ +# AI Orchestration - Event-Driven Mesh (Kafka-First) + +An event-driven agent mesh architecture using a Kafka-style event broker. Multiple agents subscribe to topics (orders, alerts, analytics), process events independently, and publish results back to the bus. Best for real-time event processing and decoupled service architectures. + +**Template ID:** `ai-orchestration-event-driven-mesh` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** ai-orchestration +**Secondary use cases:** mcp +**Complexity:** 3/5 +**Nodes:** 13 +**Lanes:** 5 +**Tags:** [ai-native, event-driven, kafka, agent-mesh, pub-sub, architecture-diagram, orchestration] +**Source path:** `` +**Repo path:** `ai-orchestration/architecture/ai-orchestration-event-driven-mesh` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/ai-orchestration/architecture/ai-orchestration-event-driven-mesh/metadata.json b/ai-orchestration/architecture/ai-orchestration-event-driven-mesh/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..c3e367a1c16785fe9f320261164cfed48edde40e --- /dev/null +++ b/ai-orchestration/architecture/ai-orchestration-event-driven-mesh/metadata.json @@ -0,0 +1,30 @@ +{ + "template_id": "ai-orchestration-event-driven-mesh", + "workflow_id": "ai-orchestration-event-driven-mesh", + "title": "AI Orchestration - Event-Driven Mesh (Kafka-First)", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "ai-orchestration", + "secondary_use_cases": [ + "mcp" + ], + "use_cases": [ + "ai-orchestration", + "mcp" + ], + "complexity": 3, + "num_nodes": 13, + "num_lanes": 5, + "tags": [ + "ai-native", + "event-driven", + "kafka", + "agent-mesh", + "pub-sub", + "architecture-diagram", + "orchestration" + ], + "description": "An event-driven agent mesh architecture using a Kafka-style event broker. Multiple agents subscribe to topics (orders, alerts, analytics), process events independently, and publish results back to the bus. Best for real-time event processing and decoupled service architectures.", + "source_path": "", + "repo_path": "ai-orchestration/architecture/ai-orchestration-event-driven-mesh" +} diff --git a/ai-orchestration/architecture/ai-orchestration-event-driven-mesh/workflow.fz b/ai-orchestration/architecture/ai-orchestration-event-driven-mesh/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..7a5e05dbdaf3b1f2760d5b03e37a47898617d416 --- /dev/null +++ b/ai-orchestration/architecture/ai-orchestration-event-driven-mesh/workflow.fz @@ -0,0 +1,39 @@ +Source { # Event Sources + n1: circle label="Start" + n2: rectangle label="User action event" + n3: rectangle label="System alert event" + n1.handle(right) -> n2.handle(left) + n2.handle(bottom) -> Broker.n4.handle(top) [label="Publish event"] + n3.handle(bottom) -> Broker.n4.handle(top) [label="Publish event"] +} + +Broker { # Event Broker (Kafka / Pub-Sub) + n4: rectangle label="Event bus receives event" + n5: rectangle label="Route to subscribers" + n4.handle(right) -> n5.handle(left) + n5.handle(bottom) -> Orders.n6.handle(top) [label="topic: orders"] + n5.handle(bottom) -> Alerts.n8.handle(top) [label="topic: alerts"] + n5.handle(bottom) -> Analytics.n10.handle(top) [label="topic: analytics"] +} + +Orders { # Order Processing Agent + n6: rectangle label="Parse order event" + n7: rectangle label="Execute fulfillment" + n6.handle(right) -> n7.handle(left) + n7.handle(bottom) -> Broker.n4.handle(top) [label="Publish: order.completed"] +} + +Alerts { # Alert Triage Agent + n8: rectangle label="Classify severity" + n9: rectangle label="Route to on-call or auto-resolve" + n8.handle(right) -> n9.handle(left) + n9.handle(bottom) -> Broker.n4.handle(top) [label="Publish: alert.resolved"] +} + +Analytics { # Analytics Agent + n10: rectangle label="Aggregate metrics" + n11: rectangle label="Update dashboard" + n12: circle label="Stored" + n10.handle(right) -> n11.handle(left) + n11.handle(right) -> n12.handle(left) +} diff --git a/ai-orchestration/architecture/ai-orchestration-single-agent/README.md b/ai-orchestration/architecture/ai-orchestration-single-agent/README.md new file mode 100644 index 0000000000000000000000000000000000000000..54384b0c786128efddf855668af4bfbe57c12967 --- /dev/null +++ b/ai-orchestration/architecture/ai-orchestration-single-agent/README.md @@ -0,0 +1,19 @@ +# AI Orchestration - Single Agent (Monolith) + +The simplest AI-native architecture — a single agent that receives user input, reasons, plans, decides on tool calls, processes results, and generates responses. Direct MCP connection over stdio or HTTP. Best for MVPs and when low latency matters. + +**Template ID:** `ai-orchestration-single-agent` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** ai-orchestration +**Secondary use cases:** mcp +**Complexity:** 2/5 +**Nodes:** 12 +**Lanes:** 3 +**Tags:** [ai-native, single-agent, monolith, mcp, architecture-diagram, orchestration] +**Source path:** `` +**Repo path:** `ai-orchestration/architecture/ai-orchestration-single-agent` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/ai-orchestration/architecture/ai-orchestration-single-agent/metadata.json b/ai-orchestration/architecture/ai-orchestration-single-agent/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..e48aefc4f2189a447adcd5a3ee233e3a86f33abe --- /dev/null +++ b/ai-orchestration/architecture/ai-orchestration-single-agent/metadata.json @@ -0,0 +1,29 @@ +{ + "template_id": "ai-orchestration-single-agent", + "workflow_id": "ai-orchestration-single-agent", + "title": "AI Orchestration - Single Agent (Monolith)", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "ai-orchestration", + "secondary_use_cases": [ + "mcp" + ], + "use_cases": [ + "ai-orchestration", + "mcp" + ], + "complexity": 2, + "num_nodes": 12, + "num_lanes": 3, + "tags": [ + "ai-native", + "single-agent", + "monolith", + "mcp", + "architecture-diagram", + "orchestration" + ], + "description": "The simplest AI-native architecture — a single agent that receives user input, reasons, plans, decides on tool calls, processes results, and generates responses. Direct MCP connection over stdio or HTTP. Best for MVPs and when low latency matters.", + "source_path": "", + "repo_path": "ai-orchestration/architecture/ai-orchestration-single-agent" +} diff --git a/ai-orchestration/architecture/ai-orchestration-single-agent/workflow.fz b/ai-orchestration/architecture/ai-orchestration-single-agent/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..e07d6d08ef6de946a4c198f938182830859f3d4e --- /dev/null +++ b/ai-orchestration/architecture/ai-orchestration-single-agent/workflow.fz @@ -0,0 +1,31 @@ +User { # User + n1: circle label="Start" + n2: rectangle label="Send request" + n1.handle(right) -> n2.handle(left) + n2.handle(bottom) -> Agent.n3.handle(top) [label="Request"] +} + +Agent { # Single AI Agent + n3: rectangle label="Receive input" + n4: rectangle label="Reason and plan" + n5: rectangle label="Decide tool call" + n6: rectangle label="Process tool result" + n7: rectangle label="Generate response" + n8: circle label="Done" + n3.handle(right) -> n4.handle(left) + n4.handle(right) -> n5.handle(left) + n5.handle(bottom) -> Tools.n9.handle(top) [label="MCP request"] + n6.handle(right) -> n7.handle(left) + n7.handle(right) -> n8.handle(left) + n7.handle(top) -> User.n2.handle(bottom) [label="Response"] + loop [retry until goal met] n4 n5 n6 n7 +} + +Tools { # Tool Server (MCP) + n9: rectangle label="Receive MCP call" + n10: rectangle label="Execute tool" + n11: rectangle label="Return result" + n9.handle(right) -> n10.handle(left) + n10.handle(right) -> n11.handle(left) + n11.handle(top) -> Agent.n6.handle(bottom) [label="Tool result"] +} diff --git a/ai-orchestration/architecture/kubernetes-container-orchestration-architecture/README.md b/ai-orchestration/architecture/kubernetes-container-orchestration-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..1616464b61693de4ccde2aa2c44cee946464b90f --- /dev/null +++ b/ai-orchestration/architecture/kubernetes-container-orchestration-architecture/README.md @@ -0,0 +1,19 @@ +# Kubernetes Container Orchestration Architecture + +A Kubernetes container orchestration architecture diagram showing the control plane (API Server, etcd, Scheduler, Controller Manager), worker nodes (Kubelet, container runtime, kube-proxy, pods), networking layer (Ingress, Network Policy, Service Mesh), and persistent storage with CSI drivers. This template provides a comprehensive view of the Kubernetes architecture stack from control plane to storage layer. Foundational reference for DevOps engineers and platform teams managing Kubernetes clusters. + +**Template ID:** `kubernetes-container-orchestration-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** ai-orchestration +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 18 +**Lanes:** 4 +**Tags:** [kubernetes, container-orchestration, k8s, control-plane, worker-node, ingress, persistent-storage, architecture-diagram] +**Source path:** `` +**Repo path:** `ai-orchestration/architecture/kubernetes-container-orchestration-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/ai-orchestration/architecture/kubernetes-container-orchestration-architecture/metadata.json b/ai-orchestration/architecture/kubernetes-container-orchestration-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..5a9883211e41c85f7b44dd69da929bdd1fb7f5e1 --- /dev/null +++ b/ai-orchestration/architecture/kubernetes-container-orchestration-architecture/metadata.json @@ -0,0 +1,28 @@ +{ + "template_id": "kubernetes-container-orchestration-architecture", + "workflow_id": "kubernetes-container-orchestration-architecture", + "title": "Kubernetes Container Orchestration Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "ai-orchestration", + "secondary_use_cases": [], + "use_cases": [ + "ai-orchestration" + ], + "complexity": 4, + "num_nodes": 18, + "num_lanes": 4, + "tags": [ + "kubernetes", + "container-orchestration", + "k8s", + "control-plane", + "worker-node", + "ingress", + "persistent-storage", + "architecture-diagram" + ], + "description": "A Kubernetes container orchestration architecture diagram showing the control plane (API Server, etcd, Scheduler, Controller Manager), worker nodes (Kubelet, container runtime, kube-proxy, pods), networking layer (Ingress, Network Policy, Service Mesh), and persistent storage with CSI drivers. This template provides a comprehensive view of the Kubernetes architecture stack from control plane to storage layer. Foundational reference for DevOps engineers and platform teams managing Kubernetes clusters.", + "source_path": "", + "repo_path": "ai-orchestration/architecture/kubernetes-container-orchestration-architecture" +} diff --git a/ai-orchestration/architecture/kubernetes-container-orchestration-architecture/workflow.fz b/ai-orchestration/architecture/kubernetes-container-orchestration-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..874b5b735921e271dfe8710be697ac3fe792898c --- /dev/null +++ b/ai-orchestration/architecture/kubernetes-container-orchestration-architecture/workflow.fz @@ -0,0 +1,41 @@ +ControlPlane { # Kubernetes Control Plane +n1: rectangle label:"API Server" +n2: rectangle label:"etcd (Cluster State)" +n3: rectangle label:"Scheduler" +n4: rectangle label:"Controller Manager" +n5: rectangle label:"Cloud Controller" +n1.handle(right) -> n2.handle(left) [label="Store State"] +n1.handle(bottom) -> n3.handle(top) [label="Schedule Pods"] +n3.handle(right) -> n4.handle(left) [label="Reconcile"] +n4.handle(right) -> n5.handle(left) [label="Cloud Resources"] +n3.handle(bottom) -> WorkerNode.n6.handle(top) [label="Assign Pod"] +} +WorkerNode { # Worker Node +n6: rectangle label:"Kubelet" +n7: rectangle label:"Container Runtime (containerd)" +n8: rectangle label:"kube-proxy" +n9: rectangle label:"Pod A (App Container)" +n10: rectangle label:"Pod B (App Container)" +n11: rectangle label:"Pod C (Sidecar + App)" +n6.handle(right) -> n7.handle(left) [label="Pull Image"] +n7.handle(right) -> n9.handle(left) [label="Start Container"] +n7.handle(bottom) -> n10.handle(top) [label="Start Container"] +n7.handle(bottom) -> n11.handle(top) [label="Start Container"] +n8.handle(bottom) -> Networking.n12.handle(top) [label="Service Routing"] +} +Networking { # Networking Layer +n12: rectangle label:"ClusterIP Service" +n13: rectangle label:"Ingress Controller" +n14: rectangle label:"Network Policy" +n15: rectangle label:"Service Mesh (Istio)" +n12.handle(right) -> n13.handle(left) [label="Expose"] +n13.handle(right) -> n14.handle(left) [label="Filter"] +n14.handle(right) -> n15.handle(left) [label="mTLS"] +} +Storage { # Persistent Storage +n16: rectangle label:"PersistentVolume" +n17: rectangle label:"StorageClass (SSD/HDD)" +n18: rectangle label:"CSI Driver" +n16.handle(right) -> n17.handle(left) [label="Provision"] +n17.handle(right) -> n18.handle(left) [label="Cloud Disk"] +} diff --git a/ai-orchestration/architecture/saga-distributed-transaction-architecture/README.md b/ai-orchestration/architecture/saga-distributed-transaction-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..043eec07fb4afef9bc90b816c24edbb9f46f1c3b --- /dev/null +++ b/ai-orchestration/architecture/saga-distributed-transaction-architecture/README.md @@ -0,0 +1,19 @@ +# Saga Distributed Transaction Architecture + +A distributed transaction architecture diagram implementing the two-phase commit protocol with a transaction coordinator sending prepare and commit messages to participating services, with global abort on any vote failure. This template visualizes the classic 2PC protocol used when strong consistency is required across multiple services, showing the prepare, vote, and commit/abort phases. Important for understanding distributed consensus trade-offs in microservices architectures. + +**Template ID:** `saga-distributed-transaction-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** ai-orchestration +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 17 +**Lanes:** 4 +**Tags:** [distributed-transaction, two-phase-commit, 2pc, transaction-coordinator, consensus, strong-consistency, prepare-commit, architecture-diagram] +**Source path:** `` +**Repo path:** `ai-orchestration/architecture/saga-distributed-transaction-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/ai-orchestration/architecture/saga-distributed-transaction-architecture/metadata.json b/ai-orchestration/architecture/saga-distributed-transaction-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..bb0250014c555a26a0ab27447587638548984573 --- /dev/null +++ b/ai-orchestration/architecture/saga-distributed-transaction-architecture/metadata.json @@ -0,0 +1,28 @@ +{ + "template_id": "saga-distributed-transaction-architecture", + "workflow_id": "saga-distributed-transaction-architecture", + "title": "Saga Distributed Transaction Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "ai-orchestration", + "secondary_use_cases": [], + "use_cases": [ + "ai-orchestration" + ], + "complexity": 4, + "num_nodes": 17, + "num_lanes": 4, + "tags": [ + "distributed-transaction", + "two-phase-commit", + "2pc", + "transaction-coordinator", + "consensus", + "strong-consistency", + "prepare-commit", + "architecture-diagram" + ], + "description": "A distributed transaction architecture diagram implementing the two-phase commit protocol with a transaction coordinator sending prepare and commit messages to participating services, with global abort on any vote failure. This template visualizes the classic 2PC protocol used when strong consistency is required across multiple services, showing the prepare, vote, and commit/abort phases. Important for understanding distributed consensus trade-offs in microservices architectures.", + "source_path": "", + "repo_path": "ai-orchestration/architecture/saga-distributed-transaction-architecture" +} diff --git a/ai-orchestration/architecture/saga-distributed-transaction-architecture/workflow.fz b/ai-orchestration/architecture/saga-distributed-transaction-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..ab8d908b26f144dea2858d69daf545b9570268dd --- /dev/null +++ b/ai-orchestration/architecture/saga-distributed-transaction-architecture/workflow.fz @@ -0,0 +1,49 @@ +Coordinator { # Transaction Coordinator +n1: circle label:"Begin Distributed Transaction" +n2: rectangle label:"Assign Transaction ID" +n3: rectangle label:"Send Prepare to All" +n16: rectangle label:"Collect Votes" +n17: diamond label:"All Voted Commit?" +n18: rectangle label:"Send Global Commit" +n19: rectangle label:"Send Global Abort" +n20: circle label:"Transaction Complete" +n1.handle(right) -> n2.handle(left) +n2.handle(right) -> n3.handle(left) [label="TxID"] +n3.handle(bottom) -> ServiceA.n4.handle(top) [label="Prepare"] +n3.handle(bottom) -> ServiceB.n7.handle(top) [label="Prepare"] +n3.handle(bottom) -> ServiceC.n10.handle(top) [label="Prepare"] +n16.handle(right) -> n17.handle(left) +n17.handle(right) -> n18.handle(left) [label="Yes"] +n17.handle(bottom) -> n19.handle(top) [label="No"] +n18.handle(right) -> n20.handle(left) +n19.handle(right) -> n20.handle(left) [label="Rolled Back"] +} +ServiceA { # Booking Service +n4: rectangle label:"Lock Resources" +n5: rectangle label:"Vote Commit" +n6: rectangle label:"Send Vote" +n4.handle(right) -> n5.handle(left) [label="Prepared"] +n5.handle(right) -> n6.handle(left) +n6.handle(top) -> Coordinator.n16.handle(bottom) [label="Vote"] +} +ServiceB { # Payment Service +n7: rectangle label:"Hold Funds" +n8: rectangle label:"Vote Commit" +n9: rectangle label:"Send Vote" +n7.handle(right) -> n8.handle(left) [label="Prepared"] +n8.handle(right) -> n9.handle(left) +n9.handle(top) -> Coordinator.n16.handle(bottom) [label="Vote"] +} +ServiceC { # Notification Service +n10: rectangle label:"Queue Notification" +n11: rectangle label:"Vote Commit" +n12: rectangle label:"Send Vote" +n13: rectangle label:"Apply Changes" +n14: rectangle label:"Capture Payment" +n15: rectangle label:"Send Notification" +n10.handle(right) -> n11.handle(left) [label="Prepared"] +n11.handle(right) -> n12.handle(left) +n12.handle(top) -> Coordinator.n16.handle(bottom) [label="Vote"] +n13.handle(right) -> n14.handle(left) +n14.handle(right) -> n15.handle(left) +} diff --git a/ai-orchestration/architecture/saga-travel-booking-architecture/README.md b/ai-orchestration/architecture/saga-travel-booking-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..fd654bf7a324ef37cfbf26fbffcbf59f71bc6495 --- /dev/null +++ b/ai-orchestration/architecture/saga-travel-booking-architecture/README.md @@ -0,0 +1,19 @@ +# Saga Travel Booking Architecture + +A travel booking saga architecture diagram orchestrating flight, hotel, and car rental reservations as a single distributed transaction, with automatic compensation to cancel all bookings if any reservation step fails. This template models the classic saga use case where multiple independent services must either all succeed or all roll back, ensuring travelers never end up with partial bookings. Perfect for demonstrating saga patterns with a real-world business scenario. + +**Template ID:** `saga-travel-booking-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** ai-orchestration +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 17 +**Lanes:** 5 +**Tags:** [saga-pattern, travel-booking, flight-reservation, hotel-booking, compensation, distributed-transaction, orchestration, architecture-diagram] +**Source path:** `` +**Repo path:** `ai-orchestration/architecture/saga-travel-booking-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/ai-orchestration/architecture/saga-travel-booking-architecture/metadata.json b/ai-orchestration/architecture/saga-travel-booking-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..7e278fa339553c57f1dd6619366f8c91677a3ce7 --- /dev/null +++ b/ai-orchestration/architecture/saga-travel-booking-architecture/metadata.json @@ -0,0 +1,28 @@ +{ + "template_id": "saga-travel-booking-architecture", + "workflow_id": "saga-travel-booking-architecture", + "title": "Saga Travel Booking Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "ai-orchestration", + "secondary_use_cases": [], + "use_cases": [ + "ai-orchestration" + ], + "complexity": 4, + "num_nodes": 17, + "num_lanes": 5, + "tags": [ + "saga-pattern", + "travel-booking", + "flight-reservation", + "hotel-booking", + "compensation", + "distributed-transaction", + "orchestration", + "architecture-diagram" + ], + "description": "A travel booking saga architecture diagram orchestrating flight, hotel, and car rental reservations as a single distributed transaction, with automatic compensation to cancel all bookings if any reservation step fails. This template models the classic saga use case where multiple independent services must either all succeed or all roll back, ensuring travelers never end up with partial bookings. Perfect for demonstrating saga patterns with a real-world business scenario.", + "source_path": "", + "repo_path": "ai-orchestration/architecture/saga-travel-booking-architecture" +} diff --git a/ai-orchestration/architecture/saga-travel-booking-architecture/workflow.fz b/ai-orchestration/architecture/saga-travel-booking-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..e542641486eaadf0dc64f48c825616acbf82ebce --- /dev/null +++ b/ai-orchestration/architecture/saga-travel-booking-architecture/workflow.fz @@ -0,0 +1,57 @@ +BookingAPI { # Booking API +n1: circle label:"Book Travel Package" +n2: rectangle label:"Validate Booking Request" +n3: rectangle label:"Start Booking Saga" +n24: rectangle label:"Return Booking Status" +n25: circle label:"End" +n1.handle(right) -> n2.handle(left) +n2.handle(right) -> n3.handle(left) [label="Valid"] +n3.handle(bottom) -> Saga.n4.handle(top) [label="Execute"] +n24.handle(right) -> n25.handle(left) +} +Saga { # Saga Orchestrator +n4: rectangle label:"Step 1: Book Flight" +n9: rectangle label:"Step 2: Book Hotel" +n14: rectangle label:"Step 3: Book Car Rental" +n19: diamond label:"All Bookings OK?" +n20: rectangle label:"Confirm All Reservations" +n21: rectangle label:"Compensate Failed Steps" +n22: rectangle label:"Send Confirmed" +n23: rectangle label:"Send Cancelled" +n4.handle(bottom) -> FlightService.n5.handle(top) [label="Reserve"] +n9.handle(bottom) -> HotelService.n10.handle(top) [label="Reserve"] +n14.handle(bottom) -> CarService.n15.handle(top) [label="Reserve"] +n19.handle(right) -> n20.handle(left) [label="All Success"] +n19.handle(bottom) -> n21.handle(top) [label="Any Failed"] +n20.handle(right) -> n22.handle(left) +n21.handle(right) -> n23.handle(left) +n22.handle(top) -> BookingAPI.n24.handle(bottom) [label="Confirmed"] +n23.handle(top) -> BookingAPI.n24.handle(bottom) [label="Cancelled"] +} +FlightService { # Flight Service +n5: rectangle label:"Reserve Flight Seat" +n6: rectangle label:"Send Flight Result" +n7: rectangle label:"Forward Flight ID" +n8: rectangle label:"Cancel Flight (Compensate)" +n5.handle(right) -> n6.handle(left) +n6.handle(right) -> n7.handle(left) +n7.handle(top) -> Saga.n9.handle(bottom) [label="Flight OK"] +} +HotelService { # Hotel Service +n10: rectangle label:"Reserve Hotel Room" +n11: rectangle label:"Send Hotel Result" +n12: rectangle label:"Forward Hotel ID" +n13: rectangle label:"Cancel Hotel (Compensate)" +n10.handle(right) -> n11.handle(left) +n11.handle(right) -> n12.handle(left) +n12.handle(top) -> Saga.n14.handle(bottom) [label="Hotel OK"] +} +CarService { # Car Rental Service +n15: rectangle label:"Reserve Car" +n16: rectangle label:"Send Car Result" +n17: rectangle label:"Forward Car ID" +n18: rectangle label:"Cancel Car (Compensate)" +n15.handle(right) -> n16.handle(left) +n16.handle(right) -> n17.handle(left) +n17.handle(top) -> Saga.n19.handle(bottom) [label="Car OK"] +} diff --git a/ai-orchestration/patterns/fan-out-fan-in-workflow/README.md b/ai-orchestration/patterns/fan-out-fan-in-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..5a6b803407fb57334af7599af9612660c502cb19 --- /dev/null +++ b/ai-orchestration/patterns/fan-out-fan-in-workflow/README.md @@ -0,0 +1,19 @@ +# Fan Out Fan In Workflow + +Fan-out/fan-in pattern with work distribution to parallel workers, concurrent execution, result aggregation, and error handling for partial failures. + +**Template ID:** `fan-out-fan-in-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** ai-orchestration +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 13 +**Lanes:** 4 +**Tags:** [fan-out-fan-in, scatter-gather, parallel-processing, aggregation, map-reduce, concurrency] +**Source path:** `patterns/fan-out-fan-in` +**Repo path:** `ai-orchestration/patterns/fan-out-fan-in-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/ai-orchestration/patterns/fan-out-fan-in-workflow/metadata.json b/ai-orchestration/patterns/fan-out-fan-in-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..035bc85d60403993f10f1a51232c9ba366adba23 --- /dev/null +++ b/ai-orchestration/patterns/fan-out-fan-in-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "fan-out-fan-in-workflow", + "workflow_id": "fan-out-fan-in", + "title": "Fan Out Fan In Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "ai-orchestration", + "secondary_use_cases": [], + "use_cases": [ + "ai-orchestration" + ], + "complexity": 4, + "num_nodes": 13, + "num_lanes": 4, + "tags": [ + "fan-out-fan-in", + "scatter-gather", + "parallel-processing", + "aggregation", + "map-reduce", + "concurrency" + ], + "description": "Fan-out/fan-in pattern with work distribution to parallel workers, concurrent execution, result aggregation, and error handling for partial failures.", + "source_path": "patterns/fan-out-fan-in", + "repo_path": "ai-orchestration/patterns/fan-out-fan-in-workflow" +} diff --git a/patterns/fan-out-fan-in/workflow.fz b/ai-orchestration/patterns/fan-out-fan-in-workflow/workflow.fz similarity index 100% rename from patterns/fan-out-fan-in/workflow.fz rename to ai-orchestration/patterns/fan-out-fan-in-workflow/workflow.fz diff --git a/approval/architecture/saga-order-fulfillment-architecture/README.md b/approval/architecture/saga-order-fulfillment-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..5a91f4ac91581053989cb083778a1b9fa5ea31e4 --- /dev/null +++ b/approval/architecture/saga-order-fulfillment-architecture/README.md @@ -0,0 +1,19 @@ +# Saga Order Fulfillment Architecture + +An order fulfillment saga architecture diagram with four sequential steps: customer verification, inventory reservation, payment authorization, and shipment creation, with a compensation chain that reverses completed steps on failure. This template models the end-to-end order lifecycle as a saga, showing how each service participates in the transaction and how compensating actions maintain data consistency. Ideal for e-commerce architects designing reliable order processing pipelines. + +**Template ID:** `saga-order-fulfillment-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** approval +**Secondary use cases:** billing, security +**Complexity:** 4/5 +**Nodes:** 18 +**Lanes:** 3 +**Tags:** [order-fulfillment, saga-pattern, e-commerce, payment-authorization, inventory-reservation, compensation-chain, distributed-transaction, architecture-diagram] +**Source path:** `` +**Repo path:** `approval/architecture/saga-order-fulfillment-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/approval/architecture/saga-order-fulfillment-architecture/metadata.json b/approval/architecture/saga-order-fulfillment-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..029475d6506c9bf25e846669acc5ef33a76460c0 --- /dev/null +++ b/approval/architecture/saga-order-fulfillment-architecture/metadata.json @@ -0,0 +1,33 @@ +{ + "template_id": "saga-order-fulfillment-architecture", + "workflow_id": "saga-order-fulfillment-architecture", + "title": "Saga Order Fulfillment Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "approval", + "secondary_use_cases": [ + "billing", + "security" + ], + "use_cases": [ + "approval", + "billing", + "security" + ], + "complexity": 4, + "num_nodes": 18, + "num_lanes": 3, + "tags": [ + "order-fulfillment", + "saga-pattern", + "e-commerce", + "payment-authorization", + "inventory-reservation", + "compensation-chain", + "distributed-transaction", + "architecture-diagram" + ], + "description": "An order fulfillment saga architecture diagram with four sequential steps: customer verification, inventory reservation, payment authorization, and shipment creation, with a compensation chain that reverses completed steps on failure. This template models the end-to-end order lifecycle as a saga, showing how each service participates in the transaction and how compensating actions maintain data consistency. Ideal for e-commerce architects designing reliable order processing pipelines.", + "source_path": "", + "repo_path": "approval/architecture/saga-order-fulfillment-architecture" +} diff --git a/approval/architecture/saga-order-fulfillment-architecture/workflow.fz b/approval/architecture/saga-order-fulfillment-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..f9e9f5f03789bac14a331ed2fad1776f7698b78d --- /dev/null +++ b/approval/architecture/saga-order-fulfillment-architecture/workflow.fz @@ -0,0 +1,70 @@ +OrderSaga { # Order Fulfillment Saga +n1: circle label:"Order Received" +n2: rectangle label:"Validate Order" +n3: rectangle label:"Step 1: Verify Customer" +n8: rectangle label:"Step 2: Check Inventory" +n13: rectangle label:"Step 3: Authorize Payment" +n18: rectangle label:"Step 4: Ship Order" +n23: diamond label:"Saga Complete?" +n24: rectangle label:"Finalize Order" +n25: rectangle label:"Trigger Compensation Chain" +n26: circle label:"Order Fulfilled" +n32: rectangle label:"Rollback Confirmed" +n1.handle(right) -> n2.handle(left) +n2.handle(right) -> n3.handle(left) [label="Valid"] +n3.handle(bottom) -> Services.n4.handle(top) [label="Verify"] +n8.handle(bottom) -> Services.n9.handle(top) [label="Reserve"] +n13.handle(bottom) -> Services.n14.handle(top) [label="Charge"] +n18.handle(bottom) -> Services.n19.handle(top) [label="Ship"] +n23.handle(right) -> n24.handle(left) [label="Success"] +n23.handle(bottom) -> n25.handle(top) [label="Failure"] +n24.handle(right) -> n26.handle(left) +n25.handle(bottom) -> Compensations.n27.handle(top) [label="Compensate"] +n32.handle(right) -> n26.handle(left) +} +Services { # Participating Services +n4: rectangle label:"Customer Service" +n5: rectangle label:"Verify Customer" +n6: rectangle label:"Send Verification" +n7: rectangle label:"Forward to Saga" +n9: rectangle label:"Inventory Service" +n10: rectangle label:"Reserve Stock" +n11: rectangle label:"Send Reservation" +n12: rectangle label:"Forward to Saga" +n14: rectangle label:"Payment Service" +n15: rectangle label:"Charge Payment" +n16: rectangle label:"Send Charge Result" +n17: rectangle label:"Forward to Saga" +n19: rectangle label:"Shipping Service" +n20: rectangle label:"Ship Order" +n21: rectangle label:"Send Shipment Status" +n22: rectangle label:"Forward to Saga" +n4.handle(right) -> n5.handle(left) +n5.handle(right) -> n6.handle(left) +n6.handle(right) -> n7.handle(left) +n7.handle(top) -> OrderSaga.n8.handle(bottom) [label="Customer OK"] +n9.handle(right) -> n10.handle(left) +n10.handle(right) -> n11.handle(left) +n11.handle(right) -> n12.handle(left) +n12.handle(top) -> OrderSaga.n13.handle(bottom) [label="Reserved"] +n14.handle(right) -> n15.handle(left) +n15.handle(right) -> n16.handle(left) +n16.handle(right) -> n17.handle(left) +n17.handle(top) -> OrderSaga.n18.handle(bottom) [label="Charged"] +n19.handle(right) -> n20.handle(left) +n20.handle(right) -> n21.handle(left) +n21.handle(right) -> n22.handle(left) +n22.handle(top) -> OrderSaga.n23.handle(bottom) [label="Shipped"] +} +Compensations { # Compensation Actions +n27: rectangle label:"Reverse Payment" +n28: rectangle label:"Release Inventory" +n29: rectangle label:"Notify Customer" +n30: rectangle label:"Notify Saga" +n31: rectangle label:"Send Rollback Status" +n27.handle(right) -> n28.handle(left) [label="Refund"] +n28.handle(right) -> n29.handle(left) [label="Unreserve"] +n29.handle(right) -> n30.handle(left) [label="Apology Email"] +n30.handle(right) -> n31.handle(left) +n31.handle(top) -> OrderSaga.n32.handle(bottom) [label="Rollback Complete"] +} diff --git a/approval/business-operations/billing-dispute-workflow/README.md b/approval/business-operations/billing-dispute-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..d670797ffb04dba51bf8f7db506be80fcdde1c4b --- /dev/null +++ b/approval/business-operations/billing-dispute-workflow/README.md @@ -0,0 +1,19 @@ +# Billing Dispute Workflow + +Billing dispute workflow with dispute intake, transaction review, fraud analysis, resolution decision, and chargeback response handling. + +**Template ID:** `billing-dispute-workflow` +**Kind:** workflow +**Source domain:** business-operations +**Primary use case:** approval +**Secondary use cases:** billing +**Complexity:** 4/5 +**Nodes:** 13 +**Lanes:** 4 +**Tags:** [billing-dispute, chargeback, refund-request, dispute-resolution, fraud-review, stripe] +**Source path:** `business-operations/billing-dispute` +**Repo path:** `approval/business-operations/billing-dispute-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/approval/business-operations/billing-dispute-workflow/metadata.json b/approval/business-operations/billing-dispute-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..5fbdb7fcd83189c8c45cd6958b86235532ad1538 --- /dev/null +++ b/approval/business-operations/billing-dispute-workflow/metadata.json @@ -0,0 +1,29 @@ +{ + "template_id": "billing-dispute-workflow", + "workflow_id": "billing-dispute", + "title": "Billing Dispute Workflow", + "kind": "workflow", + "source_domain": "business-operations", + "primary_use_case": "approval", + "secondary_use_cases": [ + "billing" + ], + "use_cases": [ + "approval", + "billing" + ], + "complexity": 4, + "num_nodes": 13, + "num_lanes": 4, + "tags": [ + "billing-dispute", + "chargeback", + "refund-request", + "dispute-resolution", + "fraud-review", + "stripe" + ], + "description": "Billing dispute workflow with dispute intake, transaction review, fraud analysis, resolution decision, and chargeback response handling.", + "source_path": "business-operations/billing-dispute", + "repo_path": "approval/business-operations/billing-dispute-workflow" +} diff --git a/business-operations/billing-dispute/workflow.fz b/approval/business-operations/billing-dispute-workflow/workflow.fz similarity index 100% rename from business-operations/billing-dispute/workflow.fz rename to approval/business-operations/billing-dispute-workflow/workflow.fz diff --git a/approval/business-operations/oauth-flow-workflow/README.md b/approval/business-operations/oauth-flow-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..bf7f2b84e029f0421fdf10d4a98c3203fc7e95d1 --- /dev/null +++ b/approval/business-operations/oauth-flow-workflow/README.md @@ -0,0 +1,19 @@ +# Oauth Flow Workflow + +OAuth 2.0 authorization code flow with redirect handling, code exchange, token storage, refresh token rotation, and scope management. + +**Template ID:** `oauth-flow-workflow` +**Kind:** workflow +**Source domain:** business-operations +**Primary use case:** approval +**Secondary use cases:** security +**Complexity:** 4/5 +**Nodes:** 13 +**Lanes:** 4 +**Tags:** [oauth-flow, oauth2, authorization-code, token-exchange, sso, third-party-auth] +**Source path:** `business-operations/oauth-flow` +**Repo path:** `approval/business-operations/oauth-flow-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/approval/business-operations/oauth-flow-workflow/metadata.json b/approval/business-operations/oauth-flow-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..b7f6670a231b29658f9f45f3923485cfe3be11b3 --- /dev/null +++ b/approval/business-operations/oauth-flow-workflow/metadata.json @@ -0,0 +1,29 @@ +{ + "template_id": "oauth-flow-workflow", + "workflow_id": "oauth-flow", + "title": "Oauth Flow Workflow", + "kind": "workflow", + "source_domain": "business-operations", + "primary_use_case": "approval", + "secondary_use_cases": [ + "security" + ], + "use_cases": [ + "approval", + "security" + ], + "complexity": 4, + "num_nodes": 13, + "num_lanes": 4, + "tags": [ + "oauth-flow", + "oauth2", + "authorization-code", + "token-exchange", + "sso", + "third-party-auth" + ], + "description": "OAuth 2.0 authorization code flow with redirect handling, code exchange, token storage, refresh token rotation, and scope management.", + "source_path": "business-operations/oauth-flow", + "repo_path": "approval/business-operations/oauth-flow-workflow" +} diff --git a/business-operations/oauth-flow/workflow.fz b/approval/business-operations/oauth-flow-workflow/workflow.fz similarity index 100% rename from business-operations/oauth-flow/workflow.fz rename to approval/business-operations/oauth-flow-workflow/workflow.fz diff --git a/approval/business-operations/review-collection-workflow/README.md b/approval/business-operations/review-collection-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..810c185dcbc3d59504292a06b1ea7f991d7e159b --- /dev/null +++ b/approval/business-operations/review-collection-workflow/README.md @@ -0,0 +1,19 @@ +# Review Collection Workflow + +Customer review collection workflow with post-purchase trigger, review request email, rating submission, moderation, and public display. + +**Template ID:** `review-collection-workflow` +**Kind:** workflow +**Source domain:** business-operations +**Primary use case:** approval +**Secondary use cases:** None +**Complexity:** 2/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [review-collection, customer-feedback, nps, ratings, social-proof, testimonials] +**Source path:** `business-operations/review-collection` +**Repo path:** `approval/business-operations/review-collection-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/approval/business-operations/review-collection-workflow/metadata.json b/approval/business-operations/review-collection-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..b4113760120c2fcd93b809e4908b008f35b9205f --- /dev/null +++ b/approval/business-operations/review-collection-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "review-collection-workflow", + "workflow_id": "review-collection", + "title": "Review Collection Workflow", + "kind": "workflow", + "source_domain": "business-operations", + "primary_use_case": "approval", + "secondary_use_cases": [], + "use_cases": [ + "approval" + ], + "complexity": 2, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "review-collection", + "customer-feedback", + "nps", + "ratings", + "social-proof", + "testimonials" + ], + "description": "Customer review collection workflow with post-purchase trigger, review request email, rating submission, moderation, and public display.", + "source_path": "business-operations/review-collection", + "repo_path": "approval/business-operations/review-collection-workflow" +} diff --git a/business-operations/review-collection/workflow.fz b/approval/business-operations/review-collection-workflow/workflow.fz similarity index 95% rename from business-operations/review-collection/workflow.fz rename to approval/business-operations/review-collection-workflow/workflow.fz index 02c21643b602a325f6a5a775113f7dac434385e2..afd5e5c6b3c87e1e3a6fb6ecfc10de827a4a5320 100644 --- a/business-operations/review-collection/workflow.fz +++ b/approval/business-operations/review-collection-workflow/workflow.fz @@ -6,7 +6,8 @@ n8nSchedule { # n8n Schedule Trigger n5: circle label:"End" n1.handle(right) -> n2.handle(left) n2.handle(right) -> n3.handle(left) - n3.handle(bottom) -> n8nFilter.n6.handle(top) [label="Orders list"] + n3.handle(right) -> n4.handle(left) + n4.handle(bottom) -> n8nFilter.n6.handle(top) [label="Filtered orders"] } n8nFilter { # n8n Filter Node diff --git a/approval/devops/access-review-workflow/README.md b/approval/devops/access-review-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..72d766ec8a7892c62bd7d56a338c7e0edee38968 --- /dev/null +++ b/approval/devops/access-review-workflow/README.md @@ -0,0 +1,19 @@ +# Access Review Workflow + +Quarterly user access review workflow with manager certification, separation of duties validation, remediation tracking, and compliance reporting for audit purposes. + +**Template ID:** `access-review-workflow` +**Kind:** workflow +**Source domain:** devops +**Primary use case:** approval +**Secondary use cases:** compliance +**Complexity:** 4/5 +**Nodes:** 18 +**Lanes:** 3 +**Tags:** [access-review, user-access-certification, quarterly-review, manager-approval, compliance, sod-violations, audit] +**Source path:** `devops/access-review` +**Repo path:** `approval/devops/access-review-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/approval/devops/access-review-workflow/metadata.json b/approval/devops/access-review-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..758a378d1c1706eefb8b4519d4a9c0e5b2d2185e --- /dev/null +++ b/approval/devops/access-review-workflow/metadata.json @@ -0,0 +1,30 @@ +{ + "template_id": "access-review-workflow", + "workflow_id": "access-review", + "title": "Access Review Workflow", + "kind": "workflow", + "source_domain": "devops", + "primary_use_case": "approval", + "secondary_use_cases": [ + "compliance" + ], + "use_cases": [ + "approval", + "compliance" + ], + "complexity": 4, + "num_nodes": 18, + "num_lanes": 3, + "tags": [ + "access-review", + "user-access-certification", + "quarterly-review", + "manager-approval", + "compliance", + "sod-violations", + "audit" + ], + "description": "Quarterly user access review workflow with manager certification, separation of duties validation, remediation tracking, and compliance reporting for audit purposes.", + "source_path": "devops/access-review", + "repo_path": "approval/devops/access-review-workflow" +} diff --git a/devops/access-review/workflow.fz b/approval/devops/access-review-workflow/workflow.fz similarity index 100% rename from devops/access-review/workflow.fz rename to approval/devops/access-review-workflow/workflow.fz diff --git a/approval/devops/database-migration-workflow/README.md b/approval/devops/database-migration-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..6be2a2107d1c84b145b9af3926b253f7787e3b83 --- /dev/null +++ b/approval/devops/database-migration-workflow/README.md @@ -0,0 +1,19 @@ +# Database Migration Workflow + +Database schema migration workflow with CI testing, DBA review and approval, maintenance window scheduling, backup snapshots, migration execution, data integrity verification, and automatic rollback. + +**Template ID:** `database-migration-workflow` +**Kind:** workflow +**Source domain:** devops +**Primary use case:** approval +**Secondary use cases:** delivery +**Complexity:** 4/5 +**Nodes:** 20 +**Lanes:** 4 +**Tags:** [database-migration, schema-changes, flyway, liquibase, rollback, dba-approval, maintenance-window] +**Source path:** `devops/database-migration` +**Repo path:** `approval/devops/database-migration-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/devops/database-migration/metadata.json b/approval/devops/database-migration-workflow/metadata.json similarity index 51% rename from devops/database-migration/metadata.json rename to approval/devops/database-migration-workflow/metadata.json index 4f70455354eab02897b83947ecc2dac2b537f4be..3cdb7621272883bf1b0b9497adeabd9ec604af10 100644 --- a/devops/database-migration/metadata.json +++ b/approval/devops/database-migration-workflow/metadata.json @@ -1,6 +1,17 @@ { + "template_id": "database-migration-workflow", "workflow_id": "database-migration", - "domain": "devops", + "title": "Database Migration Workflow", + "kind": "workflow", + "source_domain": "devops", + "primary_use_case": "approval", + "secondary_use_cases": [ + "delivery" + ], + "use_cases": [ + "approval", + "delivery" + ], "complexity": 4, "num_nodes": 20, "num_lanes": 4, @@ -13,5 +24,7 @@ "dba-approval", "maintenance-window" ], - "description": "Database schema migration workflow with CI testing, DBA review and approval, maintenance window scheduling, backup snapshots, migration execution, data integrity verification, and automatic rollback." -} \ No newline at end of file + "description": "Database schema migration workflow with CI testing, DBA review and approval, maintenance window scheduling, backup snapshots, migration execution, data integrity verification, and automatic rollback.", + "source_path": "devops/database-migration", + "repo_path": "approval/devops/database-migration-workflow" +} diff --git a/devops/database-migration/workflow.fz b/approval/devops/database-migration-workflow/workflow.fz similarity index 100% rename from devops/database-migration/workflow.fz rename to approval/devops/database-migration-workflow/workflow.fz diff --git a/approval/finance/budget-approval-workflow/README.md b/approval/finance/budget-approval-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..b898918a3c2e62dc8774289a34cfea9b3f875adc --- /dev/null +++ b/approval/finance/budget-approval-workflow/README.md @@ -0,0 +1,19 @@ +# Budget Approval Workflow + +Corporate budget approval workflow with tiered approval routing based on amount thresholds (CFO < $100K, CEO $100K-$1M, Board > $1M), prior year comparison, and fund allocation. + +**Template ID:** `budget-approval-workflow` +**Kind:** workflow +**Source domain:** finance +**Primary use case:** approval +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 19 +**Lanes:** 3 +**Tags:** [budget-approval, financial-planning, tiered-approval, cfo-approval, ceo-approval, board-approval, fund-allocation] +**Source path:** `finance/budget-approval` +**Repo path:** `approval/finance/budget-approval-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/finance/budget-approval/metadata.json b/approval/finance/budget-approval-workflow/metadata.json similarity index 56% rename from finance/budget-approval/metadata.json rename to approval/finance/budget-approval-workflow/metadata.json index 6d9f7d8e88f536019df33f3406b364ffa0bfaa42..3faa676e63f33cf60ee72992ca2a72ac23751b4d 100644 --- a/finance/budget-approval/metadata.json +++ b/approval/finance/budget-approval-workflow/metadata.json @@ -1,6 +1,14 @@ { + "template_id": "budget-approval-workflow", "workflow_id": "budget-approval", - "domain": "finance", + "title": "Budget Approval Workflow", + "kind": "workflow", + "source_domain": "finance", + "primary_use_case": "approval", + "secondary_use_cases": [], + "use_cases": [ + "approval" + ], "complexity": 4, "num_nodes": 19, "num_lanes": 3, @@ -13,5 +21,7 @@ "board-approval", "fund-allocation" ], - "description": "Corporate budget approval workflow with tiered approval routing based on amount thresholds (CFO < $100K, CEO $100K-$1M, Board > $1M), prior year comparison, and fund allocation." -} \ No newline at end of file + "description": "Corporate budget approval workflow with tiered approval routing based on amount thresholds (CFO < $100K, CEO $100K-$1M, Board > $1M), prior year comparison, and fund allocation.", + "source_path": "finance/budget-approval", + "repo_path": "approval/finance/budget-approval-workflow" +} diff --git a/finance/budget-approval/workflow.fz b/approval/finance/budget-approval-workflow/workflow.fz similarity index 100% rename from finance/budget-approval/workflow.fz rename to approval/finance/budget-approval-workflow/workflow.fz diff --git a/approval/finance/expense-claim-workflow/README.md b/approval/finance/expense-claim-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..172cba5a9527a104de968b3944aeea8bc0619cd8 --- /dev/null +++ b/approval/finance/expense-claim-workflow/README.md @@ -0,0 +1,19 @@ +# Expense Claim Workflow + +Employee expense reimbursement workflow with receipt submission, manager approval, finance review, policy compliance check, and direct deposit payment. + +**Template ID:** `expense-claim-workflow` +**Kind:** workflow +**Source domain:** finance +**Primary use case:** approval +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [expense-reimbursement, employee-expenses, receipt-upload, manager-approval, finance-review, direct-deposit] +**Source path:** `finance/expense-claim` +**Repo path:** `approval/finance/expense-claim-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/finance/expense-claim/metadata.json b/approval/finance/expense-claim-workflow/metadata.json similarity index 50% rename from finance/expense-claim/metadata.json rename to approval/finance/expense-claim-workflow/metadata.json index 957e8c6fb902328155f717eaa0677c420e416ff1..f40a8d7bc817f50f0ec47e8ddea3d40e926b8b83 100644 --- a/finance/expense-claim/metadata.json +++ b/approval/finance/expense-claim-workflow/metadata.json @@ -1,6 +1,14 @@ { + "template_id": "expense-claim-workflow", "workflow_id": "expense-claim", - "domain": "finance", + "title": "Expense Claim Workflow", + "kind": "workflow", + "source_domain": "finance", + "primary_use_case": "approval", + "secondary_use_cases": [], + "use_cases": [ + "approval" + ], "complexity": 3, "num_nodes": 10, "num_lanes": 3, @@ -12,5 +20,7 @@ "finance-review", "direct-deposit" ], - "description": "Employee expense reimbursement workflow with receipt submission, manager approval, finance review, policy compliance check, and direct deposit payment." -} \ No newline at end of file + "description": "Employee expense reimbursement workflow with receipt submission, manager approval, finance review, policy compliance check, and direct deposit payment.", + "source_path": "finance/expense-claim", + "repo_path": "approval/finance/expense-claim-workflow" +} diff --git a/finance/expense-claim/workflow.fz b/approval/finance/expense-claim-workflow/workflow.fz similarity index 100% rename from finance/expense-claim/workflow.fz rename to approval/finance/expense-claim-workflow/workflow.fz diff --git a/approval/finance/insurance-claim-workflow/README.md b/approval/finance/insurance-claim-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..218131346d351ebda6df828e3d5b763d0603bf87 --- /dev/null +++ b/approval/finance/insurance-claim-workflow/README.md @@ -0,0 +1,19 @@ +# Insurance Claim Workflow + +Insurance claim processing workflow with incident documentation, claim filing, adjuster assignment, damage assessment, and settlement negotiation. + +**Template ID:** `insurance-claim-workflow` +**Kind:** workflow +**Source domain:** finance +**Primary use case:** approval +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [insurance-claim, claim-filing, adjuster-review, settlement, property-damage, liability] +**Source path:** `finance/insurance-claim` +**Repo path:** `approval/finance/insurance-claim-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/approval/finance/insurance-claim-workflow/metadata.json b/approval/finance/insurance-claim-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..c3f21aa71fce27975f52cd062ae5c5e5ee7e6f57 --- /dev/null +++ b/approval/finance/insurance-claim-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "insurance-claim-workflow", + "workflow_id": "insurance-claim", + "title": "Insurance Claim Workflow", + "kind": "workflow", + "source_domain": "finance", + "primary_use_case": "approval", + "secondary_use_cases": [], + "use_cases": [ + "approval" + ], + "complexity": 3, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "insurance-claim", + "claim-filing", + "adjuster-review", + "settlement", + "property-damage", + "liability" + ], + "description": "Insurance claim processing workflow with incident documentation, claim filing, adjuster assignment, damage assessment, and settlement negotiation.", + "source_path": "finance/insurance-claim", + "repo_path": "approval/finance/insurance-claim-workflow" +} diff --git a/finance/insurance-claim/workflow.fz b/approval/finance/insurance-claim-workflow/workflow.fz similarity index 100% rename from finance/insurance-claim/workflow.fz rename to approval/finance/insurance-claim-workflow/workflow.fz diff --git a/approval/finance/invoice-processing-workflow/README.md b/approval/finance/invoice-processing-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..8566e00f99222a9725bc219349886fb52108d1d8 --- /dev/null +++ b/approval/finance/invoice-processing-workflow/README.md @@ -0,0 +1,19 @@ +# Invoice Processing Workflow + +Accounts payable invoice automation with OCR data extraction, three-way PO matching, tiered approval workflow, and automated payment processing with GL updates. + +**Template ID:** `invoice-processing-workflow` +**Kind:** workflow +**Source domain:** finance +**Primary use case:** approval +**Secondary use cases:** billing +**Complexity:** 4/5 +**Nodes:** 19 +**Lanes:** 4 +**Tags:** [accounts-payable, invoice-automation, ocr, po-matching, approval-workflow, payment-processing, three-way-match] +**Source path:** `finance/invoice-processing` +**Repo path:** `approval/finance/invoice-processing-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/approval/finance/invoice-processing-workflow/metadata.json b/approval/finance/invoice-processing-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..842feff47f9bd65f0589ecc2ffec940a0bd520d5 --- /dev/null +++ b/approval/finance/invoice-processing-workflow/metadata.json @@ -0,0 +1,30 @@ +{ + "template_id": "invoice-processing-workflow", + "workflow_id": "invoice-processing", + "title": "Invoice Processing Workflow", + "kind": "workflow", + "source_domain": "finance", + "primary_use_case": "approval", + "secondary_use_cases": [ + "billing" + ], + "use_cases": [ + "approval", + "billing" + ], + "complexity": 4, + "num_nodes": 19, + "num_lanes": 4, + "tags": [ + "accounts-payable", + "invoice-automation", + "ocr", + "po-matching", + "approval-workflow", + "payment-processing", + "three-way-match" + ], + "description": "Accounts payable invoice automation with OCR data extraction, three-way PO matching, tiered approval workflow, and automated payment processing with GL updates.", + "source_path": "finance/invoice-processing", + "repo_path": "approval/finance/invoice-processing-workflow" +} diff --git a/finance/invoice-processing/workflow.fz b/approval/finance/invoice-processing-workflow/workflow.fz similarity index 100% rename from finance/invoice-processing/workflow.fz rename to approval/finance/invoice-processing-workflow/workflow.fz diff --git a/approval/finance/purchase-order-workflow/README.md b/approval/finance/purchase-order-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..0e44cc07064eb631889d1e2a4f2af095be501fd4 --- /dev/null +++ b/approval/finance/purchase-order-workflow/README.md @@ -0,0 +1,19 @@ +# Purchase Order Workflow + +Procurement purchase order workflow with requisition creation, budget validation, vendor sourcing, competitive bidding, and tiered approval routing based on amount thresholds. + +**Template ID:** `purchase-order-workflow` +**Kind:** workflow +**Source domain:** finance +**Primary use case:** approval +**Secondary use cases:** ai-orchestration +**Complexity:** 4/5 +**Nodes:** 22 +**Lanes:** 3 +**Tags:** [purchase-order, procurement, requisition, vendor-sourcing, competitive-bidding, tiered-approval, budget-validation] +**Source path:** `finance/purchase-order` +**Repo path:** `approval/finance/purchase-order-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/finance/purchase-order/metadata.json b/approval/finance/purchase-order-workflow/metadata.json similarity index 54% rename from finance/purchase-order/metadata.json rename to approval/finance/purchase-order-workflow/metadata.json index 93ec9dd95090c6766b0ef19ddc0f3bd98a844fc7..ebe769f5c5fd53e4822a7234b0625578f77a031e 100644 --- a/finance/purchase-order/metadata.json +++ b/approval/finance/purchase-order-workflow/metadata.json @@ -1,6 +1,17 @@ { + "template_id": "purchase-order-workflow", "workflow_id": "purchase-order", - "domain": "finance", + "title": "Purchase Order Workflow", + "kind": "workflow", + "source_domain": "finance", + "primary_use_case": "approval", + "secondary_use_cases": [ + "ai-orchestration" + ], + "use_cases": [ + "approval", + "ai-orchestration" + ], "complexity": 4, "num_nodes": 22, "num_lanes": 3, @@ -13,5 +24,7 @@ "tiered-approval", "budget-validation" ], - "description": "Procurement purchase order workflow with requisition creation, budget validation, vendor sourcing, competitive bidding, and tiered approval routing based on amount thresholds." -} \ No newline at end of file + "description": "Procurement purchase order workflow with requisition creation, budget validation, vendor sourcing, competitive bidding, and tiered approval routing based on amount thresholds.", + "source_path": "finance/purchase-order", + "repo_path": "approval/finance/purchase-order-workflow" +} diff --git a/finance/purchase-order/workflow.fz b/approval/finance/purchase-order-workflow/workflow.fz similarity index 100% rename from finance/purchase-order/workflow.fz rename to approval/finance/purchase-order-workflow/workflow.fz diff --git a/approval/hr/expense-approval-workflow/README.md b/approval/hr/expense-approval-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..d9c1c8ea2af2b5afb8321a6f936ec627f8c04b93 --- /dev/null +++ b/approval/hr/expense-approval-workflow/README.md @@ -0,0 +1,19 @@ +# Expense Approval Workflow + +Employee expense approval workflow with receipt validation, policy compliance check, tiered approval based on amount, and reimbursement processing. + +**Template ID:** `expense-approval-workflow` +**Kind:** workflow +**Source domain:** hr +**Primary use case:** approval +**Secondary use cases:** compliance +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [expense-approval, travel-expenses, receipt-validation, policy-compliance, tiered-approval, reimbursement] +**Source path:** `hr/expense-approval` +**Repo path:** `approval/hr/expense-approval-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/approval/hr/expense-approval-workflow/metadata.json b/approval/hr/expense-approval-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..8db1a51a30b97bb213df1e9ec1c12b7bfec5154e --- /dev/null +++ b/approval/hr/expense-approval-workflow/metadata.json @@ -0,0 +1,29 @@ +{ + "template_id": "expense-approval-workflow", + "workflow_id": "expense-approval", + "title": "Expense Approval Workflow", + "kind": "workflow", + "source_domain": "hr", + "primary_use_case": "approval", + "secondary_use_cases": [ + "compliance" + ], + "use_cases": [ + "approval", + "compliance" + ], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "expense-approval", + "travel-expenses", + "receipt-validation", + "policy-compliance", + "tiered-approval", + "reimbursement" + ], + "description": "Employee expense approval workflow with receipt validation, policy compliance check, tiered approval based on amount, and reimbursement processing.", + "source_path": "hr/expense-approval", + "repo_path": "approval/hr/expense-approval-workflow" +} diff --git a/hr/expense-approval/workflow.fz b/approval/hr/expense-approval-workflow/workflow.fz similarity index 100% rename from hr/expense-approval/workflow.fz rename to approval/hr/expense-approval-workflow/workflow.fz diff --git a/approval/hr/performance-review-workflow/README.md b/approval/hr/performance-review-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..55bef9038a5da5cdbf6c3f026e7024d3e7143b93 --- /dev/null +++ b/approval/hr/performance-review-workflow/README.md @@ -0,0 +1,19 @@ +# Performance Review Workflow + +Annual performance review workflow with self-assessment, manager evaluation, 360 feedback collection, calibration sessions, and merit increase recommendations. + +**Template ID:** `performance-review-workflow` +**Kind:** workflow +**Source domain:** hr +**Primary use case:** approval +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [performance-review, annual-evaluation, goal-setting, 360-feedback, calibration, merit-increase] +**Source path:** `hr/performance-review` +**Repo path:** `approval/hr/performance-review-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/approval/hr/performance-review-workflow/metadata.json b/approval/hr/performance-review-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..e5479a0b6937973d49952285d0d8d726fab60859 --- /dev/null +++ b/approval/hr/performance-review-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "performance-review-workflow", + "workflow_id": "performance-review", + "title": "Performance Review Workflow", + "kind": "workflow", + "source_domain": "hr", + "primary_use_case": "approval", + "secondary_use_cases": [], + "use_cases": [ + "approval" + ], + "complexity": 4, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "performance-review", + "annual-evaluation", + "goal-setting", + "360-feedback", + "calibration", + "merit-increase" + ], + "description": "Annual performance review workflow with self-assessment, manager evaluation, 360 feedback collection, calibration sessions, and merit increase recommendations.", + "source_path": "hr/performance-review", + "repo_path": "approval/hr/performance-review-workflow" +} diff --git a/hr/performance-review/workflow.fz b/approval/hr/performance-review-workflow/workflow.fz similarity index 100% rename from hr/performance-review/workflow.fz rename to approval/hr/performance-review-workflow/workflow.fz diff --git a/approval/hr/pto-request-workflow/README.md b/approval/hr/pto-request-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..712f4c3f24982cd708a5ac4f30a0dfef5c54e47e --- /dev/null +++ b/approval/hr/pto-request-workflow/README.md @@ -0,0 +1,19 @@ +# Pto Request Workflow + +PTO request workflow with balance verification, manager approval, calendar blocking, and team coverage check before approval. + +**Template ID:** `pto-request-workflow` +**Kind:** workflow +**Source domain:** hr +**Primary use case:** approval +**Secondary use cases:** None +**Complexity:** 2/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [pto-request, time-off, vacation, leave-management, manager-approval, accrual-balance] +**Source path:** `hr/pto-request` +**Repo path:** `approval/hr/pto-request-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/hr/pto-request/metadata.json b/approval/hr/pto-request-workflow/metadata.json similarity index 51% rename from hr/pto-request/metadata.json rename to approval/hr/pto-request-workflow/metadata.json index af2429c2cf2c356fc05fe87979df572bf182cc28..f6cf3d3e301512c45f95632bf91818e1dd067df5 100644 --- a/hr/pto-request/metadata.json +++ b/approval/hr/pto-request-workflow/metadata.json @@ -1,6 +1,14 @@ { + "template_id": "pto-request-workflow", "workflow_id": "pto-request", - "domain": "hr", + "title": "Pto Request Workflow", + "kind": "workflow", + "source_domain": "hr", + "primary_use_case": "approval", + "secondary_use_cases": [], + "use_cases": [ + "approval" + ], "complexity": 2, "num_nodes": 7, "num_lanes": 2, @@ -12,5 +20,7 @@ "manager-approval", "accrual-balance" ], - "description": "PTO request workflow with balance verification, manager approval, calendar blocking, and team coverage check before approval." -} \ No newline at end of file + "description": "PTO request workflow with balance verification, manager approval, calendar blocking, and team coverage check before approval.", + "source_path": "hr/pto-request", + "repo_path": "approval/hr/pto-request-workflow" +} diff --git a/hr/pto-request/workflow.fz b/approval/hr/pto-request-workflow/workflow.fz similarity index 100% rename from hr/pto-request/workflow.fz rename to approval/hr/pto-request-workflow/workflow.fz diff --git a/approval/hr/salary-increase-workflow/README.md b/approval/hr/salary-increase-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..f4e1bd18ee777c6662165fe8dbf776353b54f4e8 --- /dev/null +++ b/approval/hr/salary-increase-workflow/README.md @@ -0,0 +1,19 @@ +# Salary Increase Workflow + +Salary increase workflow with market analysis, comp ratio review, budget validation, tiered approval based on increase percentage, and payroll system update. + +**Template ID:** `salary-increase-workflow` +**Kind:** workflow +**Source domain:** hr +**Primary use case:** approval +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [salary-increase, compensation, merit-raise, market-adjustment, budget-approval, comp-ratio] +**Source path:** `hr/salary-increase` +**Repo path:** `approval/hr/salary-increase-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/approval/hr/salary-increase-workflow/metadata.json b/approval/hr/salary-increase-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..925973cf1a503f9d10f18905b7f693c978b197b1 --- /dev/null +++ b/approval/hr/salary-increase-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "salary-increase-workflow", + "workflow_id": "salary-increase", + "title": "Salary Increase Workflow", + "kind": "workflow", + "source_domain": "hr", + "primary_use_case": "approval", + "secondary_use_cases": [], + "use_cases": [ + "approval" + ], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "salary-increase", + "compensation", + "merit-raise", + "market-adjustment", + "budget-approval", + "comp-ratio" + ], + "description": "Salary increase workflow with market analysis, comp ratio review, budget validation, tiered approval based on increase percentage, and payroll system update.", + "source_path": "hr/salary-increase", + "repo_path": "approval/hr/salary-increase-workflow" +} diff --git a/hr/salary-increase/workflow.fz b/approval/hr/salary-increase-workflow/workflow.fz similarity index 100% rename from hr/salary-increase/workflow.fz rename to approval/hr/salary-increase-workflow/workflow.fz diff --git a/approval/hr/termination-process-workflow/README.md b/approval/hr/termination-process-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..9dbf05f1bb0a78d6751129c009d05d2250298270 --- /dev/null +++ b/approval/hr/termination-process-workflow/README.md @@ -0,0 +1,19 @@ +# Termination Process Workflow + +Employee termination workflow handling voluntary and involuntary separations with legal review, separation agreements, final pay calculation, COBRA notices, and severance processing. + +**Template ID:** `termination-process-workflow` +**Kind:** workflow +**Source domain:** hr +**Primary use case:** approval +**Secondary use cases:** offboarding +**Complexity:** 4/5 +**Nodes:** 20 +**Lanes:** 3 +**Tags:** [employee-termination, offboarding, separation-agreement, final-pay, cobra, severance, legal-review] +**Source path:** `hr/termination-process` +**Repo path:** `approval/hr/termination-process-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/hr/termination-process/metadata.json b/approval/hr/termination-process-workflow/metadata.json similarity index 53% rename from hr/termination-process/metadata.json rename to approval/hr/termination-process-workflow/metadata.json index b212103a4a7559039a18d170032fa0d29ab0ed24..a146293f11996b9d8eb5302d50e9e469f6a8a2dc 100644 --- a/hr/termination-process/metadata.json +++ b/approval/hr/termination-process-workflow/metadata.json @@ -1,6 +1,17 @@ { + "template_id": "termination-process-workflow", "workflow_id": "termination-process", - "domain": "hr", + "title": "Termination Process Workflow", + "kind": "workflow", + "source_domain": "hr", + "primary_use_case": "approval", + "secondary_use_cases": [ + "offboarding" + ], + "use_cases": [ + "approval", + "offboarding" + ], "complexity": 4, "num_nodes": 20, "num_lanes": 3, @@ -13,5 +24,7 @@ "severance", "legal-review" ], - "description": "Employee termination workflow handling voluntary and involuntary separations with legal review, separation agreements, final pay calculation, COBRA notices, and severance processing." -} \ No newline at end of file + "description": "Employee termination workflow handling voluntary and involuntary separations with legal review, separation agreements, final pay calculation, COBRA notices, and severance processing.", + "source_path": "hr/termination-process", + "repo_path": "approval/hr/termination-process-workflow" +} diff --git a/hr/termination-process/workflow.fz b/approval/hr/termination-process-workflow/workflow.fz similarity index 100% rename from hr/termination-process/workflow.fz rename to approval/hr/termination-process-workflow/workflow.fz diff --git a/approval/patterns/authorization-flow-workflow/README.md b/approval/patterns/authorization-flow-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..cebe8ef787baa79c01b572b3faa2deb401a867b2 --- /dev/null +++ b/approval/patterns/authorization-flow-workflow/README.md @@ -0,0 +1,19 @@ +# Authorization Flow Workflow + +This workflow models checking user permissions before actions run. + +**Template ID:** `authorization-flow-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** approval +**Secondary use cases:** security +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [authorization, flow, patterns] +**Source path:** `patterns/authorization-flow` +**Repo path:** `approval/patterns/authorization-flow-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/approval/patterns/authorization-flow-workflow/metadata.json b/approval/patterns/authorization-flow-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..f9b6e83a6a8a8c33d505b538691a94b33f92fc3c --- /dev/null +++ b/approval/patterns/authorization-flow-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "authorization-flow-workflow", + "workflow_id": "authorization-flow", + "title": "Authorization Flow Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "approval", + "secondary_use_cases": [ + "security" + ], + "use_cases": [ + "approval", + "security" + ], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "authorization", + "flow", + "patterns" + ], + "description": "This workflow models checking user permissions before actions run.", + "source_path": "patterns/authorization-flow", + "repo_path": "approval/patterns/authorization-flow-workflow" +} diff --git a/patterns/authorization-flow/workflow.fz b/approval/patterns/authorization-flow-workflow/workflow.fz similarity index 100% rename from patterns/authorization-flow/workflow.fz rename to approval/patterns/authorization-flow-workflow/workflow.fz diff --git a/billing/business-operations/dunning-flow-workflow/README.md b/billing/business-operations/dunning-flow-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..30db752472c0492249e7f1ec9a2ac01de6b1f4f6 --- /dev/null +++ b/billing/business-operations/dunning-flow-workflow/README.md @@ -0,0 +1,19 @@ +# Dunning Flow Workflow + +Dunning collection workflow with escalating reminder emails, grace period management, account suspension, and payment recovery tracking. + +**Template ID:** `dunning-flow-workflow` +**Kind:** workflow +**Source domain:** business-operations +**Primary use case:** billing +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [dunning-flow, collections, overdue-payment, payment-reminder, account-suspension, revenue-recovery] +**Source path:** `business-operations/dunning-flow` +**Repo path:** `billing/business-operations/dunning-flow-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/billing/business-operations/dunning-flow-workflow/metadata.json b/billing/business-operations/dunning-flow-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..53f6355d8b6832edf34c2b2da3e358525dc113b6 --- /dev/null +++ b/billing/business-operations/dunning-flow-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "dunning-flow-workflow", + "workflow_id": "dunning-flow", + "title": "Dunning Flow Workflow", + "kind": "workflow", + "source_domain": "business-operations", + "primary_use_case": "billing", + "secondary_use_cases": [], + "use_cases": [ + "billing" + ], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "dunning-flow", + "collections", + "overdue-payment", + "payment-reminder", + "account-suspension", + "revenue-recovery" + ], + "description": "Dunning collection workflow with escalating reminder emails, grace period management, account suspension, and payment recovery tracking.", + "source_path": "business-operations/dunning-flow", + "repo_path": "billing/business-operations/dunning-flow-workflow" +} diff --git a/business-operations/dunning-flow/workflow.fz b/billing/business-operations/dunning-flow-workflow/workflow.fz similarity index 100% rename from business-operations/dunning-flow/workflow.fz rename to billing/business-operations/dunning-flow-workflow/workflow.fz diff --git a/billing/business-operations/payment-failure-workflow/README.md b/billing/business-operations/payment-failure-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..6679fb575593e2088c3c590150ba9acd39a2f5c8 --- /dev/null +++ b/billing/business-operations/payment-failure-workflow/README.md @@ -0,0 +1,19 @@ +# Payment Failure Workflow + +Failed payment recovery workflow with smart retry scheduling, dunning email sequence, payment method update prompts, and involuntary churn prevention. + +**Template ID:** `payment-failure-workflow` +**Kind:** workflow +**Source domain:** business-operations +**Primary use case:** billing +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [payment-failure, dunning, retry-logic, card-decline, revenue-recovery, stripe] +**Source path:** `business-operations/payment-failure` +**Repo path:** `billing/business-operations/payment-failure-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/billing/business-operations/payment-failure-workflow/metadata.json b/billing/business-operations/payment-failure-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..e78ef3a8f6e3dd7931d04d5815f7892370a6f4bc --- /dev/null +++ b/billing/business-operations/payment-failure-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "payment-failure-workflow", + "workflow_id": "payment-failure", + "title": "Payment Failure Workflow", + "kind": "workflow", + "source_domain": "business-operations", + "primary_use_case": "billing", + "secondary_use_cases": [], + "use_cases": [ + "billing" + ], + "complexity": 3, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "payment-failure", + "dunning", + "retry-logic", + "card-decline", + "revenue-recovery", + "stripe" + ], + "description": "Failed payment recovery workflow with smart retry scheduling, dunning email sequence, payment method update prompts, and involuntary churn prevention.", + "source_path": "business-operations/payment-failure", + "repo_path": "billing/business-operations/payment-failure-workflow" +} diff --git a/business-operations/payment-failure/workflow.fz b/billing/business-operations/payment-failure-workflow/workflow.fz similarity index 100% rename from business-operations/payment-failure/workflow.fz rename to billing/business-operations/payment-failure-workflow/workflow.fz diff --git a/billing/business-operations/plan-downgrade-workflow/README.md b/billing/business-operations/plan-downgrade-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..96c0a0c6bef77328e85bd184952e5308ec0a2a15 --- /dev/null +++ b/billing/business-operations/plan-downgrade-workflow/README.md @@ -0,0 +1,19 @@ +# Plan Downgrade Workflow + +Subscription plan downgrade workflow with retention offer, feature restriction warning, data migration handling, and end-of-period scheduling. + +**Template ID:** `plan-downgrade-workflow` +**Kind:** workflow +**Source domain:** business-operations +**Primary use case:** billing +**Secondary use cases:** delivery +**Complexity:** 3/5 +**Nodes:** 13 +**Lanes:** 4 +**Tags:** [plan-downgrade, retention, feature-restriction, data-migration, churn-prevention, billing] +**Source path:** `business-operations/plan-downgrade` +**Repo path:** `billing/business-operations/plan-downgrade-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/billing/business-operations/plan-downgrade-workflow/metadata.json b/billing/business-operations/plan-downgrade-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..62e98786bb21a0e27b75dd3232b5a46cb89f79ef --- /dev/null +++ b/billing/business-operations/plan-downgrade-workflow/metadata.json @@ -0,0 +1,29 @@ +{ + "template_id": "plan-downgrade-workflow", + "workflow_id": "plan-downgrade", + "title": "Plan Downgrade Workflow", + "kind": "workflow", + "source_domain": "business-operations", + "primary_use_case": "billing", + "secondary_use_cases": [ + "delivery" + ], + "use_cases": [ + "billing", + "delivery" + ], + "complexity": 3, + "num_nodes": 13, + "num_lanes": 4, + "tags": [ + "plan-downgrade", + "retention", + "feature-restriction", + "data-migration", + "churn-prevention", + "billing" + ], + "description": "Subscription plan downgrade workflow with retention offer, feature restriction warning, data migration handling, and end-of-period scheduling.", + "source_path": "business-operations/plan-downgrade", + "repo_path": "billing/business-operations/plan-downgrade-workflow" +} diff --git a/business-operations/plan-downgrade/workflow.fz b/billing/business-operations/plan-downgrade-workflow/workflow.fz similarity index 100% rename from business-operations/plan-downgrade/workflow.fz rename to billing/business-operations/plan-downgrade-workflow/workflow.fz diff --git a/billing/business-operations/plan-upgrade-workflow/README.md b/billing/business-operations/plan-upgrade-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..5fde89d6f12ff452ef2f8e67a24d72dfc098fdf6 --- /dev/null +++ b/billing/business-operations/plan-upgrade-workflow/README.md @@ -0,0 +1,19 @@ +# Plan Upgrade Workflow + +Subscription plan upgrade workflow with feature comparison, proration calculation, immediate feature unlock, and billing adjustment. + +**Template ID:** `plan-upgrade-workflow` +**Kind:** workflow +**Source domain:** business-operations +**Primary use case:** billing +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [plan-upgrade, upsell, proration, feature-unlock, expansion-revenue, billing] +**Source path:** `business-operations/plan-upgrade` +**Repo path:** `billing/business-operations/plan-upgrade-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/billing/business-operations/plan-upgrade-workflow/metadata.json b/billing/business-operations/plan-upgrade-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..a5de082940afca563ed8aeec6e2d89f3e3f565da --- /dev/null +++ b/billing/business-operations/plan-upgrade-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "plan-upgrade-workflow", + "workflow_id": "plan-upgrade", + "title": "Plan Upgrade Workflow", + "kind": "workflow", + "source_domain": "business-operations", + "primary_use_case": "billing", + "secondary_use_cases": [], + "use_cases": [ + "billing" + ], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "plan-upgrade", + "upsell", + "proration", + "feature-unlock", + "expansion-revenue", + "billing" + ], + "description": "Subscription plan upgrade workflow with feature comparison, proration calculation, immediate feature unlock, and billing adjustment.", + "source_path": "business-operations/plan-upgrade", + "repo_path": "billing/business-operations/plan-upgrade-workflow" +} diff --git a/business-operations/plan-upgrade/workflow.fz b/billing/business-operations/plan-upgrade-workflow/workflow.fz similarity index 100% rename from business-operations/plan-upgrade/workflow.fz rename to billing/business-operations/plan-upgrade-workflow/workflow.fz diff --git a/billing/business-operations/shopify-universal-commerce-protocol/README.md b/billing/business-operations/shopify-universal-commerce-protocol/README.md new file mode 100644 index 0000000000000000000000000000000000000000..7f6633d476c9280e666457b51433276945c27674 --- /dev/null +++ b/billing/business-operations/shopify-universal-commerce-protocol/README.md @@ -0,0 +1,19 @@ +# Shopify Universal Commerce Protocol + +End-to-end agentic commerce workflow showing how an AI assistant (ChatGPT) orchestrates product search, checkout, and payment through Shopify's Universal Commerce Protocol (UCP) gateway, enabling conversational shopping experiences. + +**Template ID:** `shopify-universal-commerce-protocol` +**Kind:** workflow +**Source domain:** business-operations +**Primary use case:** billing +**Secondary use cases:** agentic +**Complexity:** 4/5 +**Nodes:** 47 +**Lanes:** 5 +**Tags:** [shopify, ucp, universal-commerce-protocol, agentic-commerce, ai-shopping, chatgpt, e-commerce, checkout, payment] +**Source path:** `business-operations/shopify-universal-commerce-protocol` +**Repo path:** `billing/business-operations/shopify-universal-commerce-protocol` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/billing/business-operations/shopify-universal-commerce-protocol/metadata.json b/billing/business-operations/shopify-universal-commerce-protocol/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..a5c7a6f7cbf5375ce97f60382df7ae300cf6874d --- /dev/null +++ b/billing/business-operations/shopify-universal-commerce-protocol/metadata.json @@ -0,0 +1,32 @@ +{ + "template_id": "shopify-universal-commerce-protocol", + "workflow_id": "shopify-universal-commerce-protocol", + "title": "Shopify Universal Commerce Protocol", + "kind": "workflow", + "source_domain": "business-operations", + "primary_use_case": "billing", + "secondary_use_cases": [ + "agentic" + ], + "use_cases": [ + "billing", + "agentic" + ], + "complexity": 4, + "num_nodes": 47, + "num_lanes": 5, + "tags": [ + "shopify", + "ucp", + "universal-commerce-protocol", + "agentic-commerce", + "ai-shopping", + "chatgpt", + "e-commerce", + "checkout", + "payment" + ], + "description": "End-to-end agentic commerce workflow showing how an AI assistant (ChatGPT) orchestrates product search, checkout, and payment through Shopify's Universal Commerce Protocol (UCP) gateway, enabling conversational shopping experiences.", + "source_path": "business-operations/shopify-universal-commerce-protocol", + "repo_path": "billing/business-operations/shopify-universal-commerce-protocol" +} diff --git a/billing/business-operations/shopify-universal-commerce-protocol/workflow.fz b/billing/business-operations/shopify-universal-commerce-protocol/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..8a667d06504c6c66c3a3bce3b81542c9fdd6c529 --- /dev/null +++ b/billing/business-operations/shopify-universal-commerce-protocol/workflow.fz @@ -0,0 +1,107 @@ +HumanShopper { # Human Shopper + n1: circle label:"Start: open ChatGPT" + n2: rectangle label:"Ask for a product" + n14: rectangle label:"Review recommendations" + n15: rectangle label:"Choose a product" + n24: rectangle label:"Provide address & prefs" + n33: rectangle label:"Confirm payment" + n47: circle label:"Order confirmed" + n1.handle(right) -> n2.handle(left) + n2.handle(right) -> ChatGPTAssistant.n3.handle(left) [label="Product request"] + n14.handle(right) -> n15.handle(left) + n15.handle(right) -> ChatGPTAssistant.n16.handle(left) [label="Selected product"] + n24.handle(right) -> ChatGPTAssistant.n25.handle(left) [label="Address & prefs"] + n33.handle(right) -> ChatGPTAssistant.n34.handle(left) [label="Payment confirmed"] +} + +ChatGPTAssistant { # ChatGPT AI Assistant + n3: rectangle label:"Receive request & interpret intent" + n4: rectangle label:"Build structured search query" + n5: rectangle label:"Search via UCP gateway" + n11: rectangle label:"Receive UCP offers" + n12: rectangle label:"Rank & present recommendations" + n13: rectangle label:"Send recommendations to shopper" + n16: rectangle label:"Receive product selection" + n17: rectangle label:"Create checkout session via UCP" + n21: rectangle label:"Receive required checkout fields" + n22: rectangle label:"Ask shopper for missing info" + n23: rectangle label:"(wait for shopper)" + n25: rectangle label:"Receive shopper info" + n26: rectangle label:"Submit buyer details via UCP" + n30: rectangle label:"Receive final order summary" + n31: rectangle label:"Ask shopper to confirm payment" + n32: rectangle label:"(wait for confirmation)" + n34: rectangle label:"Receive payment confirmation" + n35: rectangle label:"Send payment intent via UCP" + n44: rectangle label:"Receive final order status" + n45: rectangle label:"Display confirmation" + n46: rectangle label:"(notify shopper)" + n3.handle(right) -> n4.handle(left) + n4.handle(right) -> n5.handle(left) + n5.handle(right) -> ShopifyUCPGateway.n6.handle(left) [label="Catalog search"] + n11.handle(right) -> n12.handle(left) + n12.handle(right) -> n13.handle(left) + n13.handle(left) -> HumanShopper.n14.handle(right) [label="Recommendations"] + n16.handle(right) -> n17.handle(left) + n17.handle(right) -> ShopifyUCPGateway.n18.handle(left) [label="Create checkout"] + n21.handle(right) -> n22.handle(left) + n22.handle(right) -> n23.handle(left) + n23.handle(left) -> HumanShopper.n24.handle(right) [label="Request address & prefs"] + n25.handle(right) -> n26.handle(left) + n26.handle(right) -> ShopifyUCPGateway.n27.handle(left) [label="Buyer details"] + n30.handle(right) -> n31.handle(left) + n31.handle(right) -> n32.handle(left) + n32.handle(left) -> HumanShopper.n33.handle(right) [label="Confirm payment?"] + n34.handle(right) -> n35.handle(left) + n35.handle(right) -> ShopifyUCPGateway.n36.handle(left) [label="Payment intent"] + n44.handle(right) -> n45.handle(left) + n45.handle(right) -> n46.handle(left) + n46.handle(left) -> HumanShopper.n47.handle(right) [label="Order confirmed"] +} + +ShopifyUCPGateway { # Shopify UCP Gateway + n6: rectangle label:"Normalize search request" + n7: rectangle label:"Query Shopify Store catalog" + n10: rectangle label:"Assemble & return UCP offers" + n18: rectangle label:"Create checkout session" + n19: rectangle label:"Initialize checkout with Store" + n20: rectangle label:"Return required fields" + n27: rectangle label:"Update checkout with buyer data" + n28: rectangle label:"Recalculate totals via Store" + n29: rectangle label:"Return order summary" + n36: rectangle label:"Forward payment authorization" + n38: rectangle label:"Receive payment result" + n39: rectangle label:"Create order in Store" + n42: rectangle label:"Receive order confirmation" + n43: rectangle label:"Return final order status" + n6.handle(right) -> n7.handle(left) + n7.handle(right) -> ShopifyStoreCatalog.n8.handle(left) [label="Catalog query"] + n10.handle(left) -> ChatGPTAssistant.n11.handle(right) [label="UCP offers"] + n18.handle(right) -> n19.handle(left) + n19.handle(right) -> n20.handle(left) + n20.handle(left) -> ChatGPTAssistant.n21.handle(right) [label="Required fields"] + n27.handle(right) -> n28.handle(left) + n28.handle(right) -> n29.handle(left) + n29.handle(left) -> ChatGPTAssistant.n30.handle(right) [label="Order summary"] + n36.handle(right) -> PaymentProcessor.n37.handle(left) [label="Authorize/capture"] + n38.handle(right) -> n39.handle(left) + n39.handle(right) -> ShopifyStoreCatalog.n40.handle(left) [label="Create order"] + n42.handle(right) -> n43.handle(left) + n43.handle(left) -> ChatGPTAssistant.n44.handle(right) [label="Order status"] +} + +ShopifyStoreCatalog { # Shopify Store & Catalog + n8: rectangle label:"Search catalog for products" + n9: rectangle label:"Return matching products" + n40: rectangle label:"Persist order" + n41: rectangle label:"Return order confirmation" + n8.handle(bottom) -> n9.handle(top) + n9.handle(left) -> ShopifyUCPGateway.n10.handle(right) [label="Matching products"] + n40.handle(bottom) -> n41.handle(top) + n41.handle(left) -> ShopifyUCPGateway.n42.handle(right) [label="Order confirmation"] +} + +PaymentProcessor { # Payment Processor + n37: rectangle label:"Authorize & capture payment" + n37.handle(left) -> ShopifyUCPGateway.n38.handle(right) [label="Payment result"] +} diff --git a/billing/business-operations/subscription-lifecycle-workflow/README.md b/billing/business-operations/subscription-lifecycle-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..654d659499f5552604c4186b15633c52a0f986da --- /dev/null +++ b/billing/business-operations/subscription-lifecycle-workflow/README.md @@ -0,0 +1,19 @@ +# Subscription Lifecycle Workflow + +SaaS subscription lifecycle workflow with trial signup, conversion nurturing, payment processing, renewal management, and churn prevention campaigns. + +**Template ID:** `subscription-lifecycle-workflow` +**Kind:** workflow +**Source domain:** business-operations +**Primary use case:** billing +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [subscription-lifecycle, saas, trial-conversion, renewal, churn-prevention, stripe] +**Source path:** `business-operations/subscription-lifecycle` +**Repo path:** `billing/business-operations/subscription-lifecycle-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/billing/business-operations/subscription-lifecycle-workflow/metadata.json b/billing/business-operations/subscription-lifecycle-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..5bcd42a01f47f378fdadb2e83666826e74a8d799 --- /dev/null +++ b/billing/business-operations/subscription-lifecycle-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "subscription-lifecycle-workflow", + "workflow_id": "subscription-lifecycle", + "title": "Subscription Lifecycle Workflow", + "kind": "workflow", + "source_domain": "business-operations", + "primary_use_case": "billing", + "secondary_use_cases": [], + "use_cases": [ + "billing" + ], + "complexity": 4, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "subscription-lifecycle", + "saas", + "trial-conversion", + "renewal", + "churn-prevention", + "stripe" + ], + "description": "SaaS subscription lifecycle workflow with trial signup, conversion nurturing, payment processing, renewal management, and churn prevention campaigns.", + "source_path": "business-operations/subscription-lifecycle", + "repo_path": "billing/business-operations/subscription-lifecycle-workflow" +} diff --git a/business-operations/subscription-lifecycle/workflow.fz b/billing/business-operations/subscription-lifecycle-workflow/workflow.fz similarity index 100% rename from business-operations/subscription-lifecycle/workflow.fz rename to billing/business-operations/subscription-lifecycle-workflow/workflow.fz diff --git a/billing/hr/conflict-resolution-workflow/README.md b/billing/hr/conflict-resolution-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..8accda055522a56c17e9672177458c8d9aaa4b52 --- /dev/null +++ b/billing/hr/conflict-resolution-workflow/README.md @@ -0,0 +1,19 @@ +# Conflict Resolution Workflow + +Workplace conflict resolution workflow with complaint intake, HR investigation, mediation sessions, resolution documentation, and follow-up monitoring. + +**Template ID:** `conflict-resolution-workflow` +**Kind:** workflow +**Source domain:** hr +**Primary use case:** billing +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [conflict-resolution, workplace-dispute, mediation, hr-investigation, employee-relations, grievance] +**Source path:** `hr/conflict-resolution` +**Repo path:** `billing/hr/conflict-resolution-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/billing/hr/conflict-resolution-workflow/metadata.json b/billing/hr/conflict-resolution-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..0d8fedc2ff191796c6683a227473894406406757 --- /dev/null +++ b/billing/hr/conflict-resolution-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "conflict-resolution-workflow", + "workflow_id": "conflict-resolution", + "title": "Conflict Resolution Workflow", + "kind": "workflow", + "source_domain": "hr", + "primary_use_case": "billing", + "secondary_use_cases": [], + "use_cases": [ + "billing" + ], + "complexity": 4, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "conflict-resolution", + "workplace-dispute", + "mediation", + "hr-investigation", + "employee-relations", + "grievance" + ], + "description": "Workplace conflict resolution workflow with complaint intake, HR investigation, mediation sessions, resolution documentation, and follow-up monitoring.", + "source_path": "hr/conflict-resolution", + "repo_path": "billing/hr/conflict-resolution-workflow" +} diff --git a/hr/conflict-resolution/workflow.fz b/billing/hr/conflict-resolution-workflow/workflow.fz similarity index 100% rename from hr/conflict-resolution/workflow.fz rename to billing/hr/conflict-resolution-workflow/workflow.fz diff --git a/billing/logistics/returns-processing-workflow/README.md b/billing/logistics/returns-processing-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..4e25367e65e4a645e9db7119b7748ee9b45fcf7d --- /dev/null +++ b/billing/logistics/returns-processing-workflow/README.md @@ -0,0 +1,19 @@ +# Returns Processing Workflow + +Customer returns processing workflow with RMA generation, return receipt, quality inspection, disposition decision, and refund or exchange processing. + +**Template ID:** `returns-processing-workflow` +**Kind:** workflow +**Source domain:** logistics +**Primary use case:** billing +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [returns-processing, rma, refund, restocking, quality-inspection, reverse-logistics] +**Source path:** `logistics/returns-processing` +**Repo path:** `billing/logistics/returns-processing-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/billing/logistics/returns-processing-workflow/metadata.json b/billing/logistics/returns-processing-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..b646869cd2444b9a71522aaca45b29fa5cba0733 --- /dev/null +++ b/billing/logistics/returns-processing-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "returns-processing-workflow", + "workflow_id": "returns-processing", + "title": "Returns Processing Workflow", + "kind": "workflow", + "source_domain": "logistics", + "primary_use_case": "billing", + "secondary_use_cases": [], + "use_cases": [ + "billing" + ], + "complexity": 3, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "returns-processing", + "rma", + "refund", + "restocking", + "quality-inspection", + "reverse-logistics" + ], + "description": "Customer returns processing workflow with RMA generation, return receipt, quality inspection, disposition decision, and refund or exchange processing.", + "source_path": "logistics/returns-processing", + "repo_path": "billing/logistics/returns-processing-workflow" +} diff --git a/logistics/returns-processing/workflow.fz b/billing/logistics/returns-processing-workflow/workflow.fz similarity index 100% rename from logistics/returns-processing/workflow.fz rename to billing/logistics/returns-processing-workflow/workflow.fz diff --git a/business-operations/ab-test-setup/README.md b/business-operations/ab-test-setup/README.md deleted file mode 100644 index 0467d0a91e7593e79ed21067b3c6580d875c529d..0000000000000000000000000000000000000000 --- a/business-operations/ab-test-setup/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# A/B Test Setup - -A/B test setup workflow with hypothesis definition, variant creation, traffic allocation, statistical analysis, and winner deployment. - -**Domain:** business-operations -**Complexity:** 3/5 -**Tags:** [ab-testing, experimentation, split-testing, statistical-significance, conversion-optimization, optimizely] - -## Lanes -- **Product Team** - Defines hypothesis and variants -- **Experimentation Platform** - Runs test, analyzes results -- **Users** - Experience control or variant - -## Process Flow -1. Define hypothesis and success metric -2. Create control and variant(s) -3. Set traffic allocation percentage -4. Calculate required sample size -5. Launch experiment -6. Collect conversion data -7. Monitor for statistical significance -8. Reach significance or stop early -9. Deploy winning variant diff --git a/business-operations/ab-test-setup/metadata.json b/business-operations/ab-test-setup/metadata.json deleted file mode 100644 index 0d523484c641ae8d58f885e22b04879105c60402..0000000000000000000000000000000000000000 --- a/business-operations/ab-test-setup/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "ab-test-setup", - "domain": "business-operations", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "ab-testing", - "experimentation", - "split-testing", - "statistical-significance", - "conversion-optimization", - "optimizely" - ], - "description": "A/B test setup workflow with hypothesis definition, variant creation, traffic allocation, statistical analysis, and winner deployment." -} \ No newline at end of file diff --git a/business-operations/account-deletion/README.md b/business-operations/account-deletion/README.md deleted file mode 100644 index 246e62eb4cc3e2950048fadc4727b44c1f6c59b8..0000000000000000000000000000000000000000 --- a/business-operations/account-deletion/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# Account Deletion - -Account deletion workflow with cancellation reason capture, retention offer, subscription termination, data cleanup, and confirmation email. - -**Domain:** business-operations -**Complexity:** 3/5 -**Tags:** [account-deletion, user-offboarding, data-cleanup, subscription-cancel, retention-offer, exit-survey] - -## Lanes -- **User** - Requests deletion, provides feedback -- **System** - Processes deletion, cleans up data - -## Process Flow -1. User requests account deletion -2. Present exit survey for feedback -3. Show retention offer (discount, pause) -4. If declined, confirm deletion intent -5. Cancel active subscriptions -6. Revoke API keys and tokens -7. Schedule data deletion -8. Send deletion confirmation -9. Purge data after grace period diff --git a/business-operations/account-deletion/metadata.json b/business-operations/account-deletion/metadata.json deleted file mode 100644 index 18d233cde17d9c4af613f99acab24d7a38a4e907..0000000000000000000000000000000000000000 --- a/business-operations/account-deletion/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "account-deletion", - "domain": "business-operations", - "complexity": 3, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "account-deletion", - "user-offboarding", - "data-cleanup", - "subscription-cancel", - "retention-offer", - "exit-survey" - ], - "description": "Account deletion workflow with cancellation reason capture, retention offer, subscription termination, data cleanup, and confirmation email." -} \ No newline at end of file diff --git a/business-operations/api-key-rotation/README.md b/business-operations/api-key-rotation/README.md deleted file mode 100644 index f7cce99acb512318d7cb818fd8bfff77c9c6bda2..0000000000000000000000000000000000000000 --- a/business-operations/api-key-rotation/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# API Key Rotation - -API key rotation workflow with new key generation, dual-key transition period, client notification, old key deprecation, and audit logging. - -**Domain:** business-operations -**Complexity:** 3/5 -**Tags:** [api-key-rotation, security, credential-management, zero-downtime, secrets-manager, compliance] - -## Lanes -- **Security System** - Generates keys, manages lifecycle -- **Developer Portal** - Displays keys, sends notifications -- **Client Application** - Updates to new key - -## Process Flow -1. Trigger rotation (scheduled or manual) -2. Generate new API key -3. Enable dual-key acceptance period -4. Notify client of new key -5. Client retrieves new key -6. Client updates configuration -7. Monitor old key usage -8. Deprecate old key after grace period -9. Log rotation for audit diff --git a/business-operations/api-key-rotation/metadata.json b/business-operations/api-key-rotation/metadata.json deleted file mode 100644 index 44451a2ee44e7a0fbdcbbbcfb9625efbaf0c9257..0000000000000000000000000000000000000000 --- a/business-operations/api-key-rotation/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "api-key-rotation", - "domain": "business-operations", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "api-key-rotation", - "security", - "credential-management", - "zero-downtime", - "secrets-manager", - "compliance" - ], - "description": "API key rotation workflow with new key generation, dual-key transition period, client notification, old key deprecation, and audit logging." -} \ No newline at end of file diff --git a/business-operations/billing-dispute/README.md b/business-operations/billing-dispute/README.md deleted file mode 100644 index bc1443176c8fc9630fc0c47fb08f77718a4c6ef7..0000000000000000000000000000000000000000 --- a/business-operations/billing-dispute/README.md +++ /dev/null @@ -1,24 +0,0 @@ -# Billing Dispute - -Billing dispute workflow with dispute intake, transaction review, fraud analysis, resolution decision, and chargeback response handling. - -**Domain:** business-operations -**Complexity:** 4/5 -**Tags:** [billing-dispute, chargeback, refund-request, dispute-resolution, fraud-review, stripe] - -## Lanes -- **Customer** - Files dispute -- **Support** - Investigates claim -- **Finance** - Reviews transaction -- **Fraud Team** - Analyzes for fraud - -## Process Flow -1. Receive billing dispute or chargeback -2. Acknowledge receipt to customer -3. Pull transaction and usage records -4. Review for fraud indicators -5. Determine if dispute is valid -6. If valid, process refund -7. If invalid, prepare evidence -8. Submit chargeback response -9. Notify customer of resolution diff --git a/business-operations/billing-dispute/metadata.json b/business-operations/billing-dispute/metadata.json deleted file mode 100644 index 7c856c418ddbc139dff4dd49c9f72d55166d0736..0000000000000000000000000000000000000000 --- a/business-operations/billing-dispute/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "billing-dispute", - "domain": "business-operations", - "complexity": 4, - "num_nodes": 13, - "num_lanes": 4, - "tags": [ - "billing-dispute", - "chargeback", - "refund-request", - "dispute-resolution", - "fraud-review", - "stripe" - ], - "description": "Billing dispute workflow with dispute intake, transaction review, fraud analysis, resolution decision, and chargeback response handling." -} \ No newline at end of file diff --git a/business-operations/cohort-analysis/README.md b/business-operations/cohort-analysis/README.md deleted file mode 100644 index 20a49d1e5904c6f9d9e239b36addf46033702ee4..0000000000000000000000000000000000000000 --- a/business-operations/cohort-analysis/README.md +++ /dev/null @@ -1,24 +0,0 @@ -# Cohort Analysis - -Cohort analysis workflow with user segmentation by signup date, retention curve calculation, LTV projection, and behavioral pattern identification. - -**Domain:** business-operations -**Complexity:** 4/5 -**Tags:** [cohort-analysis, retention-analysis, user-behavior, ltv, churn-prediction, analytics] - -## Lanes -- **Data Pipeline** - Collects and processes user data -- **Analytics Engine** - Calculates cohort metrics -- **Visualization** - Renders retention charts -- **Product Team** - Interprets and acts on insights - -## Process Flow -1. Define cohort criteria (signup week/month) -2. Segment users into cohorts -3. Track activity over time periods -4. Calculate retention rates per cohort -5. Generate retention matrix -6. Identify high/low performing cohorts -7. Correlate with product changes -8. Project lifetime value -9. Report insights to stakeholders diff --git a/business-operations/cohort-analysis/metadata.json b/business-operations/cohort-analysis/metadata.json deleted file mode 100644 index 624c2a0ad5e3e6de0a276d85668bff10bef9983c..0000000000000000000000000000000000000000 --- a/business-operations/cohort-analysis/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "cohort-analysis", - "domain": "business-operations", - "complexity": 4, - "num_nodes": 13, - "num_lanes": 4, - "tags": [ - "cohort-analysis", - "retention-analysis", - "user-behavior", - "ltv", - "churn-prediction", - "analytics" - ], - "description": "Cohort analysis workflow with user segmentation by signup date, retention curve calculation, LTV projection, and behavioral pattern identification." -} \ No newline at end of file diff --git a/business-operations/community-moderation/README.md b/business-operations/community-moderation/README.md deleted file mode 100644 index 9638aa6e57638bc26bfb9d41eaf441dae8f41e37..0000000000000000000000000000000000000000 --- a/business-operations/community-moderation/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# Community Moderation - -Community content moderation workflow with AI auto-flagging, user reports, human review queue, action enforcement, and appeals handling. - -**Domain:** business-operations -**Complexity:** 3/5 -**Tags:** [community-moderation, content-moderation, user-reports, trust-safety, ai-moderation, appeals] - -## Lanes -- **AI/Automation** - Auto-flags violating content -- **Moderator** - Reviews flagged content, takes action - -## Process Flow -1. User posts content -2. AI scans for policy violations -3. Auto-remove clear violations -4. Queue borderline content for review -5. User reports also enter queue -6. Moderator reviews flagged content -7. Take action (remove, warn, ban) -8. Notify user of action -9. Handle appeals if submitted diff --git a/business-operations/community-moderation/metadata.json b/business-operations/community-moderation/metadata.json deleted file mode 100644 index 74faf9b9db8991ca3521ab5c4781fdc9d6f012c1..0000000000000000000000000000000000000000 --- a/business-operations/community-moderation/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "community-moderation", - "domain": "business-operations", - "complexity": 3, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "community-moderation", - "content-moderation", - "user-reports", - "trust-safety", - "ai-moderation", - "appeals" - ], - "description": "Community content moderation workflow with AI auto-flagging, user reports, human review queue, action enforcement, and appeals handling." -} \ No newline at end of file diff --git a/business-operations/consent-management/README.md b/business-operations/consent-management/README.md deleted file mode 100644 index 204c6020a88b370e790e6d35ef6edc1e469932d9..0000000000000000000000000000000000000000 --- a/business-operations/consent-management/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# Consent Management - -User consent management workflow with cookie banner, preference center, consent recording, downstream system sync, and audit trail. - -**Domain:** business-operations -**Complexity:** 3/5 -**Tags:** [consent-management, gdpr, cookie-consent, privacy-preferences, opt-in-opt-out, compliance] - -## Lanes -- **User** - Views banner, sets preferences -- **Consent Platform** - Records and syncs consent - -## Process Flow -1. User visits site/app -2. Display cookie consent banner -3. User selects preferences (essential, analytics, marketing) -4. Record consent with timestamp -5. Store consent proof for audit -6. Sync preferences to analytics tools -7. Block non-consented tracking -8. Allow preference updates anytime -9. Re-prompt on policy changes diff --git a/business-operations/consent-management/metadata.json b/business-operations/consent-management/metadata.json deleted file mode 100644 index a56694348bee4f4d5c07b913545e1ff0cf419b86..0000000000000000000000000000000000000000 --- a/business-operations/consent-management/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "consent-management", - "domain": "business-operations", - "complexity": 3, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "consent-management", - "gdpr", - "cookie-consent", - "privacy-preferences", - "opt-in-opt-out", - "compliance" - ], - "description": "User consent management workflow with cookie banner, preference center, consent recording, downstream system sync, and audit trail." -} \ No newline at end of file diff --git a/business-operations/data-export/README.md b/business-operations/data-export/README.md deleted file mode 100644 index e1c8b09e4c62864039ac648da6ad78fc2c28c3d8..0000000000000000000000000000000000000000 --- a/business-operations/data-export/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Data Export - -User data export workflow with export request, async job processing, data aggregation, secure file generation, and download link delivery. - -**Domain:** business-operations -**Complexity:** 3/5 -**Tags:** [data-export, data-portability, gdpr, bulk-export, async-job, download-link] - -## Lanes -- **User** - Requests export, downloads data -- **Export Service** - Aggregates and packages data -- **Storage** - Stores export file temporarily - -## Process Flow -1. User requests data export -2. Verify user identity -3. Queue async export job -4. Aggregate data from all sources -5. Generate export file (JSON/CSV) -6. Encrypt and store temporarily -7. Generate secure download link -8. Email download link to user -9. Auto-delete file after expiry diff --git a/business-operations/data-export/metadata.json b/business-operations/data-export/metadata.json deleted file mode 100644 index f3eb0bb75e653e9177f9877a033d5379d1574989..0000000000000000000000000000000000000000 --- a/business-operations/data-export/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "data-export", - "domain": "business-operations", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "data-export", - "data-portability", - "gdpr", - "bulk-export", - "async-job", - "download-link" - ], - "description": "User data export workflow with export request, async job processing, data aggregation, secure file generation, and download link delivery." -} \ No newline at end of file diff --git a/business-operations/dunning-flow/README.md b/business-operations/dunning-flow/README.md deleted file mode 100644 index 62c9ca7785090c053fed1c96e4f7cd0537efb2be..0000000000000000000000000000000000000000 --- a/business-operations/dunning-flow/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Dunning Flow - -Dunning collection workflow with escalating reminder emails, grace period management, account suspension, and payment recovery tracking. - -**Domain:** business-operations -**Complexity:** 3/5 -**Tags:** [dunning-flow, collections, overdue-payment, payment-reminder, account-suspension, revenue-recovery] - -## Lanes -- **Billing System** - Tracks overdue, sends reminders -- **Customer** - Receives notices, makes payment -- **Collections** - Escalates delinquent accounts - -## Process Flow -1. Payment becomes overdue -2. Send first reminder (Day 1) -3. Wait grace period -4. Send second reminder with urgency (Day 7) -5. Send final notice with suspension warning (Day 14) -6. Suspend account access (Day 21) -7. Customer makes payment -8. Restore account access -9. Track recovery metrics diff --git a/business-operations/dunning-flow/metadata.json b/business-operations/dunning-flow/metadata.json deleted file mode 100644 index 2c91484e2eac8a38ba5aca64da0e948971b8ebe9..0000000000000000000000000000000000000000 --- a/business-operations/dunning-flow/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "dunning-flow", - "domain": "business-operations", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "dunning-flow", - "collections", - "overdue-payment", - "payment-reminder", - "account-suspension", - "revenue-recovery" - ], - "description": "Dunning collection workflow with escalating reminder emails, grace period management, account suspension, and payment recovery tracking." -} \ No newline at end of file diff --git a/business-operations/email-campaign/README.md b/business-operations/email-campaign/README.md deleted file mode 100644 index 75b7ca6412d9c0f08ce9b88aa0e201fef9319227..0000000000000000000000000000000000000000 --- a/business-operations/email-campaign/README.md +++ /dev/null @@ -1,24 +0,0 @@ -# Email Campaign - -Email marketing campaign workflow with audience segmentation, A/B testing, send scheduling, deliverability monitoring, and engagement analytics. - -**Domain:** business-operations -**Complexity:** 4/5 -**Tags:** [email-campaign, marketing-automation, mailchimp, segmentation, a-b-testing, deliverability] - -## Lanes -- **Marketing Team** - Creates content, defines audience -- **Email Platform** - Sends emails, tracks delivery -- **Analytics** - Measures engagement -- **Recipient** - Opens, clicks, converts - -## Process Flow -1. Define campaign goal and audience -2. Segment subscriber list -3. Create email content and design -4. Set up A/B test variants -5. Schedule send time -6. Send to test segment first -7. Monitor deliverability and bounces -8. Track opens, clicks, conversions -9. Generate campaign performance report diff --git a/business-operations/email-campaign/metadata.json b/business-operations/email-campaign/metadata.json deleted file mode 100644 index 863f7b8fee6472ab861c2adb45db770a2b90d83e..0000000000000000000000000000000000000000 --- a/business-operations/email-campaign/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "email-campaign", - "domain": "business-operations", - "complexity": 4, - "num_nodes": 13, - "num_lanes": 4, - "tags": [ - "email-campaign", - "marketing-automation", - "mailchimp", - "segmentation", - "a-b-testing", - "deliverability" - ], - "description": "Email marketing campaign workflow with audience segmentation, A/B testing, send scheduling, deliverability monitoring, and engagement analytics." -} \ No newline at end of file diff --git a/business-operations/gdpr-deletion/README.md b/business-operations/gdpr-deletion/README.md deleted file mode 100644 index 9c81d4ecec236c03cafe9a632c522ee8a1f5c11c..0000000000000000000000000000000000000000 --- a/business-operations/gdpr-deletion/README.md +++ /dev/null @@ -1,24 +0,0 @@ -# GDPR Data Deletion - -GDPR data deletion workflow with identity verification, data inventory scan, PII removal across systems, backup purging, and deletion confirmation. - -**Domain:** business-operations -**Complexity:** 4/5 -**Tags:** [gdpr-deletion, right-to-be-forgotten, data-privacy, pii-removal, compliance, dsar] - -## Lanes -- **Data Subject** - Requests deletion -- **Privacy Team** - Verifies and coordinates -- **Systems** - Execute deletion across databases -- **Compliance** - Audits and confirms - -## Process Flow -1. Receive data deletion request (DSAR) -2. Verify requester identity -3. Inventory all systems with user data -4. Check for legal retention requirements -5. Delete PII from primary databases -6. Remove from analytics and logs -7. Purge from backups (within retention) -8. Notify third-party processors -9. Send deletion confirmation to user diff --git a/business-operations/gdpr-deletion/metadata.json b/business-operations/gdpr-deletion/metadata.json deleted file mode 100644 index 64aba11b555e4d4e8267dfba9a158344e4ff1e24..0000000000000000000000000000000000000000 --- a/business-operations/gdpr-deletion/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "gdpr-deletion", - "domain": "business-operations", - "complexity": 4, - "num_nodes": 13, - "num_lanes": 4, - "tags": [ - "gdpr-deletion", - "right-to-be-forgotten", - "data-privacy", - "pii-removal", - "compliance", - "dsar" - ], - "description": "GDPR data deletion workflow with identity verification, data inventory scan, PII removal across systems, backup purging, and deletion confirmation." -} \ No newline at end of file diff --git a/business-operations/in-app-message/README.md b/business-operations/in-app-message/README.md deleted file mode 100644 index cd7fe818e855dbac1c245345c6137efde8e5c2cc..0000000000000000000000000000000000000000 --- a/business-operations/in-app-message/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# In-App Message - -In-app messaging workflow with trigger conditions, audience targeting, message display, user interaction tracking, and conversion measurement. - -**Domain:** business-operations -**Complexity:** 2/5 -**Tags:** [in-app-message, product-tours, tooltips, announcements, user-engagement, intercom] - -## Lanes -- **Messaging Platform** - Evaluates triggers, displays messages -- **User** - Views and interacts with messages - -## Process Flow -1. User performs trigger action -2. Evaluate targeting rules -3. Check if user already saw message -4. Display in-app message (modal, tooltip, banner) -5. User views message -6. Track impression -7. User clicks CTA or dismisses -8. Record interaction -9. Measure conversion goal diff --git a/business-operations/in-app-message/metadata.json b/business-operations/in-app-message/metadata.json deleted file mode 100644 index ce07f0c48e6c8221b99f8c725a539b9f79d2d61b..0000000000000000000000000000000000000000 --- a/business-operations/in-app-message/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "in-app-message", - "domain": "business-operations", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "in-app-message", - "product-tours", - "tooltips", - "announcements", - "user-engagement", - "intercom" - ], - "description": "In-app messaging workflow with trigger conditions, audience targeting, message display, user interaction tracking, and conversion measurement." -} \ No newline at end of file diff --git a/business-operations/knowledge-base/README.md b/business-operations/knowledge-base/README.md deleted file mode 100644 index 02468ec808e5e8f1abd6d3774e5fdb33a39ab90c..0000000000000000000000000000000000000000 --- a/business-operations/knowledge-base/README.md +++ /dev/null @@ -1,24 +0,0 @@ -# Knowledge Base - -Knowledge base management workflow with article creation, review approval, SEO optimization, version control, and search analytics tracking. - -**Domain:** business-operations -**Complexity:** 3/5 -**Tags:** [knowledge-base, help-center, documentation, self-service, article-management, zendesk] - -## Lanes -- **Content Author** - Writes and updates articles -- **Reviewer** - Approves content changes -- **KB System** - Publishes and indexes -- **Analytics** - Tracks article performance - -## Process Flow -1. Identify knowledge gap from support tickets -2. Author drafts help article -3. Add screenshots and formatting -4. Submit for review -5. Reviewer approves or requests changes -6. Optimize for search (keywords, meta) -7. Publish to knowledge base -8. Index for search -9. Track views and helpfulness ratings diff --git a/business-operations/knowledge-base/metadata.json b/business-operations/knowledge-base/metadata.json deleted file mode 100644 index e3aa05b34627be021b54f28087c8ea11d210fe96..0000000000000000000000000000000000000000 --- a/business-operations/knowledge-base/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "knowledge-base", - "domain": "business-operations", - "complexity": 3, - "num_nodes": 13, - "num_lanes": 4, - "tags": [ - "knowledge-base", - "help-center", - "documentation", - "self-service", - "article-management", - "zendesk" - ], - "description": "Knowledge base management workflow with article creation, review approval, SEO optimization, version control, and search analytics tracking." -} \ No newline at end of file diff --git a/business-operations/oauth-flow/README.md b/business-operations/oauth-flow/README.md deleted file mode 100644 index d2ae8114f522ab949d813a3d7369bfc572428d96..0000000000000000000000000000000000000000 --- a/business-operations/oauth-flow/README.md +++ /dev/null @@ -1,24 +0,0 @@ -# OAuth 2.0 Flow - -OAuth 2.0 authorization code flow with redirect handling, code exchange, token storage, refresh token rotation, and scope management. - -**Domain:** business-operations -**Complexity:** 4/5 -**Tags:** [oauth-flow, oauth2, authorization-code, token-exchange, sso, third-party-auth] - -## Lanes -- **User** - Initiates login, grants consent -- **Client App** - Requests authorization -- **Auth Server** - Issues tokens -- **Resource Server** - Validates tokens - -## Process Flow -1. User clicks "Login with Provider" -2. Redirect to authorization server -3. User authenticates and grants consent -4. Auth server redirects with auth code -5. Exchange code for access token -6. Receive access and refresh tokens -7. Store tokens securely -8. Use access token for API calls -9. Refresh token when expired diff --git a/business-operations/oauth-flow/metadata.json b/business-operations/oauth-flow/metadata.json deleted file mode 100644 index 97c5f1a3590e004a5821268d0357397cd60cf88d..0000000000000000000000000000000000000000 --- a/business-operations/oauth-flow/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "oauth-flow", - "domain": "business-operations", - "complexity": 4, - "num_nodes": 13, - "num_lanes": 4, - "tags": [ - "oauth-flow", - "oauth2", - "authorization-code", - "token-exchange", - "sso", - "third-party-auth" - ], - "description": "OAuth 2.0 authorization code flow with redirect handling, code exchange, token storage, refresh token rotation, and scope management." -} \ No newline at end of file diff --git a/business-operations/payment-failure/README.md b/business-operations/payment-failure/README.md deleted file mode 100644 index 97f883217694b3b45f8b6a780c3ca7c6d72c2baf..0000000000000000000000000000000000000000 --- a/business-operations/payment-failure/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# Payment Failure Recovery - -Failed payment recovery workflow with smart retry scheduling, dunning email sequence, payment method update prompts, and involuntary churn prevention. - -**Domain:** business-operations -**Complexity:** 3/5 -**Tags:** [payment-failure, dunning, retry-logic, card-decline, revenue-recovery, stripe] - -## Lanes -- **Billing System** - Retries payments, manages dunning -- **Customer** - Updates payment method - -## Process Flow -1. Detect failed payment -2. Classify failure reason (insufficient funds, expired, etc.) -3. Schedule smart retry based on failure type -4. Send first dunning email -5. Retry payment after delay -6. If still failing, send update card prompt -7. Customer updates payment method -8. Retry with new payment method -9. If all retries fail, suspend account diff --git a/business-operations/payment-failure/metadata.json b/business-operations/payment-failure/metadata.json deleted file mode 100644 index 14bb127ffb30f81f8b1d7955f6be2e2e774a2121..0000000000000000000000000000000000000000 --- a/business-operations/payment-failure/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "payment-failure", - "domain": "business-operations", - "complexity": 3, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "payment-failure", - "dunning", - "retry-logic", - "card-decline", - "revenue-recovery", - "stripe" - ], - "description": "Failed payment recovery workflow with smart retry scheduling, dunning email sequence, payment method update prompts, and involuntary churn prevention." -} \ No newline at end of file diff --git a/business-operations/personalization-engine/README.md b/business-operations/personalization-engine/README.md deleted file mode 100644 index afbd55eeac36468fde3bfb010a5ff4b54c56e0b4..0000000000000000000000000000000000000000 --- a/business-operations/personalization-engine/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# Personalization Engine - -Make.com automation scenario for real-time personalization using Segment events, ML recommendation API, and Braze campaign delivery across email and push channels. - -**Domain:** business-operations -**Complexity:** 4/5 -**Tags:** [make-com, personalization, segment, braze, ml-recommendations, content-delivery, marketing-automation] - -## Lanes -- **Make.com Scenario** - Watches Segment events, routes by event type -- **Make.com HTTP Module** - Calls ML recommendation API, evaluates confidence -- **Make.com Iterator** - Delivers personalized content via Braze campaigns - -## Process Flow -1. Watch Segment user events (page view, purchase, signup) -2. Parse user properties and route by event type -3. POST to recommendation API for ML predictions -4. Evaluate confidence score (threshold: 0.7) -5. Select personalized or default content based on confidence -6. Fetch content variants and select best match -7. Update Braze user profile with preferences -8. Trigger Braze campaign based on channel preference (email/push) diff --git a/business-operations/personalization-engine/metadata.json b/business-operations/personalization-engine/metadata.json deleted file mode 100644 index 483f822ac78a8967c0a6d7ac46d99222278bfda3..0000000000000000000000000000000000000000 --- a/business-operations/personalization-engine/metadata.json +++ /dev/null @@ -1,17 +0,0 @@ -{ - "workflow_id": "personalization-engine", - "domain": "business-operations", - "complexity": 4, - "num_nodes": 20, - "num_lanes": 3, - "tags": [ - "make-com", - "personalization", - "segment", - "braze", - "ml-recommendations", - "content-delivery", - "marketing-automation" - ], - "description": "Make.com automation scenario for real-time personalization using Segment events, ML recommendation API, and Braze campaign delivery across email and push channels." -} \ No newline at end of file diff --git a/business-operations/plan-downgrade/README.md b/business-operations/plan-downgrade/README.md deleted file mode 100644 index eb88b15a598b49a60f14ff038de8a7ea80ea3e3a..0000000000000000000000000000000000000000 --- a/business-operations/plan-downgrade/README.md +++ /dev/null @@ -1,24 +0,0 @@ -# Plan Downgrade - -Subscription plan downgrade workflow with retention offer, feature restriction warning, data migration handling, and end-of-period scheduling. - -**Domain:** business-operations -**Complexity:** 3/5 -**Tags:** [plan-downgrade, retention, feature-restriction, data-migration, churn-prevention, billing] - -## Lanes -- **Customer** - Requests downgrade -- **Retention** - Offers alternatives -- **Billing System** - Schedules change -- **Product** - Handles feature restrictions - -## Process Flow -1. Customer initiates downgrade request -2. Show retention offer (discount, pause) -3. If declined, show feature loss warning -4. Check data limits on new plan -5. Warn about data that won't fit -6. Schedule downgrade for period end -7. Send confirmation with effective date -8. At period end, restrict features -9. Adjust billing to new plan rate diff --git a/business-operations/plan-downgrade/metadata.json b/business-operations/plan-downgrade/metadata.json deleted file mode 100644 index 18a9a5af7817431873c0995cfcb2be3eb60e5e4d..0000000000000000000000000000000000000000 --- a/business-operations/plan-downgrade/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "plan-downgrade", - "domain": "business-operations", - "complexity": 3, - "num_nodes": 13, - "num_lanes": 4, - "tags": [ - "plan-downgrade", - "retention", - "feature-restriction", - "data-migration", - "churn-prevention", - "billing" - ], - "description": "Subscription plan downgrade workflow with retention offer, feature restriction warning, data migration handling, and end-of-period scheduling." -} \ No newline at end of file diff --git a/business-operations/plan-upgrade/README.md b/business-operations/plan-upgrade/README.md deleted file mode 100644 index 3318cda9819ab62cec319f39a35b79a02826152b..0000000000000000000000000000000000000000 --- a/business-operations/plan-upgrade/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Plan Upgrade - -Subscription plan upgrade workflow with feature comparison, proration calculation, immediate feature unlock, and billing adjustment. - -**Domain:** business-operations -**Complexity:** 3/5 -**Tags:** [plan-upgrade, upsell, proration, feature-unlock, expansion-revenue, billing] - -## Lanes -- **Customer** - Initiates upgrade -- **Billing System** - Calculates proration, processes payment -- **Product** - Unlocks new features - -## Process Flow -1. Customer views upgrade options -2. Compare current vs new plan features -3. Calculate prorated amount due -4. Display upgrade cost summary -5. Customer confirms upgrade -6. Process prorated payment -7. Update subscription in billing system -8. Unlock new plan features immediately -9. Send upgrade confirmation email diff --git a/business-operations/plan-upgrade/metadata.json b/business-operations/plan-upgrade/metadata.json deleted file mode 100644 index 02a01cd52ea2cd117d4b7a82daa6a4602f355209..0000000000000000000000000000000000000000 --- a/business-operations/plan-upgrade/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "plan-upgrade", - "domain": "business-operations", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "plan-upgrade", - "upsell", - "proration", - "feature-unlock", - "expansion-revenue", - "billing" - ], - "description": "Subscription plan upgrade workflow with feature comparison, proration calculation, immediate feature unlock, and billing adjustment." -} \ No newline at end of file diff --git a/business-operations/push-notification/README.md b/business-operations/push-notification/README.md deleted file mode 100644 index 911a97b0c292643f3dd8c14b1bda55da2ba52ea9..0000000000000000000000000000000000000000 --- a/business-operations/push-notification/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Push Notification - -Mobile push notification workflow with audience targeting, platform routing (iOS/Android), delivery tracking, and engagement analytics. - -**Domain:** business-operations -**Complexity:** 3/5 -**Tags:** [push-notification, mobile-engagement, firebase-fcm, apns, segmentation, deep-linking] - -## Lanes -- **Marketing/System** - Triggers notification -- **Push Service** - Routes to platform providers -- **Mobile Device** - Receives and displays - -## Process Flow -1. Trigger push notification event -2. Select target audience segment -3. Compose notification content -4. Add deep link for action -5. Route to FCM (Android) or APNS (iOS) -6. Deliver to device -7. Track delivery status -8. User taps notification -9. Record engagement metrics diff --git a/business-operations/push-notification/metadata.json b/business-operations/push-notification/metadata.json deleted file mode 100644 index c7f6d464143ce5272b227ff10e9b3a0949e6d445..0000000000000000000000000000000000000000 --- a/business-operations/push-notification/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "push-notification", - "domain": "business-operations", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "push-notification", - "mobile-engagement", - "firebase-fcm", - "apns", - "segmentation", - "deep-linking" - ], - "description": "Mobile push notification workflow with audience targeting, platform routing (iOS/Android), delivery tracking, and engagement analytics." -} \ No newline at end of file diff --git a/business-operations/referral-program/README.md b/business-operations/referral-program/README.md deleted file mode 100644 index 781a3c2e5cf5dd8d4e7ab8b8381af67b085e6095..0000000000000000000000000000000000000000 --- a/business-operations/referral-program/README.md +++ /dev/null @@ -1,24 +0,0 @@ -# Referral Program - -Customer referral program workflow with unique link generation, referral tracking, conversion validation, and dual-sided reward fulfillment. - -**Domain:** business-operations -**Complexity:** 3/5 -**Tags:** [referral-program, viral-growth, referral-tracking, reward-fulfillment, affiliate, word-of-mouth] - -## Lanes -- **Referrer** - Shares referral link -- **Referred Friend** - Signs up via link -- **Referral System** - Tracks and validates -- **Rewards** - Fulfills incentives - -## Process Flow -1. Customer requests referral link -2. Generate unique tracking link -3. Customer shares link -4. Friend clicks and signs up -5. Track referral attribution -6. Validate conversion (paid signup) -7. Credit referrer's account -8. Send reward to referred friend -9. Notify both parties of reward diff --git a/business-operations/referral-program/metadata.json b/business-operations/referral-program/metadata.json deleted file mode 100644 index a2b9af1ee1acac3f0b6e67f8d4fb43a93a56e2f6..0000000000000000000000000000000000000000 --- a/business-operations/referral-program/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "referral-program", - "domain": "business-operations", - "complexity": 3, - "num_nodes": 13, - "num_lanes": 4, - "tags": [ - "referral-program", - "viral-growth", - "referral-tracking", - "reward-fulfillment", - "affiliate", - "word-of-mouth" - ], - "description": "Customer referral program workflow with unique link generation, referral tracking, conversion validation, and dual-sided reward fulfillment." -} \ No newline at end of file diff --git a/business-operations/review-collection/README.md b/business-operations/review-collection/README.md deleted file mode 100644 index 3701d94df06bb63abd1b2cf01239f5b41baf5ce6..0000000000000000000000000000000000000000 --- a/business-operations/review-collection/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# Review Collection - -Customer review collection workflow with post-purchase trigger, review request email, rating submission, moderation, and public display. - -**Domain:** business-operations -**Complexity:** 2/5 -**Tags:** [review-collection, customer-feedback, nps, ratings, social-proof, testimonials] - -## Lanes -- **Customer** - Receives request, submits review -- **Review System** - Sends requests, moderates, displays - -## Process Flow -1. Customer completes purchase/milestone -2. Wait appropriate delay (7 days) -3. Send review request email -4. Customer clicks to leave review -5. Submit star rating and comment -6. Auto-moderate for spam/profanity -7. Flag for manual review if needed -8. Publish approved review -9. Thank customer for feedback diff --git a/business-operations/review-collection/metadata.json b/business-operations/review-collection/metadata.json deleted file mode 100644 index 9f84f7150d6f4075a6f4abb96c75183e6b4c1349..0000000000000000000000000000000000000000 --- a/business-operations/review-collection/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "review-collection", - "domain": "business-operations", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "review-collection", - "customer-feedback", - "nps", - "ratings", - "social-proof", - "testimonials" - ], - "description": "Customer review collection workflow with post-purchase trigger, review request email, rating submission, moderation, and public display." -} \ No newline at end of file diff --git a/business-operations/search-optimization/README.md b/business-operations/search-optimization/README.md deleted file mode 100644 index 3823ee4009b3e5c30438ddfb775c3b7b5a9d9aa4..0000000000000000000000000000000000000000 --- a/business-operations/search-optimization/README.md +++ /dev/null @@ -1,24 +0,0 @@ -# Search Optimization - -Search optimization workflow with query analysis, relevance tuning, synonym management, click-through tracking, and A/B testing of ranking algorithms. - -**Domain:** business-operations -**Complexity:** 4/5 -**Tags:** [search-optimization, elasticsearch, relevance-tuning, query-analysis, algolia, search-analytics] - -## Lanes -- **Search Analytics** - Tracks queries and clicks -- **Search Team** - Analyzes and tunes -- **Search Engine** - Indexes and ranks -- **Users** - Perform searches - -## Process Flow -1. Collect search query logs -2. Analyze zero-result queries -3. Identify low click-through queries -4. Add synonyms and redirects -5. Tune relevance scoring weights -6. A/B test ranking changes -7. Monitor search conversion rate -8. Update index with new content -9. Report on search KPIs diff --git a/business-operations/search-optimization/metadata.json b/business-operations/search-optimization/metadata.json deleted file mode 100644 index 8a8bf11d1078e564b45c941e6312de999076e6f0..0000000000000000000000000000000000000000 --- a/business-operations/search-optimization/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "search-optimization", - "domain": "business-operations", - "complexity": 4, - "num_nodes": 13, - "num_lanes": 4, - "tags": [ - "search-optimization", - "elasticsearch", - "relevance-tuning", - "query-analysis", - "algolia", - "search-analytics" - ], - "description": "Search optimization workflow with query analysis, relevance tuning, synonym management, click-through tracking, and A/B testing of ranking algorithms." -} \ No newline at end of file diff --git a/business-operations/sms-verification/README.md b/business-operations/sms-verification/README.md deleted file mode 100644 index f0117b19a02b3fdcbc185752759d3e92964c27c9..0000000000000000000000000000000000000000 --- a/business-operations/sms-verification/README.md +++ /dev/null @@ -1,24 +0,0 @@ -# SMS Verification - -SMS phone verification workflow with OTP generation, rate limiting, code validation, retry handling, and verification status tracking. - -**Domain:** business-operations -**Complexity:** 3/5 -**Tags:** [sms-verification, otp, twilio, phone-verification, 2fa, fraud-prevention] - -## Lanes -- **User** - Enters phone, submits code -- **Application** - Validates input -- **SMS Provider** - Sends OTP via Twilio -- **Verification Service** - Validates code - -## Process Flow -1. User enters phone number -2. Validate phone format -3. Check rate limits (prevent abuse) -4. Generate 6-digit OTP -5. Send SMS via Twilio -6. User receives and enters code -7. Validate code matches and not expired -8. If invalid, allow retry (max 3) -9. Mark phone as verified diff --git a/business-operations/sms-verification/metadata.json b/business-operations/sms-verification/metadata.json deleted file mode 100644 index 949c4a622100f7bcce85c643e0526e99134b1b0b..0000000000000000000000000000000000000000 --- a/business-operations/sms-verification/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "sms-verification", - "domain": "business-operations", - "complexity": 3, - "num_nodes": 13, - "num_lanes": 4, - "tags": [ - "sms-verification", - "otp", - "twilio", - "phone-verification", - "2fa", - "fraud-prevention" - ], - "description": "SMS phone verification workflow with OTP generation, rate limiting, code validation, retry handling, and verification status tracking." -} \ No newline at end of file diff --git a/business-operations/subscription-lifecycle/README.md b/business-operations/subscription-lifecycle/README.md deleted file mode 100644 index 806e9cb53d160c68acfd04ef7a2f4ee7fecc1ec6..0000000000000000000000000000000000000000 --- a/business-operations/subscription-lifecycle/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Subscription Lifecycle - -SaaS subscription lifecycle workflow with trial signup, conversion nurturing, payment processing, renewal management, and churn prevention campaigns. - -**Domain:** business-operations -**Complexity:** 4/5 -**Tags:** [subscription-lifecycle, saas, trial-conversion, renewal, churn-prevention, stripe] - -## Lanes -- **Customer** - Signs up, uses product, renews -- **Billing System** - Processes payments, manages subscriptions -- **Marketing Automation** - Sends lifecycle emails - -## Process Flow -1. Customer starts free trial -2. Send onboarding email sequence -3. Track product engagement -4. Send trial expiration reminder -5. Convert to paid subscription -6. Process recurring payment -7. Send renewal reminder before expiry -8. Handle failed payment with dunning -9. Win-back campaign if churned diff --git a/business-operations/subscription-lifecycle/metadata.json b/business-operations/subscription-lifecycle/metadata.json deleted file mode 100644 index ac3446a5d16e99704e83b735577263edbfdc0820..0000000000000000000000000000000000000000 --- a/business-operations/subscription-lifecycle/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "subscription-lifecycle", - "domain": "business-operations", - "complexity": 4, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "subscription-lifecycle", - "saas", - "trial-conversion", - "renewal", - "churn-prevention", - "stripe" - ], - "description": "SaaS subscription lifecycle workflow with trial signup, conversion nurturing, payment processing, renewal management, and churn prevention campaigns." -} \ No newline at end of file diff --git a/business-operations/support-ticket/README.md b/business-operations/support-ticket/README.md deleted file mode 100644 index 1d46117d9ffd1eb0d1052dca67f39ee5fe9e346f..0000000000000000000000000000000000000000 --- a/business-operations/support-ticket/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Support Ticket - -Customer support ticket workflow with auto-categorization, SLA tracking, agent assignment, escalation rules, and satisfaction survey. - -**Domain:** business-operations -**Complexity:** 3/5 -**Tags:** [support-ticket, helpdesk, zendesk, sla, ticket-routing, customer-service] - -## Lanes -- **Customer** - Submits ticket, provides feedback -- **Support System** - Routes tickets, tracks SLA -- **Support Agent** - Resolves issues, escalates if needed - -## Process Flow -1. Customer submits support request -2. Auto-categorize ticket (billing, technical, etc.) -3. Assign priority based on customer tier -4. Route to appropriate agent/team -5. Start SLA timer -6. Agent investigates and responds -7. Escalate if SLA at risk -8. Resolve and close ticket -9. Send satisfaction survey diff --git a/business-operations/support-ticket/metadata.json b/business-operations/support-ticket/metadata.json deleted file mode 100644 index 65e9f7fb82ee0af3661b251cda05c937001f1e4b..0000000000000000000000000000000000000000 --- a/business-operations/support-ticket/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "support-ticket", - "domain": "business-operations", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "support-ticket", - "helpdesk", - "zendesk", - "sla", - "ticket-routing", - "customer-service" - ], - "description": "Customer support ticket workflow with auto-categorization, SLA tracking, agent assignment, escalation rules, and satisfaction survey." -} \ No newline at end of file diff --git a/business-operations/two-factor-setup/README.md b/business-operations/two-factor-setup/README.md deleted file mode 100644 index 42f21e3f02e21e8d6e7cf8e0bcf2d8446fe6709d..0000000000000000000000000000000000000000 --- a/business-operations/two-factor-setup/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# Two Factor Setup - -Two-factor authentication setup workflow with method selection (TOTP/SMS), QR code generation, backup codes, and verification confirmation. - -**Domain:** business-operations -**Complexity:** 2/5 -**Tags:** [two-factor-auth, mfa, totp, authenticator-app, security, account-protection] - -## Lanes -- **User** - Initiates 2FA setup and completes verification -- **Auth System** - Generates secrets, QR codes, and validates codes - -## Process Flow -1. User navigates to security settings -2. Select 2FA method (authenticator app or SMS) -3. Generate TOTP secret and QR code -4. User scans QR code with authenticator app -5. User enters verification code -6. Validate code against secret -7. Generate backup recovery codes -8. Store 2FA configuration -9. Send confirmation email diff --git a/business-operations/two-factor-setup/metadata.json b/business-operations/two-factor-setup/metadata.json deleted file mode 100644 index e130bb438a2cb3bfe0c3062cbf8e5cbc00fe7929..0000000000000000000000000000000000000000 --- a/business-operations/two-factor-setup/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "two-factor-setup", - "domain": "business-operations", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "two-factor-auth", - "mfa", - "totp", - "authenticator-app", - "security", - "account-protection" - ], - "description": "Two-factor authentication setup workflow with method selection (TOTP/SMS), QR code generation, backup codes, and verification confirmation." -} \ No newline at end of file diff --git a/business-operations/user-onboarding/README.md b/business-operations/user-onboarding/README.md deleted file mode 100644 index 3cb6a4f4a976a8477b0db94b97c5f14ab76bcd7d..0000000000000000000000000000000000000000 --- a/business-operations/user-onboarding/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# User Onboarding - -New user onboarding workflow with welcome email, profile setup, product tour, first action prompt, and activation milestone tracking. - -**Domain:** business-operations -**Complexity:** 2/5 -**Tags:** [user-onboarding, activation, product-tour, welcome-email, first-time-user, time-to-value] - -## Lanes -- **New User** - Completes onboarding steps -- **Onboarding System** - Guides user through activation - -## Process Flow -1. User completes signup -2. Send welcome email with getting started guide -3. Prompt profile completion -4. Launch interactive product tour -5. Highlight key features -6. Prompt first meaningful action -7. Track activation milestone -8. Trigger follow-up if inactive -9. Mark user as onboarded diff --git a/business-operations/user-onboarding/metadata.json b/business-operations/user-onboarding/metadata.json deleted file mode 100644 index cac12e0b2e7b7855b03f0090d23330fecf011028..0000000000000000000000000000000000000000 --- a/business-operations/user-onboarding/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "user-onboarding", - "domain": "business-operations", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "user-onboarding", - "activation", - "product-tour", - "welcome-email", - "first-time-user", - "time-to-value" - ], - "description": "New user onboarding workflow with welcome email, profile setup, product tour, first action prompt, and activation milestone tracking." -} \ No newline at end of file diff --git a/business-operations/user-segmentation/README.md b/business-operations/user-segmentation/README.md deleted file mode 100644 index 4de0b914a16b9108e93c13df7b2c0f0d1dc62b83..0000000000000000000000000000000000000000 --- a/business-operations/user-segmentation/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# User Segmentation - -User segmentation workflow with attribute collection, behavioral event tracking, segment rule definition, dynamic membership, and downstream sync. - -**Domain:** business-operations -**Complexity:** 2/5 -**Tags:** [user-segmentation, audience-targeting, behavioral-cohorts, customer-segments, segment, marketing-automation] - -## Lanes -- **Data Pipeline** - Collects user attributes and events -- **Segmentation Engine** - Evaluates rules and assigns users - -## Process Flow -1. Collect user profile attributes -2. Track behavioral events (page views, purchases) -3. Define segment rules (e.g., "active users last 7 days") -4. Evaluate users against segment criteria -5. Assign users to matching segments -6. Update segment membership dynamically -7. Sync segments to marketing tools -8. Trigger segment-based campaigns -9. Report on segment sizes and trends diff --git a/business-operations/user-segmentation/metadata.json b/business-operations/user-segmentation/metadata.json deleted file mode 100644 index 5fb8aa739468e94998efabb06d5c5c7afc37ae44..0000000000000000000000000000000000000000 --- a/business-operations/user-segmentation/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "user-segmentation", - "domain": "business-operations", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "user-segmentation", - "audience-targeting", - "behavioral-cohorts", - "customer-segments", - "segment", - "marketing-automation" - ], - "description": "User segmentation workflow with attribute collection, behavioral event tracking, segment rule definition, dynamic membership, and downstream sync." -} \ No newline at end of file diff --git a/business-operations/webhook-integration/README.md b/business-operations/webhook-integration/README.md deleted file mode 100644 index 19021a6ce964359157ac2f95aa95255fdf021d29..0000000000000000000000000000000000000000 --- a/business-operations/webhook-integration/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# Webhook Integration - -Webhook integration workflow with endpoint registration, payload signing, delivery attempt, retry with backoff, and delivery status tracking. - -**Domain:** business-operations -**Complexity:** 2/5 -**Tags:** [webhook, event-driven, http-callback, integration, retry-logic, payload-signing] - -## Lanes -- **Source System** - Triggers events and sends webhooks -- **Webhook Service** - Manages delivery and retries - -## Process Flow -1. Register webhook endpoint URL -2. Configure event subscriptions -3. Event occurs in source system -4. Build webhook payload -5. Sign payload with HMAC secret -6. POST to registered endpoint -7. Check response status code -8. Retry with exponential backoff on failure -9. Log delivery status and attempts diff --git a/business-operations/webhook-integration/metadata.json b/business-operations/webhook-integration/metadata.json deleted file mode 100644 index 361eca1e86c71b57f3ba363303dc5048a301895c..0000000000000000000000000000000000000000 --- a/business-operations/webhook-integration/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "webhook-integration", - "domain": "business-operations", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "webhook", - "event-driven", - "http-callback", - "integration", - "retry-logic", - "payload-signing" - ], - "description": "Webhook integration workflow with endpoint registration, payload signing, delivery attempt, retry with backoff, and delivery status tracking." -} \ No newline at end of file diff --git a/business-operations/webinar-registration/README.md b/business-operations/webinar-registration/README.md deleted file mode 100644 index 244de7eea3baa2ebe356f5e8539f2815906ebf04..0000000000000000000000000000000000000000 --- a/business-operations/webinar-registration/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Webinar Registration - -Webinar registration workflow with signup form, calendar invite, reminder email sequence, attendance tracking, and post-event follow-up. - -**Domain:** business-operations -**Complexity:** 3/5 -**Tags:** [webinar, event-registration, zoom, calendar-invite, reminder-sequence, lead-capture] - -## Lanes -- **Registrant** - Signs up and attends webinar -- **Marketing System** - Manages registration and reminders -- **Webinar Platform** - Hosts the live event - -## Process Flow -1. User submits registration form -2. Capture lead information -3. Send confirmation email with details -4. Add calendar invite (.ics) -5. Send reminder 24 hours before -6. Send reminder 1 hour before -7. Track attendance during webinar -8. Send recording to no-shows -9. Trigger post-event follow-up sequence diff --git a/business-operations/webinar-registration/metadata.json b/business-operations/webinar-registration/metadata.json deleted file mode 100644 index f6f210aa7af5148d520304ddba0493d72ae119ce..0000000000000000000000000000000000000000 --- a/business-operations/webinar-registration/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "webinar-registration", - "domain": "business-operations", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "webinar", - "event-registration", - "zoom", - "calendar-invite", - "reminder-sequence", - "lead-capture" - ], - "description": "Webinar registration workflow with signup form, calendar invite, reminder email sequence, attendance tracking, and post-event follow-up." -} \ No newline at end of file diff --git a/compliance/business-operations/consent-management-workflow/README.md b/compliance/business-operations/consent-management-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..71ecf1bb2de3f043cb729d8bd076b21eab034a2d --- /dev/null +++ b/compliance/business-operations/consent-management-workflow/README.md @@ -0,0 +1,19 @@ +# Consent Management Workflow + +User consent management workflow with cookie banner, preference center, consent recording, downstream system sync, and audit trail. + +**Template ID:** `consent-management-workflow` +**Kind:** workflow +**Source domain:** business-operations +**Primary use case:** compliance +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [consent-management, gdpr, cookie-consent, privacy-preferences, opt-in-opt-out, compliance] +**Source path:** `business-operations/consent-management` +**Repo path:** `compliance/business-operations/consent-management-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/compliance/business-operations/consent-management-workflow/metadata.json b/compliance/business-operations/consent-management-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..3aa1d1dc28b3e866d34bf1ef55927896c1578296 --- /dev/null +++ b/compliance/business-operations/consent-management-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "consent-management-workflow", + "workflow_id": "consent-management", + "title": "Consent Management Workflow", + "kind": "workflow", + "source_domain": "business-operations", + "primary_use_case": "compliance", + "secondary_use_cases": [], + "use_cases": [ + "compliance" + ], + "complexity": 3, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "consent-management", + "gdpr", + "cookie-consent", + "privacy-preferences", + "opt-in-opt-out", + "compliance" + ], + "description": "User consent management workflow with cookie banner, preference center, consent recording, downstream system sync, and audit trail.", + "source_path": "business-operations/consent-management", + "repo_path": "compliance/business-operations/consent-management-workflow" +} diff --git a/business-operations/consent-management/workflow.fz b/compliance/business-operations/consent-management-workflow/workflow.fz similarity index 100% rename from business-operations/consent-management/workflow.fz rename to compliance/business-operations/consent-management-workflow/workflow.fz diff --git a/compliance/business-operations/data-export-workflow/README.md b/compliance/business-operations/data-export-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..6ae023bae6d6baa96bfc6e528ae5bdec2b0d1c6f --- /dev/null +++ b/compliance/business-operations/data-export-workflow/README.md @@ -0,0 +1,19 @@ +# Data Export Workflow + +User data export workflow with export request, async job processing, data aggregation, secure file generation, and download link delivery. + +**Template ID:** `data-export-workflow` +**Kind:** workflow +**Source domain:** business-operations +**Primary use case:** compliance +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [data-export, data-portability, gdpr, bulk-export, async-job, download-link] +**Source path:** `business-operations/data-export` +**Repo path:** `compliance/business-operations/data-export-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/compliance/business-operations/data-export-workflow/metadata.json b/compliance/business-operations/data-export-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..e4d9421bb8f93d3469da8f031f7cc694195eb797 --- /dev/null +++ b/compliance/business-operations/data-export-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "data-export-workflow", + "workflow_id": "data-export", + "title": "Data Export Workflow", + "kind": "workflow", + "source_domain": "business-operations", + "primary_use_case": "compliance", + "secondary_use_cases": [], + "use_cases": [ + "compliance" + ], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "data-export", + "data-portability", + "gdpr", + "bulk-export", + "async-job", + "download-link" + ], + "description": "User data export workflow with export request, async job processing, data aggregation, secure file generation, and download link delivery.", + "source_path": "business-operations/data-export", + "repo_path": "compliance/business-operations/data-export-workflow" +} diff --git a/business-operations/data-export/workflow.fz b/compliance/business-operations/data-export-workflow/workflow.fz similarity index 100% rename from business-operations/data-export/workflow.fz rename to compliance/business-operations/data-export-workflow/workflow.fz diff --git a/compliance/business-operations/gdpr-deletion-workflow/README.md b/compliance/business-operations/gdpr-deletion-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..e29c153e2e17f2010f12334155f0de707a621fd7 --- /dev/null +++ b/compliance/business-operations/gdpr-deletion-workflow/README.md @@ -0,0 +1,19 @@ +# Gdpr Deletion Workflow + +GDPR data deletion workflow with identity verification, data inventory scan, PII removal across systems, backup purging, and deletion confirmation. + +**Template ID:** `gdpr-deletion-workflow` +**Kind:** workflow +**Source domain:** business-operations +**Primary use case:** compliance +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 13 +**Lanes:** 4 +**Tags:** [gdpr-deletion, right-to-be-forgotten, data-privacy, pii-removal, compliance, dsar] +**Source path:** `business-operations/gdpr-deletion` +**Repo path:** `compliance/business-operations/gdpr-deletion-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/compliance/business-operations/gdpr-deletion-workflow/metadata.json b/compliance/business-operations/gdpr-deletion-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..c2a57af921158438c75a29488ad50355f9263cc5 --- /dev/null +++ b/compliance/business-operations/gdpr-deletion-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "gdpr-deletion-workflow", + "workflow_id": "gdpr-deletion", + "title": "Gdpr Deletion Workflow", + "kind": "workflow", + "source_domain": "business-operations", + "primary_use_case": "compliance", + "secondary_use_cases": [], + "use_cases": [ + "compliance" + ], + "complexity": 4, + "num_nodes": 13, + "num_lanes": 4, + "tags": [ + "gdpr-deletion", + "right-to-be-forgotten", + "data-privacy", + "pii-removal", + "compliance", + "dsar" + ], + "description": "GDPR data deletion workflow with identity verification, data inventory scan, PII removal across systems, backup purging, and deletion confirmation.", + "source_path": "business-operations/gdpr-deletion", + "repo_path": "compliance/business-operations/gdpr-deletion-workflow" +} diff --git a/business-operations/gdpr-deletion/workflow.fz b/compliance/business-operations/gdpr-deletion-workflow/workflow.fz similarity index 100% rename from business-operations/gdpr-deletion/workflow.fz rename to compliance/business-operations/gdpr-deletion-workflow/workflow.fz diff --git a/compliance/finance/financial-reporting-workflow/README.md b/compliance/finance/financial-reporting-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..76860b4290ea3a038c9e92a302fc994a47ed8949 --- /dev/null +++ b/compliance/finance/financial-reporting-workflow/README.md @@ -0,0 +1,19 @@ +# Financial Reporting Workflow + +Financial reporting workflow with GAAP-compliant statement preparation, management review, audit committee approval, and SEC filing for public companies. + +**Template ID:** `financial-reporting-workflow` +**Kind:** workflow +**Source domain:** finance +**Primary use case:** compliance +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [financial-reporting, gaap-compliance, income-statement, balance-sheet, cash-flow-statement, sec-filing] +**Source path:** `finance/financial-reporting` +**Repo path:** `compliance/finance/financial-reporting-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/compliance/finance/financial-reporting-workflow/metadata.json b/compliance/finance/financial-reporting-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..94169395148fd93999169b1cea8b832fe91209e0 --- /dev/null +++ b/compliance/finance/financial-reporting-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "financial-reporting-workflow", + "workflow_id": "financial-reporting", + "title": "Financial Reporting Workflow", + "kind": "workflow", + "source_domain": "finance", + "primary_use_case": "compliance", + "secondary_use_cases": [], + "use_cases": [ + "compliance" + ], + "complexity": 4, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "financial-reporting", + "gaap-compliance", + "income-statement", + "balance-sheet", + "cash-flow-statement", + "sec-filing" + ], + "description": "Financial reporting workflow with GAAP-compliant statement preparation, management review, audit committee approval, and SEC filing for public companies.", + "source_path": "finance/financial-reporting", + "repo_path": "compliance/finance/financial-reporting-workflow" +} diff --git a/finance/financial-reporting/workflow.fz b/compliance/finance/financial-reporting-workflow/workflow.fz similarity index 100% rename from finance/financial-reporting/workflow.fz rename to compliance/finance/financial-reporting-workflow/workflow.fz diff --git a/compliance/finance/internal-controls-workflow/README.md b/compliance/finance/internal-controls-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..94db9993fd1326f5a414fccad5843abdd9f59b43 --- /dev/null +++ b/compliance/finance/internal-controls-workflow/README.md @@ -0,0 +1,19 @@ +# Internal Controls Workflow + +Internal controls testing workflow with risk assessment, control design evaluation, operating effectiveness testing, deficiency identification, and remediation tracking. + +**Template ID:** `internal-controls-workflow` +**Kind:** workflow +**Source domain:** finance +**Primary use case:** compliance +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [internal-controls, sox-compliance, control-testing, segregation-of-duties, risk-assessment, remediation] +**Source path:** `finance/internal-controls` +**Repo path:** `compliance/finance/internal-controls-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/compliance/finance/internal-controls-workflow/metadata.json b/compliance/finance/internal-controls-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..a82f35f3f198736a19ca9444517468b1a3ea7f69 --- /dev/null +++ b/compliance/finance/internal-controls-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "internal-controls-workflow", + "workflow_id": "internal-controls", + "title": "Internal Controls Workflow", + "kind": "workflow", + "source_domain": "finance", + "primary_use_case": "compliance", + "secondary_use_cases": [], + "use_cases": [ + "compliance" + ], + "complexity": 4, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "internal-controls", + "sox-compliance", + "control-testing", + "segregation-of-duties", + "risk-assessment", + "remediation" + ], + "description": "Internal controls testing workflow with risk assessment, control design evaluation, operating effectiveness testing, deficiency identification, and remediation tracking.", + "source_path": "finance/internal-controls", + "repo_path": "compliance/finance/internal-controls-workflow" +} diff --git a/finance/internal-controls/workflow.fz b/compliance/finance/internal-controls-workflow/workflow.fz similarity index 100% rename from finance/internal-controls/workflow.fz rename to compliance/finance/internal-controls-workflow/workflow.fz diff --git a/compliance/finance/payroll-processing-workflow/README.md b/compliance/finance/payroll-processing-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..77cf56641d917fe960010f5342b6f60450a9af82 --- /dev/null +++ b/compliance/finance/payroll-processing-workflow/README.md @@ -0,0 +1,19 @@ +# Payroll Processing Workflow + +Complete payroll processing workflow with timesheet collection, gross pay calculation, overtime, tax withholding (federal, state, FICA), benefits deductions, compliance validation, and ACH direct deposit. + +**Template ID:** `payroll-processing-workflow` +**Kind:** workflow +**Source domain:** finance +**Primary use case:** compliance +**Secondary use cases:** None +**Complexity:** 5/5 +**Nodes:** 24 +**Lanes:** 4 +**Tags:** [payroll-processing, salary-calculation, tax-withholding, fica, ach-direct-deposit, benefits-deductions, compliance] +**Source path:** `finance/payroll-processing` +**Repo path:** `compliance/finance/payroll-processing-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/finance/payroll-processing/metadata.json b/compliance/finance/payroll-processing-workflow/metadata.json similarity index 54% rename from finance/payroll-processing/metadata.json rename to compliance/finance/payroll-processing-workflow/metadata.json index 0e0e9a644dd0b93e0692285790cb6978fdff636e..cf19847fe0ac52b647b64a45dc78d28acf91603f 100644 --- a/finance/payroll-processing/metadata.json +++ b/compliance/finance/payroll-processing-workflow/metadata.json @@ -1,6 +1,14 @@ { + "template_id": "payroll-processing-workflow", "workflow_id": "payroll-processing", - "domain": "finance", + "title": "Payroll Processing Workflow", + "kind": "workflow", + "source_domain": "finance", + "primary_use_case": "compliance", + "secondary_use_cases": [], + "use_cases": [ + "compliance" + ], "complexity": 5, "num_nodes": 24, "num_lanes": 4, @@ -13,5 +21,7 @@ "benefits-deductions", "compliance" ], - "description": "Complete payroll processing workflow with timesheet collection, gross pay calculation, overtime, tax withholding (federal, state, FICA), benefits deductions, compliance validation, and ACH direct deposit." -} \ No newline at end of file + "description": "Complete payroll processing workflow with timesheet collection, gross pay calculation, overtime, tax withholding (federal, state, FICA), benefits deductions, compliance validation, and ACH direct deposit.", + "source_path": "finance/payroll-processing", + "repo_path": "compliance/finance/payroll-processing-workflow" +} diff --git a/finance/payroll-processing/workflow.fz b/compliance/finance/payroll-processing-workflow/workflow.fz similarity index 100% rename from finance/payroll-processing/workflow.fz rename to compliance/finance/payroll-processing-workflow/workflow.fz diff --git a/compliance/finance/tax-filing-workflow/README.md b/compliance/finance/tax-filing-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..cf34686053368d66348e2232f542b2605d56cfd8 --- /dev/null +++ b/compliance/finance/tax-filing-workflow/README.md @@ -0,0 +1,19 @@ +# Tax Filing Workflow + +Corporate tax filing workflow with taxable income calculation, deductions, tax credits, variance review, and electronic or paper filing to IRS with receipt confirmation. + +**Template ID:** `tax-filing-workflow` +**Kind:** workflow +**Source domain:** finance +**Primary use case:** compliance +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 19 +**Lanes:** 3 +**Tags:** [tax-filing, corporate-tax, tax-calculation, irs-efile, tax-credits, deductions, compliance] +**Source path:** `finance/tax-filing` +**Repo path:** `compliance/finance/tax-filing-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/compliance/finance/tax-filing-workflow/metadata.json b/compliance/finance/tax-filing-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..89f4c531c3dde1f1e43e76a9bda474c902e18542 --- /dev/null +++ b/compliance/finance/tax-filing-workflow/metadata.json @@ -0,0 +1,27 @@ +{ + "template_id": "tax-filing-workflow", + "workflow_id": "tax-filing", + "title": "Tax Filing Workflow", + "kind": "workflow", + "source_domain": "finance", + "primary_use_case": "compliance", + "secondary_use_cases": [], + "use_cases": [ + "compliance" + ], + "complexity": 4, + "num_nodes": 19, + "num_lanes": 3, + "tags": [ + "tax-filing", + "corporate-tax", + "tax-calculation", + "irs-efile", + "tax-credits", + "deductions", + "compliance" + ], + "description": "Corporate tax filing workflow with taxable income calculation, deductions, tax credits, variance review, and electronic or paper filing to IRS with receipt confirmation.", + "source_path": "finance/tax-filing", + "repo_path": "compliance/finance/tax-filing-workflow" +} diff --git a/finance/tax-filing/workflow.fz b/compliance/finance/tax-filing-workflow/workflow.fz similarity index 100% rename from finance/tax-filing/workflow.fz rename to compliance/finance/tax-filing-workflow/workflow.fz diff --git a/compliance/finance/yearly-audit-workflow/README.md b/compliance/finance/yearly-audit-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..8fdb8faca7939e56e7c3b15c01e8a3f714d707e0 --- /dev/null +++ b/compliance/finance/yearly-audit-workflow/README.md @@ -0,0 +1,19 @@ +# Yearly Audit Workflow + +Annual financial audit workflow with external auditor engagement, document preparation, fieldwork coordination, findings remediation, and management letter response. + +**Template ID:** `yearly-audit-workflow` +**Kind:** workflow +**Source domain:** finance +**Primary use case:** compliance +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [annual-audit, external-auditors, sox-compliance, financial-statements, audit-findings, management-letter] +**Source path:** `finance/yearly-audit` +**Repo path:** `compliance/finance/yearly-audit-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/compliance/finance/yearly-audit-workflow/metadata.json b/compliance/finance/yearly-audit-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..73e972f50beeb988c988bd28b1d3efac24b8c81c --- /dev/null +++ b/compliance/finance/yearly-audit-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "yearly-audit-workflow", + "workflow_id": "yearly-audit", + "title": "Yearly Audit Workflow", + "kind": "workflow", + "source_domain": "finance", + "primary_use_case": "compliance", + "secondary_use_cases": [], + "use_cases": [ + "compliance" + ], + "complexity": 4, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "annual-audit", + "external-auditors", + "sox-compliance", + "financial-statements", + "audit-findings", + "management-letter" + ], + "description": "Annual financial audit workflow with external auditor engagement, document preparation, fieldwork coordination, findings remediation, and management letter response.", + "source_path": "finance/yearly-audit", + "repo_path": "compliance/finance/yearly-audit-workflow" +} diff --git a/finance/yearly-audit/workflow.fz b/compliance/finance/yearly-audit-workflow/workflow.fz similarity index 100% rename from finance/yearly-audit/workflow.fz rename to compliance/finance/yearly-audit-workflow/workflow.fz diff --git a/compliance/hr/training-enrollment-workflow/README.md b/compliance/hr/training-enrollment-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..be91013d0a02bf06a8fc7568933c2ee2786685d5 --- /dev/null +++ b/compliance/hr/training-enrollment-workflow/README.md @@ -0,0 +1,19 @@ +# Training Enrollment Workflow + +Training enrollment workflow with course catalog browsing, manager approval, LMS registration, completion tracking, and certification management. + +**Template ID:** `training-enrollment-workflow` +**Kind:** workflow +**Source domain:** hr +**Primary use case:** compliance +**Secondary use cases:** None +**Complexity:** 2/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [training-enrollment, learning-management, lms, professional-development, compliance-training, certification] +**Source path:** `hr/training-enrollment` +**Repo path:** `compliance/hr/training-enrollment-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/hr/training-enrollment/metadata.json b/compliance/hr/training-enrollment-workflow/metadata.json similarity index 50% rename from hr/training-enrollment/metadata.json rename to compliance/hr/training-enrollment-workflow/metadata.json index 6209c4d6f2795763b5ac1a3c372f9531d2669b4c..d5f262f2baf34ac185892f79312c3b6a6453c9e3 100644 --- a/hr/training-enrollment/metadata.json +++ b/compliance/hr/training-enrollment-workflow/metadata.json @@ -1,6 +1,14 @@ { + "template_id": "training-enrollment-workflow", "workflow_id": "training-enrollment", - "domain": "hr", + "title": "Training Enrollment Workflow", + "kind": "workflow", + "source_domain": "hr", + "primary_use_case": "compliance", + "secondary_use_cases": [], + "use_cases": [ + "compliance" + ], "complexity": 2, "num_nodes": 7, "num_lanes": 2, @@ -12,5 +20,7 @@ "compliance-training", "certification" ], - "description": "Training enrollment workflow with course catalog browsing, manager approval, LMS registration, completion tracking, and certification management." -} \ No newline at end of file + "description": "Training enrollment workflow with course catalog browsing, manager approval, LMS registration, completion tracking, and certification management.", + "source_path": "hr/training-enrollment", + "repo_path": "compliance/hr/training-enrollment-workflow" +} diff --git a/hr/training-enrollment/workflow.fz b/compliance/hr/training-enrollment-workflow/workflow.fz similarity index 100% rename from hr/training-enrollment/workflow.fz rename to compliance/hr/training-enrollment-workflow/workflow.fz diff --git a/compliance/logistics/cycle-counting-workflow/README.md b/compliance/logistics/cycle-counting-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..b7d2a4b4033ff00d2552cf7383c37900b7705411 --- /dev/null +++ b/compliance/logistics/cycle-counting-workflow/README.md @@ -0,0 +1,19 @@ +# Cycle Counting Workflow + +Inventory cycle counting workflow with ABC classification, count scheduling, variance investigation, adjustment approval, and inventory accuracy tracking. + +**Template ID:** `cycle-counting-workflow` +**Kind:** workflow +**Source domain:** logistics +**Primary use case:** compliance +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [cycle-counting, inventory-accuracy, abc-analysis, variance-investigation, perpetual-inventory, audit] +**Source path:** `logistics/cycle-counting` +**Repo path:** `compliance/logistics/cycle-counting-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/compliance/logistics/cycle-counting-workflow/metadata.json b/compliance/logistics/cycle-counting-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..e6d36453b9e8a253a34f988fb19e5525d7f358a1 --- /dev/null +++ b/compliance/logistics/cycle-counting-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "cycle-counting-workflow", + "workflow_id": "cycle-counting", + "title": "Cycle Counting Workflow", + "kind": "workflow", + "source_domain": "logistics", + "primary_use_case": "compliance", + "secondary_use_cases": [], + "use_cases": [ + "compliance" + ], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "cycle-counting", + "inventory-accuracy", + "abc-analysis", + "variance-investigation", + "perpetual-inventory", + "audit" + ], + "description": "Inventory cycle counting workflow with ABC classification, count scheduling, variance investigation, adjustment approval, and inventory accuracy tracking.", + "source_path": "logistics/cycle-counting", + "repo_path": "compliance/logistics/cycle-counting-workflow" +} diff --git a/logistics/cycle-counting/workflow.fz b/compliance/logistics/cycle-counting-workflow/workflow.fz similarity index 100% rename from logistics/cycle-counting/workflow.fz rename to compliance/logistics/cycle-counting-workflow/workflow.fz diff --git a/compliance/logistics/fleet-maintenance-workflow/README.md b/compliance/logistics/fleet-maintenance-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..d4da6775d2ca1bfe4befdf80c5b40f50ad6dc05f --- /dev/null +++ b/compliance/logistics/fleet-maintenance-workflow/README.md @@ -0,0 +1,19 @@ +# Fleet Maintenance Workflow + +Fleet maintenance workflow with preventive maintenance scheduling, vehicle inspection, work order creation, parts ordering, and DOT compliance tracking. + +**Template ID:** `fleet-maintenance-workflow` +**Kind:** workflow +**Source domain:** logistics +**Primary use case:** compliance +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [fleet-maintenance, preventive-maintenance, vehicle-inspection, work-order, dot-compliance, telematics] +**Source path:** `logistics/fleet-maintenance` +**Repo path:** `compliance/logistics/fleet-maintenance-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/compliance/logistics/fleet-maintenance-workflow/metadata.json b/compliance/logistics/fleet-maintenance-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..c241a3625ec43d9f1b75d4725eb4298e29077c58 --- /dev/null +++ b/compliance/logistics/fleet-maintenance-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "fleet-maintenance-workflow", + "workflow_id": "fleet-maintenance", + "title": "Fleet Maintenance Workflow", + "kind": "workflow", + "source_domain": "logistics", + "primary_use_case": "compliance", + "secondary_use_cases": [], + "use_cases": [ + "compliance" + ], + "complexity": 3, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "fleet-maintenance", + "preventive-maintenance", + "vehicle-inspection", + "work-order", + "dot-compliance", + "telematics" + ], + "description": "Fleet maintenance workflow with preventive maintenance scheduling, vehicle inspection, work order creation, parts ordering, and DOT compliance tracking.", + "source_path": "logistics/fleet-maintenance", + "repo_path": "compliance/logistics/fleet-maintenance-workflow" +} diff --git a/logistics/fleet-maintenance/workflow.fz b/compliance/logistics/fleet-maintenance-workflow/workflow.fz similarity index 100% rename from logistics/fleet-maintenance/workflow.fz rename to compliance/logistics/fleet-maintenance-workflow/workflow.fz diff --git a/compliance/patterns/audit-trail-workflow/README.md b/compliance/patterns/audit-trail-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..0f7be31a91e5d63a7305b75b9cf3eeabe179fd8a --- /dev/null +++ b/compliance/patterns/audit-trail-workflow/README.md @@ -0,0 +1,19 @@ +# Audit Trail Workflow + +This workflow models logging all important actions for compliance. + +**Template ID:** `audit-trail-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** compliance +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 13 +**Lanes:** 4 +**Tags:** [audit, trail, patterns, decision, loop] +**Source path:** `patterns/audit-trail` +**Repo path:** `compliance/patterns/audit-trail-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/compliance/patterns/audit-trail-workflow/metadata.json b/compliance/patterns/audit-trail-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..4cfc4009fd5ca45f1cf6271d09c8fc2295627c20 --- /dev/null +++ b/compliance/patterns/audit-trail-workflow/metadata.json @@ -0,0 +1,25 @@ +{ + "template_id": "audit-trail-workflow", + "workflow_id": "audit-trail", + "title": "Audit Trail Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "compliance", + "secondary_use_cases": [], + "use_cases": [ + "compliance" + ], + "complexity": 4, + "num_nodes": 13, + "num_lanes": 4, + "tags": [ + "audit", + "trail", + "patterns", + "decision", + "loop" + ], + "description": "This workflow models logging all important actions for compliance.", + "source_path": "patterns/audit-trail", + "repo_path": "compliance/patterns/audit-trail-workflow" +} diff --git a/patterns/audit-trail/workflow.fz b/compliance/patterns/audit-trail-workflow/workflow.fz similarity index 100% rename from patterns/audit-trail/workflow.fz rename to compliance/patterns/audit-trail-workflow/workflow.fz diff --git a/compliance/patterns/event-sourcing-workflow/README.md b/compliance/patterns/event-sourcing-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..3669b36a6a98891220a4bfccab7f208234d190d6 --- /dev/null +++ b/compliance/patterns/event-sourcing-workflow/README.md @@ -0,0 +1,19 @@ +# Event Sourcing Workflow + +Event sourcing pattern with event capture, event store persistence, aggregate reconstruction, snapshot optimization, and temporal state queries. + +**Template ID:** `event-sourcing-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** compliance +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [event-sourcing, event-store, aggregate, replay, audit-log, temporal-query] +**Source path:** `patterns/event-sourcing` +**Repo path:** `compliance/patterns/event-sourcing-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/compliance/patterns/event-sourcing-workflow/metadata.json b/compliance/patterns/event-sourcing-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..ab9be4512b125e9a376a037e889e4f9153278962 --- /dev/null +++ b/compliance/patterns/event-sourcing-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "event-sourcing-workflow", + "workflow_id": "event-sourcing", + "title": "Event Sourcing Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "compliance", + "secondary_use_cases": [], + "use_cases": [ + "compliance" + ], + "complexity": 4, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "event-sourcing", + "event-store", + "aggregate", + "replay", + "audit-log", + "temporal-query" + ], + "description": "Event sourcing pattern with event capture, event store persistence, aggregate reconstruction, snapshot optimization, and temporal state queries.", + "source_path": "patterns/event-sourcing", + "repo_path": "compliance/patterns/event-sourcing-workflow" +} diff --git a/patterns/event-sourcing/workflow.fz b/compliance/patterns/event-sourcing-workflow/workflow.fz similarity index 100% rename from patterns/event-sourcing/workflow.fz rename to compliance/patterns/event-sourcing-workflow/workflow.fz diff --git a/context-management/architecture/context-episodic-memory/README.md b/context-management/architecture/context-episodic-memory/README.md new file mode 100644 index 0000000000000000000000000000000000000000..60227bdfbc1676b1d4d2c5bbc097515e1ae85318 --- /dev/null +++ b/context-management/architecture/context-episodic-memory/README.md @@ -0,0 +1,19 @@ +# Context Management - Episodic Memory + +Learning-from-experience pattern where every task run becomes an episode with input, actions, and outcome. Before tackling a new task, the agent fetches similar episodes and uses them as hints. Over time, the agent feels like it's learning instead of repeating the same failed plans. + +**Template ID:** `context-episodic-memory` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** context-management +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 11 +**Lanes:** 4 +**Tags:** [context-management, episodic-memory, learning, experience, architecture-diagram] +**Source path:** `` +**Repo path:** `context-management/architecture/context-episodic-memory` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/context-management/architecture/context-episodic-memory/metadata.json b/context-management/architecture/context-episodic-memory/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..efb14789cd8ed34644e3e07199728d16775bc322 --- /dev/null +++ b/context-management/architecture/context-episodic-memory/metadata.json @@ -0,0 +1,25 @@ +{ + "template_id": "context-episodic-memory", + "workflow_id": "context-episodic-memory", + "title": "Context Management - Episodic Memory", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "context-management", + "secondary_use_cases": [], + "use_cases": [ + "context-management" + ], + "complexity": 3, + "num_nodes": 11, + "num_lanes": 4, + "tags": [ + "context-management", + "episodic-memory", + "learning", + "experience", + "architecture-diagram" + ], + "description": "Learning-from-experience pattern where every task run becomes an episode with input, actions, and outcome. Before tackling a new task, the agent fetches similar episodes and uses them as hints. Over time, the agent feels like it's learning instead of repeating the same failed plans.", + "source_path": "", + "repo_path": "context-management/architecture/context-episodic-memory" +} diff --git a/context-management/architecture/context-episodic-memory/workflow.fz b/context-management/architecture/context-episodic-memory/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..5122354d73495b4cd0507241a1769c00e3e982e6 --- /dev/null +++ b/context-management/architecture/context-episodic-memory/workflow.fz @@ -0,0 +1,38 @@ +User { + n1: circle label="1. Submit task" + n2: rectangle label="12. See result" + n1.handle(right) -> Agent.n3.handle(left) + Agent.n9.handle(right) -> n2.handle(left) +} + +Agent { + n3: rectangle label="1. Receive task" + n4: rectangle label="2. Search similar episodes" + n5: rectangle label="4. Past lessons" + n6: rectangle label="5. Execute plan" + n7: rectangle label="6. Capture outcome" + n8: rectangle label="7. Send episode for scoring" + n9: rectangle label="11. Return result" + n3.handle(right) -> n4.handle(left) + n5.handle(right) -> n6.handle(left) + n6.handle(right) -> n7.handle(left) + n7.handle(right) -> n8.handle(left) + n8.handle(right) -> Evaluator.n13.handle(left) [label="8. Outcome"] + EpisodeStore.n12.handle(right) -> n9.handle(left) [label="11.b Outcome"] +} + +EpisodeStore { + n10: rectangle label="3. Episode search" + n11: rectangle label="3.2 Search similar episodes" + n12: rectangle label="10. Episode + lesson" + Agent.n4.handle(right) -> n10.handle(left) [label="2. Search similar episodes"] + n10.handle(right) -> n11.handle(left) [label="3. Episode search"] + n11.handle(right) -> Agent.n5.handle(left) [label="4. Past lessons"] + Evaluator.n14.handle(right) -> n12.handle(left) [label="10. Episode + lesson"] +} + +Evaluator { + n13: rectangle label="9. Score outcome" + n14: rectangle label="9. Extract lesson" + n13.handle(right) -> n14.handle(left) +} diff --git a/context-management/architecture/context-hybrid-retrieval-memory/README.md b/context-management/architecture/context-hybrid-retrieval-memory/README.md new file mode 100644 index 0000000000000000000000000000000000000000..d88651e514eb4a59f241013bb7d194bc7bceb918 --- /dev/null +++ b/context-management/architecture/context-hybrid-retrieval-memory/README.md @@ -0,0 +1,19 @@ +# Context Management - Hybrid Retrieval Memory + +Multi-modal retrieval pattern combining semantic search, exact/keyword search, and recency search in parallel. Results are merged and reranked into a single context set. Much higher recall because the agent can find both fuzzy references and exact entities. Essential for comprehensive knowledge retrieval. + +**Template ID:** `context-hybrid-retrieval-memory` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** context-management +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 11 +**Lanes:** 5 +**Tags:** [context-management, hybrid-retrieval, semantic, keyword, recency, architecture-diagram] +**Source path:** `` +**Repo path:** `context-management/architecture/context-hybrid-retrieval-memory` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/context-management/architecture/context-hybrid-retrieval-memory/metadata.json b/context-management/architecture/context-hybrid-retrieval-memory/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..0f97634580f8de329e7e991d762396b14fc6548e --- /dev/null +++ b/context-management/architecture/context-hybrid-retrieval-memory/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "context-hybrid-retrieval-memory", + "workflow_id": "context-hybrid-retrieval-memory", + "title": "Context Management - Hybrid Retrieval Memory", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "context-management", + "secondary_use_cases": [], + "use_cases": [ + "context-management" + ], + "complexity": 4, + "num_nodes": 11, + "num_lanes": 5, + "tags": [ + "context-management", + "hybrid-retrieval", + "semantic", + "keyword", + "recency", + "architecture-diagram" + ], + "description": "Multi-modal retrieval pattern combining semantic search, exact/keyword search, and recency search in parallel. Results are merged and reranked into a single context set. Much higher recall because the agent can find both fuzzy references and exact entities. Essential for comprehensive knowledge retrieval.", + "source_path": "", + "repo_path": "context-management/architecture/context-hybrid-retrieval-memory" +} diff --git a/context-management/architecture/context-hybrid-retrieval-memory/workflow.fz b/context-management/architecture/context-hybrid-retrieval-memory/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..52e08387f774a7fa493b3b09d6a8370792ec4b4a --- /dev/null +++ b/context-management/architecture/context-hybrid-retrieval-memory/workflow.fz @@ -0,0 +1,52 @@ +User { + n1: circle label="Ask mixed query" + n2: rectangle label="See answer" + n1.handle(right) -> Agent.n3.handle(left) + Agent.n18.handle(right) -> n2.handle(left) +} + +Agent { + n3: rectangle label="Plan retrieval strategy" + n4: rectangle label="Trigger semantic search" + n5: rectangle label="Trigger keyword search" + n6: rectangle label="Trigger recent-history search" + n7: rectangle label="Merge and rerank" + n8: rectangle label="Build prompt with hybrid context" + n9: rectangle label="Call LLM" + n18: rectangle label="Return answer" + n3.handle(bottom) -> n4.handle(top) [label="Semantic"] + n3.handle(right) -> n5.handle(left) [label="Keyword"] + n3.handle(left) -> n6.handle(right) [label="Recent"] + n7.handle(right) -> n8.handle(left) + n8.handle(right) -> n9.handle(left) + n9.handle(right) -> LLM.n19.handle(left) +} + +Semantic { + n10: rectangle label="Vector search" + n11: rectangle label="Return semantic matches" + Agent.n4.handle(right) -> n10.handle(left) + n10.handle(right) -> n11.handle(left) + n11.handle(bottom) -> Agent.n7.handle(top) [label="Semantic"] +} + +Keyword { + n12: rectangle label="Exact/ID search" + n13: rectangle label="Return exact matches" + Agent.n5.handle(right) -> n12.handle(left) + n12.handle(right) -> n13.handle(left) + n13.handle(bottom) -> Agent.n7.handle(top) [label="Keyword"] +} + +Recent { + n14: rectangle label="Scan recent messages" + n15: rectangle label="Return recent matches" + Agent.n6.handle(right) -> n14.handle(left) + n14.handle(right) -> n15.handle(left) + n15.handle(bottom) -> Agent.n7.handle(top) [label="Recent"] +} + +LLM { + n19: rectangle label="Reason over hybrid context" + n19.handle(right) -> Agent.n18.handle(left) +} diff --git a/context-management/architecture/context-profile-memory/README.md b/context-management/architecture/context-profile-memory/README.md new file mode 100644 index 0000000000000000000000000000000000000000..c36fa40c00678a88e511ca137fc9a64f478da8f8 --- /dev/null +++ b/context-management/architecture/context-profile-memory/README.md @@ -0,0 +1,19 @@ +# Context Management - Profile Memory + +Identity-style memory pattern where profile data is loaded at session start. Each prompt combines system persona, user profile, and current message. New facts can be written back to profile memory. Small predictable overhead with big UX lift — the agent remembers your name, stack, tone, and constraints. + +**Template ID:** `context-profile-memory` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** context-management +**Secondary use cases:** None +**Complexity:** 2/5 +**Nodes:** 7 +**Lanes:** 3 +**Tags:** [context-management, profile-memory, identity, user-profile, architecture-diagram] +**Source path:** `` +**Repo path:** `context-management/architecture/context-profile-memory` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/context-management/architecture/context-profile-memory/metadata.json b/context-management/architecture/context-profile-memory/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..5b40525f3076eb7159b232720e90fa72d6c35722 --- /dev/null +++ b/context-management/architecture/context-profile-memory/metadata.json @@ -0,0 +1,25 @@ +{ + "template_id": "context-profile-memory", + "workflow_id": "context-profile-memory", + "title": "Context Management - Profile Memory", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "context-management", + "secondary_use_cases": [], + "use_cases": [ + "context-management" + ], + "complexity": 2, + "num_nodes": 7, + "num_lanes": 3, + "tags": [ + "context-management", + "profile-memory", + "identity", + "user-profile", + "architecture-diagram" + ], + "description": "Identity-style memory pattern where profile data is loaded at session start. Each prompt combines system persona, user profile, and current message. New facts can be written back to profile memory. Small predictable overhead with big UX lift — the agent remembers your name, stack, tone, and constraints.", + "source_path": "", + "repo_path": "context-management/architecture/context-profile-memory" +} diff --git a/context-management/architecture/context-profile-memory/workflow.fz b/context-management/architecture/context-profile-memory/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..a1d1506e2ee6574ebe4602d75e327fb28aeadb93 --- /dev/null +++ b/context-management/architecture/context-profile-memory/workflow.fz @@ -0,0 +1,33 @@ +User { + n1: circle label="Start session" + n2: rectangle label="Send request" + n3: rectangle label="See personalized reply" + n1.handle(right) -> n2.handle(left) + n2.handle(right) -> Agent.n4.handle(left) + Agent.n9.handle(right) -> n3.handle(left) +} + +Agent { + n4: rectangle label="Identify user" + n5: rectangle label="Load profile" + n6: rectangle label="Build prompt with profile" + n7: rectangle label="Call LLM" + n8: rectangle label="Optionally update profile" + n9: rectangle label="Return answer" + n4.handle(right) -> n5.handle(left) + n5.handle(right) -> n6.handle(left) + n6.handle(right) -> n7.handle(left) + n7.handle(right) -> LLM.n10.handle(left) + n8.handle(right) -> ProfileStore.n11.handle(left) [label="Write profile"] +} + +ProfileStore { + n11: rectangle label="Read/Write profile" + Agent.n5.handle(bottom) -> n11.handle(top) [label="Read profile"] + n11.handle(right) -> Agent.n5.handle(left) +} + +LLM { + n10: rectangle label="Generate answer using profile" + n10.handle(right) -> Agent.n9.handle(left) +} diff --git a/context-management/architecture/context-rolling-summary-memory/README.md b/context-management/architecture/context-rolling-summary-memory/README.md new file mode 100644 index 0000000000000000000000000000000000000000..bc7e990f81e0304681a5f6f2f51b3ef275261aca --- /dev/null +++ b/context-management/architecture/context-rolling-summary-memory/README.md @@ -0,0 +1,19 @@ +# Context Management - Rolling Summary Memory + +Compressed history pattern that keeps full history for a while, then when a threshold is hit, summarizes the last chunk and replaces detailed turns with a shorter summary message. Dramatically reduces prompt size on long-running chats while maintaining gist continuity. + +**Template ID:** `context-rolling-summary-memory` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** context-management +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 8 +**Lanes:** 4 +**Tags:** [context-management, rolling-summary, compression, memory, architecture-diagram] +**Source path:** `` +**Repo path:** `context-management/architecture/context-rolling-summary-memory` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/context-management/architecture/context-rolling-summary-memory/metadata.json b/context-management/architecture/context-rolling-summary-memory/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..554b34f06c79ec3859eb1ad1b32ef9ecdd2de399 --- /dev/null +++ b/context-management/architecture/context-rolling-summary-memory/metadata.json @@ -0,0 +1,25 @@ +{ + "template_id": "context-rolling-summary-memory", + "workflow_id": "context-rolling-summary-memory", + "title": "Context Management - Rolling Summary Memory", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "context-management", + "secondary_use_cases": [], + "use_cases": [ + "context-management" + ], + "complexity": 3, + "num_nodes": 8, + "num_lanes": 4, + "tags": [ + "context-management", + "rolling-summary", + "compression", + "memory", + "architecture-diagram" + ], + "description": "Compressed history pattern that keeps full history for a while, then when a threshold is hit, summarizes the last chunk and replaces detailed turns with a shorter summary message. Dramatically reduces prompt size on long-running chats while maintaining gist continuity.", + "source_path": "", + "repo_path": "context-management/architecture/context-rolling-summary-memory" +} diff --git a/context-management/architecture/context-rolling-summary-memory/workflow.fz b/context-management/architecture/context-rolling-summary-memory/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..7d34ea4ffe48e35fa8205e29d2c532370aae8ec8 --- /dev/null +++ b/context-management/architecture/context-rolling-summary-memory/workflow.fz @@ -0,0 +1,39 @@ +User { + n1: circle label="New message" + n2: rectangle label="See reply" + n1.handle(right) -> Agent.n3.handle(left) + Agent.n12.handle(right) -> n2.handle(left) +} + +Agent { + n3: rectangle label="Append turn to history" + n4: diamond label="Summary threshold reached?" + n5: rectangle label="Request latest summary" + n6: rectangle label="Build compact prompt" + n7: rectangle label="Call LLM" + n12: rectangle label="Return answer" + n3.handle(right) -> n4.handle(left) + n4.handle(right) -> Summarizer.n8.handle(left) [label="Yes"] + n4.handle(bottom) -> n5.handle(top) [label="No"] + n5.handle(bottom) -> SummaryStore.n10.handle(top) [label="Load summary"] + n6.handle(right) -> n7.handle(left) + n7.handle(right) -> LLM.n13.handle(left) +} + +Summarizer { + n8: rectangle label="Summarize recent turns" + n9: rectangle label="Store summary snapshot" + n8.handle(right) -> n9.handle(left) + n9.handle(bottom) -> SummaryStore.n11.handle(top) [label="Save summary"] +} + +SummaryStore { + n10: rectangle label="Read latest summary" + n11: rectangle label="Write summary" + n10.handle(right) -> Agent.n6.handle(left) +} + +LLM { + n13: rectangle label="Generate answer" + n13.handle(right) -> Agent.n12.handle(left) +} diff --git a/context-management/architecture/context-semantic-memory/README.md b/context-management/architecture/context-semantic-memory/README.md new file mode 100644 index 0000000000000000000000000000000000000000..b7b3f8fbbfe6eef7f38aabb85e41ac7eae9e7061 --- /dev/null +++ b/context-management/architecture/context-semantic-memory/README.md @@ -0,0 +1,19 @@ +# Context Management - Semantic Memory + +Vector-based memory pattern where text is chunked, embedded, and stored in a vector database. On query, the question is embedded, a vector search is run, candidates are reranked, and top results are injected into the prompt. Where the agent feels like it remembers everything without hallucinating. + +**Template ID:** `context-semantic-memory` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** context-management +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 9 +**Lanes:** 4 +**Tags:** [context-management, semantic-memory, vector-db, embeddings, rag, architecture-diagram] +**Source path:** `` +**Repo path:** `context-management/architecture/context-semantic-memory` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/context-management/architecture/context-semantic-memory/metadata.json b/context-management/architecture/context-semantic-memory/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..ce2b39557b786f586f9e82954afb4b685099273d --- /dev/null +++ b/context-management/architecture/context-semantic-memory/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "context-semantic-memory", + "workflow_id": "context-semantic-memory", + "title": "Context Management - Semantic Memory", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "context-management", + "secondary_use_cases": [], + "use_cases": [ + "context-management" + ], + "complexity": 3, + "num_nodes": 9, + "num_lanes": 4, + "tags": [ + "context-management", + "semantic-memory", + "vector-db", + "embeddings", + "rag", + "architecture-diagram" + ], + "description": "Vector-based memory pattern where text is chunked, embedded, and stored in a vector database. On query, the question is embedded, a vector search is run, candidates are reranked, and top results are injected into the prompt. Where the agent feels like it remembers everything without hallucinating.", + "source_path": "", + "repo_path": "context-management/architecture/context-semantic-memory" +} diff --git a/context-management/architecture/context-semantic-memory/workflow.fz b/context-management/architecture/context-semantic-memory/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..139e0f97efdca6d51bbec2f00d974867feddfc73 --- /dev/null +++ b/context-management/architecture/context-semantic-memory/workflow.fz @@ -0,0 +1,41 @@ +User { + n1: circle label="Ask question" + n2: rectangle label="See answer with references" + n1.handle(right) -> Agent.n3.handle(left) + Agent.n12.handle(right) -> n2.handle(left) +} + +Agent { + n3: rectangle label="Receive query" + n4: rectangle label="Build memory search query" + n5: rectangle label="Send to retriever" + n6: rectangle label="Inject recalled memories" + n7: rectangle label="Assemble final prompt" + n8: rectangle label="Call LLM" + n12: rectangle label="Return answer" + n3.handle(right) -> n4.handle(left) + n4.handle(right) -> n5.handle(left) + n5.handle(bottom) -> Retriever.n9.handle(top) [label="Semantic query"] + n6.handle(right) -> n7.handle(left) + n7.handle(right) -> n8.handle(left) + n8.handle(right) -> LLM.n13.handle(left) +} + +Retriever { + n9: rectangle label="Embed query" + n10: rectangle label="Search vector store" + n11: rectangle label="Rerank top memories" + n9.handle(right) -> n10.handle(left) + n10.handle(right) -> n11.handle(left) + n11.handle(top) -> Agent.n6.handle(bottom) [label="Top memories"] +} + +VectorDB { + n13: rectangle label="Vector index" + Retriever.n10.handle(bottom) -> n13.handle(top) [label="Similarity search"] +} + +LLM { + n14: rectangle label="Answer using recalled facts" + n14.handle(right) -> Agent.n12.handle(left) +} diff --git a/context-management/architecture/context-session-memory/README.md b/context-management/architecture/context-session-memory/README.md new file mode 100644 index 0000000000000000000000000000000000000000..98848a9a5b0b487340515c7fa34d62147761cbd7 --- /dev/null +++ b/context-management/architecture/context-session-memory/README.md @@ -0,0 +1,19 @@ +# Context Management - Session Memory + +Short-term context pattern where the channel sends new messages plus recent history. The agent runtime merges that with local session state, assembles the prompt, and persists the response back into history. Simple but cost and latency grow with history length. + +**Template ID:** `context-session-memory` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** context-management +**Secondary use cases:** None +**Complexity:** 2/5 +**Nodes:** 9 +**Lanes:** 3 +**Tags:** [context-management, session-memory, short-term, memory, architecture-diagram] +**Source path:** `` +**Repo path:** `context-management/architecture/context-session-memory` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/context-management/architecture/context-session-memory/metadata.json b/context-management/architecture/context-session-memory/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..5a683d6f5d3fc177dc0f439063cf7869f27da673 --- /dev/null +++ b/context-management/architecture/context-session-memory/metadata.json @@ -0,0 +1,25 @@ +{ + "template_id": "context-session-memory", + "workflow_id": "context-session-memory", + "title": "Context Management - Session Memory", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "context-management", + "secondary_use_cases": [], + "use_cases": [ + "context-management" + ], + "complexity": 2, + "num_nodes": 9, + "num_lanes": 3, + "tags": [ + "context-management", + "session-memory", + "short-term", + "memory", + "architecture-diagram" + ], + "description": "Short-term context pattern where the channel sends new messages plus recent history. The agent runtime merges that with local session state, assembles the prompt, and persists the response back into history. Simple but cost and latency grow with history length.", + "source_path": "", + "repo_path": "context-management/architecture/context-session-memory" +} diff --git a/context-management/architecture/context-session-memory/workflow.fz b/context-management/architecture/context-session-memory/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..03199121603f200914926ec0fbcfd78a85daf144 --- /dev/null +++ b/context-management/architecture/context-session-memory/workflow.fz @@ -0,0 +1,39 @@ +User { # User +n1: circle label="User sends message" +n2: rectangle label="See agent reply" + +n1.handle(right) -> Agent.n3.handle(left) +Agent.n8.handle(right) -> n2.handle(left) +} + +Agent { # Agent +n3: rectangle label="Receive message" +n4: rectangle label="Load session history" +n5: rectangle label="Assemble prompt" +n6: rectangle label="Call LLM" +n7: rectangle label="Receive LLM reply" +n8: rectangle label="Return answer to user" +n9: rectangle label="Persist updated session" + +n3.handle(right) -> n4.handle(left) +n4.handle(right) -> n5.handle(left) +n5.handle(right) -> n6.handle(left) +n6.handle(right) -> LLM.n10.handle(left) +n7.handle(right) -> n8.handle(left) +n8.handle(bottom) -> n9.handle(top) [label="Save session"] +} + +Memory { # Session Store +n11: rectangle label="Read session state" +n12: rectangle label="Write session state" + +n3.handle(bottom) -> n11.handle(top) [label="Get history"] +n11.handle(right) -> Agent.n4.handle(left) +Agent.n9.handle(bottom) -> n12.handle(top) [label="Store history"] +} + +LLM { # LLM +n10: rectangle label="Generate answer" + +n10.handle(right) -> Agent.n7.handle(left) +} diff --git a/delivery/architecture/agentic-sequential-pipeline/README.md b/delivery/architecture/agentic-sequential-pipeline/README.md new file mode 100644 index 0000000000000000000000000000000000000000..96c44d4ee7f0514920b8aca708fd582f0d067522 --- /dev/null +++ b/delivery/architecture/agentic-sequential-pipeline/README.md @@ -0,0 +1,19 @@ +# Agentic Sequential Pipeline Architecture + +A sequential pipeline multi-agent architecture where agents are arranged in a strict sequence. Each agent transforms or enriches the output of the previous one, then passes it forward. No central orchestrator — the flow is deterministic like an assembly line. + +**Template ID:** `agentic-sequential-pipeline` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** delivery +**Secondary use cases:** agentic, ai-orchestration +**Complexity:** 2/5 +**Nodes:** 5 +**Lanes:** 5 +**Tags:** [agentic, sequential-pipeline, multi-agent, assembly-line, architecture-diagram, ai-team] +**Source path:** `` +**Repo path:** `delivery/architecture/agentic-sequential-pipeline` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/delivery/architecture/agentic-sequential-pipeline/metadata.json b/delivery/architecture/agentic-sequential-pipeline/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..81cfe6dca8f6a7a5812b3b635b499bf1f722d818 --- /dev/null +++ b/delivery/architecture/agentic-sequential-pipeline/metadata.json @@ -0,0 +1,31 @@ +{ + "template_id": "agentic-sequential-pipeline", + "workflow_id": "agentic-sequential-pipeline", + "title": "Agentic Sequential Pipeline Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "delivery", + "secondary_use_cases": [ + "agentic", + "ai-orchestration" + ], + "use_cases": [ + "delivery", + "agentic", + "ai-orchestration" + ], + "complexity": 2, + "num_nodes": 5, + "num_lanes": 5, + "tags": [ + "agentic", + "sequential-pipeline", + "multi-agent", + "assembly-line", + "architecture-diagram", + "ai-team" + ], + "description": "A sequential pipeline multi-agent architecture where agents are arranged in a strict sequence. Each agent transforms or enriches the output of the previous one, then passes it forward. No central orchestrator — the flow is deterministic like an assembly line.", + "source_path": "", + "repo_path": "delivery/architecture/agentic-sequential-pipeline" +} diff --git a/delivery/architecture/agentic-sequential-pipeline/workflow.fz b/delivery/architecture/agentic-sequential-pipeline/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..54a91b47cff3c972df80c4048b6a9fdf787be58f --- /dev/null +++ b/delivery/architecture/agentic-sequential-pipeline/workflow.fz @@ -0,0 +1,23 @@ +research_agent {# Research Agent + n1: rectangle label="Summarize Sources (RAG)" + n1.handle(right) -> outline_agent.n2.handle(left) [label="Raw Sources"] +} + +outline_agent {# Outline Agent + n2: rectangle label="Structure Headings" + n2.handle(right) -> writer_agent.n3.handle(left) [label="Document Outline"] +} + +writer_agent {# Writer Agent + n3: rectangle label="Draft Full Text" + n3.handle(right) -> editor_agent.n4.handle(left) [label="First Draft"] +} + +editor_agent {# Editor Agent + n4: rectangle label="Refine Tone & Grammar" + n4.handle(right) -> seo_agent.n5.handle(left) [label="Refined Text"] +} + +seo_agent {# SEO Agent + n5: rectangle label="Add Keywords & Meta" +} diff --git a/delivery/architecture/ai-native-parallel-fan-out-architecture/README.md b/delivery/architecture/ai-native-parallel-fan-out-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..49d832ee5c95cf504ecc8090d9a2f85c2b4befb7 --- /dev/null +++ b/delivery/architecture/ai-native-parallel-fan-out-architecture/README.md @@ -0,0 +1,19 @@ +# AI-Native Parallel Fan-Out Architecture + +A parallel fan-out architecture that runs multiple agents simultaneously on independent checks (style, security, performance) and then merges results. This is a standard multi-agent design approach for throughput, mapping cleanly to CI/CD, incident response, and research. Fan-in reconciliation becomes the subtle part. + +**Template ID:** `ai-native-parallel-fan-out-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** delivery +**Secondary use cases:** agentic, ai-orchestration +**Complexity:** 3/5 +**Nodes:** 11 +**Lanes:** 2 +**Tags:** [ai-native, parallel-fan-out, agentic-ai, map-reduce, ci-cd, architecture-diagram] +**Source path:** `` +**Repo path:** `delivery/architecture/ai-native-parallel-fan-out-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/delivery/architecture/ai-native-parallel-fan-out-architecture/metadata.json b/delivery/architecture/ai-native-parallel-fan-out-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..fe048a1a855c6803ef5d0bf99d143324d5af1179 --- /dev/null +++ b/delivery/architecture/ai-native-parallel-fan-out-architecture/metadata.json @@ -0,0 +1,31 @@ +{ + "template_id": "ai-native-parallel-fan-out-architecture", + "workflow_id": "ai-native-parallel-fan-out-architecture", + "title": "AI-Native Parallel Fan-Out Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "delivery", + "secondary_use_cases": [ + "agentic", + "ai-orchestration" + ], + "use_cases": [ + "delivery", + "agentic", + "ai-orchestration" + ], + "complexity": 3, + "num_nodes": 11, + "num_lanes": 2, + "tags": [ + "ai-native", + "parallel-fan-out", + "agentic-ai", + "map-reduce", + "ci-cd", + "architecture-diagram" + ], + "description": "A parallel fan-out architecture that runs multiple agents simultaneously on independent checks (style, security, performance) and then merges results. This is a standard multi-agent design approach for throughput, mapping cleanly to CI/CD, incident response, and research. Fan-in reconciliation becomes the subtle part.", + "source_path": "", + "repo_path": "delivery/architecture/ai-native-parallel-fan-out-architecture" +} diff --git a/delivery/architecture/ai-native-parallel-fan-out-architecture/workflow.fz b/delivery/architecture/ai-native-parallel-fan-out-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..9315f978347b47a41b1df38ab10e4aca2cf0913a --- /dev/null +++ b/delivery/architecture/ai-native-parallel-fan-out-architecture/workflow.fz @@ -0,0 +1,29 @@ +Trigger { # Trigger +n1: circle label:"Start" +n2: rectangle label:"PR submitted for review" +n1.handle(right) -> n2.handle(left) +n2.handle(bottom) -> Coordinator.n3.handle(top) [label="PR payload"] +} +Coordinator { # Coordinator Agent +n3: rectangle label:"Fan out to reviewers" +n4: rectangle label:"Gather all reviews" +n5: diamond label:"All passed?" +n6: rectangle label:"Approve PR" +n7: rectangle label:"Request changes" +n8: circle label:"Done" +n3.handle(bottom) -> Reviewers.n9.handle(top) [label="Style check"] +n3.handle(bottom) -> Reviewers.n10.handle(top) [label="Security audit"] +n3.handle(bottom) -> Reviewers.n11.handle(top) [label="Perf analysis"] +n4.handle(right) -> n5.handle(left) +n5.handle(right) -> n6.handle(left) [label="Yes"] +n5.handle(bottom) -> n7.handle(top) [label="No"] +n6.handle(right) -> n8.handle(left) +} +Reviewers { # Parallel Review Agents +n9: rectangle label:"Style Agent" +n10: rectangle label:"Security Agent" +n11: rectangle label:"Performance Agent" +n9.handle(top) -> Coordinator.n4.handle(bottom) [label="Style report"] +n10.handle(top) -> Coordinator.n4.handle(bottom) [label="Security report"] +n11.handle(top) -> Coordinator.n4.handle(bottom) [label="Perf report"] +} diff --git a/delivery/architecture/ai-native-sequential-pipeline-architecture/README.md b/delivery/architecture/ai-native-sequential-pipeline-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..ac7424e50200e290efc908962b8a2a19d95f5463 --- /dev/null +++ b/delivery/architecture/ai-native-sequential-pipeline-architecture/README.md @@ -0,0 +1,19 @@ +# AI-Native Sequential Pipeline Architecture + +A sequential pipeline architecture chaining multiple agents in a fixed order (parse → enrich → analyze → format), which is a common 'LLM microservices' setup when each step can be isolated. This structure is often used in document processing and ETL-like workflows because each step is testable and predictable. + +**Template ID:** `ai-native-sequential-pipeline-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** delivery +**Secondary use cases:** agentic, ai-orchestration +**Complexity:** 2/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [ai-native, sequential-pipeline, agentic-ai, llm-microservices, architecture-diagram] +**Source path:** `` +**Repo path:** `delivery/architecture/ai-native-sequential-pipeline-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/delivery/architecture/ai-native-sequential-pipeline-architecture/metadata.json b/delivery/architecture/ai-native-sequential-pipeline-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..acbd900087bbcd474f7ece2939454b6d6d67f800 --- /dev/null +++ b/delivery/architecture/ai-native-sequential-pipeline-architecture/metadata.json @@ -0,0 +1,30 @@ +{ + "template_id": "ai-native-sequential-pipeline-architecture", + "workflow_id": "ai-native-sequential-pipeline-architecture", + "title": "AI-Native Sequential Pipeline Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "delivery", + "secondary_use_cases": [ + "agentic", + "ai-orchestration" + ], + "use_cases": [ + "delivery", + "agentic", + "ai-orchestration" + ], + "complexity": 2, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "ai-native", + "sequential-pipeline", + "agentic-ai", + "llm-microservices", + "architecture-diagram" + ], + "description": "A sequential pipeline architecture chaining multiple agents in a fixed order (parse → enrich → analyze → format), which is a common 'LLM microservices' setup when each step can be isolated. This structure is often used in document processing and ETL-like workflows because each step is testable and predictable.", + "source_path": "", + "repo_path": "delivery/architecture/ai-native-sequential-pipeline-architecture" +} diff --git a/delivery/architecture/ai-native-sequential-pipeline-architecture/workflow.fz b/delivery/architecture/ai-native-sequential-pipeline-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..fa50bfb6ad41dcb8d576c5feb678d8c29822a191 --- /dev/null +++ b/delivery/architecture/ai-native-sequential-pipeline-architecture/workflow.fz @@ -0,0 +1,18 @@ +Trigger { # Trigger +n1: circle label:"Start" +n2: rectangle label:"Incoming request" +n1.handle(right) -> n2.handle(left) +n2.handle(bottom) -> Pipeline.n3.handle(top) [label="Input"] +} +Pipeline { # Sequential Pipeline +n3: rectangle label:"Agent A: Parse input" +n4: rectangle label:"Agent B: Enrich data" +n5: rectangle label:"Agent C: Analyze" +n6: rectangle label:"Agent D: Format output" +n7: circle label:"Done" +n3.handle(right) -> n4.handle(left) +n4.handle(right) -> n5.handle(left) +n5.handle(right) -> n6.handle(left) +n6.handle(right) -> n7.handle(left) +n6.handle(top) -> Trigger.n2.handle(bottom) [label="Final output"] +} diff --git a/delivery/architecture/ai-orchestration-sequential-pipeline/README.md b/delivery/architecture/ai-orchestration-sequential-pipeline/README.md new file mode 100644 index 0000000000000000000000000000000000000000..57fa035d232a9e73a8e68e0cb4637c49c566038b --- /dev/null +++ b/delivery/architecture/ai-orchestration-sequential-pipeline/README.md @@ -0,0 +1,19 @@ +# AI Orchestration - Sequential Pipeline + +An assembly-line architecture where agents are arranged in a strict sequence. Each agent transforms or enriches the output of the previous one, then passes it forward. Best for tasks with clear sequential dependencies — document processing, content production pipelines, compliance workflows. + +**Template ID:** `ai-orchestration-sequential-pipeline` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** delivery +**Secondary use cases:** ai-orchestration +**Complexity:** 2/5 +**Nodes:** 5 +**Lanes:** 2 +**Tags:** [ai-native, sequential-pipeline, assembly-line, architecture-diagram, orchestration] +**Source path:** `` +**Repo path:** `delivery/architecture/ai-orchestration-sequential-pipeline` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/delivery/architecture/ai-orchestration-sequential-pipeline/metadata.json b/delivery/architecture/ai-orchestration-sequential-pipeline/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..ba5db8505c26f34fed75be97d4a0d2a60f1ba886 --- /dev/null +++ b/delivery/architecture/ai-orchestration-sequential-pipeline/metadata.json @@ -0,0 +1,28 @@ +{ + "template_id": "ai-orchestration-sequential-pipeline", + "workflow_id": "ai-orchestration-sequential-pipeline", + "title": "AI Orchestration - Sequential Pipeline", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "delivery", + "secondary_use_cases": [ + "ai-orchestration" + ], + "use_cases": [ + "delivery", + "ai-orchestration" + ], + "complexity": 2, + "num_nodes": 5, + "num_lanes": 2, + "tags": [ + "ai-native", + "sequential-pipeline", + "assembly-line", + "architecture-diagram", + "orchestration" + ], + "description": "An assembly-line architecture where agents are arranged in a strict sequence. Each agent transforms or enriches the output of the previous one, then passes it forward. Best for tasks with clear sequential dependencies — document processing, content production pipelines, compliance workflows.", + "source_path": "", + "repo_path": "delivery/architecture/ai-orchestration-sequential-pipeline" +} diff --git a/delivery/architecture/ai-orchestration-sequential-pipeline/workflow.fz b/delivery/architecture/ai-orchestration-sequential-pipeline/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..8c34945416751240dee5d912bd70a41dc3c6470c --- /dev/null +++ b/delivery/architecture/ai-orchestration-sequential-pipeline/workflow.fz @@ -0,0 +1,19 @@ +Trigger { # User + n1: circle label="Start" + n2: rectangle label="Submit complex task" + n1.handle(right) -> n2.handle(left) + n2.handle(bottom) -> Pipeline.n3.handle(top) [label="Task"] +} + +Pipeline { # Sequential Pipeline + n3: rectangle label="Agent A: Parse input" + n4: rectangle label="Agent B: Enrich data" + n5: rectangle label="Agent C: Analyze" + n6: rectangle label="Agent D: Format output" + n7: circle label="Done" + n3.handle(right) -> n4.handle(left) + n4.handle(right) -> n5.handle(left) + n5.handle(right) -> n6.handle(left) + n6.handle(right) -> n7.handle(left) + n6.handle(top) -> Trigger.n2.handle(bottom) [label="Final output"] +} diff --git a/delivery/architecture/event-driven-event-streaming-pipeline-architecture/README.md b/delivery/architecture/event-driven-event-streaming-pipeline-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..53666182e34a9d29fa02acb916f81fc042036eb2 --- /dev/null +++ b/delivery/architecture/event-driven-event-streaming-pipeline-architecture/README.md @@ -0,0 +1,19 @@ +# Event-Driven Streaming Pipeline Architecture + +A real-time event streaming pipeline architecture diagram with IoT sensors, application logs, and clickstream data flowing through Kafka into Apache Flink for window aggregation, anomaly detection, and multi-sink output to data lakes and dashboards. This template visualizes end-to-end stream processing from ingestion through transformation to storage and alerting. Essential for data engineers building real-time analytics and monitoring platforms. + +**Template ID:** `event-driven-event-streaming-pipeline-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** delivery +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 18 +**Lanes:** 4 +**Tags:** [event-streaming, kafka, apache-flink, stream-processing, real-time-analytics, iot, data-pipeline, architecture-diagram] +**Source path:** `` +**Repo path:** `delivery/architecture/event-driven-event-streaming-pipeline-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/delivery/architecture/event-driven-event-streaming-pipeline-architecture/metadata.json b/delivery/architecture/event-driven-event-streaming-pipeline-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..2fea284d333a00e425769a7e10ae8f91f906eaca --- /dev/null +++ b/delivery/architecture/event-driven-event-streaming-pipeline-architecture/metadata.json @@ -0,0 +1,28 @@ +{ + "template_id": "event-driven-event-streaming-pipeline-architecture", + "workflow_id": "event-driven-event-streaming-pipeline-architecture", + "title": "Event-Driven Streaming Pipeline Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "delivery", + "secondary_use_cases": [], + "use_cases": [ + "delivery" + ], + "complexity": 4, + "num_nodes": 18, + "num_lanes": 4, + "tags": [ + "event-streaming", + "kafka", + "apache-flink", + "stream-processing", + "real-time-analytics", + "iot", + "data-pipeline", + "architecture-diagram" + ], + "description": "A real-time event streaming pipeline architecture diagram with IoT sensors, application logs, and clickstream data flowing through Kafka into Apache Flink for window aggregation, anomaly detection, and multi-sink output to data lakes and dashboards. This template visualizes end-to-end stream processing from ingestion through transformation to storage and alerting. Essential for data engineers building real-time analytics and monitoring platforms.", + "source_path": "", + "repo_path": "delivery/architecture/event-driven-event-streaming-pipeline-architecture" +} diff --git a/delivery/architecture/event-driven-event-streaming-pipeline-architecture/workflow.fz b/delivery/architecture/event-driven-event-streaming-pipeline-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..85ee8a9c476a5a82fcc79a0941a10a9b4b4b3de3 --- /dev/null +++ b/delivery/architecture/event-driven-event-streaming-pipeline-architecture/workflow.fz @@ -0,0 +1,44 @@ +Sources { # Data Sources +n1: rectangle label:"IoT Sensor Stream" +n2: rectangle label:"Application Logs" +n3: rectangle label:"User Clickstream" +n4: rectangle label:"Transaction Events" +n1.handle(bottom) -> Ingestion.n5.handle(top) [label="MQTT"] +n2.handle(bottom) -> Ingestion.n5.handle(top) [label="Fluentd"] +n3.handle(bottom) -> Ingestion.n6.handle(top) [label="Kafka Connect"] +n4.handle(bottom) -> Ingestion.n6.handle(top) [label="CDC"] +} +Ingestion { # Stream Ingestion (Kafka) +n5: rectangle label:"Kafka Topic: Raw Events" +n6: rectangle label:"Kafka Topic: Enriched Events" +n7: rectangle label:"Schema Registry Validate" +n8: rectangle label:"Partition by Key" +n5.handle(right) -> n7.handle(left) [label="Validate"] +n7.handle(right) -> n8.handle(left) [label="Schema OK"] +n8.handle(bottom) -> Processing.n9.handle(top) [label="Partitioned"] +n6.handle(bottom) -> Processing.n9.handle(top) [label="Stream"] +} +Processing { # Stream Processing (Flink/Spark) +n9: rectangle label:"Window Aggregation" +n10: rectangle label:"Filter and Transform" +n11: rectangle label:"Join Streams" +n12: diamond label:"Anomaly Detected?" +n13: rectangle label:"Emit Alert Event" +n14: rectangle label:"Write to Sink" +n9.handle(right) -> n10.handle(left) [label="5-min Window"] +n10.handle(right) -> n11.handle(left) [label="Cleaned"] +n11.handle(right) -> n12.handle(left) [label="Enriched"] +n12.handle(right) -> n14.handle(left) [label="Normal"] +n12.handle(bottom) -> n13.handle(top) [label="Anomaly"] +n13.handle(right) -> n14.handle(left) [label="Alert + Data"] +n14.handle(bottom) -> Sinks.n15.handle(top) [label="Output"] +} +Sinks { # Data Sinks +n15: rectangle label:"Data Lake (S3/HDFS)" +n16: rectangle label:"Real-Time Dashboard" +n17: rectangle label:"Alert Notification" +n18: rectangle label:"Search Index (Elasticsearch)" +n15.handle(right) -> n16.handle(left) [label="Batch Analytics"] +n16.handle(right) -> n17.handle(left) [label="Alerts"] +n17.handle(right) -> n18.handle(left) [label="Index"] +} diff --git a/delivery/architecture/gitops-deployment-architecture/README.md b/delivery/architecture/gitops-deployment-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..1cf5720fb1bbfded1a8ac9475685d6af392dd179 --- /dev/null +++ b/delivery/architecture/gitops-deployment-architecture/README.md @@ -0,0 +1,19 @@ +# GitOps Deployment Architecture + +A GitOps deployment architecture diagram with developer Git workflow, CI/CD pipeline building and pushing container images, ArgoCD or Flux detecting Git manifest changes, drift detection, automatic cluster synchronization, and rolling update deployment to Kubernetes. This template models the GitOps paradigm where Git is the single source of truth for both application code and infrastructure state, enabling declarative, auditable, and reproducible deployments. Critical for teams adopting GitOps practices for Kubernetes deployments. + +**Template ID:** `gitops-deployment-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** delivery +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 19 +**Lanes:** 4 +**Tags:** [gitops, argocd, flux, kubernetes-deployment, declarative-infrastructure, drift-detection, rolling-update, architecture-diagram] +**Source path:** `` +**Repo path:** `delivery/architecture/gitops-deployment-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/delivery/architecture/gitops-deployment-architecture/metadata.json b/delivery/architecture/gitops-deployment-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..405b970f3b2a56fa0093dae615c083449f9c8c36 --- /dev/null +++ b/delivery/architecture/gitops-deployment-architecture/metadata.json @@ -0,0 +1,28 @@ +{ + "template_id": "gitops-deployment-architecture", + "workflow_id": "gitops-deployment-architecture", + "title": "GitOps Deployment Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "delivery", + "secondary_use_cases": [], + "use_cases": [ + "delivery" + ], + "complexity": 4, + "num_nodes": 19, + "num_lanes": 4, + "tags": [ + "gitops", + "argocd", + "flux", + "kubernetes-deployment", + "declarative-infrastructure", + "drift-detection", + "rolling-update", + "architecture-diagram" + ], + "description": "A GitOps deployment architecture diagram with developer Git workflow, CI/CD pipeline building and pushing container images, ArgoCD or Flux detecting Git manifest changes, drift detection, automatic cluster synchronization, and rolling update deployment to Kubernetes. This template models the GitOps paradigm where Git is the single source of truth for both application code and infrastructure state, enabling declarative, auditable, and reproducible deployments. Critical for teams adopting GitOps practices for Kubernetes deployments.", + "source_path": "", + "repo_path": "delivery/architecture/gitops-deployment-architecture" +} diff --git a/delivery/architecture/gitops-deployment-architecture/workflow.fz b/delivery/architecture/gitops-deployment-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..fb1a51b6465ed8697a99c506e94dfc8c2292f79b --- /dev/null +++ b/delivery/architecture/gitops-deployment-architecture/workflow.fz @@ -0,0 +1,45 @@ +Developer { # Developer +n1: circle label:"Code Change" +n2: rectangle label:"Git Push to Main" +n3: rectangle label:"Open Pull Request" +n4: rectangle label:"Merge After Review" +n1.handle(right) -> n2.handle(left) +n2.handle(right) -> n3.handle(left) [label="Feature Branch"] +n3.handle(right) -> n4.handle(left) [label="Approved"] +n4.handle(bottom) -> CICD.n5.handle(top) [label="Trigger"] +} +CICD { # CI/CD Pipeline +n5: rectangle label:"Run Tests and Lint" +n6: rectangle label:"Build Container Image" +n7: rectangle label:"Push to Registry" +n8: rectangle label:"Update Manifest in Git" +n5.handle(right) -> n6.handle(left) [label="Tests Pass"] +n6.handle(right) -> n7.handle(left) [label="Tag: sha-abc123"] +n7.handle(right) -> n8.handle(left) [label="Update Image Tag"] +n8.handle(bottom) -> GitOps.n9.handle(top) [label="Commit Manifest"] +} +GitOps { # GitOps Controller (ArgoCD/Flux) +n9: rectangle label:"Detect Git Diff" +n10: rectangle label:"Compare Desired vs Live" +n11: diamond label:"Drift Detected?" +n12: rectangle label:"Sync to Cluster" +n13: rectangle label:"State Already Synced" +n14: rectangle label:"Health Check" +n9.handle(right) -> n10.handle(left) [label="Poll/Webhook"] +n10.handle(right) -> n11.handle(left) +n11.handle(right) -> n12.handle(left) [label="Yes"] +n11.handle(bottom) -> n13.handle(top) [label="No"] +n12.handle(right) -> n14.handle(left) [label="Apply"] +n14.handle(bottom) -> Cluster.n15.handle(top) [label="Deploy"] +} +Cluster { # Kubernetes Cluster +n15: rectangle label:"Rolling Update Deployment" +n16: rectangle label:"New Pods Created" +n17: rectangle label:"Old Pods Terminated" +n18: rectangle label:"Service Routes Traffic" +n19: circle label:"Deployment Complete" +n15.handle(right) -> n16.handle(left) [label="Scale Up"] +n16.handle(right) -> n17.handle(left) [label="Healthy"] +n17.handle(right) -> n18.handle(left) [label="Cutover"] +n18.handle(right) -> n19.handle(left) +} diff --git a/delivery/architecture/microservices-strangler-fig-migration/README.md b/delivery/architecture/microservices-strangler-fig-migration/README.md new file mode 100644 index 0000000000000000000000000000000000000000..fd3cd0f58e88b7271e6e17436f8f1795b5ad1eb2 --- /dev/null +++ b/delivery/architecture/microservices-strangler-fig-migration/README.md @@ -0,0 +1,19 @@ +# Microservices Strangler Fig Migration Architecture + +A strangler fig migration architecture diagram showing the incremental replacement of a legacy monolith with new microservices, using a routing layer to split traffic between old and new systems. This template models the proven migration strategy where new features are built as microservices while legacy endpoints are gradually retired. Essential for teams modernizing legacy systems without risky big-bang rewrites. + +**Template ID:** `microservices-strangler-fig-migration` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** delivery +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 16 +**Lanes:** 4 +**Tags:** [strangler-fig, legacy-migration, monolith-decomposition, anti-corruption-layer, incremental-migration, modernization, architecture-diagram] +**Source path:** `` +**Repo path:** `delivery/architecture/microservices-strangler-fig-migration` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/delivery/architecture/microservices-strangler-fig-migration/metadata.json b/delivery/architecture/microservices-strangler-fig-migration/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..87e6ab28ad15024ec0e47da6decb8f467dc9b24e --- /dev/null +++ b/delivery/architecture/microservices-strangler-fig-migration/metadata.json @@ -0,0 +1,27 @@ +{ + "template_id": "microservices-strangler-fig-migration", + "workflow_id": "microservices-strangler-fig-migration", + "title": "Microservices Strangler Fig Migration Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "delivery", + "secondary_use_cases": [], + "use_cases": [ + "delivery" + ], + "complexity": 4, + "num_nodes": 16, + "num_lanes": 4, + "tags": [ + "strangler-fig", + "legacy-migration", + "monolith-decomposition", + "anti-corruption-layer", + "incremental-migration", + "modernization", + "architecture-diagram" + ], + "description": "A strangler fig migration architecture diagram showing the incremental replacement of a legacy monolith with new microservices, using a routing layer to split traffic between old and new systems. This template models the proven migration strategy where new features are built as microservices while legacy endpoints are gradually retired. Essential for teams modernizing legacy systems without risky big-bang rewrites.", + "source_path": "", + "repo_path": "delivery/architecture/microservices-strangler-fig-migration" +} diff --git a/delivery/architecture/microservices-strangler-fig-migration/workflow.fz b/delivery/architecture/microservices-strangler-fig-migration/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..96ae5cb69a3a453a8ddd5b666252138382b2926e --- /dev/null +++ b/delivery/architecture/microservices-strangler-fig-migration/workflow.fz @@ -0,0 +1,41 @@ +Client { # Client +n1: circle label:"User Request" +n2: rectangle label:"Anti-Corruption Layer" +n3: rectangle label:"Receive Response" +n4: circle label:"End" +n1.handle(right) -> n2.handle(left) +n2.handle(bottom) -> Router.n5.handle(top) [label="Translate"] +n3.handle(right) -> n4.handle(left) +} +Router { # Strangler Fig Router +n5: rectangle label:"Inspect Request Path" +n6: diamond label:"Migrated Endpoint?" +n7: rectangle label:"Route to New Service" +n8: rectangle label:"Route to Legacy Monolith" +n9: rectangle label:"Log Migration Metrics" +n5.handle(right) -> n6.handle(left) +n6.handle(right) -> n7.handle(left) [label="Yes"] +n6.handle(bottom) -> n8.handle(top) [label="No"] +n7.handle(bottom) -> NewServices.n10.handle(top) [label="Forward"] +n8.handle(bottom) -> Legacy.n14.handle(top) [label="Forward"] +n7.handle(right) -> n9.handle(left) [label="Track"] +n8.handle(right) -> n9.handle(left) [label="Track"] +} +NewServices { # New Microservices +n10: rectangle label:"Process in New Service" +n11: rectangle label:"New Service Database" +n12: rectangle label:"Publish Domain Event" +n13: rectangle label:"Return Response" +n10.handle(right) -> n11.handle(left) [label="Query"] +n11.handle(right) -> n12.handle(left) [label="Write"] +n12.handle(right) -> n13.handle(left) +n13.handle(top) -> Client.n3.handle(bottom) [label="New Response"] +} +Legacy { # Legacy Monolith +n14: rectangle label:"Process in Monolith" +n15: rectangle label:"Legacy Database" +n16: rectangle label:"Return Legacy Response" +n14.handle(right) -> n15.handle(left) [label="SQL"] +n15.handle(right) -> n16.handle(left) [label="Result"] +n16.handle(top) -> Client.n3.handle(bottom) [label="Legacy Response"] +} diff --git a/delivery/architecture/saga-orchestration-pattern-architecture/README.md b/delivery/architecture/saga-orchestration-pattern-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..3e416f901a355093e334da5fe6838f85f8b9c724 --- /dev/null +++ b/delivery/architecture/saga-orchestration-pattern-architecture/README.md @@ -0,0 +1,19 @@ +# Saga Orchestration Pattern Architecture + +A saga orchestration architecture diagram with a central orchestrator coordinating multi-step distributed transactions across Order, Inventory, and Payment services, with a dedicated compensation chain for rollback on failure. This template models the orchestration-based saga pattern where a single coordinator manages the transaction lifecycle and triggers compensating actions when any step fails. Essential for architects implementing reliable distributed transactions without two-phase commit. + +**Template ID:** `saga-orchestration-pattern-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** delivery +**Secondary use cases:** ai-orchestration +**Complexity:** 4/5 +**Nodes:** 19 +**Lanes:** 5 +**Tags:** [saga-pattern, orchestration, distributed-transaction, compensation, microservices, rollback, consistency, architecture-diagram] +**Source path:** `` +**Repo path:** `delivery/architecture/saga-orchestration-pattern-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/delivery/architecture/saga-orchestration-pattern-architecture/metadata.json b/delivery/architecture/saga-orchestration-pattern-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..6a7b4f469676fc802ed2ee174b26c18eed5e6055 --- /dev/null +++ b/delivery/architecture/saga-orchestration-pattern-architecture/metadata.json @@ -0,0 +1,31 @@ +{ + "template_id": "saga-orchestration-pattern-architecture", + "workflow_id": "saga-orchestration-pattern-architecture", + "title": "Saga Orchestration Pattern Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "delivery", + "secondary_use_cases": [ + "ai-orchestration" + ], + "use_cases": [ + "delivery", + "ai-orchestration" + ], + "complexity": 4, + "num_nodes": 19, + "num_lanes": 5, + "tags": [ + "saga-pattern", + "orchestration", + "distributed-transaction", + "compensation", + "microservices", + "rollback", + "consistency", + "architecture-diagram" + ], + "description": "A saga orchestration architecture diagram with a central orchestrator coordinating multi-step distributed transactions across Order, Inventory, and Payment services, with a dedicated compensation chain for rollback on failure. This template models the orchestration-based saga pattern where a single coordinator manages the transaction lifecycle and triggers compensating actions when any step fails. Essential for architects implementing reliable distributed transactions without two-phase commit.", + "source_path": "", + "repo_path": "delivery/architecture/saga-orchestration-pattern-architecture" +} diff --git a/delivery/architecture/saga-orchestration-pattern-architecture/workflow.fz b/delivery/architecture/saga-orchestration-pattern-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..417252c6711e02888f9ecbb74ab52fb5dbc47fba --- /dev/null +++ b/delivery/architecture/saga-orchestration-pattern-architecture/workflow.fz @@ -0,0 +1,60 @@ +Orchestrator { # Saga Orchestrator +n1: circle label:"Start Saga" +n2: rectangle label:"Create Saga Instance" +n3: rectangle label:"Execute Step 1: Create Order" +n8: rectangle label:"Execute Step 2: Reserve Inventory" +n12: rectangle label:"Execute Step 3: Process Payment" +n16: diamond label:"All Steps Succeeded?" +n17: rectangle label:"Mark Saga Complete" +n18: rectangle label:"Begin Compensation" +n19: circle label:"Saga Finished" +n25: rectangle label:"Rollback Confirmed" +n1.handle(right) -> n2.handle(left) +n2.handle(right) -> n3.handle(left) [label="Initialize"] +n3.handle(bottom) -> OrderService.n4.handle(top) [label="Command"] +n8.handle(bottom) -> InventoryService.n9.handle(top) [label="Command"] +n12.handle(bottom) -> PaymentService.n13.handle(top) [label="Command"] +n16.handle(right) -> n17.handle(left) [label="Yes"] +n16.handle(bottom) -> n18.handle(top) [label="No"] +n17.handle(right) -> n19.handle(left) +n18.handle(bottom) -> Compensation.n20.handle(top) [label="Rollback"] +n25.handle(right) -> n19.handle(left) +} +OrderService { # Order Service +n4: rectangle label:"Create Order Record" +n5: rectangle label:"Return Order ID" +n6: rectangle label:"Send Order Result" +n7: rectangle label:"Forward to Orchestrator" +n4.handle(right) -> n5.handle(left) [label="Persisted"] +n5.handle(right) -> n6.handle(left) +n6.handle(right) -> n7.handle(left) +n7.handle(top) -> Orchestrator.n8.handle(bottom) [label="Step 1 OK"] +} +InventoryService { # Inventory Service +n9: rectangle label:"Reserve Stock Items" +n10: rectangle label:"Return Reservation ID" +n11: rectangle label:"Forward to Orchestrator" +n9.handle(right) -> n10.handle(left) [label="Reserved"] +n10.handle(right) -> n11.handle(left) +n11.handle(top) -> Orchestrator.n12.handle(bottom) [label="Step 2 OK"] +} +PaymentService { # Payment Service +n13: rectangle label:"Charge Payment Method" +n14: rectangle label:"Return Transaction ID" +n15: rectangle label:"Forward to Orchestrator" +n13.handle(right) -> n14.handle(left) [label="Charged"] +n14.handle(right) -> n15.handle(left) +n15.handle(top) -> Orchestrator.n16.handle(bottom) [label="Result"] +} +Compensation { # Compensation Steps +n20: rectangle label:"Reverse Payment" +n21: rectangle label:"Release Inventory" +n22: rectangle label:"Cancel Order" +n23: rectangle label:"Notify Orchestrator" +n24: rectangle label:"Send Rollback Status" +n20.handle(right) -> n21.handle(left) [label="Refund"] +n21.handle(right) -> n22.handle(left) [label="Unreserve"] +n22.handle(right) -> n23.handle(left) [label="Cancelled"] +n23.handle(right) -> n24.handle(left) +n24.handle(top) -> Orchestrator.n25.handle(bottom) [label="Rollback Complete"] +} diff --git a/delivery/architecture/serverless-data-pipeline-architecture/README.md b/delivery/architecture/serverless-data-pipeline-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..35417e9f9486c46b8df41fae60270fa4373487c8 --- /dev/null +++ b/delivery/architecture/serverless-data-pipeline-architecture/README.md @@ -0,0 +1,19 @@ +# Serverless Data Pipeline Architecture + +A serverless data pipeline architecture diagram with Kinesis ingestion, Lambda transformation functions, S3 data lake storage zones (raw and curated), Glue catalog registration, and Athena query engine feeding QuickSight dashboards and SageMaker ML models. This template models a complete serverless ETL pipeline from data ingestion through transformation, cataloging, and analytics without managing any infrastructure. Ideal for data teams building cost-effective analytics platforms. + +**Template ID:** `serverless-data-pipeline-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** delivery +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 17 +**Lanes:** 4 +**Tags:** [serverless-data-pipeline, kinesis, glue, athena, s3-data-lake, etl, sagemaker, architecture-diagram] +**Source path:** `` +**Repo path:** `delivery/architecture/serverless-data-pipeline-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/delivery/architecture/serverless-data-pipeline-architecture/metadata.json b/delivery/architecture/serverless-data-pipeline-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..ec9a782a56459fbfb82cff2b32dedb764e744ecc --- /dev/null +++ b/delivery/architecture/serverless-data-pipeline-architecture/metadata.json @@ -0,0 +1,28 @@ +{ + "template_id": "serverless-data-pipeline-architecture", + "workflow_id": "serverless-data-pipeline-architecture", + "title": "Serverless Data Pipeline Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "delivery", + "secondary_use_cases": [], + "use_cases": [ + "delivery" + ], + "complexity": 4, + "num_nodes": 17, + "num_lanes": 4, + "tags": [ + "serverless-data-pipeline", + "kinesis", + "glue", + "athena", + "s3-data-lake", + "etl", + "sagemaker", + "architecture-diagram" + ], + "description": "A serverless data pipeline architecture diagram with Kinesis ingestion, Lambda transformation functions, S3 data lake storage zones (raw and curated), Glue catalog registration, and Athena query engine feeding QuickSight dashboards and SageMaker ML models. This template models a complete serverless ETL pipeline from data ingestion through transformation, cataloging, and analytics without managing any infrastructure. Ideal for data teams building cost-effective analytics platforms.", + "source_path": "", + "repo_path": "delivery/architecture/serverless-data-pipeline-architecture" +} diff --git a/delivery/architecture/serverless-data-pipeline-architecture/workflow.fz b/delivery/architecture/serverless-data-pipeline-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..46155f68f9bd52129413c13e8387229ee4444efd --- /dev/null +++ b/delivery/architecture/serverless-data-pipeline-architecture/workflow.fz @@ -0,0 +1,41 @@ +Ingestion { # Data Ingestion +n1: rectangle label:"Kinesis Data Stream" +n2: rectangle label:"API Gateway Endpoint" +n3: rectangle label:"IoT Core MQTT" +n4: rectangle label:"Kinesis Firehose" +n1.handle(right) -> n4.handle(left) [label="Stream"] +n2.handle(right) -> n4.handle(left) [label="Batch"] +n3.handle(right) -> n4.handle(left) [label="Device Data"] +n4.handle(bottom) -> Transform.n5.handle(top) [label="Buffer + Deliver"] +} +Transform { # Serverless Transform +n5: rectangle label:"Lambda Transform Function" +n6: rectangle label:"Validate Schema" +n7: diamond label:"Valid Record?" +n8: rectangle label:"Enrich with Reference Data" +n9: rectangle label:"Route to Error Bucket" +n10: rectangle label:"Partition by Date" +n5.handle(right) -> n6.handle(left) +n6.handle(right) -> n7.handle(left) +n7.handle(right) -> n8.handle(left) [label="Valid"] +n7.handle(bottom) -> n9.handle(top) [label="Invalid"] +n8.handle(right) -> n10.handle(left) [label="Enriched"] +n10.handle(bottom) -> Storage.n11.handle(top) [label="Partitioned"] +} +Storage { # Data Lake Storage +n11: rectangle label:"S3 Raw Zone" +n12: rectangle label:"S3 Curated Zone" +n13: rectangle label:"Glue Catalog" +n14: rectangle label:"Athena Query Engine" +n11.handle(right) -> n12.handle(left) [label="Glue ETL Job"] +n12.handle(right) -> n13.handle(left) [label="Register Schema"] +n13.handle(right) -> n14.handle(left) [label="Queryable"] +} +Analytics { # Analytics Layer +n15: rectangle label:"QuickSight Dashboard" +n16: rectangle label:"SageMaker ML Model" +n17: rectangle label:"Redshift Data Warehouse" +n14.handle(bottom) -> Analytics.n15.handle(top) [label="Visualize"] +n14.handle(bottom) -> Analytics.n16.handle(top) [label="Train Model"] +n14.handle(bottom) -> Analytics.n17.handle(top) [label="COPY INTO"] +} diff --git a/delivery/devops/backup-restore-workflow/README.md b/delivery/devops/backup-restore-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..63b69e9f564b13f8e719ecabb599749c41356169 --- /dev/null +++ b/delivery/devops/backup-restore-workflow/README.md @@ -0,0 +1,19 @@ +# Backup Restore Workflow + +Backup and restore workflow with scheduled backups, offsite replication, retention policy enforcement, restore testing, and RTO/RPO validation. + +**Template ID:** `backup-restore-workflow` +**Kind:** workflow +**Source domain:** devops +**Primary use case:** delivery +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [backup-restore, disaster-recovery, rpo-rto, snapshot, data-protection, recovery-testing] +**Source path:** `devops/backup-restore` +**Repo path:** `delivery/devops/backup-restore-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/delivery/devops/backup-restore-workflow/metadata.json b/delivery/devops/backup-restore-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..2ce74923f7c56a9f1ee7d966d2689aa49368a3e9 --- /dev/null +++ b/delivery/devops/backup-restore-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "backup-restore-workflow", + "workflow_id": "backup-restore", + "title": "Backup Restore Workflow", + "kind": "workflow", + "source_domain": "devops", + "primary_use_case": "delivery", + "secondary_use_cases": [], + "use_cases": [ + "delivery" + ], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "backup-restore", + "disaster-recovery", + "rpo-rto", + "snapshot", + "data-protection", + "recovery-testing" + ], + "description": "Backup and restore workflow with scheduled backups, offsite replication, retention policy enforcement, restore testing, and RTO/RPO validation.", + "source_path": "devops/backup-restore", + "repo_path": "delivery/devops/backup-restore-workflow" +} diff --git a/devops/backup-restore/workflow.fz b/delivery/devops/backup-restore-workflow/workflow.fz similarity index 100% rename from devops/backup-restore/workflow.fz rename to delivery/devops/backup-restore-workflow/workflow.fz diff --git a/delivery/devops/ci-cd-pipeline-workflow/README.md b/delivery/devops/ci-cd-pipeline-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..6e1e23ea105fa69121c931e3fbb6c577ccb8d1ac --- /dev/null +++ b/delivery/devops/ci-cd-pipeline-workflow/README.md @@ -0,0 +1,19 @@ +# Ci Cd Pipeline Workflow + +Full CI/CD pipeline with code checkout, linting, unit tests, artifact building, staging deployment, smoke tests, production deployment, and automatic rollback on failure. + +**Template ID:** `ci-cd-pipeline-workflow` +**Kind:** workflow +**Source domain:** devops +**Primary use case:** delivery +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 22 +**Lanes:** 3 +**Tags:** [ci-cd, continuous-integration, continuous-deployment, github-actions, artifact-registry, staging, production, rollback] +**Source path:** `devops/ci-cd-pipeline` +**Repo path:** `delivery/devops/ci-cd-pipeline-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/devops/ci-cd-pipeline/metadata.json b/delivery/devops/ci-cd-pipeline-workflow/metadata.json similarity index 50% rename from devops/ci-cd-pipeline/metadata.json rename to delivery/devops/ci-cd-pipeline-workflow/metadata.json index a3498b213c5fb89e6e3604e02aa3fa760d7fb085..afb6f541583aac846c59273fe0ab06d68bb01997 100644 --- a/devops/ci-cd-pipeline/metadata.json +++ b/delivery/devops/ci-cd-pipeline-workflow/metadata.json @@ -1,6 +1,14 @@ { + "template_id": "ci-cd-pipeline-workflow", "workflow_id": "ci-cd-pipeline", - "domain": "devops", + "title": "Ci Cd Pipeline Workflow", + "kind": "workflow", + "source_domain": "devops", + "primary_use_case": "delivery", + "secondary_use_cases": [], + "use_cases": [ + "delivery" + ], "complexity": 4, "num_nodes": 22, "num_lanes": 3, @@ -14,5 +22,7 @@ "production", "rollback" ], - "description": "Full CI/CD pipeline with code checkout, linting, unit tests, artifact building, staging deployment, smoke tests, production deployment, and automatic rollback on failure." -} \ No newline at end of file + "description": "Full CI/CD pipeline with code checkout, linting, unit tests, artifact building, staging deployment, smoke tests, production deployment, and automatic rollback on failure.", + "source_path": "devops/ci-cd-pipeline", + "repo_path": "delivery/devops/ci-cd-pipeline-workflow" +} diff --git a/devops/ci-cd-pipeline/workflow.fz b/delivery/devops/ci-cd-pipeline-workflow/workflow.fz similarity index 100% rename from devops/ci-cd-pipeline/workflow.fz rename to delivery/devops/ci-cd-pipeline-workflow/workflow.fz diff --git a/delivery/devops/infrastructure-provisioning-workflow/README.md b/delivery/devops/infrastructure-provisioning-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..7689891f70e0689ec9ec124a9296e153560ec381 --- /dev/null +++ b/delivery/devops/infrastructure-provisioning-workflow/README.md @@ -0,0 +1,19 @@ +# Infrastructure Provisioning Workflow + +Infrastructure as Code provisioning workflow with Terraform plan, approval gates, state management, resource creation, and drift detection. + +**Template ID:** `infrastructure-provisioning-workflow` +**Kind:** workflow +**Source domain:** devops +**Primary use case:** delivery +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [infrastructure-provisioning, terraform, iac, cloud-resources, gitops, state-management] +**Source path:** `devops/infrastructure-provisioning` +**Repo path:** `delivery/devops/infrastructure-provisioning-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/delivery/devops/infrastructure-provisioning-workflow/metadata.json b/delivery/devops/infrastructure-provisioning-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..523fda8c69755d053e6df1c6b016dc587ed0f3e7 --- /dev/null +++ b/delivery/devops/infrastructure-provisioning-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "infrastructure-provisioning-workflow", + "workflow_id": "infrastructure-provisioning", + "title": "Infrastructure Provisioning Workflow", + "kind": "workflow", + "source_domain": "devops", + "primary_use_case": "delivery", + "secondary_use_cases": [], + "use_cases": [ + "delivery" + ], + "complexity": 4, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "infrastructure-provisioning", + "terraform", + "iac", + "cloud-resources", + "gitops", + "state-management" + ], + "description": "Infrastructure as Code provisioning workflow with Terraform plan, approval gates, state management, resource creation, and drift detection.", + "source_path": "devops/infrastructure-provisioning", + "repo_path": "delivery/devops/infrastructure-provisioning-workflow" +} diff --git a/devops/infrastructure-provisioning/workflow.fz b/delivery/devops/infrastructure-provisioning-workflow/workflow.fz similarity index 100% rename from devops/infrastructure-provisioning/workflow.fz rename to delivery/devops/infrastructure-provisioning-workflow/workflow.fz diff --git a/delivery/devops/load-testing-workflow/README.md b/delivery/devops/load-testing-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..6bfbea47d128cc74a5d272ccb0d0c30f3150bda4 --- /dev/null +++ b/delivery/devops/load-testing-workflow/README.md @@ -0,0 +1,19 @@ +# Load Testing Workflow + +Load testing workflow with test scenario design, gradual ramp-up, performance metrics collection, bottleneck identification, and capacity recommendations. + +**Template ID:** `load-testing-workflow` +**Kind:** workflow +**Source domain:** devops +**Primary use case:** delivery +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 13 +**Lanes:** 4 +**Tags:** [load-testing, performance-testing, stress-testing, k6, jmeter, capacity-planning] +**Source path:** `devops/load-testing` +**Repo path:** `delivery/devops/load-testing-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/delivery/devops/load-testing-workflow/metadata.json b/delivery/devops/load-testing-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..73983de5f70457378da4cca366498c6379431a01 --- /dev/null +++ b/delivery/devops/load-testing-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "load-testing-workflow", + "workflow_id": "load-testing", + "title": "Load Testing Workflow", + "kind": "workflow", + "source_domain": "devops", + "primary_use_case": "delivery", + "secondary_use_cases": [], + "use_cases": [ + "delivery" + ], + "complexity": 4, + "num_nodes": 13, + "num_lanes": 4, + "tags": [ + "load-testing", + "performance-testing", + "stress-testing", + "k6", + "jmeter", + "capacity-planning" + ], + "description": "Load testing workflow with test scenario design, gradual ramp-up, performance metrics collection, bottleneck identification, and capacity recommendations.", + "source_path": "devops/load-testing", + "repo_path": "delivery/devops/load-testing-workflow" +} diff --git a/devops/load-testing/workflow.fz b/delivery/devops/load-testing-workflow/workflow.fz similarity index 100% rename from devops/load-testing/workflow.fz rename to delivery/devops/load-testing-workflow/workflow.fz diff --git a/delivery/patterns/blue-green-deploy-workflow/README.md b/delivery/patterns/blue-green-deploy-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..303e4870fc6be719c5b47dc8a92aeeb3bbe193ca --- /dev/null +++ b/delivery/patterns/blue-green-deploy-workflow/README.md @@ -0,0 +1,19 @@ +# Blue Green Deploy Workflow + +Blue-green deployment pattern with parallel environment setup, smoke testing, load balancer traffic switch, and instant rollback capability. + +**Template ID:** `blue-green-deploy-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** delivery +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 13 +**Lanes:** 4 +**Tags:** [blue-green-deployment, zero-downtime, traffic-switching, rollback, load-balancer, release-management] +**Source path:** `patterns/blue-green-deploy` +**Repo path:** `delivery/patterns/blue-green-deploy-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/delivery/patterns/blue-green-deploy-workflow/metadata.json b/delivery/patterns/blue-green-deploy-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..ceab063c809900f1203f627403411628dc47421e --- /dev/null +++ b/delivery/patterns/blue-green-deploy-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "blue-green-deploy-workflow", + "workflow_id": "blue-green-deploy", + "title": "Blue Green Deploy Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "delivery", + "secondary_use_cases": [], + "use_cases": [ + "delivery" + ], + "complexity": 4, + "num_nodes": 13, + "num_lanes": 4, + "tags": [ + "blue-green-deployment", + "zero-downtime", + "traffic-switching", + "rollback", + "load-balancer", + "release-management" + ], + "description": "Blue-green deployment pattern with parallel environment setup, smoke testing, load balancer traffic switch, and instant rollback capability.", + "source_path": "patterns/blue-green-deploy", + "repo_path": "delivery/patterns/blue-green-deploy-workflow" +} diff --git a/patterns/blue-green-deploy/workflow.fz b/delivery/patterns/blue-green-deploy-workflow/workflow.fz similarity index 100% rename from patterns/blue-green-deploy/workflow.fz rename to delivery/patterns/blue-green-deploy-workflow/workflow.fz diff --git a/delivery/patterns/saga-pattern-workflow/README.md b/delivery/patterns/saga-pattern-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..ea38f6e0afc1bc64dff7f16e004aaa4c1bb0c2c5 --- /dev/null +++ b/delivery/patterns/saga-pattern-workflow/README.md @@ -0,0 +1,19 @@ +# Saga Pattern Workflow + +Saga orchestration pattern for distributed transactions across Order, Payment, and Shipping services with automatic compensation rollback on failures. + +**Template ID:** `saga-pattern-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** delivery +**Secondary use cases:** ai-orchestration +**Complexity:** 5/5 +**Nodes:** 20 +**Lanes:** 4 +**Tags:** [saga-pattern, distributed-transactions, microservices, compensation, orchestration, eventual-consistency, rollback] +**Source path:** `patterns/saga-pattern` +**Repo path:** `delivery/patterns/saga-pattern-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/delivery/patterns/saga-pattern-workflow/metadata.json b/delivery/patterns/saga-pattern-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..4e32b297f3bb4e0926b21926511330c04f08de44 --- /dev/null +++ b/delivery/patterns/saga-pattern-workflow/metadata.json @@ -0,0 +1,30 @@ +{ + "template_id": "saga-pattern-workflow", + "workflow_id": "saga-pattern", + "title": "Saga Pattern Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "delivery", + "secondary_use_cases": [ + "ai-orchestration" + ], + "use_cases": [ + "delivery", + "ai-orchestration" + ], + "complexity": 5, + "num_nodes": 20, + "num_lanes": 4, + "tags": [ + "saga-pattern", + "distributed-transactions", + "microservices", + "compensation", + "orchestration", + "eventual-consistency", + "rollback" + ], + "description": "Saga orchestration pattern for distributed transactions across Order, Payment, and Shipping services with automatic compensation rollback on failures.", + "source_path": "patterns/saga-pattern", + "repo_path": "delivery/patterns/saga-pattern-workflow" +} diff --git a/patterns/saga-pattern/workflow.fz b/delivery/patterns/saga-pattern-workflow/workflow.fz similarity index 100% rename from patterns/saga-pattern/workflow.fz rename to delivery/patterns/saga-pattern-workflow/workflow.fz diff --git a/devops/access-review/README.md b/devops/access-review/README.md deleted file mode 100644 index 9e060c406654a5be1f8af2fad7e15cec3d700079..0000000000000000000000000000000000000000 --- a/devops/access-review/README.md +++ /dev/null @@ -1,24 +0,0 @@ -# Access Review - -Quarterly user access review workflow with manager certification, separation of duties validation, remediation tracking, and compliance reporting for audit purposes. - -**Domain:** devops -**Complexity:** 4/5 -**Tags:** [access-review, user-access-certification, quarterly-review, manager-approval, compliance, sod-violations, audit] - -## Lanes -- **Compliance Team** - Initiates review, tracks remediation, generates reports -- **Manager Review** - Certifies user access, identifies revocations -- **IT Security** - Processes revocations, validates SoD, updates systems - -## Process Flow -1. Initiate quarterly access review -2. Extract user access data from systems -3. Distribute access lists to managers -4. Manager reviews and certifies each user's access -5. Identify access to revoke or modify -6. Check for separation of duties violations -7. Process approved revocations -8. Track remediation of flagged items -9. Generate compliance report for audit -10. Archive review documentation diff --git a/devops/access-review/metadata.json b/devops/access-review/metadata.json deleted file mode 100644 index cba09d491f26ca69580867d042e859b3f31337ce..0000000000000000000000000000000000000000 --- a/devops/access-review/metadata.json +++ /dev/null @@ -1,17 +0,0 @@ -{ - "workflow_id": "access-review", - "domain": "devops", - "complexity": 4, - "num_nodes": 18, - "num_lanes": 3, - "tags": [ - "access-review", - "user-access-certification", - "quarterly-review", - "manager-approval", - "compliance", - "sod-violations", - "audit" - ], - "description": "Quarterly user access review workflow with manager certification, separation of duties validation, remediation tracking, and compliance reporting for audit purposes." -} \ No newline at end of file diff --git a/devops/backup-restore/README.md b/devops/backup-restore/README.md deleted file mode 100644 index be05b54a9b7760dd85767d95a691b5fe86cef09a..0000000000000000000000000000000000000000 --- a/devops/backup-restore/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Backup and Restore - -Backup and restore workflow with scheduled backups, offsite replication, retention policy enforcement, restore testing, and RTO/RPO validation. - -**Domain:** devops -**Complexity:** 3/5 -**Tags:** [backup-restore, disaster-recovery, rpo-rto, snapshot, data-protection, recovery-testing] - -## Lanes -- **Backup System** - Schedules and executes backups -- **Storage** - Stores backups, manages retention -- **Recovery Team** - Tests restores, validates data - -## Process Flow -1. Schedule backup based on RPO requirements -2. Create database/filesystem snapshot -3. Compress and encrypt backup -4. Transfer to offsite storage -5. Verify backup integrity -6. Apply retention policy (delete old backups) -7. Periodically test restore process -8. Validate restored data completeness -9. Document RTO achievement diff --git a/devops/backup-restore/metadata.json b/devops/backup-restore/metadata.json deleted file mode 100644 index 2fab221d88e1b2095ec347e27319f7f659a1ace9..0000000000000000000000000000000000000000 --- a/devops/backup-restore/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "backup-restore", - "domain": "devops", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "backup-restore", - "disaster-recovery", - "rpo-rto", - "snapshot", - "data-protection", - "recovery-testing" - ], - "description": "Backup and restore workflow with scheduled backups, offsite replication, retention policy enforcement, restore testing, and RTO/RPO validation." -} \ No newline at end of file diff --git a/devops/certificate-renewal/README.md b/devops/certificate-renewal/README.md deleted file mode 100644 index 2ae99130fa1cb03d23688ce2306d46ae0cefd1e1..0000000000000000000000000000000000000000 --- a/devops/certificate-renewal/README.md +++ /dev/null @@ -1,24 +0,0 @@ -# Certificate Renewal - -SSL/TLS certificate renewal workflow with expiration monitoring, certificate request by type (DV/OV/EV), domain validation, deployment to load balancers, and health check verification with rollback. - -**Domain:** devops -**Complexity:** 4/5 -**Tags:** [ssl-certificate, tls-renewal, lets-encrypt, certificate-authority, domain-validation, load-balancer, health-check] - -## Lanes -- **Certificate Monitor** - Monitors expiration, triggers renewal process -- **Certificate Authority** - Requests certificates, validates domains -- **Deployment** - Deploys to load balancers, verifies health - -## Process Flow -1. Monitor certificate expiration dates -2. Trigger renewal 30 days before expiry -3. Determine certificate type (DV/OV/EV) -4. Submit certificate request to CA -5. Complete domain validation (DNS/HTTP) -6. Download renewed certificate -7. Deploy to load balancers -8. Run health checks on endpoints -9. Rollback to previous cert if health check fails -10. Update certificate inventory diff --git a/devops/chaos-engineering/README.md b/devops/chaos-engineering/README.md deleted file mode 100644 index 67144646912221de27d0ccb75581fa4954baf508..0000000000000000000000000000000000000000 --- a/devops/chaos-engineering/README.md +++ /dev/null @@ -1,24 +0,0 @@ -# Chaos Engineering - -Chaos engineering workflow with hypothesis definition, steady-state monitoring, controlled fault injection, blast radius limitation, and resilience validation. - -**Domain:** devops -**Complexity:** 4/5 -**Tags:** [chaos-engineering, fault-injection, resilience-testing, game-day, blast-radius, steady-state] - -## Lanes -- **SRE Team** - Designs experiments, analyzes results -- **Chaos Platform** - Executes fault injection -- **Monitoring** - Tracks system behavior -- **Production System** - Target of chaos experiments - -## Process Flow -1. Define hypothesis about system resilience -2. Establish steady-state metrics baseline -3. Design chaos experiment -4. Limit blast radius (start small) -5. Inject fault (network, CPU, pod kill) -6. Monitor system behavior -7. Verify graceful degradation -8. Halt if unexpected impact -9. Document findings and improvements diff --git a/devops/chaos-engineering/metadata.json b/devops/chaos-engineering/metadata.json deleted file mode 100644 index 988f3e0b14e0fb7b15a7b10d21070be78cc3dcbb..0000000000000000000000000000000000000000 --- a/devops/chaos-engineering/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "chaos-engineering", - "domain": "devops", - "complexity": 4, - "num_nodes": 13, - "num_lanes": 4, - "tags": [ - "chaos-engineering", - "fault-injection", - "resilience-testing", - "game-day", - "blast-radius", - "steady-state" - ], - "description": "Chaos engineering workflow with hypothesis definition, steady-state monitoring, controlled fault injection, blast radius limitation, and resilience validation." -} \ No newline at end of file diff --git a/devops/ci-cd-pipeline/README.md b/devops/ci-cd-pipeline/README.md deleted file mode 100644 index 6bc3862bc331caa6b1d90cc21aa1679d954172b4..0000000000000000000000000000000000000000 --- a/devops/ci-cd-pipeline/README.md +++ /dev/null @@ -1,24 +0,0 @@ -# CI/CD Pipeline - -Full CI/CD pipeline with code checkout, linting, unit tests, artifact building, staging deployment, smoke tests, production deployment, and automatic rollback on failure. - -**Domain:** devops -**Complexity:** 4/5 -**Tags:** [ci-cd, continuous-integration, continuous-deployment, github-actions, artifact-registry, staging, production, rollback] - -## Lanes -- **Developer** - Pushes code, reviews pipeline status, merges to main -- **Continuous Integration** - Checkout, lint, test, build, push artifacts -- **Continuous Deployment** - Deploy to staging, run smoke tests, deploy to production - -## Process Flow -1. Developer pushes code to repository, triggering the build -2. CI checks out source code and installs dependencies -3. Run linting checks (fail build if lint fails) -4. Run unit tests (fail build if tests fail) -5. Build artifacts and push to artifact registry -6. Pull artifacts and deploy to staging environment -7. Run staging tests to validate deployment -8. Deploy to production if staging passes -9. Run smoke tests and health checks -10. Update load balancer if healthy, rollback if not diff --git a/devops/database-migration/README.md b/devops/database-migration/README.md deleted file mode 100644 index 12f75533eaeeae908953a51b8db6f7872202e155..0000000000000000000000000000000000000000 --- a/devops/database-migration/README.md +++ /dev/null @@ -1,27 +0,0 @@ -# Database Migration - -Database schema migration workflow with CI testing, DBA review and approval, maintenance window scheduling, backup snapshots, migration execution, data integrity verification, and automatic rollback. - -**Domain:** devops -**Complexity:** 4/5 -**Tags:** [database-migration, schema-changes, flyway, liquibase, rollback, dba-approval, maintenance-window] - -## Lanes -- **Developer** - Creates migration script, tests locally, reviews results -- **CI Pipeline** - Runs migration in test DB, generates rollback script -- **Database Admin** - Reviews migration plan, approves for production -- **Production Database** - Creates backup, executes migration, verifies integrity - -## Process Flow -1. Developer creates migration script -2. Test migration locally -3. CI runs migration in test database -4. If successful, generate rollback script -5. DBA reviews migration plan -6. If approved, schedule maintenance window -7. Create backup snapshot before migration -8. Enable maintenance mode -9. Execute migration script -10. Verify data integrity -11. If failed, execute rollback script -12. Disable maintenance mode and notify developer diff --git a/devops/deployment-rollback/README.md b/devops/deployment-rollback/README.md deleted file mode 100644 index c38750f22119cbc69a036cd3df0b8e705a48c391..0000000000000000000000000000000000000000 --- a/devops/deployment-rollback/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Deployment Rollback - -Deployment rollback workflow with issue detection, rollback decision, previous version restoration, health verification, and post-mortem documentation. - -**Domain:** devops -**Complexity:** 3/5 -**Tags:** [deployment-rollback, version-revert, incident-response, kubernetes, helm-rollback, service-recovery] - -## Lanes -- **Monitoring** - Detects issues, triggers alerts -- **On-Call Engineer** - Decides and executes rollback -- **CI/CD System** - Performs rollback deployment - -## Process Flow -1. Detect deployment issue (errors, latency) -2. Assess severity and impact -3. Decide to rollback vs hotfix -4. Identify last known good version -5. Execute rollback (helm rollback, kubectl) -6. Verify health checks pass -7. Confirm error rates normalized -8. Notify stakeholders -9. Schedule post-mortem diff --git a/devops/deployment-rollback/metadata.json b/devops/deployment-rollback/metadata.json deleted file mode 100644 index 42c6840d1df34a70378c67249895f8870c555736..0000000000000000000000000000000000000000 --- a/devops/deployment-rollback/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "deployment-rollback", - "domain": "devops", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "deployment-rollback", - "version-revert", - "incident-response", - "kubernetes", - "helm-rollback", - "service-recovery" - ], - "description": "Deployment rollback workflow with issue detection, rollback decision, previous version restoration, health verification, and post-mortem documentation." -} \ No newline at end of file diff --git a/devops/incident-response/README.md b/devops/incident-response/README.md deleted file mode 100644 index e03bd42b1f84bed79d3336f4b0b14d6ec9934121..0000000000000000000000000000000000000000 --- a/devops/incident-response/README.md +++ /dev/null @@ -1,26 +0,0 @@ -# Incident Response - -Production incident response workflow with severity-based routing, war room coordination, incident commander assignment, customer communication, root cause analysis, and postmortem scheduling. - -**Domain:** devops -**Complexity:** 5/5 -**Tags:** [incident-management, on-call, pagerduty, war-room, severity-levels, postmortem, sre] - -## Lanes -- **Monitoring System** - Triggers alerts, pages on-call, logs timeline -- **On-Call Responder** - Acknowledges, assesses severity, escalates -- **Incident Command** - Opens war room, assigns commander, coordinates -- **Resolution** - Root cause analysis, fix implementation, postmortem - -## Process Flow -1. Alert triggered by monitoring system -2. Page on-call responder via PagerDuty -3. Responder acknowledges and assesses severity -4. SEV-1/2: Declare major incident, open war room -5. SEV-3/4: Begin direct troubleshooting -6. Assign incident commander for major incidents -7. Coordinate response teams and communicate status -8. Notify customer success if customer impact detected -9. Identify root cause and implement fix -10. Verify recovery and close incident -11. Schedule postmortem for learning diff --git a/devops/infrastructure-provisioning/README.md b/devops/infrastructure-provisioning/README.md deleted file mode 100644 index 1308d59ae57bd76954bcf451c9f93cc801f5516d..0000000000000000000000000000000000000000 --- a/devops/infrastructure-provisioning/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Infrastructure Provisioning - -Infrastructure as Code provisioning workflow with Terraform plan, approval gates, state management, resource creation, and drift detection. - -**Domain:** devops -**Complexity:** 4/5 -**Tags:** [infrastructure-provisioning, terraform, iac, cloud-resources, gitops, state-management] - -## Lanes -- **Developer** - Writes IaC, submits PR -- **CI/CD Pipeline** - Plans and applies changes -- **Cloud Provider** - Provisions resources - -## Process Flow -1. Write infrastructure code (Terraform/Pulumi) -2. Submit pull request for review -3. CI runs terraform plan -4. Review plan output for changes -5. Approve PR and merge -6. CD runs terraform apply -7. Provision cloud resources -8. Update state file -9. Run drift detection periodically diff --git a/devops/infrastructure-provisioning/metadata.json b/devops/infrastructure-provisioning/metadata.json deleted file mode 100644 index f66c886f276c40b32e3ee9e29012158dcff38154..0000000000000000000000000000000000000000 --- a/devops/infrastructure-provisioning/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "infrastructure-provisioning", - "domain": "devops", - "complexity": 4, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "infrastructure-provisioning", - "terraform", - "iac", - "cloud-resources", - "gitops", - "state-management" - ], - "description": "Infrastructure as Code provisioning workflow with Terraform plan, approval gates, state management, resource creation, and drift detection." -} \ No newline at end of file diff --git a/devops/load-testing/README.md b/devops/load-testing/README.md deleted file mode 100644 index 620bea0c5a08d7c78b3f70c38a61c88fc018c950..0000000000000000000000000000000000000000 --- a/devops/load-testing/README.md +++ /dev/null @@ -1,24 +0,0 @@ -# Load Testing - -Load testing workflow with test scenario design, gradual ramp-up, performance metrics collection, bottleneck identification, and capacity recommendations. - -**Domain:** devops -**Complexity:** 4/5 -**Tags:** [load-testing, performance-testing, stress-testing, k6, jmeter, capacity-planning] - -## Lanes -- **QA/Performance Team** - Designs tests, analyzes results -- **Load Generator** - Executes load scenarios -- **Target System** - System under test -- **Monitoring** - Collects performance metrics - -## Process Flow -1. Define load test scenarios -2. Configure virtual users and ramp-up -3. Set up monitoring dashboards -4. Execute load test -5. Gradually increase load -6. Monitor response times and errors -7. Identify performance bottlenecks -8. Generate performance report -9. Recommend capacity changes diff --git a/devops/load-testing/metadata.json b/devops/load-testing/metadata.json deleted file mode 100644 index 27f417c11b711040e7df55a08648085e0635deaa..0000000000000000000000000000000000000000 --- a/devops/load-testing/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "load-testing", - "domain": "devops", - "complexity": 4, - "num_nodes": 13, - "num_lanes": 4, - "tags": [ - "load-testing", - "performance-testing", - "stress-testing", - "k6", - "jmeter", - "capacity-planning" - ], - "description": "Load testing workflow with test scenario design, gradual ramp-up, performance metrics collection, bottleneck identification, and capacity recommendations." -} \ No newline at end of file diff --git a/devops/monitoring-alert/README.md b/devops/monitoring-alert/README.md deleted file mode 100644 index d36631f877278adf4f3d4ed4c465928949e213ff..0000000000000000000000000000000000000000 --- a/devops/monitoring-alert/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Monitoring and Alerting - -Monitoring and alerting workflow with metric collection, threshold evaluation, alert routing, escalation policies, and incident creation. - -**Domain:** devops -**Complexity:** 3/5 -**Tags:** [monitoring-alerting, prometheus, pagerduty, threshold-alerts, anomaly-detection, on-call] - -## Lanes -- **Monitoring System** - Collects metrics, evaluates rules -- **Alert Manager** - Routes alerts, manages escalation -- **On-Call Engineer** - Receives and responds to alerts - -## Process Flow -1. Collect metrics from services -2. Evaluate alerting rules -3. Detect threshold breach -4. Deduplicate and group alerts -5. Route to appropriate team -6. Send notification (Slack, PagerDuty) -7. If no acknowledgment, escalate -8. On-call investigates issue -9. Resolve or create incident diff --git a/devops/monitoring-alert/metadata.json b/devops/monitoring-alert/metadata.json deleted file mode 100644 index dcdbe9803c65947633c7c89c819c341e08bf4d92..0000000000000000000000000000000000000000 --- a/devops/monitoring-alert/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "monitoring-alert", - "domain": "devops", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "monitoring-alerting", - "prometheus", - "pagerduty", - "threshold-alerts", - "anomaly-detection", - "on-call" - ], - "description": "Monitoring and alerting workflow with metric collection, threshold evaluation, alert routing, escalation policies, and incident creation." -} \ No newline at end of file diff --git a/devops/on-call-rotation/README.md b/devops/on-call-rotation/README.md deleted file mode 100644 index 4b8e077cd655f586b1d070131c8289dba8857d5b..0000000000000000000000000000000000000000 --- a/devops/on-call-rotation/README.md +++ /dev/null @@ -1,24 +0,0 @@ -# On-Call Rotation - -On-call rotation workflow with schedule creation, shift handoffs, override management, escalation policies, and fair rotation distribution. - -**Domain:** devops -**Complexity:** 3/5 -**Tags:** [on-call-rotation, incident-management, pagerduty, escalation, schedule-management, handoff] - -## Lanes -- **Engineering Manager** - Creates rotation schedule -- **On-Call Engineer** - Primary responder -- **Backup Engineer** - Secondary escalation -- **PagerDuty** - Manages schedules and alerts - -## Process Flow -1. Create on-call rotation schedule -2. Assign engineers to shifts -3. Configure escalation policies -4. Handle override requests (PTO, swaps) -5. Notify engineer of upcoming shift -6. Conduct shift handoff meeting -7. Transfer context on active issues -8. Update schedule in PagerDuty -9. Track on-call burden for fairness diff --git a/devops/on-call-rotation/metadata.json b/devops/on-call-rotation/metadata.json deleted file mode 100644 index e111db7a2b4634de7f97a209a9ec344770376334..0000000000000000000000000000000000000000 --- a/devops/on-call-rotation/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "on-call-rotation", - "domain": "devops", - "complexity": 3, - "num_nodes": 13, - "num_lanes": 4, - "tags": [ - "on-call-rotation", - "incident-management", - "pagerduty", - "escalation", - "schedule-management", - "handoff" - ], - "description": "On-call rotation workflow with schedule creation, shift handoffs, override management, escalation policies, and fair rotation distribution." -} \ No newline at end of file diff --git a/devops/secret-rotation/README.md b/devops/secret-rotation/README.md deleted file mode 100644 index 75614d596f24664d2c48140da64cffae59adf14f..0000000000000000000000000000000000000000 --- a/devops/secret-rotation/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Secret Rotation - -Automated secret rotation workflow with HashiCorp Vault for API keys, database passwords, and certificates including Kubernetes secret updates and rolling service restarts. - -**Domain:** devops -**Complexity:** 4/5 -**Tags:** [secret-rotation, vault, kubernetes-secrets, api-keys, database-passwords, certificates, security] - -## Lanes -- **Rotation Scheduler** - Monitors expiration dates, triggers rotation -- **Secret Vault** - Generates new secrets, stores versions by type -- **Secret Deployment** - Updates K8s secrets, triggers rolling restarts - -## Process Flow -1. Check secret expiration dates in inventory -2. Identify secrets due for rotation -3. Generate new secret value in Vault -4. Store new version with metadata -5. Route by secret type (API key, DB password, certificate) -6. Update Kubernetes secrets -7. Trigger rolling restart of dependent services -8. Verify services are healthy after restart -9. Mark rotation successful or rollback to previous diff --git a/devops/secret-rotation/metadata.json b/devops/secret-rotation/metadata.json deleted file mode 100644 index d673c72c57f818eb32b24c0bf9fb5ecd9aa5944a..0000000000000000000000000000000000000000 --- a/devops/secret-rotation/metadata.json +++ /dev/null @@ -1,17 +0,0 @@ -{ - "workflow_id": "secret-rotation", - "domain": "devops", - "complexity": 4, - "num_nodes": 18, - "num_lanes": 3, - "tags": [ - "secret-rotation", - "vault", - "kubernetes-secrets", - "api-keys", - "database-passwords", - "certificates", - "security" - ], - "description": "Automated secret rotation workflow with HashiCorp Vault for API keys, database passwords, and certificates including Kubernetes secret updates and rolling service restarts." -} \ No newline at end of file diff --git a/devops/security-scan/README.md b/devops/security-scan/README.md deleted file mode 100644 index 01e064df335f7feb2f1213b11244a20fc7ae5b2c..0000000000000000000000000000000000000000 --- a/devops/security-scan/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Security Scanning - -Security scanning workflow with SAST, DAST, dependency vulnerability scanning, finding triage, and remediation tracking in CI/CD pipeline. - -**Domain:** devops -**Complexity:** 3/5 -**Tags:** [security-scanning, sast, dast, dependency-check, snyk, devsecops] - -## Lanes -- **CI/CD Pipeline** - Triggers scans on code changes -- **Security Scanner** - Performs SAST/DAST/SCA -- **Security Team** - Triages and tracks findings - -## Process Flow -1. Trigger scan on PR or commit -2. Run SAST (static analysis) -3. Run dependency vulnerability scan -4. Run DAST on deployed app (if applicable) -5. Aggregate findings -6. Filter false positives -7. Classify severity (critical, high, medium, low) -8. Block PR if critical findings -9. Track remediation in security dashboard diff --git a/devops/security-scan/metadata.json b/devops/security-scan/metadata.json deleted file mode 100644 index 17c36c24cf9fdc734eaf8053ee736b3d6a19f13c..0000000000000000000000000000000000000000 --- a/devops/security-scan/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "security-scan", - "domain": "devops", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "security-scanning", - "sast", - "dast", - "dependency-check", - "snyk", - "devsecops" - ], - "description": "Security scanning workflow with SAST, DAST, dependency vulnerability scanning, finding triage, and remediation tracking in CI/CD pipeline." -} \ No newline at end of file diff --git a/devops/vulnerability-patch/README.md b/devops/vulnerability-patch/README.md deleted file mode 100644 index 16223c8a019f34498381f816619bb1898190f87f..0000000000000000000000000000000000000000 --- a/devops/vulnerability-patch/README.md +++ /dev/null @@ -1,24 +0,0 @@ -# Vulnerability Patch - -Security vulnerability patching workflow with CVE scanning, severity-based triage (critical/high/medium), patch testing, staging deployment, and production rollout with rollback capability. - -**Domain:** devops -**Complexity:** 4/5 -**Tags:** [vulnerability-management, security-patching, cve-triage, cvss-scoring, patch-testing, rollback, compliance] - -## Lanes -- **Vulnerability Scanner** - Runs dependency scans, analyzes CVE database -- **Vulnerability Triage** - Assesses CVSS scores, creates tickets by severity -- **Patch Application** - Updates dependencies, tests, deploys with rollback - -## Process Flow -1. Run dependency scan against CVE database -2. Assess CVSS score for each vulnerability -3. Route by severity: Critical, High, or Medium/Low -4. Critical/High: Create priority ticket and assign to security team -5. Medium/Low: Add to backlog for scheduled patching -6. Update dependency version with patch -7. Run regression tests -8. Deploy to staging and verify health -9. Deploy to production if staging healthy -10. Rollback if issues detected diff --git a/edge-cases/bidirectional-loop/README.md b/edge-cases/bidirectional-loop/README.md deleted file mode 100644 index 50436a684762895c7c29d2dfd13cdd217b94bb14..0000000000000000000000000000000000000000 --- a/edge-cases/bidirectional-loop/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Bidirectional Loop - -This workflow models circular references between nodes in both directions. - -**Domain:** edge-cases -**Complexity:** 5/5 -**Tags:** [bidirectional, loop, decision] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/edge-cases/bidirectional-loop/metadata.json b/edge-cases/bidirectional-loop/metadata.json deleted file mode 100644 index 482a6189511974314436a5bcc27a8b9b56c6e2c4..0000000000000000000000000000000000000000 --- a/edge-cases/bidirectional-loop/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "bidirectional-loop", - "domain": "edge-cases", - "complexity": 5, - "num_nodes": 16, - "num_lanes": 4, - "tags": [ - "bidirectional", - "loop", - "decision" - ], - "description": "This workflow models circular references between nodes in both directions." -} \ No newline at end of file diff --git a/edge-cases/bidirectional-loop/workflow.fz b/edge-cases/bidirectional-loop/workflow.fz deleted file mode 100644 index 7dbb773c939ad2076647a62a4f8404f5f0e07354..0000000000000000000000000000000000000000 --- a/edge-cases/bidirectional-loop/workflow.fz +++ /dev/null @@ -1,46 +0,0 @@ -laneA { # Lanea - n1: circle label:"Start Bidirectional Loop" - n2: diamond label:"Bidirectional Loop step 2" - n5: rectangle label:"Bidirectional Loop step 5" - n9: rectangle label:"Bidirectional Loop step 9" - n13: rectangle label:"Bidirectional Loop step 13" - n1.handle(right) -> n2.handle(left) - n2.handle(bottom) -> laneC.n3.handle(top) [label="Yes/Approved"] - n2.handle(bottom) -> laneD.n4.handle(top) [label="No/Rejected"] - n5.handle(bottom) -> laneB.n6.handle(top) - n9.handle(bottom) -> laneB.n10.handle(top) - n13.handle(bottom) -> laneB.n14.handle(top) - n2.handle(right) -> laneC.n3.handle(left) [label="Forward"] - loop [retry until success] n2 n5 n9 n13 n6 n10 n14 n3 n7 n11 n15 n4 n8 n12 -} - -laneB { # Laneb - n6: rectangle label:"Bidirectional Loop step 6" - n10: rectangle label:"Bidirectional Loop step 10" - n14: rectangle label:"Bidirectional Loop step 14" - n6.handle(bottom) -> laneC.n7.handle(top) - n10.handle(bottom) -> laneC.n11.handle(top) - n14.handle(bottom) -> laneC.n15.handle(top) -} - -laneC { # Lanec - n3: rectangle label:"Bidirectional Loop step 3" - n7: rectangle label:"Bidirectional Loop step 7" - n11: rectangle label:"Bidirectional Loop step 11" - n15: rectangle label:"Bidirectional Loop step 15" - n7.handle(bottom) -> laneD.n8.handle(top) - n11.handle(bottom) -> laneD.n12.handle(top) - n15.handle(bottom) -> laneD.n16.handle(top) - n3.handle(left) -> laneA.n2.handle(right) [label="Back"] - n3.handle(right) -> laneA.n5.handle(left) -} - -laneD { # Laned - n4: rectangle label:"Bidirectional Loop step 4" - n8: rectangle label:"Bidirectional Loop step 8" - n12: rectangle label:"Bidirectional Loop step 12" - n16: circle label:"End Bidirectional Loop" - n12.handle(right) -> laneA.n13.handle(left) - n8.handle(right) -> laneA.n9.handle(left) - n4.handle(right) -> laneA.n5.handle(left) -} diff --git a/edge-cases/comment-like-labels/README.md b/edge-cases/comment-like-labels/README.md deleted file mode 100644 index 6be1425f7ef635e22a43680cd1dcca345fcb5680..0000000000000000000000000000000000000000 --- a/edge-cases/comment-like-labels/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Comment Like Labels - -This workflow models labels that look like code comments. - -**Domain:** edge-cases -**Complexity:** 1/5 -**Tags:** [comment, like, labels] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/edge-cases/comment-like-labels/metadata.json b/edge-cases/comment-like-labels/metadata.json deleted file mode 100644 index ac7d8ff3458edbb2b6e8c65991f71258b6ded8a3..0000000000000000000000000000000000000000 --- a/edge-cases/comment-like-labels/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "comment-like-labels", - "domain": "edge-cases", - "complexity": 1, - "num_nodes": 5, - "num_lanes": 1, - "tags": [ - "comment", - "like", - "labels" - ], - "description": "This workflow models labels that look like code comments." -} \ No newline at end of file diff --git a/edge-cases/comment-like-labels/workflow.fz b/edge-cases/comment-like-labels/workflow.fz deleted file mode 100644 index 2044d5504a77c776ef514b96ef589b1b6e868846..0000000000000000000000000000000000000000 --- a/edge-cases/comment-like-labels/workflow.fz +++ /dev/null @@ -1,12 +0,0 @@ -laneA { # Lanea - n1: circle label:"Start Comment Like Labels" - n2: rectangle label:"// looks like a comment" - n3: rectangle label:"# also looks like a comment" - n4: rectangle label:"Comment Like Labels step 4" - n5: circle label:"End Comment Like Labels" - - n1.handle(right) -> n2.handle(left) - n2.handle(right) -> n3.handle(left) [label="Next"] - n3.handle(right) -> n4.handle(left) - n4.handle(right) -> n5.handle(left) -} \ No newline at end of file diff --git a/edge-cases/cross-lane-circular/README.md b/edge-cases/cross-lane-circular/README.md deleted file mode 100644 index 7e6751b1aac82ebac500e8878e23385202ddd10d..0000000000000000000000000000000000000000 --- a/edge-cases/cross-lane-circular/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Cross Lane Circular - -This workflow models arrows that loop across lanes. - -**Domain:** edge-cases -**Complexity:** 4/5 -**Tags:** [cross, lane, circular] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/edge-cases/cross-lane-circular/metadata.json b/edge-cases/cross-lane-circular/metadata.json deleted file mode 100644 index b9f23f4ccaf9201346102d129d2822e95ba1ed34..0000000000000000000000000000000000000000 --- a/edge-cases/cross-lane-circular/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "cross-lane-circular", - "domain": "edge-cases", - "complexity": 4, - "num_nodes": 13, - "num_lanes": 4, - "tags": [ - "cross", - "lane", - "circular" - ], - "description": "This workflow models arrows that loop across lanes." -} \ No newline at end of file diff --git a/edge-cases/cross-lane-circular/workflow.fz b/edge-cases/cross-lane-circular/workflow.fz deleted file mode 100644 index 5057e4cbf5d8ee1ffaa75c32528d9ffdec4248bc..0000000000000000000000000000000000000000 --- a/edge-cases/cross-lane-circular/workflow.fz +++ /dev/null @@ -1,38 +0,0 @@ -laneA { # Lane A - n1: circle label:"Start Cross Lane Circular" - n5: rectangle label:"Cross Lane Circular step 5" - n9: rectangle label:"Cross Lane Circular step 9" - n13: circle label:"End Cross Lane Circular" - n1.handle(bottom) -> laneB.n2.handle(top) - n5.handle(bottom) -> laneB.n6.handle(top) [label="Done"] - n9.handle(bottom) -> laneB.n10.handle(top) -} - -laneB { # Lane B - n2: rectangle label:"Cross Lane Circular step 2" - n6: rectangle label:"Cross Lane Circular step 6" - n10: rectangle label:"Cross Lane Circular step 10" - n2.handle(bottom) -> laneC.n3.handle(top) [label="Next"] - n6.handle(bottom) -> laneC.n7.handle(top) - n10.handle(bottom) -> laneC.n11.handle(top) -} - -laneC { # Lane C - n3: rectangle label:"Cross Lane Circular step 3" - n7: rectangle label:"Cross Lane Circular step 7" - n11: rectangle label:"Cross Lane Circular step 11" - n3.handle(bottom) -> laneD.n4.handle(top) - n7.handle(bottom) -> laneD.n8.handle(top) - n11.handle(bottom) -> laneD.n12.handle(top) [label="Success"] -} - -laneD { # Lane D - n4: diamond label:"Cross Lane Circular step 4" - n8: rectangle label:"Cross Lane Circular step 8" - n12: diamond label:"Cross Lane Circular step 12" - n12.handle(left) -> laneC.n11.handle(left) [label="Retry/Rejected"] - n12.handle(right) -> laneA.n13.handle(bottom) - n8.handle(right) -> laneA.n9.handle(left) [label="Processed"] - n4.handle(right) -> laneA.n5.handle(left) - n4.handle(left) -> laneC.n3.handle(left) [label="Retry/Rejected"] -} diff --git a/edge-cases/deep-nesting/README.md b/edge-cases/deep-nesting/README.md deleted file mode 100644 index 58bb666ef72b2b0d6a50351c971fc4798651aac6..0000000000000000000000000000000000000000 --- a/edge-cases/deep-nesting/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Deep Nesting - -This workflow models lanes that are conceptually nested within each other. - -**Domain:** edge-cases -**Complexity:** 4/5 -**Tags:** [deep, nesting, parallel] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/edge-cases/deep-nesting/metadata.json b/edge-cases/deep-nesting/metadata.json deleted file mode 100644 index 907c4b8290f07c6d1aa062031fd4aeadd91f6cdb..0000000000000000000000000000000000000000 --- a/edge-cases/deep-nesting/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "deep-nesting", - "domain": "edge-cases", - "complexity": 4, - "num_nodes": 13, - "num_lanes": 4, - "tags": [ - "deep", - "nesting", - "parallel" - ], - "description": "This workflow models lanes that are conceptually nested within each other." -} \ No newline at end of file diff --git a/edge-cases/deep-nesting/workflow.fz b/edge-cases/deep-nesting/workflow.fz deleted file mode 100644 index 1ed203c450372be03cb8ef8482806c963985c33b..0000000000000000000000000000000000000000 --- a/edge-cases/deep-nesting/workflow.fz +++ /dev/null @@ -1,46 +0,0 @@ -laneA { # Lane A - n1: circle label:"Start Deep Nesting" - n5: rectangle label:"Deep Nesting step 5" - n9: rectangle label:"Deep Nesting step 9" - n13: circle label:"End Deep Nesting" - n1.handle(bottom) -> laneB.n2.handle(top) - n1.handle(bottom) -> laneC.n3.handle(top) - n1.handle(bottom) -> laneD.n4.handle(top) - n1.handle(right) -> n5.handle(left) - n1.handle(bottom) -> laneB.n6.handle(top) - n1.handle(bottom) -> laneC.n7.handle(top) - n1.handle(bottom) -> laneD.n8.handle(top) - n1.handle(right) -> n9.handle(left) - n1.handle(bottom) -> laneB.n10.handle(top) - n1.handle(bottom) -> laneC.n11.handle(top) - n1.handle(bottom) -> laneD.n12.handle(top) - n5.handle(right) -> n13.handle(left) - n9.handle(right) -> n13.handle(left) -} - -laneB { # Lane B - n2: rectangle label:"Deep Nesting step 2" - n6: diamond label:"Deep Nesting step 6" - n10: rectangle label:"Deep Nesting step 10" - n10.handle(right) -> laneA.n13.handle(bottom) - n6.handle(right) -> laneA.n13.handle(bottom) - n2.handle(right) -> laneA.n13.handle(bottom) -} - -laneC { # Lane C - n3: rectangle label:"Deep Nesting step 3" - n7: rectangle label:"Deep Nesting step 7" - n11: rectangle label:"Deep Nesting step 11" - n11.handle(right) -> laneA.n13.handle(bottom) - n7.handle(right) -> laneA.n13.handle(bottom) - n3.handle(right) -> laneA.n13.handle(bottom) -} - -laneD { # Lane D - n4: rectangle label:"Deep Nesting step 4" - n8: rectangle label:"Deep Nesting step 8" - n12: rectangle label:"Deep Nesting step 12" - n12.handle(right) -> laneA.n13.handle(bottom) - n8.handle(right) -> laneA.n13.handle(bottom) - n4.handle(right) -> laneA.n13.handle(bottom) -} diff --git a/edge-cases/disconnected-lanes/README.md b/edge-cases/disconnected-lanes/README.md deleted file mode 100644 index f12c5c5a1de31860527d1543d5d96c8eff0d7569..0000000000000000000000000000000000000000 --- a/edge-cases/disconnected-lanes/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Disconnected Lanes - -This workflow models lanes that never connect to each other. - -**Domain:** edge-cases -**Complexity:** 2/5 -**Tags:** [disconnected, lanes, decision, loop] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/edge-cases/disconnected-lanes/metadata.json b/edge-cases/disconnected-lanes/metadata.json deleted file mode 100644 index fca0351ca5b528f8ca281efcfc0ba84efba0c13b..0000000000000000000000000000000000000000 --- a/edge-cases/disconnected-lanes/metadata.json +++ /dev/null @@ -1,14 +0,0 @@ -{ - "workflow_id": "disconnected-lanes", - "domain": "edge-cases", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "disconnected", - "lanes", - "decision", - "loop" - ], - "description": "This workflow models lanes that never connect to each other." -} \ No newline at end of file diff --git a/edge-cases/disconnected-lanes/workflow.fz b/edge-cases/disconnected-lanes/workflow.fz deleted file mode 100644 index c539d36199fc23152aa80ca452da0eb36cd237aa..0000000000000000000000000000000000000000 --- a/edge-cases/disconnected-lanes/workflow.fz +++ /dev/null @@ -1,22 +0,0 @@ - -laneA { # Lane A - n1: circle label:"Start Disconnected Lanes" - n2: diamond label:"Disconnected Lanes step 2" - n3: rectangle label:"Disconnected Lanes step 3" - n5: rectangle label:"Disconnected Lanes step 5" - n7: circle label:"End Disconnected Lanes" - n1.handle(right) -> n2.handle(left) - n2.handle(right) -> n3.handle(left) [label="Yes/Approved"] - n2.handle(bottom) -> laneB.n4.handle(top) [label="No/Rejected"] - n3.handle(right) -> n5.handle(left) - n5.handle(bottom) -> laneB.n6.handle(top) - - loop [retry until success] n2 n3 n4 n5 n6 -} - -laneB { # Lane B - n4: rectangle label:"Disconnected Lanes step 4" - n6: rectangle label:"Disconnected Lanes step 6" - n6.handle(right) -> laneA.n7.handle(bottom) - n4.handle(right) -> laneA.n5.handle(left) -} diff --git a/edge-cases/duplicate-node-ids/README.md b/edge-cases/duplicate-node-ids/README.md deleted file mode 100644 index f5114ed902191c9909cb532af37789779d3999df..0000000000000000000000000000000000000000 --- a/edge-cases/duplicate-node-ids/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Duplicate Node Ids - -This workflow models the same node IDs reused in different lanes. - -**Domain:** edge-cases -**Complexity:** 3/5 -**Tags:** [duplicate, node, ids] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/edge-cases/duplicate-node-ids/metadata.json b/edge-cases/duplicate-node-ids/metadata.json deleted file mode 100644 index 0a43d1f841eb75a0aa7e0fcf27662fe18866417f..0000000000000000000000000000000000000000 --- a/edge-cases/duplicate-node-ids/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "duplicate-node-ids", - "domain": "edge-cases", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "duplicate", - "node", - "ids" - ], - "description": "This workflow models the same node IDs reused in different lanes." -} \ No newline at end of file diff --git a/edge-cases/duplicate-node-ids/workflow.fz b/edge-cases/duplicate-node-ids/workflow.fz deleted file mode 100644 index 110cc057d7ae354f242989373cf76a630508832c..0000000000000000000000000000000000000000 --- a/edge-cases/duplicate-node-ids/workflow.fz +++ /dev/null @@ -1,29 +0,0 @@ -laneA { # Lanea - n1: circle label:"Start Duplicate Node Ids" - n2: rectangle label:"Duplicate Node Ids step 4" - n1: rectangle label:"Duplicate Node Ids step 7" - n2: circle label:"End Duplicate Node Ids" - - n1.handle(bottom) -> laneB.n2.handle(top) [label="Success"] - n2.handle(bottom) -> laneB.n1.handle(top) [label="Valid"] - n1.handle(bottom) -> laneB.n2.handle(top) [label="Next"] -} -laneB { # Laneb - n2: rectangle label:"Duplicate Node Ids step 2" - n1: rectangle label:"Duplicate Node Ids step 5" - n2: diamond label:"Duplicate Node Ids step 8" - - n2.handle(bottom) -> laneC.n1.handle(top) - n1.handle(bottom) -> laneC.n2.handle(top) - n2.handle(bottom) -> laneC.n1.handle(top) - n2.handle(right) -> laneA.n1.handle(right) [label="Retry/Rejected"] -} -laneC { # Lanec - n1: rectangle label:"Duplicate Node Ids step 3" - n2: rectangle label:"Duplicate Node Ids step 6" - n1: rectangle label:"Duplicate Node Ids step 9" - - n1.handle(bottom) -> laneA.n2.handle(top) - n2.handle(bottom) -> laneA.n1.handle(top) - n1.handle(bottom) -> laneA.n2.handle(top) -} \ No newline at end of file diff --git a/edge-cases/empty-lane/README.md b/edge-cases/empty-lane/README.md deleted file mode 100644 index d0ab66ee7dc3a1532841879668c28455e8f4c247..0000000000000000000000000000000000000000 --- a/edge-cases/empty-lane/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Empty Lane - -This workflow models a lane with no nodes. - -**Domain:** edge-cases -**Complexity:** 3/5 -**Tags:** [empty, lane] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/edge-cases/empty-lane/metadata.json b/edge-cases/empty-lane/metadata.json deleted file mode 100644 index ff8d421603399cb79ef8161a0597f2bc0d32b008..0000000000000000000000000000000000000000 --- a/edge-cases/empty-lane/metadata.json +++ /dev/null @@ -1,12 +0,0 @@ -{ - "workflow_id": "empty-lane", - "domain": "edge-cases", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "empty", - "lane" - ], - "description": "This workflow models a lane with no nodes." -} \ No newline at end of file diff --git a/edge-cases/empty-lane/workflow.fz b/edge-cases/empty-lane/workflow.fz deleted file mode 100644 index 81e115fc2b1d3f7050f6c05738ec1c7580cf3649..0000000000000000000000000000000000000000 --- a/edge-cases/empty-lane/workflow.fz +++ /dev/null @@ -1,29 +0,0 @@ -laneA { # Lanea - n1: circle label:"Start Empty Lane" - n4: rectangle label:"Empty Lane step 4" - n7: rectangle label:"Empty Lane step 7" - n10: circle label:"End Empty Lane" - - n1.handle(bottom) -> laneB.n2.handle(top) [label="Success"] - n4.handle(bottom) -> laneB.n5.handle(top) [label="Valid"] - n7.handle(bottom) -> laneB.n8.handle(top) [label="Next"] -} -laneB { # Laneb - n2: rectangle label:"Empty Lane step 2" - n5: rectangle label:"Empty Lane step 5" - n8: rectangle label:"Empty Lane step 8" - - n2.handle(bottom) -> laneC.n3.handle(top) - n5.handle(bottom) -> laneC.n6.handle(top) - n8.handle(bottom) -> laneC.n9.handle(top) -} -laneC { # Lanec - n3: diamond label:"Empty Lane step 3" - n6: rectangle label:"Empty Lane step 6" - n9: rectangle label:"Empty Lane step 9" - - n3.handle(bottom) -> laneA.n4.handle(top) - n3.handle(right) -> laneB.n2.handle(right) [label="Retry/Rejected"] - n6.handle(bottom) -> laneA.n7.handle(top) - n9.handle(bottom) -> laneA.n10.handle(top) -} \ No newline at end of file diff --git a/edge-cases/extra-whitespace/README.md b/edge-cases/extra-whitespace/README.md deleted file mode 100644 index b456c9045d67db828734afe7b526046f0589044a..0000000000000000000000000000000000000000 --- a/edge-cases/extra-whitespace/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Extra Whitespace - -This workflow models labels that include leading and trailing spaces. - -**Domain:** edge-cases -**Complexity:** 5/5 -**Tags:** [extra, whitespace] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/edge-cases/extra-whitespace/metadata.json b/edge-cases/extra-whitespace/metadata.json deleted file mode 100644 index 1e3a2ea6070446d415b1c61e562003f0c8c21201..0000000000000000000000000000000000000000 --- a/edge-cases/extra-whitespace/metadata.json +++ /dev/null @@ -1,12 +0,0 @@ -{ - "workflow_id": "extra-whitespace", - "domain": "edge-cases", - "complexity": 5, - "num_nodes": 16, - "num_lanes": 4, - "tags": [ - "extra", - "whitespace" - ], - "description": "This workflow models labels that include leading and trailing spaces." -} \ No newline at end of file diff --git a/edge-cases/extra-whitespace/workflow.fz b/edge-cases/extra-whitespace/workflow.fz deleted file mode 100644 index 782eb3e697dbdc95810e732c1c9b610a5babee69..0000000000000000000000000000000000000000 --- a/edge-cases/extra-whitespace/workflow.fz +++ /dev/null @@ -1,45 +0,0 @@ -laneA { # Lanea - n1: circle label:"Start Extra Whitespace" - n5: rectangle label:"Extra Whitespace step 5" - n9: rectangle label:"Extra Whitespace step 9" - n13: rectangle label:"Extra Whitespace step 13" - - n1.handle(bottom) -> laneB.n2.handle(top) - n5.handle(bottom) -> laneB.n6.handle(top) - n9.handle(bottom) -> laneB.n10.handle(top) [label="Valid"] - n13.handle(bottom) -> laneB.n14.handle(top) -} -laneB { # Laneb - n2: rectangle label:" Label with spaces " - n6: rectangle label:"Extra Whitespace step 6" - n10: rectangle label:"Extra Whitespace step 10" - n14: rectangle label:"Extra Whitespace step 14" - - n2.handle(bottom) -> laneC.n3.handle(top) - n6.handle(bottom) -> laneC.n7.handle(top) [label="Success"] - n10.handle(bottom) -> laneC.n11.handle(top) - n14.handle(bottom) -> laneC.n15.handle(top) -} -laneC { # Lanec - n3: rectangle label:"Extra Whitespace step 3" - n7: diamond label:"Extra Whitespace step 7" - n11: rectangle label:"Extra Whitespace step 11" - n15: diamond label:"Extra Whitespace step 15" - - n3.handle(bottom) -> laneD.n4.handle(top) [label="Processed"] - n7.handle(bottom) -> laneD.n8.handle(top) - n7.handle(right) -> laneB.n6.handle(right) [label="Retry/Rejected"] - n11.handle(bottom) -> laneD.n12.handle(top) - n15.handle(bottom) -> laneD.n16.handle(top) [label="Done"] - n15.handle(right) -> laneB.n14.handle(right) [label="Retry/Rejected"] -} -laneD { # Laned - n4: rectangle label:"Extra Whitespace step 4" - n8: rectangle label:"Extra Whitespace step 8" - n12: rectangle label:"Extra Whitespace step 12" - n16: circle label:"End Extra Whitespace" - - n4.handle(bottom) -> laneA.n5.handle(top) - n8.handle(bottom) -> laneA.n9.handle(top) - n12.handle(bottom) -> laneA.n13.handle(top) [label="Next"] -} \ No newline at end of file diff --git a/edge-cases/json-in-label/README.md b/edge-cases/json-in-label/README.md deleted file mode 100644 index 4ec663e5d6dbda54600122336eca8f82528be5d9..0000000000000000000000000000000000000000 --- a/edge-cases/json-in-label/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Json In Label - -This workflow models a label that contains JSON text. - -**Domain:** edge-cases -**Complexity:** 4/5 -**Tags:** [json, in, label] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/edge-cases/json-in-label/metadata.json b/edge-cases/json-in-label/metadata.json deleted file mode 100644 index 543d2894eb4958a5e531d688ae92bb14f59fb709..0000000000000000000000000000000000000000 --- a/edge-cases/json-in-label/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "json-in-label", - "domain": "edge-cases", - "complexity": 4, - "num_nodes": 13, - "num_lanes": 4, - "tags": [ - "json", - "in", - "label" - ], - "description": "This workflow models a label that contains JSON text." -} \ No newline at end of file diff --git a/edge-cases/json-in-label/workflow.fz b/edge-cases/json-in-label/workflow.fz deleted file mode 100644 index 97a6f73a2b5383ac112ac1ee1ffe4f1bf45b8e75..0000000000000000000000000000000000000000 --- a/edge-cases/json-in-label/workflow.fz +++ /dev/null @@ -1,39 +0,0 @@ -laneA { # Lanea - n1: circle label:"Start Json In Label" - n5: rectangle label:"Json In Label step 5" - n9: rectangle label:"Json In Label step 9" - n13: circle label:"End Json In Label" - - n1.handle(bottom) -> laneB.n2.handle(top) - n5.handle(bottom) -> laneB.n6.handle(top) - n9.handle(bottom) -> laneB.n10.handle(top) [label="Valid"] -} -laneB { # Laneb - n2: rectangle label:"{\"key\":\"value\",\"count\":3}" - n6: rectangle label:"Json In Label step 6" - n10: rectangle label:"Json In Label step 10" - - n2.handle(bottom) -> laneC.n3.handle(top) - n6.handle(bottom) -> laneC.n7.handle(top) [label="Success"] - n10.handle(bottom) -> laneC.n11.handle(top) -} -laneC { # Lanec - n3: rectangle label:"Json In Label step 3" - n7: rectangle label:"Json In Label step 7" - n11: rectangle label:"Json In Label step 11" - - n3.handle(bottom) -> laneD.n4.handle(top) [label="Processed"] - n7.handle(bottom) -> laneD.n8.handle(top) - n11.handle(bottom) -> laneD.n12.handle(top) -} -laneD { # Laned - n4: diamond label:"Json In Label step 4" - n8: rectangle label:"Json In Label step 8" - n12: diamond label:"Json In Label step 12" - - n4.handle(bottom) -> laneA.n5.handle(top) - n4.handle(right) -> laneC.n3.handle(right) [label="Retry/Rejected"] - n8.handle(bottom) -> laneA.n9.handle(top) - n12.handle(bottom) -> laneA.n13.handle(top) [label="Next"] - n12.handle(right) -> laneC.n11.handle(right) [label="Retry/Rejected"] -} \ No newline at end of file diff --git a/edge-cases/label-escaping/README.md b/edge-cases/label-escaping/README.md deleted file mode 100644 index d507f888001951c208da04c6b319a4b5f853c5a4..0000000000000000000000000000000000000000 --- a/edge-cases/label-escaping/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Label Escaping - -This workflow models labels containing quotes and special characters. - -**Domain:** edge-cases -**Complexity:** 5/5 -**Tags:** [label, escaping] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/edge-cases/label-escaping/metadata.json b/edge-cases/label-escaping/metadata.json deleted file mode 100644 index 5bed03a102970d243676f9ce1aafb6dfe8bb87c7..0000000000000000000000000000000000000000 --- a/edge-cases/label-escaping/metadata.json +++ /dev/null @@ -1,12 +0,0 @@ -{ - "workflow_id": "label-escaping", - "domain": "edge-cases", - "complexity": 5, - "num_nodes": 16, - "num_lanes": 4, - "tags": [ - "label", - "escaping" - ], - "description": "This workflow models labels containing quotes and special characters." -} \ No newline at end of file diff --git a/edge-cases/label-escaping/workflow.fz b/edge-cases/label-escaping/workflow.fz deleted file mode 100644 index 6386eed9c7f47fe2057348214c2ee1609073dc10..0000000000000000000000000000000000000000 --- a/edge-cases/label-escaping/workflow.fz +++ /dev/null @@ -1,45 +0,0 @@ -laneA { # Lanea - n1: circle label:"Start Label Escaping" - n5: rectangle label:"Label Escaping step 5" - n9: rectangle label:"Label Escaping step 9" - n13: rectangle label:"Label Escaping step 13" - - n1.handle(bottom) -> laneB.n2.handle(top) - n5.handle(bottom) -> laneB.n6.handle(top) [label="Done"] - n9.handle(bottom) -> laneB.n10.handle(top) - n13.handle(bottom) -> laneB.n14.handle(top) -} -laneB { # Laneb - n2: rectangle label:"Label Escaping step 2" - n6: rectangle label:"Label Escaping step 6" - n10: rectangle label:"Label Escaping step 10" - n14: rectangle label:"Label Escaping step 14" - - n2.handle(bottom) -> laneC.n3.handle(top) [label="Next"] - n6.handle(bottom) -> laneC.n7.handle(top) - n10.handle(bottom) -> laneC.n11.handle(top) - n14.handle(bottom) -> laneC.n15.handle(top) [label="Valid"] -} -laneC { # Lanec - n3: rectangle label:"Label Escaping step 3" - n7: rectangle label:"Label Escaping step 7" - n11: rectangle label:"Label Escaping step 11" - n15: rectangle label:"Label Escaping step 15" - - n3.handle(bottom) -> laneD.n4.handle(top) - n7.handle(bottom) -> laneD.n8.handle(top) - n11.handle(bottom) -> laneD.n12.handle(top) [label="Success"] - n15.handle(bottom) -> laneD.n16.handle(top) -} -laneD { # Laned - n4: diamond label:"Label Escaping step 4" - n8: rectangle label:"Label Escaping step 8" - n12: diamond label:"Label Escaping step 12" - n16: circle label:"End Label Escaping" - - n4.handle(bottom) -> laneA.n5.handle(top) - n4.handle(right) -> laneC.n3.handle(right) [label="Retry/Rejected"] - n8.handle(bottom) -> laneA.n9.handle(top) [label="Processed"] - n12.handle(bottom) -> laneA.n13.handle(top) - n12.handle(right) -> laneC.n11.handle(right) [label="Retry/Rejected"] -} \ No newline at end of file diff --git a/edge-cases/markdown-in-label/README.md b/edge-cases/markdown-in-label/README.md deleted file mode 100644 index 54a75ca6e26720e1c941a664caa70e8e6b29183f..0000000000000000000000000000000000000000 --- a/edge-cases/markdown-in-label/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Markdown In Label - -This workflow models a label that contains markdown formatting. - -**Domain:** edge-cases -**Complexity:** 1/5 -**Tags:** [markdown, in, label] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/edge-cases/markdown-in-label/metadata.json b/edge-cases/markdown-in-label/metadata.json deleted file mode 100644 index 6a7193218b9fde2a014a89165c7c70a95b4991d7..0000000000000000000000000000000000000000 --- a/edge-cases/markdown-in-label/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "markdown-in-label", - "domain": "edge-cases", - "complexity": 1, - "num_nodes": 5, - "num_lanes": 1, - "tags": [ - "markdown", - "in", - "label" - ], - "description": "This workflow models a label that contains markdown formatting." -} \ No newline at end of file diff --git a/edge-cases/markdown-in-label/workflow.fz b/edge-cases/markdown-in-label/workflow.fz deleted file mode 100644 index 0752173b2a75f28add35cacedd2cb22cbdcf83b6..0000000000000000000000000000000000000000 --- a/edge-cases/markdown-in-label/workflow.fz +++ /dev/null @@ -1,13 +0,0 @@ -laneA { # Lanea - n1: circle label:"Start Markdown In Label" - n2: rectangle label:"**Bold** _italic_ [link](https://example.com)" - n3: diamond label:"Markdown In Label step 3" - n4: rectangle label:"Markdown In Label step 4" - n5: circle label:"End Markdown In Label" - - n1.handle(right) -> n2.handle(left) - n2.handle(right) -> n3.handle(left) [label="Next"] - n3.handle(right) -> n4.handle(left) - n3.handle(bottom) -> n2.handle(bottom) [label="Retry/Rejected"] - n4.handle(right) -> n5.handle(left) -} \ No newline at end of file diff --git a/edge-cases/max-lanes/README.md b/edge-cases/max-lanes/README.md deleted file mode 100644 index 04841fe9b03772bb52b2643a3876e4396191f010..0000000000000000000000000000000000000000 --- a/edge-cases/max-lanes/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Max Lanes - -This workflow models 10 lanes with simple cross-lane arrows. - -**Domain:** edge-cases -**Complexity:** 3/5 -**Tags:** [max, lanes] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/edge-cases/max-lanes/metadata.json b/edge-cases/max-lanes/metadata.json deleted file mode 100644 index d28ec8d914460319454edf73712841da4a5088ad..0000000000000000000000000000000000000000 --- a/edge-cases/max-lanes/metadata.json +++ /dev/null @@ -1,12 +0,0 @@ -{ - "workflow_id": "max-lanes", - "domain": "edge-cases", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 10, - "tags": [ - "max", - "lanes" - ], - "description": "This workflow models 10 lanes with simple cross-lane arrows." -} \ No newline at end of file diff --git a/edge-cases/max-lanes/workflow.fz b/edge-cases/max-lanes/workflow.fz deleted file mode 100644 index 5b81f35abdd82068c837f7cb77c421a111f913c3..0000000000000000000000000000000000000000 --- a/edge-cases/max-lanes/workflow.fz +++ /dev/null @@ -1,50 +0,0 @@ -laneA { # Lanea - n1: circle label:"Start Max Lanes" - - n1.handle(bottom) -> laneB.n2.handle(top) [label="Success"] -} -laneB { # Laneb - n2: rectangle label:"Max Lanes step 2" - - n2.handle(bottom) -> laneC.n3.handle(top) -} -laneC { # Lanec - n3: diamond label:"Max Lanes step 3" - - n3.handle(bottom) -> laneD.n4.handle(top) - n3.handle(right) -> laneB.n2.handle(right) [label="Retry/Rejected"] -} -laneD { # Laned - n4: rectangle label:"Max Lanes step 4" - - n4.handle(bottom) -> laneE.n5.handle(top) [label="Valid"] -} -laneE { # Lanee - n5: rectangle label:"Max Lanes step 5" - - n5.handle(bottom) -> laneF.n6.handle(top) -} -laneF { # Lanef - n6: rectangle label:"Max Lanes step 6" - - n6.handle(bottom) -> laneG.n7.handle(top) -} -laneG { # Laneg - n7: rectangle label:"Max Lanes step 7" - - n7.handle(bottom) -> laneH.n8.handle(top) [label="Next"] -} -laneH { # Laneh - n8: rectangle label:"Max Lanes step 8" - - n8.handle(bottom) -> laneI.n9.handle(top) -} -laneI { # Lanei - n9: rectangle label:"Max Lanes step 9" - - n9.handle(bottom) -> laneJ.n10.handle(top) -} -laneJ { # Lanej - n10: circle label:"End Max Lanes" - -} \ No newline at end of file diff --git a/edge-cases/max-nodes/README.md b/edge-cases/max-nodes/README.md deleted file mode 100644 index 5dd1dfaad3a39767d7888c0ed61db7d2f96fb5be..0000000000000000000000000000000000000000 --- a/edge-cases/max-nodes/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Max Nodes - -This workflow models 50 nodes in a single lane as a parser stress test. - -**Domain:** edge-cases -**Complexity:** 2/5 -**Tags:** [max, nodes] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/edge-cases/max-nodes/metadata.json b/edge-cases/max-nodes/metadata.json deleted file mode 100644 index 8c56903bddac6b923acda5065cd164d2454a1bdb..0000000000000000000000000000000000000000 --- a/edge-cases/max-nodes/metadata.json +++ /dev/null @@ -1,12 +0,0 @@ -{ - "workflow_id": "max-nodes", - "domain": "edge-cases", - "complexity": 2, - "num_nodes": 50, - "num_lanes": 2, - "tags": [ - "max", - "nodes" - ], - "description": "This workflow models 50 nodes in a single lane as a parser stress test." -} \ No newline at end of file diff --git a/edge-cases/max-nodes/workflow.fz b/edge-cases/max-nodes/workflow.fz deleted file mode 100644 index 5643c894f0ea91a1d65a09f7b0751dfdd9ce6091..0000000000000000000000000000000000000000 --- a/edge-cases/max-nodes/workflow.fz +++ /dev/null @@ -1,111 +0,0 @@ -laneA { # Lanea - n1: circle label:"Start Max Nodes" - n3: rectangle label:"Max Nodes step 3" - n5: rectangle label:"Max Nodes step 5" - n7: diamond label:"Max Nodes step 7" - n9: rectangle label:"Max Nodes step 9" - n11: rectangle label:"Max Nodes step 11" - n13: rectangle label:"Max Nodes step 13" - n15: diamond label:"Max Nodes step 15" - n17: rectangle label:"Max Nodes step 17" - n19: rectangle label:"Max Nodes step 19" - n21: rectangle label:"Max Nodes step 21" - n23: diamond label:"Max Nodes step 23" - n25: rectangle label:"Max Nodes step 25" - n27: rectangle label:"Max Nodes step 27" - n29: rectangle label:"Max Nodes step 29" - n31: diamond label:"Max Nodes step 31" - n33: rectangle label:"Max Nodes step 33" - n35: rectangle label:"Max Nodes step 35" - n37: rectangle label:"Max Nodes step 37" - n39: diamond label:"Max Nodes step 39" - n41: rectangle label:"Max Nodes step 41" - n43: rectangle label:"Max Nodes step 43" - n45: rectangle label:"Max Nodes step 45" - n47: diamond label:"Max Nodes step 47" - n49: rectangle label:"Max Nodes step 49" - - n1.handle(bottom) -> laneB.n2.handle(top) [label="Success"] - n3.handle(bottom) -> laneB.n4.handle(top) - n5.handle(bottom) -> laneB.n6.handle(top) - n7.handle(bottom) -> laneB.n8.handle(top) [label="Next"] - n7.handle(right) -> laneB.n6.handle(right) [label="Retry/Rejected"] - n9.handle(bottom) -> laneB.n10.handle(top) - n11.handle(bottom) -> laneB.n12.handle(top) - n13.handle(bottom) -> laneB.n14.handle(top) [label="Processed"] - n15.handle(bottom) -> laneB.n16.handle(top) - n15.handle(right) -> laneB.n14.handle(right) [label="Retry/Rejected"] - n17.handle(bottom) -> laneB.n18.handle(top) - n19.handle(bottom) -> laneB.n20.handle(top) [label="Valid"] - n21.handle(bottom) -> laneB.n22.handle(top) - n23.handle(bottom) -> laneB.n24.handle(top) - n23.handle(right) -> laneB.n22.handle(right) [label="Retry/Rejected"] - n25.handle(bottom) -> laneB.n26.handle(top) [label="Done"] - n27.handle(bottom) -> laneB.n28.handle(top) - n29.handle(bottom) -> laneB.n30.handle(top) - n31.handle(bottom) -> laneB.n32.handle(top) [label="Success"] - n31.handle(right) -> laneB.n30.handle(right) [label="Retry/Rejected"] - n33.handle(bottom) -> laneB.n34.handle(top) - n35.handle(bottom) -> laneB.n36.handle(top) - n37.handle(bottom) -> laneB.n38.handle(top) [label="Next"] - n39.handle(bottom) -> laneB.n40.handle(top) - n39.handle(right) -> laneB.n38.handle(right) [label="Retry/Rejected"] - n41.handle(bottom) -> laneB.n42.handle(top) - n43.handle(bottom) -> laneB.n44.handle(top) [label="Processed"] - n45.handle(bottom) -> laneB.n46.handle(top) - n47.handle(bottom) -> laneB.n48.handle(top) - n47.handle(right) -> laneB.n46.handle(right) [label="Retry/Rejected"] - n49.handle(bottom) -> laneB.n50.handle(top) [label="Valid"] -} -laneB { # Laneb - n2: rectangle label:"Max Nodes step 2" - n4: rectangle label:"Max Nodes step 4" - n6: rectangle label:"Max Nodes step 6" - n8: rectangle label:"Max Nodes step 8" - n10: rectangle label:"Max Nodes step 10" - n12: rectangle label:"Max Nodes step 12" - n14: rectangle label:"Max Nodes step 14" - n16: rectangle label:"Max Nodes step 16" - n18: rectangle label:"Max Nodes step 18" - n20: rectangle label:"Max Nodes step 20" - n22: rectangle label:"Max Nodes step 22" - n24: rectangle label:"Max Nodes step 24" - n26: rectangle label:"Max Nodes step 26" - n28: rectangle label:"Max Nodes step 28" - n30: rectangle label:"Max Nodes step 30" - n32: rectangle label:"Max Nodes step 32" - n34: rectangle label:"Max Nodes step 34" - n36: rectangle label:"Max Nodes step 36" - n38: rectangle label:"Max Nodes step 38" - n40: rectangle label:"Max Nodes step 40" - n42: rectangle label:"Max Nodes step 42" - n44: rectangle label:"Max Nodes step 44" - n46: rectangle label:"Max Nodes step 46" - n48: rectangle label:"Max Nodes step 48" - n50: circle label:"End Max Nodes" - - n2.handle(bottom) -> laneA.n3.handle(top) - n4.handle(bottom) -> laneA.n5.handle(top) [label="Valid"] - n6.handle(bottom) -> laneA.n7.handle(top) - n8.handle(bottom) -> laneA.n9.handle(top) - n10.handle(bottom) -> laneA.n11.handle(top) [label="Done"] - n12.handle(bottom) -> laneA.n13.handle(top) - n14.handle(bottom) -> laneA.n15.handle(top) - n16.handle(bottom) -> laneA.n17.handle(top) [label="Success"] - n18.handle(bottom) -> laneA.n19.handle(top) - n20.handle(bottom) -> laneA.n21.handle(top) - n22.handle(bottom) -> laneA.n23.handle(top) [label="Next"] - n24.handle(bottom) -> laneA.n25.handle(top) - n26.handle(bottom) -> laneA.n27.handle(top) - n28.handle(bottom) -> laneA.n29.handle(top) [label="Processed"] - n30.handle(bottom) -> laneA.n31.handle(top) - n32.handle(bottom) -> laneA.n33.handle(top) - n34.handle(bottom) -> laneA.n35.handle(top) [label="Valid"] - n36.handle(bottom) -> laneA.n37.handle(top) - n38.handle(bottom) -> laneA.n39.handle(top) - n40.handle(bottom) -> laneA.n41.handle(top) [label="Done"] - n42.handle(bottom) -> laneA.n43.handle(top) - n44.handle(bottom) -> laneA.n45.handle(top) - n46.handle(bottom) -> laneA.n47.handle(top) [label="Success"] - n48.handle(bottom) -> laneA.n49.handle(top) -} \ No newline at end of file diff --git a/edge-cases/minimal-workflow/README.md b/edge-cases/minimal-workflow/README.md deleted file mode 100644 index d0765a3d6a79d06671bf5e30e136029edab09978..0000000000000000000000000000000000000000 --- a/edge-cases/minimal-workflow/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Minimal Workflow - -This workflow models a workflow with a single node only. - -**Domain:** edge-cases -**Complexity:** 2/5 -**Tags:** [minimal, workflow] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/edge-cases/minimal-workflow/metadata.json b/edge-cases/minimal-workflow/metadata.json deleted file mode 100644 index 33924a3497c7b6cba3e138d065976f1b60da0598..0000000000000000000000000000000000000000 --- a/edge-cases/minimal-workflow/metadata.json +++ /dev/null @@ -1,12 +0,0 @@ -{ - "workflow_id": "minimal-workflow", - "domain": "edge-cases", - "complexity": 2, - "num_nodes": 1, - "num_lanes": 2, - "tags": [ - "minimal", - "workflow" - ], - "description": "This workflow models a workflow with a single node only." -} \ No newline at end of file diff --git a/edge-cases/minimal-workflow/workflow.fz b/edge-cases/minimal-workflow/workflow.fz deleted file mode 100644 index 27d7ee3eec87e4d59b80a759329ae4f9a49ebb20..0000000000000000000000000000000000000000 --- a/edge-cases/minimal-workflow/workflow.fz +++ /dev/null @@ -1,7 +0,0 @@ -laneA { # Lanea - n1: circle label:"Start Minimal Workflow" - -} -laneB { # Laneb - -} \ No newline at end of file diff --git a/edge-cases/missing-labels/README.md b/edge-cases/missing-labels/README.md deleted file mode 100644 index 4c6bb54b32367c588ece1caff0219c3be5c80c5b..0000000000000000000000000000000000000000 --- a/edge-cases/missing-labels/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Missing Labels - -This workflow models nodes without label parameters. - -**Domain:** edge-cases -**Complexity:** 4/5 -**Tags:** [missing, labels, decision] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/edge-cases/missing-labels/metadata.json b/edge-cases/missing-labels/metadata.json deleted file mode 100644 index 7ee95a2f028d02ba716659ceefeb7ebb0598e7b7..0000000000000000000000000000000000000000 --- a/edge-cases/missing-labels/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "missing-labels", - "domain": "edge-cases", - "complexity": 4, - "num_nodes": 13, - "num_lanes": 4, - "tags": [ - "missing", - "labels", - "decision" - ], - "description": "This workflow models nodes without label parameters." -} \ No newline at end of file diff --git a/edge-cases/missing-labels/workflow.fz b/edge-cases/missing-labels/workflow.fz deleted file mode 100644 index 4ff3161af2c7536ec71c8c07a477bf0583329bbd..0000000000000000000000000000000000000000 --- a/edge-cases/missing-labels/workflow.fz +++ /dev/null @@ -1,38 +0,0 @@ -laneA { # Lanea - n1: circle label:"Start Missing Labels" - n2: diamond - n5: rectangle label:"Missing Labels step 5" - n9: rectangle label:"Missing Labels step 9" - n13: circle label:"End Missing Labels" - - n1.handle(right) -> n2.handle(left) - n2.handle(bottom) -> laneC.n3.handle(top) [label="Yes/Approved"] - n2.handle(bottom) -> laneD.n4.handle(top) [label="No/Rejected"] - n5.handle(bottom) -> laneB.n6.handle(top) - n9.handle(bottom) -> laneB.n10.handle(top) -} -laneB { # Laneb - n6: rectangle label:"Missing Labels step 6" - n10: rectangle label:"Missing Labels step 10" - - n6.handle(bottom) -> laneC.n7.handle(top) - n10.handle(bottom) -> laneC.n11.handle(top) -} -laneC { # Lanec - n3: rectangle - n7: rectangle label:"Missing Labels step 7" - n11: rectangle label:"Missing Labels step 11" - - n3.handle(bottom) -> laneA.n5.handle(top) - n7.handle(bottom) -> laneD.n8.handle(top) - n11.handle(bottom) -> laneD.n12.handle(top) -} -laneD { # Laned - n4: rectangle label:"Missing Labels step 4" - n8: rectangle label:"Missing Labels step 8" - n12: rectangle label:"Missing Labels step 12" - - n4.handle(bottom) -> laneA.n5.handle(top) - n8.handle(bottom) -> laneA.n9.handle(top) - n12.handle(bottom) -> laneA.n13.handle(top) -} \ No newline at end of file diff --git a/edge-cases/orphan-node/README.md b/edge-cases/orphan-node/README.md deleted file mode 100644 index ae91975380347ffe9ead94a8bb2cda1ee466a2b0..0000000000000000000000000000000000000000 --- a/edge-cases/orphan-node/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Orphan Node - -This workflow models a node with no connections. - -**Domain:** edge-cases -**Complexity:** 1/5 -**Tags:** [orphan, node] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/edge-cases/orphan-node/metadata.json b/edge-cases/orphan-node/metadata.json deleted file mode 100644 index 2d8e59c3ebbaffa844c8987da1515dd34a24273b..0000000000000000000000000000000000000000 --- a/edge-cases/orphan-node/metadata.json +++ /dev/null @@ -1,12 +0,0 @@ -{ - "workflow_id": "orphan-node", - "domain": "edge-cases", - "complexity": 1, - "num_nodes": 5, - "num_lanes": 1, - "tags": [ - "orphan", - "node" - ], - "description": "This workflow models a node with no connections." -} \ No newline at end of file diff --git a/edge-cases/orphan-node/workflow.fz b/edge-cases/orphan-node/workflow.fz deleted file mode 100644 index a23da3ee63e2877c08b7ffea0cd7b7579fa71d86..0000000000000000000000000000000000000000 --- a/edge-cases/orphan-node/workflow.fz +++ /dev/null @@ -1,13 +0,0 @@ -laneA { # Lanea - n1: circle label:"Start Orphan Node" - n2: rectangle label:"Orphan Node step 2" - n3: diamond label:"Orphan Node step 3" - n4: rectangle label:"Orphan Node step 4" - n5: circle label:"End Orphan Node" - - n1.handle(right) -> n2.handle(left) - n2.handle(right) -> n3.handle(left) [label="Next"] - n3.handle(right) -> n4.handle(left) - n3.handle(bottom) -> n2.handle(bottom) [label="Retry/Rejected"] - n4.handle(right) -> n5.handle(left) -} \ No newline at end of file diff --git a/edge-cases/sql-injection-label/README.md b/edge-cases/sql-injection-label/README.md deleted file mode 100644 index 9165e5d0f41729d13d4e7e8732f8ccac7d97576c..0000000000000000000000000000000000000000 --- a/edge-cases/sql-injection-label/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Sql Injection Label - -This workflow models a label that looks like an SQL injection attempt. - -**Domain:** edge-cases -**Complexity:** 2/5 -**Tags:** [sql, injection, label] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/edge-cases/sql-injection-label/metadata.json b/edge-cases/sql-injection-label/metadata.json deleted file mode 100644 index ec20d48179e0b27dcb955d6c8a81b3f9c0762803..0000000000000000000000000000000000000000 --- a/edge-cases/sql-injection-label/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "sql-injection-label", - "domain": "edge-cases", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "sql", - "injection", - "label" - ], - "description": "This workflow models a label that looks like an SQL injection attempt." -} \ No newline at end of file diff --git a/edge-cases/sql-injection-label/workflow.fz b/edge-cases/sql-injection-label/workflow.fz deleted file mode 100644 index 1c8deae05fb5e7b1ede067fd4aaa1aa6b70021dd..0000000000000000000000000000000000000000 --- a/edge-cases/sql-injection-label/workflow.fz +++ /dev/null @@ -1,19 +0,0 @@ -laneA { # Lanea - n1: circle label:"Start Sql Injection Label" - n3: rectangle label:"Sql Injection Label step 3" - n5: rectangle label:"Sql Injection Label step 5" - n7: circle label:"End Sql Injection Label" - - n1.handle(bottom) -> laneB.n2.handle(top) - n3.handle(bottom) -> laneB.n4.handle(top) [label="Processed"] - n5.handle(bottom) -> laneB.n6.handle(top) -} -laneB { # Laneb - n2: rectangle label:"SELECT * FROM users WHERE name='admin' OR 1=1; --" - n4: rectangle label:"Sql Injection Label step 4" - n6: rectangle label:"Sql Injection Label step 6" - - n2.handle(bottom) -> laneA.n3.handle(top) - n4.handle(bottom) -> laneA.n5.handle(top) - n6.handle(bottom) -> laneA.n7.handle(top) [label="Success"] -} \ No newline at end of file diff --git a/edge-cases/unicode-labels/README.md b/edge-cases/unicode-labels/README.md deleted file mode 100644 index e871f8fd68d1a524b3c8c4ee8b998eb439b3f4b4..0000000000000000000000000000000000000000 --- a/edge-cases/unicode-labels/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Unicode Labels - -This workflow models emoji and international characters in labels. - -**Domain:** edge-cases -**Complexity:** 1/5 -**Tags:** [unicode, labels] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/edge-cases/unicode-labels/metadata.json b/edge-cases/unicode-labels/metadata.json deleted file mode 100644 index 71ade5441062d6c66230c9ef0c19c49aa86262e7..0000000000000000000000000000000000000000 --- a/edge-cases/unicode-labels/metadata.json +++ /dev/null @@ -1,12 +0,0 @@ -{ - "workflow_id": "unicode-labels", - "domain": "edge-cases", - "complexity": 1, - "num_nodes": 5, - "num_lanes": 1, - "tags": [ - "unicode", - "labels" - ], - "description": "This workflow models emoji and international characters in labels." -} \ No newline at end of file diff --git a/edge-cases/unicode-labels/workflow.fz b/edge-cases/unicode-labels/workflow.fz deleted file mode 100644 index d05375c58b8a021cca754e3f1f5dbe08bd4317be..0000000000000000000000000000000000000000 --- a/edge-cases/unicode-labels/workflow.fz +++ /dev/null @@ -1,12 +0,0 @@ -laneA { # Lanea - n1: circle label:"Start Unicode Labels" - n2: rectangle label:"Unicode label 🚀" - n3: rectangle label:"多言語ラベル" - n4: rectangle label:"Unicode Labels step 4" - n5: circle label:"End Unicode Labels" - - n1.handle(right) -> n2.handle(left) - n2.handle(right) -> n3.handle(left) [label="Next"] - n3.handle(right) -> n4.handle(left) - n4.handle(right) -> n5.handle(left) -} \ No newline at end of file diff --git a/edge-cases/very-long-label/README.md b/edge-cases/very-long-label/README.md deleted file mode 100644 index bb89a00d27d2d8acadc0fbca32e5d9652233226b..0000000000000000000000000000000000000000 --- a/edge-cases/very-long-label/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Very Long Label - -This workflow models labels with very long text. - -**Domain:** edge-cases -**Complexity:** 1/5 -**Tags:** [very, long, label, decision, loop] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/edge-cases/very-long-label/metadata.json b/edge-cases/very-long-label/metadata.json deleted file mode 100644 index d92b951cdc77f84ee4fc313a2d12a7cc3e4616f8..0000000000000000000000000000000000000000 --- a/edge-cases/very-long-label/metadata.json +++ /dev/null @@ -1,15 +0,0 @@ -{ - "workflow_id": "very-long-label", - "domain": "edge-cases", - "complexity": 1, - "num_nodes": 5, - "num_lanes": 1, - "tags": [ - "very", - "long", - "label", - "decision", - "loop" - ], - "description": "This workflow models labels with very long text." -} \ No newline at end of file diff --git a/edge-cases/very-long-label/workflow.fz b/edge-cases/very-long-label/workflow.fz deleted file mode 100644 index c784fa0effebff0be1523ae690fd1b032580f852..0000000000000000000000000000000000000000 --- a/edge-cases/very-long-label/workflow.fz +++ /dev/null @@ -1,14 +0,0 @@ -laneA { # Lanea - n1: circle label:"Start Very Long Label" - n2: diamond label:"Very long label for demonstration for demonstration for demonstration for demonstration for demonstration for demonstration for demonstration for demonstration " - n3: rectangle label:"Very Long Label step 3" - n4: rectangle label:"Very Long Label step 4" - n5: circle label:"End Very Long Label" - - n1.handle(right) -> n2.handle(left) - n2.handle(right) -> n3.handle(left) [label="Yes/Approved"] - n2.handle(bottom) -> n4.handle(top) [label="No/Rejected"] - n3.handle(right) -> n5.handle(left) - n4.handle(right) -> n5.handle(left) -} -loop [retry until success] n2 n3 n4 \ No newline at end of file diff --git a/edge-cases/xml-in-label/README.md b/edge-cases/xml-in-label/README.md deleted file mode 100644 index 5caf13852371e207d3e071c863c8821af8891065..0000000000000000000000000000000000000000 --- a/edge-cases/xml-in-label/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Xml In Label - -This workflow models a label that contains XML text. - -**Domain:** edge-cases -**Complexity:** 5/5 -**Tags:** [xml, in, label] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/edge-cases/xml-in-label/metadata.json b/edge-cases/xml-in-label/metadata.json deleted file mode 100644 index a85ad07ad44c958fb703dea7c6fb6569f7d43cd7..0000000000000000000000000000000000000000 --- a/edge-cases/xml-in-label/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "xml-in-label", - "domain": "edge-cases", - "complexity": 5, - "num_nodes": 16, - "num_lanes": 4, - "tags": [ - "xml", - "in", - "label" - ], - "description": "This workflow models a label that contains XML text." -} \ No newline at end of file diff --git a/edge-cases/xml-in-label/workflow.fz b/edge-cases/xml-in-label/workflow.fz deleted file mode 100644 index ed74b623f673f8c1d7516e6151e1ad262dca9e4c..0000000000000000000000000000000000000000 --- a/edge-cases/xml-in-label/workflow.fz +++ /dev/null @@ -1,44 +0,0 @@ -laneA { # Lanea - n1: circle label:"Start Xml In Label" - n5: rectangle label:"Xml In Label step 5" - n9: rectangle label:"Xml In Label step 9" - n13: rectangle label:"Xml In Label step 13" - - n1.handle(bottom) -> laneB.n2.handle(top) [label="Success"] - n5.handle(bottom) -> laneB.n6.handle(top) - n9.handle(bottom) -> laneB.n10.handle(top) - n13.handle(bottom) -> laneB.n14.handle(top) [label="Processed"] -} -laneB { # Laneb - n2: rectangle label:"UserExample" - n6: rectangle label:"Xml In Label step 6" - n10: rectangle label:"Xml In Label step 10" - n14: rectangle label:"Xml In Label step 14" - - n2.handle(bottom) -> laneC.n3.handle(top) - n6.handle(bottom) -> laneC.n7.handle(top) - n10.handle(bottom) -> laneC.n11.handle(top) [label="Done"] - n14.handle(bottom) -> laneC.n15.handle(top) -} -laneC { # Lanec - n3: rectangle label:"Xml In Label step 3" - n7: rectangle label:"Xml In Label step 7" - n11: rectangle label:"Xml In Label step 11" - n15: rectangle label:"Xml In Label step 15" - - n3.handle(bottom) -> laneD.n4.handle(top) - n7.handle(bottom) -> laneD.n8.handle(top) [label="Next"] - n11.handle(bottom) -> laneD.n12.handle(top) - n15.handle(bottom) -> laneD.n16.handle(top) -} -laneD { # Laned - n4: rectangle label:"Xml In Label step 4" - n8: diamond label:"Xml In Label step 8" - n12: rectangle label:"Xml In Label step 12" - n16: circle label:"End Xml In Label" - - n4.handle(bottom) -> laneA.n5.handle(top) [label="Valid"] - n8.handle(bottom) -> laneA.n9.handle(top) - n8.handle(right) -> laneC.n7.handle(right) [label="Retry/Rejected"] - n12.handle(bottom) -> laneA.n13.handle(top) -} \ No newline at end of file diff --git a/edge-cases/xss-label/README.md b/edge-cases/xss-label/README.md deleted file mode 100644 index fc5cb46d7c58868389b1efa15bab93b3d2b8b293..0000000000000000000000000000000000000000 --- a/edge-cases/xss-label/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Xss Label - -This workflow models a label that looks like an XSS script. - -**Domain:** edge-cases -**Complexity:** 3/5 -**Tags:** [xss, label] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/edge-cases/xss-label/metadata.json b/edge-cases/xss-label/metadata.json deleted file mode 100644 index 712224c8751241882363c629fd2b54fa515a74d6..0000000000000000000000000000000000000000 --- a/edge-cases/xss-label/metadata.json +++ /dev/null @@ -1,12 +0,0 @@ -{ - "workflow_id": "xss-label", - "domain": "edge-cases", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "xss", - "label" - ], - "description": "This workflow models a label that looks like an XSS script." -} \ No newline at end of file diff --git a/edge-cases/xss-label/workflow.fz b/edge-cases/xss-label/workflow.fz deleted file mode 100644 index 4728565c950ad057f72ec687047c44acec6e8a78..0000000000000000000000000000000000000000 --- a/edge-cases/xss-label/workflow.fz +++ /dev/null @@ -1,29 +0,0 @@ -laneA { # Lanea - n1: circle label:"Start Xss Label" - n4: rectangle label:"Xss Label step 4" - n7: diamond label:"Xss Label step 7" - n10: circle label:"End Xss Label" - - n1.handle(bottom) -> laneB.n2.handle(top) [label="Success"] - n4.handle(bottom) -> laneB.n5.handle(top) [label="Valid"] - n7.handle(bottom) -> laneB.n8.handle(top) [label="Next"] - n7.handle(right) -> laneC.n6.handle(right) [label="Retry/Rejected"] -} -laneB { # Laneb - n2: rectangle label:"" - n5: rectangle label:"Xss Label step 5" - n8: rectangle label:"Xss Label step 8" - - n2.handle(bottom) -> laneC.n3.handle(top) - n5.handle(bottom) -> laneC.n6.handle(top) - n8.handle(bottom) -> laneC.n9.handle(top) -} -laneC { # Lanec - n3: rectangle label:"Xss Label step 3" - n6: rectangle label:"Xss Label step 6" - n9: rectangle label:"Xss Label step 9" - - n3.handle(bottom) -> laneA.n4.handle(top) - n6.handle(bottom) -> laneA.n7.handle(top) - n9.handle(bottom) -> laneA.n10.handle(top) -} \ No newline at end of file diff --git a/finance/bank-reconciliation/README.md b/finance/bank-reconciliation/README.md deleted file mode 100644 index 15be8270015b94ba1dd56a8bc8919918736d82ff..0000000000000000000000000000000000000000 --- a/finance/bank-reconciliation/README.md +++ /dev/null @@ -1,24 +0,0 @@ -# Bank Reconciliation - -Bank reconciliation workflow with automated transaction matching, variance reporting, discrepancy research, and journal entry creation for timing differences and bank errors. - -**Domain:** finance -**Complexity:** 4/5 -**Tags:** [bank-reconciliation, gl-matching, variance-analysis, journal-entries, auto-matching, discrepancy-resolution] - -## Lanes -- **Accountant** - Imports statements, reviews reports, approves reconciliation -- **Reconciliation Engine** - Parses transactions, auto-matches, generates reports -- **Manual Review** - Researches discrepancies, creates adjusting entries - -## Process Flow -1. Accountant imports bank statement -2. Engine parses bank transactions and matches with GL entries -3. If auto-match rate > 95%, generate variance report -4. If < 95%, flag unmatched items and apply matching rules -5. Display unmatched items for manual review -6. Research discrepancies and classify type -7. Create journal entry for timing differences -8. Flag unknown discrepancies for investigation -9. Mark bank errors for follow-up -10. Accountant reviews and approves reconciliation diff --git a/finance/budget-approval/README.md b/finance/budget-approval/README.md deleted file mode 100644 index e6157938f12a796b62467496a5da2b95e74d6880..0000000000000000000000000000000000000000 --- a/finance/budget-approval/README.md +++ /dev/null @@ -1,24 +0,0 @@ -# Budget Approval - -Corporate budget approval workflow with tiered approval routing based on amount thresholds (CFO < $100K, CEO $100K-$1M, Board > $1M), prior year comparison, and fund allocation. - -**Domain:** finance -**Complexity:** 4/5 -**Tags:** [budget-approval, financial-planning, tiered-approval, cfo-approval, ceo-approval, board-approval, fund-allocation] - -## Lanes -- **Department Manager** - Submits budget request, justifies line items -- **Finance Department** - Reviews request, compares to prior year -- **Executive Approval** - Tiered approval based on budget amount - -## Process Flow -1. Department manager submits budget request -2. Justify line items and submit to Finance -3. Finance reviews and compares to prior year -4. If within guidelines, recommend approval -5. If over budget, recommend reduction -6. Route to appropriate approver based on amount -7. < $100K: CFO approval -8. $100K-$1M: CEO approval -9. > $1M: Board approval -10. If approved, allocate funds to department diff --git a/finance/cash-flow-forecast/README.md b/finance/cash-flow-forecast/README.md deleted file mode 100644 index 2aaa48fec011bd6f58381202eb15b2f7c24f61c3..0000000000000000000000000000000000000000 --- a/finance/cash-flow-forecast/README.md +++ /dev/null @@ -1,21 +0,0 @@ -# Cash Flow Forecast - -Cash flow forecasting workflow with AR/AP projections, working capital analysis, liquidity gap identification, and short-term financing recommendations. - -**Domain:** finance -**Complexity:** 3/5 -**Tags:** [cash-flow-forecast, liquidity-planning, working-capital, ar-collections, ap-disbursements, treasury] - -## Lanes -- **Treasury Analyst** - Gathers data, builds forecast, presents to management -- **Finance System** - Aggregates AR/AP data, calculates projections - -## Process Flow -1. Gather accounts receivable aging data -2. Project expected collections by week -3. Gather accounts payable obligations -4. Project disbursements by due date -5. Calculate net cash position by period -6. Identify liquidity gaps or surpluses -7. Recommend short-term borrowing or investment -8. Present forecast to treasury management diff --git a/finance/cash-flow-forecast/metadata.json b/finance/cash-flow-forecast/metadata.json deleted file mode 100644 index 7067ef0c06104bdccc2a4d9ac14d94e4d902230a..0000000000000000000000000000000000000000 --- a/finance/cash-flow-forecast/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "cash-flow-forecast", - "domain": "finance", - "complexity": 3, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "cash-flow-forecast", - "liquidity-planning", - "working-capital", - "ar-collections", - "ap-disbursements", - "treasury" - ], - "description": "Cash flow forecasting workflow with AR/AP projections, working capital analysis, liquidity gap identification, and short-term financing recommendations." -} \ No newline at end of file diff --git a/finance/cost-center/README.md b/finance/cost-center/README.md deleted file mode 100644 index 9043d34ade6a6e1b572562028fe77588776e0be7..0000000000000000000000000000000000000000 --- a/finance/cost-center/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Cost Center - -This workflow models managing cost center budgets. - -**Domain:** finance -**Complexity:** 2/5 -**Tags:** [cost, center, finance, decision] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/finance/cost-center/metadata.json b/finance/cost-center/metadata.json deleted file mode 100644 index fae0f4d356fdd9a1ce1721e7ec6dd1c7cc6f819b..0000000000000000000000000000000000000000 --- a/finance/cost-center/metadata.json +++ /dev/null @@ -1,14 +0,0 @@ -{ - "workflow_id": "cost-center", - "domain": "finance", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "cost", - "center", - "finance", - "decision" - ], - "description": "This workflow models managing cost center budgets." -} \ No newline at end of file diff --git a/finance/credit-control/README.md b/finance/credit-control/README.md deleted file mode 100644 index 1b0e3f7f51d348283a14f9ea08514d7a71faa45f..0000000000000000000000000000000000000000 --- a/finance/credit-control/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# Credit Control - -Customer credit control workflow with credit limit assessment, credit scoring, order hold management, collections escalation, and payment plan negotiation. - -**Domain:** finance -**Complexity:** 3/5 -**Tags:** [credit-control, credit-limit, customer-credit, credit-scoring, collections, accounts-receivable] - -## Lanes -- **Sales** - Requests credit limit changes, manages customer relationships -- **Credit Team** - Assesses credit risk, sets limits, manages holds -- **Collections** - Escalates overdue accounts, negotiates payment plans - -## Process Flow -1. New customer or credit limit change request -2. Pull credit report and assess credit score -3. Review payment history and financial statements -4. Set or adjust credit limit based on risk -5. Monitor accounts for overdue invoices -6. Place orders on hold if over limit -7. Escalate to collections if payment overdue -8. Negotiate payment plan if needed diff --git a/finance/credit-control/metadata.json b/finance/credit-control/metadata.json deleted file mode 100644 index 0c71fd82fee64c4b2ba8c304b88f71329ea6c119..0000000000000000000000000000000000000000 --- a/finance/credit-control/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "credit-control", - "domain": "finance", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "credit-control", - "credit-limit", - "customer-credit", - "credit-scoring", - "collections", - "accounts-receivable" - ], - "description": "Customer credit control workflow with credit limit assessment, credit scoring, order hold management, collections escalation, and payment plan negotiation." -} \ No newline at end of file diff --git a/finance/expense-allocation/README.md b/finance/expense-allocation/README.md deleted file mode 100644 index d1552256ab72fbbfc31edbf4a0d1f51477ca0a3c..0000000000000000000000000000000000000000 --- a/finance/expense-allocation/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Expense Allocation - -This workflow models allocating costs to departments. - -**Domain:** finance -**Complexity:** 3/5 -**Tags:** [expense, allocation, finance] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/finance/expense-allocation/metadata.json b/finance/expense-allocation/metadata.json deleted file mode 100644 index f78399c1e02f09eb16eef7e5522d7c28fe80bcf5..0000000000000000000000000000000000000000 --- a/finance/expense-allocation/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "expense-allocation", - "domain": "finance", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "expense", - "allocation", - "finance" - ], - "description": "This workflow models allocating costs to departments." -} \ No newline at end of file diff --git a/finance/expense-claim/README.md b/finance/expense-claim/README.md deleted file mode 100644 index 0185be23a28d315d0e8a28571d799a7b255c1ac3..0000000000000000000000000000000000000000 --- a/finance/expense-claim/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# Expense Claim - -Employee expense reimbursement workflow with receipt submission, manager approval, finance review, policy compliance check, and direct deposit payment. - -**Domain:** finance -**Complexity:** 3/5 -**Tags:** [expense-reimbursement, employee-expenses, receipt-upload, manager-approval, finance-review, direct-deposit] - -## Lanes -- **Employee** - Submits expense claim with receipts -- **Manager** - Reviews and approves employee expenses -- **Finance App** - Validates policy compliance, processes payment - -## Process Flow -1. Employee submits expense claim with receipts -2. Manager receives and reviews expense request -3. Finance reviews expense details for policy compliance -4. Employee makes any required corrections -5. Manager updates records and approves -6. Finance processes approved expense -7. Payment issued via direct deposit -8. Employee receives reimbursement confirmation diff --git a/finance/financial-reporting/README.md b/finance/financial-reporting/README.md deleted file mode 100644 index 74d937f5475d9cf3e5667a4d5608a77865ea1c91..0000000000000000000000000000000000000000 --- a/finance/financial-reporting/README.md +++ /dev/null @@ -1,24 +0,0 @@ -# Financial Reporting - -Financial reporting workflow with GAAP-compliant statement preparation, management review, audit committee approval, and SEC filing for public companies. - -**Domain:** finance -**Complexity:** 4/5 -**Tags:** [financial-reporting, gaap-compliance, income-statement, balance-sheet, cash-flow-statement, sec-filing] - -## Lanes -- **Accounting Team** - Prepares statements, makes adjustments -- **Controller** - Reviews for GAAP compliance, approves -- **Executive/Board** - Final review, SEC filing authorization - -## Process Flow -1. Close accounting period -2. Generate trial balance -3. Prepare income statement -4. Prepare balance sheet -5. Prepare cash flow statement -6. Review for GAAP compliance -7. Make adjusting entries as needed -8. Controller approval -9. Audit committee review -10. File with SEC (10-K/10-Q for public companies) diff --git a/finance/financial-reporting/metadata.json b/finance/financial-reporting/metadata.json deleted file mode 100644 index 897104bcb18c6563f3a135cec568f90ad39d2d83..0000000000000000000000000000000000000000 --- a/finance/financial-reporting/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "financial-reporting", - "domain": "finance", - "complexity": 4, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "financial-reporting", - "gaap-compliance", - "income-statement", - "balance-sheet", - "cash-flow-statement", - "sec-filing" - ], - "description": "Financial reporting workflow with GAAP-compliant statement preparation, management review, audit committee approval, and SEC filing for public companies." -} \ No newline at end of file diff --git a/finance/fixed-assets/README.md b/finance/fixed-assets/README.md deleted file mode 100644 index 44ae11024263ca83e0d07102fe52f4afbe2f6cea..0000000000000000000000000000000000000000 --- a/finance/fixed-assets/README.md +++ /dev/null @@ -1,21 +0,0 @@ -# Fixed Assets - -Fixed asset management workflow with asset capitalization, depreciation scheduling, physical inventory verification, and asset disposal/retirement processing. - -**Domain:** finance -**Complexity:** 3/5 -**Tags:** [fixed-assets, asset-tracking, depreciation, capitalization, asset-disposal, physical-inventory] - -## Lanes -- **Asset Manager** - Requests capitalization, manages inventory -- **Finance System** - Calculates depreciation, maintains asset register - -## Process Flow -1. Receive asset acquisition request -2. Determine if expense or capitalize (threshold check) -3. Create asset record with useful life -4. Calculate and schedule depreciation -5. Conduct periodic physical inventory -6. Reconcile physical count to register -7. Process asset transfers between locations -8. Handle asset disposal or retirement diff --git a/finance/fixed-assets/metadata.json b/finance/fixed-assets/metadata.json deleted file mode 100644 index d7bc3147323b38b64653892f7b1fb11e10662f3f..0000000000000000000000000000000000000000 --- a/finance/fixed-assets/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "fixed-assets", - "domain": "finance", - "complexity": 3, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "fixed-assets", - "asset-tracking", - "depreciation", - "capitalization", - "asset-disposal", - "physical-inventory" - ], - "description": "Fixed asset management workflow with asset capitalization, depreciation scheduling, physical inventory verification, and asset disposal/retirement processing." -} \ No newline at end of file diff --git a/finance/insurance-claim/README.md b/finance/insurance-claim/README.md deleted file mode 100644 index 236cfffd9130886983d30e177eb74a3ec60a5dfc..0000000000000000000000000000000000000000 --- a/finance/insurance-claim/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# Insurance Claim - -Insurance claim processing workflow with incident documentation, claim filing, adjuster assignment, damage assessment, and settlement negotiation. - -**Domain:** finance -**Complexity:** 3/5 -**Tags:** [insurance-claim, claim-filing, adjuster-review, settlement, property-damage, liability] - -## Lanes -- **Claimant** - Reports incident, provides documentation -- **Insurance Company** - Assigns adjuster, processes settlement - -## Process Flow -1. Report incident to insurance company -2. Document damage with photos and descriptions -3. File formal claim with policy number -4. Insurance assigns claims adjuster -5. Adjuster reviews documentation -6. Conduct damage assessment or inspection -7. Determine coverage and liability -8. Negotiate settlement amount -9. Issue payment or denial with explanation diff --git a/finance/insurance-claim/metadata.json b/finance/insurance-claim/metadata.json deleted file mode 100644 index 5b7c6591af1bd549d4727ef096be9657fafb0f69..0000000000000000000000000000000000000000 --- a/finance/insurance-claim/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "insurance-claim", - "domain": "finance", - "complexity": 3, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "insurance-claim", - "claim-filing", - "adjuster-review", - "settlement", - "property-damage", - "liability" - ], - "description": "Insurance claim processing workflow with incident documentation, claim filing, adjuster assignment, damage assessment, and settlement negotiation." -} \ No newline at end of file diff --git a/finance/internal-controls/README.md b/finance/internal-controls/README.md deleted file mode 100644 index 3488ac5665e49c0bdbb5cd6517fa1b76caa445ce..0000000000000000000000000000000000000000 --- a/finance/internal-controls/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Internal Controls - -Internal controls testing workflow with risk assessment, control design evaluation, operating effectiveness testing, deficiency identification, and remediation tracking. - -**Domain:** finance -**Complexity:** 4/5 -**Tags:** [internal-controls, sox-compliance, control-testing, segregation-of-duties, risk-assessment, remediation] - -## Lanes -- **Internal Audit** - Performs risk assessment, tests controls -- **Control Owners** - Provides evidence, remediates deficiencies -- **Management** - Reviews findings, approves remediation plans - -## Process Flow -1. Perform annual risk assessment -2. Identify key controls for testing -3. Evaluate control design effectiveness -4. Test operating effectiveness with samples -5. Document test results and exceptions -6. Classify deficiencies (significant/material) -7. Develop remediation plans with owners -8. Track remediation to completion -9. Report control status to audit committee diff --git a/finance/internal-controls/metadata.json b/finance/internal-controls/metadata.json deleted file mode 100644 index 59b47161caf07e89105416fffb6ae54b00cc1334..0000000000000000000000000000000000000000 --- a/finance/internal-controls/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "internal-controls", - "domain": "finance", - "complexity": 4, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "internal-controls", - "sox-compliance", - "control-testing", - "segregation-of-duties", - "risk-assessment", - "remediation" - ], - "description": "Internal controls testing workflow with risk assessment, control design evaluation, operating effectiveness testing, deficiency identification, and remediation tracking." -} \ No newline at end of file diff --git a/finance/invoice-processing/README.md b/finance/invoice-processing/README.md deleted file mode 100644 index 4e27d01452ed50eb4fd5e52c66db010a8006dcbf..0000000000000000000000000000000000000000 --- a/finance/invoice-processing/README.md +++ /dev/null @@ -1,25 +0,0 @@ -# Invoice Processing - -Accounts payable invoice automation with OCR data extraction, three-way PO matching, tiered approval workflow, and automated payment processing with GL updates. - -**Domain:** finance -**Complexity:** 4/5 -**Tags:** [accounts-payable, invoice-automation, ocr, po-matching, approval-workflow, payment-processing, three-way-match] - -## Lanes -- **Vendor** - Submits invoices, receives payment notifications -- **AP Automation** - OCR extraction, PO matching, auto-approval -- **Approval Workflow** - Manager and director approval routing -- **Payment Processing** - Batch scheduling, bank transfers, GL updates - -## Process Flow -1. Vendor submits invoice via email -2. OCR extracts invoice data automatically -3. System attempts to match invoice to purchase order -4. If PO match found and within threshold, auto-approve -5. If no match or over threshold, route to manual review -6. Manager approval required for flagged invoices -7. Director approval for amounts over manager limit -8. Schedule approved invoices in payment batch -9. Execute bank transfer and update general ledger -10. Send remittance advice to vendor diff --git a/finance/invoice-processing/metadata.json b/finance/invoice-processing/metadata.json deleted file mode 100644 index eb3d76c5e4a88d91187c1d87543f796c00a7187e..0000000000000000000000000000000000000000 --- a/finance/invoice-processing/metadata.json +++ /dev/null @@ -1,17 +0,0 @@ -{ - "workflow_id": "invoice-processing", - "domain": "finance", - "complexity": 4, - "num_nodes": 19, - "num_lanes": 4, - "tags": [ - "accounts-payable", - "invoice-automation", - "ocr", - "po-matching", - "approval-workflow", - "payment-processing", - "three-way-match" - ], - "description": "Accounts payable invoice automation with OCR data extraction, three-way PO matching, tiered approval workflow, and automated payment processing with GL updates." -} \ No newline at end of file diff --git a/finance/monthly-close/README.md b/finance/monthly-close/README.md deleted file mode 100644 index e3b9d78f6c999a505327143b20d902da615dbb31..0000000000000000000000000000000000000000 --- a/finance/monthly-close/README.md +++ /dev/null @@ -1,25 +0,0 @@ -# Monthly Close - -Corporate month-end financial close process including transaction posting, bank reconciliation, accruals, depreciation, trial balance validation, and financial statement generation. - -**Domain:** finance -**Complexity:** 4/5 -**Tags:** [monthly-close, financial-reporting, accounting, reconciliation, trial-balance, period-close] - -## Lanes -- **Controller** - Initiates close, reviews checklist, approves statements -- **Accounting Team** - Posts transactions, reconciles accounts, records accruals -- **Validation** - Runs trial balance, verifies debits/credits balance -- **Financial Reporting** - Generates income statement, balance sheet, cash flow - -## Process Flow -1. Controller initiates month-end close process -2. Accounting posts pending transactions and reconciles bank accounts -3. System checks if reconciliation is balanced (retry if not) -4. Record accruals and post depreciation entries -5. Review intercompany transactions -6. Run trial balance and verify debits equal credits -7. Lock accounting period once validated -8. Generate financial statements (P&L, balance sheet, cash flow) -9. Prepare variance analysis and package for leadership -10. Controller approves final financial statements diff --git a/finance/payment-run/README.md b/finance/payment-run/README.md deleted file mode 100644 index 1669b35958b66f29f2131d0d332803cb01c1fb72..0000000000000000000000000000000000000000 --- a/finance/payment-run/README.md +++ /dev/null @@ -1,24 +0,0 @@ -# Payment Run - -Accounts payable payment run workflow with batch creation, tiered approval (single/dual based on amount), ACH file generation, check printing, and vendor record updates. - -**Domain:** finance -**Complexity:** 4/5 -**Tags:** [payment-run, accounts-payable, ach-payments, check-run, dual-approval, bank-transfer, vendor-payments] - -## Lanes -- **AP Clerk** - Selects invoices, creates batch, confirms payments -- **Payment Approval** - Reviews batch, routes for single/dual approval -- **Banking System** - Generates ACH files, prints checks, submits to bank - -## Process Flow -1. AP clerk selects invoices for payment -2. Create payment batch -3. Review batch and check total amount -4. < $50K: Single approver required -5. >= $50K: Dual approval required -6. If rejected, return for correction -7. Generate ACH file or check run based on payment method -8. Submit to bank or print checks -9. Confirm transmission -10. Update vendor records with payment status diff --git a/finance/payment-run/metadata.json b/finance/payment-run/metadata.json deleted file mode 100644 index 82343243315a2902a1f70850b9f1c41f7489524d..0000000000000000000000000000000000000000 --- a/finance/payment-run/metadata.json +++ /dev/null @@ -1,17 +0,0 @@ -{ - "workflow_id": "payment-run", - "domain": "finance", - "complexity": 4, - "num_nodes": 18, - "num_lanes": 3, - "tags": [ - "payment-run", - "accounts-payable", - "ach-payments", - "check-run", - "dual-approval", - "bank-transfer", - "vendor-payments" - ], - "description": "Accounts payable payment run workflow with batch creation, tiered approval (single/dual based on amount), ACH file generation, check printing, and vendor record updates." -} \ No newline at end of file diff --git a/finance/payroll-processing/README.md b/finance/payroll-processing/README.md deleted file mode 100644 index 2cd47459f540649484406fd7f0ca69334d5e2181..0000000000000000000000000000000000000000 --- a/finance/payroll-processing/README.md +++ /dev/null @@ -1,27 +0,0 @@ -# Payroll Processing - -Complete payroll processing workflow with timesheet collection, gross pay calculation, overtime, tax withholding (federal, state, FICA), benefits deductions, compliance validation, and ACH direct deposit. - -**Domain:** finance -**Complexity:** 5/5 -**Tags:** [payroll-processing, salary-calculation, tax-withholding, fica, ach-direct-deposit, benefits-deductions, compliance] - -## Lanes -- **HR System** - Collects timesheets, imports attendance, finalizes payroll -- **Payroll Engine** - Applies pay rates, calculates overtime, processes deductions -- **Compliance** - Withholds taxes (federal, state, FICA), validates compliance -- **Banking** - Creates ACH batch, submits to bank, confirms transfers - -## Process Flow -1. Collect timesheet data and import attendance records -2. Apply pay rates and calculate overtime -3. Add bonuses and commissions -4. Process deductions and validate -5. Calculate net pay -6. Withhold federal and state taxes -7. Calculate FICA contributions -8. Process benefits deductions -9. Run compliance check -10. Generate pay stubs -11. Create ACH batch file and submit to bank -12. Confirm transfers and update payroll records diff --git a/finance/procurement-card/README.md b/finance/procurement-card/README.md deleted file mode 100644 index 4a084d0750d879d3d97ea1ee911ab808a535ed23..0000000000000000000000000000000000000000 --- a/finance/procurement-card/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Procurement Card - -This workflow models managing company credit cards. - -**Domain:** finance -**Complexity:** 3/5 -**Tags:** [procurement, card, finance] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/finance/procurement-card/metadata.json b/finance/procurement-card/metadata.json deleted file mode 100644 index db47acf37b69f004b1e6851813bd038c43b39cf1..0000000000000000000000000000000000000000 --- a/finance/procurement-card/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "procurement-card", - "domain": "finance", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "procurement", - "card", - "finance" - ], - "description": "This workflow models managing company credit cards." -} \ No newline at end of file diff --git a/finance/purchase-order/README.md b/finance/purchase-order/README.md deleted file mode 100644 index b45a43a09777133674fdad67c076a926fc2e697e..0000000000000000000000000000000000000000 --- a/finance/purchase-order/README.md +++ /dev/null @@ -1,25 +0,0 @@ -# Purchase Order - -Procurement purchase order workflow with requisition creation, budget validation, vendor sourcing, competitive bidding, and tiered approval routing based on amount thresholds. - -**Domain:** finance -**Complexity:** 4/5 -**Tags:** [purchase-order, procurement, requisition, vendor-sourcing, competitive-bidding, tiered-approval, budget-validation] - -## Lanes -- **Requester** - Creates requisition, adds line items, receives PO number -- **Procurement** - Reviews requisition, sources vendors, requests quotes -- **Approval Chain** - Routes based on amount, manager/director/VP approval - -## Process Flow -1. Requester creates purchase requisition with line items -2. Attach specifications and submit -3. Procurement reviews and checks budget availability -4. Source vendors and determine if competitive bids required -5. Request quotes from multiple vendors if required -6. Select best vendor based on price/quality -7. Route for approval based on amount threshold -8. < $5K: Manager approval -9. $5K-$50K: Director approval -10. > $50K: VP approval -11. Generate PO number upon approval diff --git a/finance/tax-filing/README.md b/finance/tax-filing/README.md deleted file mode 100644 index dc4e58546dba9fa0dd0a8c471a23b018e66fd3bc..0000000000000000000000000000000000000000 --- a/finance/tax-filing/README.md +++ /dev/null @@ -1,25 +0,0 @@ -# Tax Filing - -Corporate tax filing workflow with taxable income calculation, deductions, tax credits, variance review, and electronic or paper filing to IRS with receipt confirmation. - -**Domain:** finance -**Complexity:** 4/5 -**Tags:** [tax-filing, corporate-tax, tax-calculation, irs-efile, tax-credits, deductions, compliance] - -## Lanes -- **Tax Team** - Gathers data, prepares schedules, submits filing -- **Tax Calculation** - Computes income, applies deductions and credits -- **Tax Review** - Reviews calculations, prepares documents, files return - -## Process Flow -1. Tax team gathers financial data -2. Prepare tax schedules -3. Calculate taxable income -4. Apply deductions and compute tax liability -5. Check for applicable tax credits -6. Calculate final amount owed/refund -7. Review calculations for discrepancies -8. Prepare filing documents -9. Choose filing type (electronic or paper) -10. E-file with IRS or mail paper return -11. Confirm receipt of filing diff --git a/finance/tax-filing/metadata.json b/finance/tax-filing/metadata.json deleted file mode 100644 index a6a49d4adae15f5f38a30ed63db57609ab4bf94f..0000000000000000000000000000000000000000 --- a/finance/tax-filing/metadata.json +++ /dev/null @@ -1,17 +0,0 @@ -{ - "workflow_id": "tax-filing", - "domain": "finance", - "complexity": 4, - "num_nodes": 19, - "num_lanes": 3, - "tags": [ - "tax-filing", - "corporate-tax", - "tax-calculation", - "irs-efile", - "tax-credits", - "deductions", - "compliance" - ], - "description": "Corporate tax filing workflow with taxable income calculation, deductions, tax credits, variance review, and electronic or paper filing to IRS with receipt confirmation." -} \ No newline at end of file diff --git a/finance/treasury-management/README.md b/finance/treasury-management/README.md deleted file mode 100644 index 77def748a032e6b3efa50a58b0fb92355a333de3..0000000000000000000000000000000000000000 --- a/finance/treasury-management/README.md +++ /dev/null @@ -1,21 +0,0 @@ -# Treasury Management - -Corporate treasury management workflow with cash pooling, FX exposure hedging, short-term investment decisions, and bank relationship management. - -**Domain:** finance -**Complexity:** 3/5 -**Tags:** [treasury-management, cash-pooling, fx-hedging, investment-portfolio, bank-relationships, liquidity] - -## Lanes -- **Treasury Manager** - Monitors positions, executes transactions -- **Banking System** - Aggregates balances, executes transfers - -## Process Flow -1. Monitor daily cash positions across accounts -2. Execute cash pooling to concentrate funds -3. Identify FX exposures from international operations -4. Execute hedging transactions (forwards, options) -5. Evaluate short-term investment opportunities -6. Place excess cash in money market or T-bills -7. Manage bank relationships and credit facilities -8. Report treasury positions to CFO diff --git a/finance/treasury-management/metadata.json b/finance/treasury-management/metadata.json deleted file mode 100644 index 4ff910a9198ba9ed1a34a80f60e08313751b9950..0000000000000000000000000000000000000000 --- a/finance/treasury-management/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "treasury-management", - "domain": "finance", - "complexity": 3, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "treasury-management", - "cash-pooling", - "fx-hedging", - "investment-portfolio", - "bank-relationships", - "liquidity" - ], - "description": "Corporate treasury management workflow with cash pooling, FX exposure hedging, short-term investment decisions, and bank relationship management." -} \ No newline at end of file diff --git a/finance/vendor-onboarding/README.md b/finance/vendor-onboarding/README.md deleted file mode 100644 index 75ef765e0e437d58ca4c1f5c954fa3be7db0db85..0000000000000000000000000000000000000000 --- a/finance/vendor-onboarding/README.md +++ /dev/null @@ -1,24 +0,0 @@ -# Vendor Onboarding - -Vendor onboarding workflow with application review, W-9/W-8BEN verification, insurance certificate validation, background checks, and compliance approval before vendor activation. - -**Domain:** finance -**Complexity:** 4/5 -**Tags:** [vendor-onboarding, supplier-management, w9-verification, insurance-compliance, background-check, payment-terms, procurement] - -## Lanes -- **Vendor** - Submits registration, uploads documents, receives approval -- **Procurement** - Reviews application, assigns category, sets payment terms -- **Compliance** - Verifies tax forms, checks insurance, runs background check - -## Process Flow -1. Vendor submits registration form -2. Procurement reviews application and validates business need -3. Request additional information if needed -4. Assign vendor category and set payment terms -5. Vendor uploads required documents (W-9, insurance) -6. Compliance verifies W-9 or W-8BEN tax forms -7. Check insurance certificates for coverage -8. Run background check on vendor -9. Approve or reject based on compliance results -10. Notify vendor of approval status diff --git a/finance/yearly-audit/README.md b/finance/yearly-audit/README.md deleted file mode 100644 index 5518d38df358d8dc35f5d26fa7ce7a9f7ed8eb45..0000000000000000000000000000000000000000 --- a/finance/yearly-audit/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Yearly Audit - -Annual financial audit workflow with external auditor engagement, document preparation, fieldwork coordination, findings remediation, and management letter response. - -**Domain:** finance -**Complexity:** 4/5 -**Tags:** [annual-audit, external-auditors, sox-compliance, financial-statements, audit-findings, management-letter] - -## Lanes -- **Finance Team** - Prepares documents, coordinates with auditors -- **External Auditors** - Conducts fieldwork, issues findings -- **Management** - Reviews findings, provides responses - -## Process Flow -1. Engage external audit firm -2. Prepare PBC (Prepared by Client) documents -3. Auditors conduct planning and risk assessment -4. Fieldwork: test controls and substantive procedures -5. Review preliminary findings with management -6. Remediate identified issues -7. Receive draft audit report -8. Prepare management letter response -9. Issue final audited financial statements diff --git a/finance/yearly-audit/metadata.json b/finance/yearly-audit/metadata.json deleted file mode 100644 index fa451c79651c39ca9fd4b25b33be1980fdfbcdd0..0000000000000000000000000000000000000000 --- a/finance/yearly-audit/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "yearly-audit", - "domain": "finance", - "complexity": 4, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "annual-audit", - "external-auditors", - "sox-compliance", - "financial-statements", - "audit-findings", - "management-letter" - ], - "description": "Annual financial audit workflow with external auditor engagement, document preparation, fieldwork coordination, findings remediation, and management letter response." -} \ No newline at end of file diff --git a/handoff/architecture/bulkhead-isolation-architecture/README.md b/handoff/architecture/bulkhead-isolation-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..7d429317c78ab63c84558453c1138e2b153c2a33 --- /dev/null +++ b/handoff/architecture/bulkhead-isolation-architecture/README.md @@ -0,0 +1,19 @@ +# Bulkhead Isolation Architecture + +A bulkhead isolation architecture diagram with separate thread pools for critical, standard, and batch workloads, each with independent connection pools, exhaustion detection, and backpressure strategies to prevent one workload from starving others. This template models the bulkhead pattern inspired by ship hull compartments, where resource isolation ensures that a failure or overload in one component cannot cascade to others. Critical for systems requiring guaranteed availability for high-priority operations. + +**Template ID:** `bulkhead-isolation-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** handoff +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 18 +**Lanes:** 4 +**Tags:** [bulkhead-pattern, resource-isolation, thread-pool, backpressure, fault-isolation, resilience, priority-routing, architecture-diagram] +**Source path:** `` +**Repo path:** `handoff/architecture/bulkhead-isolation-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/handoff/architecture/bulkhead-isolation-architecture/metadata.json b/handoff/architecture/bulkhead-isolation-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..71714f1a6344cedeb07744a85a8e124b54694222 --- /dev/null +++ b/handoff/architecture/bulkhead-isolation-architecture/metadata.json @@ -0,0 +1,28 @@ +{ + "template_id": "bulkhead-isolation-architecture", + "workflow_id": "bulkhead-isolation-architecture", + "title": "Bulkhead Isolation Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "handoff", + "secondary_use_cases": [], + "use_cases": [ + "handoff" + ], + "complexity": 4, + "num_nodes": 18, + "num_lanes": 4, + "tags": [ + "bulkhead-pattern", + "resource-isolation", + "thread-pool", + "backpressure", + "fault-isolation", + "resilience", + "priority-routing", + "architecture-diagram" + ], + "description": "A bulkhead isolation architecture diagram with separate thread pools for critical, standard, and batch workloads, each with independent connection pools, exhaustion detection, and backpressure strategies to prevent one workload from starving others. This template models the bulkhead pattern inspired by ship hull compartments, where resource isolation ensures that a failure or overload in one component cannot cascade to others. Critical for systems requiring guaranteed availability for high-priority operations.", + "source_path": "", + "repo_path": "handoff/architecture/bulkhead-isolation-architecture" +} diff --git a/handoff/architecture/bulkhead-isolation-architecture/workflow.fz b/handoff/architecture/bulkhead-isolation-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..7aa216093c96fb8441ece73cb149c1517adcc38c --- /dev/null +++ b/handoff/architecture/bulkhead-isolation-architecture/workflow.fz @@ -0,0 +1,43 @@ +Gateway { # API Gateway +n1: circle label:"Incoming Request" +n2: rectangle label:"Classify Request Type" +n3: diamond label:"Request Category?" +n4: rectangle label:"Route to Critical Pool" +n5: rectangle label:"Route to Standard Pool" +n6: rectangle label:"Route to Batch Pool" +n1.handle(right) -> n2.handle(left) +n2.handle(right) -> n3.handle(left) +n3.handle(right) -> n4.handle(left) [label="Critical"] +n3.handle(bottom) -> n5.handle(top) [label="Standard"] +n3.handle(left) -> n6.handle(right) [label="Batch"] +n4.handle(bottom) -> CriticalPool.n7.handle(top) [label="Priority"] +n5.handle(bottom) -> StandardPool.n11.handle(top) [label="Normal"] +n6.handle(bottom) -> BatchPool.n15.handle(top) [label="Low Priority"] +} +CriticalPool { # Critical Thread Pool (10 threads) +n7: rectangle label:"Dedicated Connection Pool" +n8: diamond label:"Pool Exhausted?" +n9: rectangle label:"Process Payment Request" +n10: rectangle label:"Queue with Timeout" +n7.handle(right) -> n8.handle(left) [label="Check"] +n8.handle(right) -> n9.handle(left) [label="Available"] +n8.handle(bottom) -> n10.handle(top) [label="Exhausted"] +} +StandardPool { # Standard Thread Pool (20 threads) +n11: rectangle label:"Shared Connection Pool" +n12: diamond label:"Pool Exhausted?" +n13: rectangle label:"Process API Request" +n14: rectangle label:"Return 503 Service Unavailable" +n11.handle(right) -> n12.handle(left) [label="Check"] +n12.handle(right) -> n13.handle(left) [label="Available"] +n12.handle(bottom) -> n14.handle(top) [label="Exhausted"] +} +BatchPool { # Batch Thread Pool (5 threads) +n15: rectangle label:"Rate-Limited Pool" +n16: diamond label:"Pool Exhausted?" +n17: rectangle label:"Process Batch Job" +n18: rectangle label:"Backpressure: Delay Retry" +n15.handle(right) -> n16.handle(left) [label="Check"] +n16.handle(right) -> n17.handle(left) [label="Available"] +n16.handle(bottom) -> n18.handle(top) [label="Exhausted"] +} diff --git a/handoff/architecture/cell-based-architecture/README.md b/handoff/architecture/cell-based-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..8afa71e011a29332f08e4838633d38e40bc2a5bf --- /dev/null +++ b/handoff/architecture/cell-based-architecture/README.md @@ -0,0 +1,19 @@ +# Cell-Based Architecture + +A cell-based architecture diagram with geographic routing to independent, self-contained cells (US-East, EU-West), each with its own gateway, compute, database, cache, and message queue, plus shared services for cross-cell replication and global configuration. This template models the cell architecture pattern used by hyperscale systems to achieve blast radius isolation, where failures in one cell cannot affect users in another. Key for architects designing systems that require extreme availability and fault isolation. + +**Template ID:** `cell-based-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** handoff +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 20 +**Lanes:** 4 +**Tags:** [cell-based-architecture, blast-radius, geographic-routing, fault-isolation, independent-cells, cross-cell-replication, hyperscale, architecture-diagram] +**Source path:** `` +**Repo path:** `handoff/architecture/cell-based-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/handoff/architecture/cell-based-architecture/metadata.json b/handoff/architecture/cell-based-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..cc6ee197de3b0c57dd4cb72d9f751e86b33abed2 --- /dev/null +++ b/handoff/architecture/cell-based-architecture/metadata.json @@ -0,0 +1,28 @@ +{ + "template_id": "cell-based-architecture", + "workflow_id": "cell-based-architecture", + "title": "Cell-Based Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "handoff", + "secondary_use_cases": [], + "use_cases": [ + "handoff" + ], + "complexity": 4, + "num_nodes": 20, + "num_lanes": 4, + "tags": [ + "cell-based-architecture", + "blast-radius", + "geographic-routing", + "fault-isolation", + "independent-cells", + "cross-cell-replication", + "hyperscale", + "architecture-diagram" + ], + "description": "A cell-based architecture diagram with geographic routing to independent, self-contained cells (US-East, EU-West), each with its own gateway, compute, database, cache, and message queue, plus shared services for cross-cell replication and global configuration. This template models the cell architecture pattern used by hyperscale systems to achieve blast radius isolation, where failures in one cell cannot affect users in another. Key for architects designing systems that require extreme availability and fault isolation.", + "source_path": "", + "repo_path": "handoff/architecture/cell-based-architecture" +} diff --git a/handoff/architecture/cell-based-architecture/workflow.fz b/handoff/architecture/cell-based-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..66a37944886738bf850073e7be5565569682b731 --- /dev/null +++ b/handoff/architecture/cell-based-architecture/workflow.fz @@ -0,0 +1,48 @@ +GlobalRouter { # Global Router +n1: circle label:"User Request" +n2: rectangle label:"Geographic Routing" +n3: diamond label:"User Cell Assignment?" +n4: rectangle label:"Route to Cell A" +n5: rectangle label:"Route to Cell B" +n1.handle(right) -> n2.handle(left) +n2.handle(right) -> n3.handle(left) +n3.handle(right) -> n4.handle(left) [label="US-East"] +n3.handle(bottom) -> n5.handle(top) [label="EU-West"] +n4.handle(bottom) -> CellA.n6.handle(top) [label="Forward"] +n5.handle(bottom) -> CellB.n12.handle(top) [label="Forward"] +} +CellA { # Cell A (US-East) +n6: rectangle label:"Cell Gateway" +n7: rectangle label:"Compute Layer" +n8: rectangle label:"Cell Database" +n9: rectangle label:"Cell Cache" +n10: rectangle label:"Cell Message Queue" +n11: circle label:"Cell Response" +n6.handle(right) -> n7.handle(left) [label="Process"] +n7.handle(right) -> n8.handle(left) [label="Read/Write"] +n7.handle(bottom) -> n9.handle(top) [label="Cache"] +n7.handle(bottom) -> n10.handle(top) [label="Async"] +n8.handle(right) -> n11.handle(left) +n8.handle(bottom) -> SharedServices.n18.handle(top) [label="Replicate"] +} +CellB { # Cell B (EU-West) +n12: rectangle label:"Cell Gateway" +n13: rectangle label:"Compute Layer" +n14: rectangle label:"Cell Database" +n15: rectangle label:"Cell Cache" +n16: rectangle label:"Cell Message Queue" +n17: circle label:"Cell Response" +n12.handle(right) -> n13.handle(left) [label="Process"] +n13.handle(right) -> n14.handle(left) [label="Read/Write"] +n13.handle(bottom) -> n15.handle(top) [label="Cache"] +n13.handle(bottom) -> n16.handle(top) [label="Async"] +n14.handle(right) -> n17.handle(left) +n14.handle(bottom) -> SharedServices.n18.handle(top) [label="Replicate"] +} +SharedServices { # Shared Services (Cross-Cell) +n18: rectangle label:"Cross-Cell Replication" +n19: rectangle label:"Global Config Service" +n20: rectangle label:"Monitoring and Alerting" +n18.handle(right) -> n19.handle(left) [label="Sync Config"] +n19.handle(right) -> n20.handle(left) [label="Health"] +} diff --git a/handoff/architecture/microservices-service-discovery-architecture/README.md b/handoff/architecture/microservices-service-discovery-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..d8ad165df19fb272bb3eec638c00396382fda490 --- /dev/null +++ b/handoff/architecture/microservices-service-discovery-architecture/README.md @@ -0,0 +1,19 @@ +# Microservices Service Discovery Architecture + +A service discovery architecture diagram with Consul or Eureka registry, client-side load balancing, health check heartbeats, and automatic instance registration and deregistration. This template visualizes how microservices dynamically locate each other without hardcoded endpoints, enabling elastic scaling and self-healing infrastructure. Key for platform teams building resilient service-to-service communication. + +**Template ID:** `microservices-service-discovery-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** handoff +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 16 +**Lanes:** 3 +**Tags:** [service-discovery, consul, eureka, health-check, client-side-load-balancing, service-registry, dynamic-routing, architecture-diagram] +**Source path:** `` +**Repo path:** `handoff/architecture/microservices-service-discovery-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/handoff/architecture/microservices-service-discovery-architecture/metadata.json b/handoff/architecture/microservices-service-discovery-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..aaad540757c17fdc5f7c60f2c93508a039022e2d --- /dev/null +++ b/handoff/architecture/microservices-service-discovery-architecture/metadata.json @@ -0,0 +1,28 @@ +{ + "template_id": "microservices-service-discovery-architecture", + "workflow_id": "microservices-service-discovery-architecture", + "title": "Microservices Service Discovery Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "handoff", + "secondary_use_cases": [], + "use_cases": [ + "handoff" + ], + "complexity": 3, + "num_nodes": 16, + "num_lanes": 3, + "tags": [ + "service-discovery", + "consul", + "eureka", + "health-check", + "client-side-load-balancing", + "service-registry", + "dynamic-routing", + "architecture-diagram" + ], + "description": "A service discovery architecture diagram with Consul or Eureka registry, client-side load balancing, health check heartbeats, and automatic instance registration and deregistration. This template visualizes how microservices dynamically locate each other without hardcoded endpoints, enabling elastic scaling and self-healing infrastructure. Key for platform teams building resilient service-to-service communication.", + "source_path": "", + "repo_path": "handoff/architecture/microservices-service-discovery-architecture" +} diff --git a/handoff/architecture/microservices-service-discovery-architecture/workflow.fz b/handoff/architecture/microservices-service-discovery-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..35dc02f76834a9552266dc0cf5553af10921a4e3 --- /dev/null +++ b/handoff/architecture/microservices-service-discovery-architecture/workflow.fz @@ -0,0 +1,59 @@ +Client { # Client Service +n1: circle label:"Service Call Needed" +n2: rectangle label:"Query Service Registry" +n8: rectangle label:"Client-Side Load Balance" +n9: rectangle label:"Send Request to Instance" +n14: rectangle label:"Receive Response" +n15: rectangle label:"Process Result" +n1.handle(right) -> n2.handle(left) +n2.handle(bottom) -> Registry.n3.handle(top) [label="Lookup"] +n8.handle(right) -> n9.handle(left) +n9.handle(bottom) -> Target.n10.handle(top) [label="HTTP/gRPC"] +n14.handle(right) -> n15.handle(left) +} +Registry { # Service Registry (Consul/Eureka) +n3: rectangle label:"Receive Lookup Request" +n4: rectangle label:"Check Health Status" +n5: diamond label:"Healthy Instances?" +n6: rectangle label:"Return Instance List" +n7: rectangle label:"Return Service Unavailable" +n18: rectangle label:"Receive Heartbeat" +n19: rectangle label:"Send Registration Ack" +n21: rectangle label:"Receive Ready Signal" +n22: rectangle label:"Send Health Ping" +n24: rectangle label:"Update Health Status" +n27: rectangle label:"Process Removal" +n3.handle(right) -> n4.handle(left) +n4.handle(right) -> n5.handle(left) +n5.handle(right) -> n6.handle(left) [label="Yes"] +n5.handle(bottom) -> n7.handle(top) [label="No"] +n6.handle(top) -> Client.n8.handle(bottom) [label="Endpoints"] +n7.handle(top) -> Client.n14.handle(bottom) [label="503"] +n18.handle(right) -> n19.handle(left) +n19.handle(bottom) -> Target.n20.handle(top) [label="Registered OK"] +n21.handle(right) -> n22.handle(left) +n22.handle(bottom) -> Target.n23.handle(top) [label="Ping"] +} +Target { # Target Service +n10: rectangle label:"Instance A (Primary)" +n11: rectangle label:"Instance B (Replica)" +n12: rectangle label:"Instance C (Replica)" +n13: rectangle label:"Send Response" +n16: rectangle label:"Register on Startup" +n17: rectangle label:"Send Heartbeat" +n20: rectangle label:"Receive Registration Ack" +n23: rectangle label:"Respond to Ping" +n25: rectangle label:"Service Running" +n26: rectangle label:"Deregister on Shutdown" +n10.handle(right) -> n11.handle(left) [label="Replicate"] +n11.handle(right) -> n12.handle(left) [label="Replicate"] +n12.handle(right) -> n13.handle(left) +n13.handle(top) -> Client.n14.handle(bottom) [label="Response"] +n16.handle(right) -> n17.handle(left) +n17.handle(top) -> Registry.n18.handle(bottom) [label="Heartbeat"] +n20.handle(top) -> Registry.n21.handle(bottom) [label="Ready for Ping"] +n23.handle(top) -> Registry.n24.handle(bottom) [label="Healthy"] +n23.handle(right) -> n25.handle(left) +n25.handle(right) -> n26.handle(left) [label="Shutdown"] +n26.handle(top) -> Registry.n27.handle(bottom) [label="Remove"] +} diff --git a/handoff/architecture/serverless-edge-computing-architecture/README.md b/handoff/architecture/serverless-edge-computing-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..409bf8be9dd02e1fcd71cf11b2ef0aea4b5b9286 --- /dev/null +++ b/handoff/architecture/serverless-edge-computing-architecture/README.md @@ -0,0 +1,19 @@ +# Serverless Edge Computing Architecture + +A serverless edge computing architecture diagram with CloudFront or Cloudflare edge locations, Lambda@Edge functions for A/B testing and geo-personalization, origin shield request collapsing, and cache-first response strategies. This template visualizes how computation moves to the network edge for ultra-low latency responses, with edge functions modifying requests and responses before they reach the origin. Essential for performance-critical applications serving global audiences. + +**Template ID:** `serverless-edge-computing-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** handoff +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 15 +**Lanes:** 3 +**Tags:** [edge-computing, lambda-at-edge, cloudfront, cloudflare, cdn, geo-routing, cache-strategy, architecture-diagram] +**Source path:** `` +**Repo path:** `handoff/architecture/serverless-edge-computing-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/handoff/architecture/serverless-edge-computing-architecture/metadata.json b/handoff/architecture/serverless-edge-computing-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..48191a0b713d3ba52d92a5ad7f0a4a170025e42d --- /dev/null +++ b/handoff/architecture/serverless-edge-computing-architecture/metadata.json @@ -0,0 +1,28 @@ +{ + "template_id": "serverless-edge-computing-architecture", + "workflow_id": "serverless-edge-computing-architecture", + "title": "Serverless Edge Computing Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "handoff", + "secondary_use_cases": [], + "use_cases": [ + "handoff" + ], + "complexity": 3, + "num_nodes": 15, + "num_lanes": 3, + "tags": [ + "edge-computing", + "lambda-at-edge", + "cloudfront", + "cloudflare", + "cdn", + "geo-routing", + "cache-strategy", + "architecture-diagram" + ], + "description": "A serverless edge computing architecture diagram with CloudFront or Cloudflare edge locations, Lambda@Edge functions for A/B testing and geo-personalization, origin shield request collapsing, and cache-first response strategies. This template visualizes how computation moves to the network edge for ultra-low latency responses, with edge functions modifying requests and responses before they reach the origin. Essential for performance-critical applications serving global audiences.", + "source_path": "", + "repo_path": "handoff/architecture/serverless-edge-computing-architecture" +} diff --git a/handoff/architecture/serverless-edge-computing-architecture/workflow.fz b/handoff/architecture/serverless-edge-computing-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..048197b964a1e755e227568f46f1d15f785f58c6 --- /dev/null +++ b/handoff/architecture/serverless-edge-computing-architecture/workflow.fz @@ -0,0 +1,51 @@ +User { # End User +n1: circle label:"Browser Request" +n2: rectangle label:"DNS Resolution (Route 53)" +n21: rectangle label:"Receive Optimized Response" +n22: circle label:"Page Rendered" +n1.handle(right) -> n2.handle(left) +n2.handle(bottom) -> Edge.n3.handle(top) [label="Nearest PoP"] +n21.handle(right) -> n22.handle(left) +} +Edge { # Edge Network (CloudFront/Cloudflare) +n3: rectangle label:"Edge Location PoP" +n4: diamond label:"Cache Hit?" +n5: rectangle label:"Return Cached Response" +n6: rectangle label:"Edge Function (Lambda@Edge)" +n7: rectangle label:"A/B Test Routing" +n8: rectangle label:"Geo-Based Personalization" +n19: rectangle label:"Cache and Forward Response" +n20: rectangle label:"Send to User" +n3.handle(right) -> n4.handle(left) +n4.handle(right) -> n5.handle(left) [label="HIT"] +n4.handle(bottom) -> n6.handle(top) [label="MISS"] +n5.handle(top) -> User.n21.handle(bottom) [label="Fast Response"] +n6.handle(right) -> n7.handle(left) [label="Modify Request"] +n7.handle(right) -> n8.handle(left) [label="Personalize"] +n8.handle(bottom) -> Origin.n9.handle(top) [label="Forward"] +n19.handle(right) -> n20.handle(left) +n20.handle(top) -> User.n21.handle(bottom) [label="Response"] +} +Origin { # Origin Services +n9: rectangle label:"Origin Shield" +n10: rectangle label:"Application Load Balancer" +n11: rectangle label:"Serverless API" +n12: rectangle label:"Static Asset Store (S3)" +n13: rectangle label:"Generate Response" +n14: rectangle label:"Prepare Origin Response" +n15: rectangle label:"Package Response" +n16: rectangle label:"Forward Origin Response" +n17: rectangle label:"Send Cached Response" +n18: rectangle label:"Deliver to Edge" +n9.handle(right) -> n10.handle(left) [label="Collapse Requests"] +n10.handle(right) -> n11.handle(left) [label="Dynamic"] +n10.handle(bottom) -> n12.handle(top) [label="Static"] +n11.handle(right) -> n13.handle(left) [label="Compute"] +n12.handle(right) -> n13.handle(left) [label="Assets"] +n13.handle(right) -> n14.handle(left) +n14.handle(right) -> n15.handle(left) +n15.handle(right) -> n16.handle(left) +n16.handle(right) -> n17.handle(left) +n17.handle(right) -> n18.handle(left) +n18.handle(top) -> Edge.n19.handle(bottom) [label="Cache + Return"] +} diff --git a/handoff/architecture/serverless-multi-cloud-architecture/README.md b/handoff/architecture/serverless-multi-cloud-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..7575612f7f6c8aa544aa6364af3f867112375c59 --- /dev/null +++ b/handoff/architecture/serverless-multi-cloud-architecture/README.md @@ -0,0 +1,19 @@ +# Serverless Multi-Cloud Architecture + +A multi-cloud serverless architecture diagram with DNS-based traffic routing between AWS and Azure regions, automatic failover on health check failures, and bi-directional data replication with conflict resolution across cloud providers. This template models the multi-cloud strategy for maximum availability and vendor independence, using serverless services from both AWS (Lambda, DynamoDB) and Azure (Functions, Cosmos DB). Critical for enterprises requiring cloud provider redundancy. + +**Template ID:** `serverless-multi-cloud-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** handoff +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 18 +**Lanes:** 4 +**Tags:** [multi-cloud, aws, azure, cloud-failover, dns-routing, data-replication, vendor-independence, architecture-diagram] +**Source path:** `` +**Repo path:** `handoff/architecture/serverless-multi-cloud-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/handoff/architecture/serverless-multi-cloud-architecture/metadata.json b/handoff/architecture/serverless-multi-cloud-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..e6a9074494178c4e17cff2b41cc9c2824af40b1c --- /dev/null +++ b/handoff/architecture/serverless-multi-cloud-architecture/metadata.json @@ -0,0 +1,28 @@ +{ + "template_id": "serverless-multi-cloud-architecture", + "workflow_id": "serverless-multi-cloud-architecture", + "title": "Serverless Multi-Cloud Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "handoff", + "secondary_use_cases": [], + "use_cases": [ + "handoff" + ], + "complexity": 4, + "num_nodes": 18, + "num_lanes": 4, + "tags": [ + "multi-cloud", + "aws", + "azure", + "cloud-failover", + "dns-routing", + "data-replication", + "vendor-independence", + "architecture-diagram" + ], + "description": "A multi-cloud serverless architecture diagram with DNS-based traffic routing between AWS and Azure regions, automatic failover on health check failures, and bi-directional data replication with conflict resolution across cloud providers. This template models the multi-cloud strategy for maximum availability and vendor independence, using serverless services from both AWS (Lambda, DynamoDB) and Azure (Functions, Cosmos DB). Critical for enterprises requiring cloud provider redundancy.", + "source_path": "", + "repo_path": "handoff/architecture/serverless-multi-cloud-architecture" +} diff --git a/handoff/architecture/serverless-multi-cloud-architecture/workflow.fz b/handoff/architecture/serverless-multi-cloud-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..211e2527eafe54caabc6926478508d906f44ded9 --- /dev/null +++ b/handoff/architecture/serverless-multi-cloud-architecture/workflow.fz @@ -0,0 +1,55 @@ +TrafficManager { # Global Traffic Manager +n1: circle label:"User Request" +n2: rectangle label:"DNS-Based Routing" +n3: diamond label:"Primary Cloud Healthy?" +n4: rectangle label:"Route to Primary (AWS)" +n5: rectangle label:"Failover to Secondary (Azure)" +n20: rectangle label:"Receive Cloud Response" +n21: circle label:"Return to User" +n1.handle(right) -> n2.handle(left) +n2.handle(right) -> n3.handle(left) +n3.handle(right) -> n4.handle(left) [label="Healthy"] +n3.handle(bottom) -> n5.handle(top) [label="Unhealthy"] +n4.handle(bottom) -> AWS.n6.handle(top) [label="Forward"] +n5.handle(bottom) -> Azure.n13.handle(top) [label="Forward"] +n20.handle(right) -> n21.handle(left) +} +AWS { # AWS Region +n6: rectangle label:"API Gateway" +n7: rectangle label:"Lambda Functions" +n8: rectangle label:"DynamoDB" +n9: rectangle label:"S3 Storage" +n10: rectangle label:"CloudWatch Monitoring" +n11: rectangle label:"Prepare Response" +n12: rectangle label:"Return to TrafficManager" +n6.handle(right) -> n7.handle(left) [label="Invoke"] +n7.handle(right) -> n8.handle(left) [label="Read/Write"] +n7.handle(bottom) -> n9.handle(top) [label="Store"] +n8.handle(right) -> n10.handle(left) [label="Monitor"] +n10.handle(right) -> n11.handle(left) +n11.handle(right) -> n12.handle(left) +n12.handle(top) -> TrafficManager.n20.handle(bottom) [label="AWS Response"] +} +Azure { # Azure Region +n13: rectangle label:"Azure API Management" +n14: rectangle label:"Azure Functions" +n15: rectangle label:"Cosmos DB" +n16: rectangle label:"Blob Storage" +n17: rectangle label:"Azure Monitor" +n18: rectangle label:"Prepare Response" +n19: rectangle label:"Return to TrafficManager" +n13.handle(right) -> n14.handle(left) [label="Invoke"] +n14.handle(right) -> n15.handle(left) [label="Read/Write"] +n14.handle(bottom) -> n16.handle(top) [label="Store"] +n15.handle(right) -> n17.handle(left) [label="Monitor"] +n17.handle(right) -> n18.handle(left) +n18.handle(right) -> n19.handle(left) +n19.handle(top) -> TrafficManager.n20.handle(bottom) [label="Azure Response"] +} +DataSync { # Cross-Cloud Sync +n22: rectangle label:"Event Bridge" +n23: rectangle label:"Bi-Directional Replication" +n24: rectangle label:"Conflict Resolution" +n22.handle(right) -> n23.handle(left) [label="CDC Events"] +n23.handle(right) -> n24.handle(left) [label="Last-Write-Wins"] +} diff --git a/handoff/business-operations/support-ticket-workflow/README.md b/handoff/business-operations/support-ticket-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..01dc037037e916b2f90b32e2bb83c3ed90a72a87 --- /dev/null +++ b/handoff/business-operations/support-ticket-workflow/README.md @@ -0,0 +1,19 @@ +# Support Ticket Workflow + +Customer support ticket workflow with auto-categorization, SLA tracking, agent assignment, escalation rules, and satisfaction survey. + +**Template ID:** `support-ticket-workflow` +**Kind:** workflow +**Source domain:** business-operations +**Primary use case:** handoff +**Secondary use cases:** support +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [support-ticket, helpdesk, zendesk, sla, ticket-routing, customer-service] +**Source path:** `business-operations/support-ticket` +**Repo path:** `handoff/business-operations/support-ticket-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/handoff/business-operations/support-ticket-workflow/metadata.json b/handoff/business-operations/support-ticket-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..32b84ba3b717ea6accec588984983cf97e69619c --- /dev/null +++ b/handoff/business-operations/support-ticket-workflow/metadata.json @@ -0,0 +1,29 @@ +{ + "template_id": "support-ticket-workflow", + "workflow_id": "support-ticket", + "title": "Support Ticket Workflow", + "kind": "workflow", + "source_domain": "business-operations", + "primary_use_case": "handoff", + "secondary_use_cases": [ + "support" + ], + "use_cases": [ + "handoff", + "support" + ], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "support-ticket", + "helpdesk", + "zendesk", + "sla", + "ticket-routing", + "customer-service" + ], + "description": "Customer support ticket workflow with auto-categorization, SLA tracking, agent assignment, escalation rules, and satisfaction survey.", + "source_path": "business-operations/support-ticket", + "repo_path": "handoff/business-operations/support-ticket-workflow" +} diff --git a/business-operations/support-ticket/workflow.fz b/handoff/business-operations/support-ticket-workflow/workflow.fz similarity index 100% rename from business-operations/support-ticket/workflow.fz rename to handoff/business-operations/support-ticket-workflow/workflow.fz diff --git a/handoff/devops/mcp-tool-router/README.md b/handoff/devops/mcp-tool-router/README.md new file mode 100644 index 0000000000000000000000000000000000000000..3874f8571cc7b1acff4ea44c7f3e3ec7719d6234 --- /dev/null +++ b/handoff/devops/mcp-tool-router/README.md @@ -0,0 +1,19 @@ +# MCP Tool Router Architecture + +A routing pattern that puts a semantic router in front of MCP tools so the LLM only sees the subset it needs. Uses vector embeddings and cosine similarity to match user intent to tools dynamically. Achieves up to 96% reduction in input tokens when dealing with large tool catalogs. + +**Template ID:** `mcp-tool-router` +**Kind:** architecture +**Source domain:** DevOps +**Primary use case:** handoff +**Secondary use cases:** mcp +**Complexity:** 3/5 +**Nodes:** 8 +**Lanes:** 4 +**Tags:** [mcp, tool-router, semantic-routing, embeddings, token-optimization, architecture-diagram, production-grade] +**Source path:** `` +**Repo path:** `handoff/devops/mcp-tool-router` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/handoff/devops/mcp-tool-router/metadata.json b/handoff/devops/mcp-tool-router/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..31a012d4b604b5e994efbd6504d3082a09b65f7b --- /dev/null +++ b/handoff/devops/mcp-tool-router/metadata.json @@ -0,0 +1,30 @@ +{ + "template_id": "mcp-tool-router", + "workflow_id": "mcp-tool-router", + "title": "MCP Tool Router Architecture", + "kind": "architecture", + "source_domain": "DevOps", + "primary_use_case": "handoff", + "secondary_use_cases": [ + "mcp" + ], + "use_cases": [ + "handoff", + "mcp" + ], + "complexity": 3, + "num_nodes": 8, + "num_lanes": 4, + "tags": [ + "mcp", + "tool-router", + "semantic-routing", + "embeddings", + "token-optimization", + "architecture-diagram", + "production-grade" + ], + "description": "A routing pattern that puts a semantic router in front of MCP tools so the LLM only sees the subset it needs. Uses vector embeddings and cosine similarity to match user intent to tools dynamically. Achieves up to 96% reduction in input tokens when dealing with large tool catalogs.", + "source_path": "", + "repo_path": "handoff/devops/mcp-tool-router" +} diff --git a/handoff/devops/mcp-tool-router/workflow.fz b/handoff/devops/mcp-tool-router/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..007cfc9b21a824724cf6242fadb61be9948073c8 --- /dev/null +++ b/handoff/devops/mcp-tool-router/workflow.fz @@ -0,0 +1,41 @@ +Host { + n1: circle label="User sends prompt" + n2: rectangle label="Agent extracts intent" + n3: rectangle label="Send intent to router" + n4: rectangle label="Receive routed result" + n5: rectangle label="Agent responds to user" + n1.handle(right) -> n2.handle(left) + n2.handle(right) -> n3.handle(left) + n3.handle(bottom) -> Router.n6.handle(top) [label="Intent + tool request"] + n4.handle(right) -> n5.handle(left) +} + +Router { + n6: rectangle label="Receive intent" + n7: rectangle label="Semantic match via embeddings" + n8: diamond label="Which MCP server?" + n9: rectangle label="Forward to Server A" + n10: rectangle label="Forward to Server B" + n11: rectangle label="Normalize and return result" + n6.handle(right) -> n7.handle(left) + n7.handle(right) -> n8.handle(left) + n8.handle(bottom) -> n9.handle(top) [label="Route A"] + n8.handle(right) -> n10.handle(left) [label="Route B"] + n9.handle(bottom) -> ServerA.n12.handle(top) [label="Call Server A"] + n10.handle(bottom) -> ServerB.n14.handle(top) [label="Call Server B"] + n11.handle(top) -> Host.n4.handle(bottom) [label="Final result"] +} + +ServerA { + n12: rectangle label="Execute tool A" + n13: rectangle label="Return A result" + n12.handle(right) -> n13.handle(left) + n13.handle(top) -> Router.n11.handle(bottom) [label="Result A"] +} + +ServerB { + n14: rectangle label="Execute tool B" + n15: rectangle label="Return B result" + n14.handle(right) -> n15.handle(left) + n15.handle(top) -> Router.n11.handle(left) [label="Result B"] +} diff --git a/handoff/devops/on-call-rotation-workflow/README.md b/handoff/devops/on-call-rotation-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..0bcc1c7c63f223be18d69c4531c5adab88f65f1f --- /dev/null +++ b/handoff/devops/on-call-rotation-workflow/README.md @@ -0,0 +1,19 @@ +# On Call Rotation Workflow + +On-call rotation workflow with schedule creation, shift handoffs, override management, escalation policies, and fair rotation distribution. + +**Template ID:** `on-call-rotation-workflow` +**Kind:** workflow +**Source domain:** devops +**Primary use case:** handoff +**Secondary use cases:** incident, security +**Complexity:** 3/5 +**Nodes:** 13 +**Lanes:** 4 +**Tags:** [on-call-rotation, incident-management, pagerduty, escalation, schedule-management, handoff] +**Source path:** `devops/on-call-rotation` +**Repo path:** `handoff/devops/on-call-rotation-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/handoff/devops/on-call-rotation-workflow/metadata.json b/handoff/devops/on-call-rotation-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..ea9f3a69a6c495277fb994ee1de11c6e1dab6e97 --- /dev/null +++ b/handoff/devops/on-call-rotation-workflow/metadata.json @@ -0,0 +1,31 @@ +{ + "template_id": "on-call-rotation-workflow", + "workflow_id": "on-call-rotation", + "title": "On Call Rotation Workflow", + "kind": "workflow", + "source_domain": "devops", + "primary_use_case": "handoff", + "secondary_use_cases": [ + "incident", + "security" + ], + "use_cases": [ + "handoff", + "incident", + "security" + ], + "complexity": 3, + "num_nodes": 13, + "num_lanes": 4, + "tags": [ + "on-call-rotation", + "incident-management", + "pagerduty", + "escalation", + "schedule-management", + "handoff" + ], + "description": "On-call rotation workflow with schedule creation, shift handoffs, override management, escalation policies, and fair rotation distribution.", + "source_path": "devops/on-call-rotation", + "repo_path": "handoff/devops/on-call-rotation-workflow" +} diff --git a/devops/on-call-rotation/workflow.fz b/handoff/devops/on-call-rotation-workflow/workflow.fz similarity index 100% rename from devops/on-call-rotation/workflow.fz rename to handoff/devops/on-call-rotation-workflow/workflow.fz diff --git a/handoff/finance/payment-run-workflow/README.md b/handoff/finance/payment-run-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..25404e1c54c85fe7d7d05d2f4996951a96017f22 --- /dev/null +++ b/handoff/finance/payment-run-workflow/README.md @@ -0,0 +1,19 @@ +# Payment Run Workflow + +Accounts payable payment run workflow with batch creation, tiered approval (single/dual based on amount), ACH file generation, check printing, and vendor record updates. + +**Template ID:** `payment-run-workflow` +**Kind:** workflow +**Source domain:** finance +**Primary use case:** handoff +**Secondary use cases:** approval, billing +**Complexity:** 4/5 +**Nodes:** 18 +**Lanes:** 3 +**Tags:** [payment-run, accounts-payable, ach-payments, check-run, dual-approval, bank-transfer, vendor-payments] +**Source path:** `finance/payment-run` +**Repo path:** `handoff/finance/payment-run-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/handoff/finance/payment-run-workflow/metadata.json b/handoff/finance/payment-run-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..8f269a0170843bfc9394c0e8c1b6b8741d5fbdc5 --- /dev/null +++ b/handoff/finance/payment-run-workflow/metadata.json @@ -0,0 +1,32 @@ +{ + "template_id": "payment-run-workflow", + "workflow_id": "payment-run", + "title": "Payment Run Workflow", + "kind": "workflow", + "source_domain": "finance", + "primary_use_case": "handoff", + "secondary_use_cases": [ + "approval", + "billing" + ], + "use_cases": [ + "handoff", + "approval", + "billing" + ], + "complexity": 4, + "num_nodes": 18, + "num_lanes": 3, + "tags": [ + "payment-run", + "accounts-payable", + "ach-payments", + "check-run", + "dual-approval", + "bank-transfer", + "vendor-payments" + ], + "description": "Accounts payable payment run workflow with batch creation, tiered approval (single/dual based on amount), ACH file generation, check printing, and vendor record updates.", + "source_path": "finance/payment-run", + "repo_path": "handoff/finance/payment-run-workflow" +} diff --git a/finance/payment-run/workflow.fz b/handoff/finance/payment-run-workflow/workflow.fz similarity index 100% rename from finance/payment-run/workflow.fz rename to handoff/finance/payment-run-workflow/workflow.fz diff --git a/handoff/hr/offboarding-workflow/README.md b/handoff/hr/offboarding-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..63915e52b61b6e8a11ec149c1072ec7adb8f0194 --- /dev/null +++ b/handoff/hr/offboarding-workflow/README.md @@ -0,0 +1,19 @@ +# Offboarding Workflow + +Employee offboarding workflow with exit interview, knowledge transfer, asset collection, access revocation, final pay processing, and benefits continuation. + +**Template ID:** `offboarding-workflow` +**Kind:** workflow +**Source domain:** hr +**Primary use case:** handoff +**Secondary use cases:** offboarding +**Complexity:** 4/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [employee-offboarding, exit-interview, access-revocation, asset-return, knowledge-transfer, final-paycheck] +**Source path:** `hr/offboarding` +**Repo path:** `handoff/hr/offboarding-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/handoff/hr/offboarding-workflow/metadata.json b/handoff/hr/offboarding-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..fa22c2c4cd273e33133cee4dee49e2d95b78a1d0 --- /dev/null +++ b/handoff/hr/offboarding-workflow/metadata.json @@ -0,0 +1,29 @@ +{ + "template_id": "offboarding-workflow", + "workflow_id": "offboarding", + "title": "Offboarding Workflow", + "kind": "workflow", + "source_domain": "hr", + "primary_use_case": "handoff", + "secondary_use_cases": [ + "offboarding" + ], + "use_cases": [ + "handoff", + "offboarding" + ], + "complexity": 4, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "employee-offboarding", + "exit-interview", + "access-revocation", + "asset-return", + "knowledge-transfer", + "final-paycheck" + ], + "description": "Employee offboarding workflow with exit interview, knowledge transfer, asset collection, access revocation, final pay processing, and benefits continuation.", + "source_path": "hr/offboarding", + "repo_path": "handoff/hr/offboarding-workflow" +} diff --git a/hr/offboarding/workflow.fz b/handoff/hr/offboarding-workflow/workflow.fz similarity index 100% rename from hr/offboarding/workflow.fz rename to handoff/hr/offboarding-workflow/workflow.fz diff --git a/handoff/logistics/stock-transfer-workflow/README.md b/handoff/logistics/stock-transfer-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..0ac2cf2c93da8a94b7d15cddf75b033b7a391f1a --- /dev/null +++ b/handoff/logistics/stock-transfer-workflow/README.md @@ -0,0 +1,19 @@ +# Stock Transfer Workflow + +Internal stock transfer workflow with transfer request, source location pick, destination put-away, and inventory record updates across locations. + +**Template ID:** `stock-transfer-workflow` +**Kind:** workflow +**Source domain:** logistics +**Primary use case:** handoff +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [stock-transfer, inventory-movement, location-transfer, bin-to-bin, wms, inventory-rebalancing] +**Source path:** `logistics/stock-transfer` +**Repo path:** `handoff/logistics/stock-transfer-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/handoff/logistics/stock-transfer-workflow/metadata.json b/handoff/logistics/stock-transfer-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..608f5baf42c19c3842f8a40fe19260d0079c8f4e --- /dev/null +++ b/handoff/logistics/stock-transfer-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "stock-transfer-workflow", + "workflow_id": "stock-transfer", + "title": "Stock Transfer Workflow", + "kind": "workflow", + "source_domain": "logistics", + "primary_use_case": "handoff", + "secondary_use_cases": [], + "use_cases": [ + "handoff" + ], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "stock-transfer", + "inventory-movement", + "location-transfer", + "bin-to-bin", + "wms", + "inventory-rebalancing" + ], + "description": "Internal stock transfer workflow with transfer request, source location pick, destination put-away, and inventory record updates across locations.", + "source_path": "logistics/stock-transfer", + "repo_path": "handoff/logistics/stock-transfer-workflow" +} diff --git a/logistics/stock-transfer/workflow.fz b/handoff/logistics/stock-transfer-workflow/workflow.fz similarity index 100% rename from logistics/stock-transfer/workflow.fz rename to handoff/logistics/stock-transfer-workflow/workflow.fz diff --git a/handoff/logistics/warehouse-transfer-workflow/README.md b/handoff/logistics/warehouse-transfer-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..c1e1eeb7ba1859c24d8b922a245b9e77cb9bfa40 --- /dev/null +++ b/handoff/logistics/warehouse-transfer-workflow/README.md @@ -0,0 +1,19 @@ +# Warehouse Transfer Workflow + +Inter-warehouse transfer workflow with transfer order creation, shipping from source DC, in-transit tracking, and receiving at destination warehouse. + +**Template ID:** `warehouse-transfer-workflow` +**Kind:** workflow +**Source domain:** logistics +**Primary use case:** handoff +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [warehouse-transfer, inter-facility, transfer-order, in-transit-inventory, network-optimization, distribution] +**Source path:** `logistics/warehouse-transfer` +**Repo path:** `handoff/logistics/warehouse-transfer-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/handoff/logistics/warehouse-transfer-workflow/metadata.json b/handoff/logistics/warehouse-transfer-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..6223d7ae2a9e9e8447b74ebf6b04b958916bf6bb --- /dev/null +++ b/handoff/logistics/warehouse-transfer-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "warehouse-transfer-workflow", + "workflow_id": "warehouse-transfer", + "title": "Warehouse Transfer Workflow", + "kind": "workflow", + "source_domain": "logistics", + "primary_use_case": "handoff", + "secondary_use_cases": [], + "use_cases": [ + "handoff" + ], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "warehouse-transfer", + "inter-facility", + "transfer-order", + "in-transit-inventory", + "network-optimization", + "distribution" + ], + "description": "Inter-warehouse transfer workflow with transfer order creation, shipping from source DC, in-transit tracking, and receiving at destination warehouse.", + "source_path": "logistics/warehouse-transfer", + "repo_path": "handoff/logistics/warehouse-transfer-workflow" +} diff --git a/logistics/warehouse-transfer/workflow.fz b/handoff/logistics/warehouse-transfer-workflow/workflow.fz similarity index 100% rename from logistics/warehouse-transfer/workflow.fz rename to handoff/logistics/warehouse-transfer-workflow/workflow.fz diff --git a/handoff/patterns/api-gateway-workflow/README.md b/handoff/patterns/api-gateway-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..ea4456657c7e44cb7b504588189f1ac6010145fe --- /dev/null +++ b/handoff/patterns/api-gateway-workflow/README.md @@ -0,0 +1,19 @@ +# Api Gateway Workflow + +API Gateway pattern with request authentication, rate limiting, request routing to backend services, response aggregation, and error handling. + +**Template ID:** `api-gateway-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** handoff +**Secondary use cases:** security, mcp +**Complexity:** 3/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [api-gateway, microservices, rate-limiting, request-routing, authentication, load-balancing] +**Source path:** `patterns/api-gateway` +**Repo path:** `handoff/patterns/api-gateway-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/handoff/patterns/api-gateway-workflow/metadata.json b/handoff/patterns/api-gateway-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..7dc1a06c4fcb775f38865b859a33acf0daa59f87 --- /dev/null +++ b/handoff/patterns/api-gateway-workflow/metadata.json @@ -0,0 +1,31 @@ +{ + "template_id": "api-gateway-workflow", + "workflow_id": "api-gateway", + "title": "Api Gateway Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "handoff", + "secondary_use_cases": [ + "security", + "mcp" + ], + "use_cases": [ + "handoff", + "security", + "mcp" + ], + "complexity": 3, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "api-gateway", + "microservices", + "rate-limiting", + "request-routing", + "authentication", + "load-balancing" + ], + "description": "API Gateway pattern with request authentication, rate limiting, request routing to backend services, response aggregation, and error handling.", + "source_path": "patterns/api-gateway", + "repo_path": "handoff/patterns/api-gateway-workflow" +} diff --git a/patterns/api-gateway/workflow.fz b/handoff/patterns/api-gateway-workflow/workflow.fz similarity index 100% rename from patterns/api-gateway/workflow.fz rename to handoff/patterns/api-gateway-workflow/workflow.fz diff --git a/handoff/patterns/escalation-pattern-workflow/README.md b/handoff/patterns/escalation-pattern-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..9d99264fc3e3b177cc1af71a8c938f26b55ca9f5 --- /dev/null +++ b/handoff/patterns/escalation-pattern-workflow/README.md @@ -0,0 +1,19 @@ +# Escalation Pattern Workflow + +This workflow models escalating issues to higher authority when needed. + +**Template ID:** `escalation-pattern-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** handoff +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [escalation, pattern, patterns] +**Source path:** `patterns/escalation-pattern` +**Repo path:** `handoff/patterns/escalation-pattern-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/handoff/patterns/escalation-pattern-workflow/metadata.json b/handoff/patterns/escalation-pattern-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..4dd8b653d6fa9f43ba21f6b9969438990b24e4a8 --- /dev/null +++ b/handoff/patterns/escalation-pattern-workflow/metadata.json @@ -0,0 +1,23 @@ +{ + "template_id": "escalation-pattern-workflow", + "workflow_id": "escalation-pattern", + "title": "Escalation Pattern Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "handoff", + "secondary_use_cases": [], + "use_cases": [ + "handoff" + ], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "escalation", + "pattern", + "patterns" + ], + "description": "This workflow models escalating issues to higher authority when needed.", + "source_path": "patterns/escalation-pattern", + "repo_path": "handoff/patterns/escalation-pattern-workflow" +} diff --git a/patterns/escalation-pattern/workflow.fz b/handoff/patterns/escalation-pattern-workflow/workflow.fz similarity index 100% rename from patterns/escalation-pattern/workflow.fz rename to handoff/patterns/escalation-pattern-workflow/workflow.fz diff --git a/handoff/patterns/routing-slip-workflow/README.md b/handoff/patterns/routing-slip-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..354161f62a2f5d2e38a082884fb02724c049fd5c --- /dev/null +++ b/handoff/patterns/routing-slip-workflow/README.md @@ -0,0 +1,19 @@ +# Routing Slip Workflow + +This workflow models having messages carry their own routing instructions. + +**Template ID:** `routing-slip-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** handoff +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 13 +**Lanes:** 4 +**Tags:** [routing, slip, patterns] +**Source path:** `patterns/routing-slip` +**Repo path:** `handoff/patterns/routing-slip-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/handoff/patterns/routing-slip-workflow/metadata.json b/handoff/patterns/routing-slip-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..c9e3eec2bfa2f19567e55509d40e538da478d5bc --- /dev/null +++ b/handoff/patterns/routing-slip-workflow/metadata.json @@ -0,0 +1,23 @@ +{ + "template_id": "routing-slip-workflow", + "workflow_id": "routing-slip", + "title": "Routing Slip Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "handoff", + "secondary_use_cases": [], + "use_cases": [ + "handoff" + ], + "complexity": 4, + "num_nodes": 13, + "num_lanes": 4, + "tags": [ + "routing", + "slip", + "patterns" + ], + "description": "This workflow models having messages carry their own routing instructions.", + "source_path": "patterns/routing-slip", + "repo_path": "handoff/patterns/routing-slip-workflow" +} diff --git a/patterns/routing-slip/workflow.fz b/handoff/patterns/routing-slip-workflow/workflow.fz similarity index 100% rename from patterns/routing-slip/workflow.fz rename to handoff/patterns/routing-slip-workflow/workflow.fz diff --git a/hr/background-check/README.md b/hr/background-check/README.md deleted file mode 100644 index 328a928b1e3acaeaad4d963d2989967c05099970..0000000000000000000000000000000000000000 --- a/hr/background-check/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# Background Check - -Pre-employment background check workflow with criminal history search, employment verification, education verification, and drug screening coordination. - -**Domain:** hr -**Complexity:** 3/5 -**Tags:** [background-check, pre-employment, criminal-history, employment-verification, education-verification, drug-screening] - -## Lanes -- **HR/Recruiter** - Initiates check, reviews results, makes decision -- **Background Check Vendor** - Conducts searches, returns results - -## Process Flow -1. Initiate background check after conditional offer -2. Candidate provides consent and information -3. Submit to background check vendor -4. Run criminal history search -5. Verify employment history -6. Verify education credentials -7. Coordinate drug screening if required -8. Review results for adverse findings -9. Make hire/no-hire decision based on results diff --git a/hr/bonus-allocation/README.md b/hr/bonus-allocation/README.md deleted file mode 100644 index 697c6c1103631ca88185b3537a7be4d421922cbb..0000000000000000000000000000000000000000 --- a/hr/bonus-allocation/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# Bonus Allocation - -Annual bonus allocation workflow with budget pool distribution, performance-based calculation, manager calibration, executive approval, and payroll processing. - -**Domain:** hr -**Complexity:** 3/5 -**Tags:** [bonus-allocation, annual-bonus, performance-bonus, budget-pool, calibration, payout] - -## Lanes -- **HR/Compensation** - Sets budget pool, calculates targets -- **Management** - Allocates to team, calibrates across org - -## Process Flow -1. Finance approves annual bonus budget pool -2. HR distributes pool to departments -3. Calculate target bonus by role/level -4. Manager allocates based on performance -5. Calibration session across teams -6. Executive approval of final allocations -7. Generate bonus letters -8. Process through payroll -9. Communicate to employees diff --git a/hr/bonus-allocation/metadata.json b/hr/bonus-allocation/metadata.json deleted file mode 100644 index 5b649a05d88e4730af52ff34d3db354bac9cdf93..0000000000000000000000000000000000000000 --- a/hr/bonus-allocation/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "bonus-allocation", - "domain": "hr", - "complexity": 3, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "bonus-allocation", - "annual-bonus", - "performance-bonus", - "budget-pool", - "calibration", - "payout" - ], - "description": "Annual bonus allocation workflow with budget pool distribution, performance-based calculation, manager calibration, executive approval, and payroll processing." -} \ No newline at end of file diff --git a/hr/candidate-rejection/README.md b/hr/candidate-rejection/README.md deleted file mode 100644 index 5a5458b14add7eebfc9c8662e2c9cffce468669a..0000000000000000000000000000000000000000 --- a/hr/candidate-rejection/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Candidate Rejection - -Candidate rejection workflow with stage-appropriate messaging, personalized rejection letters, talent pool consideration, ATS status update, and candidate experience feedback. - -**Domain:** hr -**Complexity:** 3/5 -**Tags:** [candidate-rejection, hiring-decision, rejection-letter, talent-pool, candidate-experience, ats-update] - -## Lanes -- **Hiring Manager** - Makes rejection decision, provides feedback -- **Recruiter** - Crafts message, sends notification -- **ATS System** - Updates status, archives candidate - -## Process Flow -1. Hiring manager decides not to proceed -2. Document rejection reason -3. Determine rejection stage (resume, phone, onsite) -4. Select appropriate rejection template -5. Personalize message with feedback (if appropriate) -6. Consider for talent pool for future roles -7. Send rejection notification -8. Update ATS with final status -9. Archive candidate record diff --git a/hr/conflict-resolution/README.md b/hr/conflict-resolution/README.md deleted file mode 100644 index 39c6b71b31d5a852a5290dd6043a820dff4c805b..0000000000000000000000000000000000000000 --- a/hr/conflict-resolution/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Conflict Resolution - -Workplace conflict resolution workflow with complaint intake, HR investigation, mediation sessions, resolution documentation, and follow-up monitoring. - -**Domain:** hr -**Complexity:** 4/5 -**Tags:** [conflict-resolution, workplace-dispute, mediation, hr-investigation, employee-relations, grievance] - -## Lanes -- **Employee** - Reports conflict, participates in resolution -- **HR** - Investigates, facilitates mediation -- **Management** - Supports resolution, implements changes - -## Process Flow -1. Employee reports workplace conflict -2. HR conducts initial intake interview -3. Assess severity and determine approach -4. Interview all parties involved -5. Document findings and perspectives -6. Schedule mediation session if appropriate -7. Facilitate resolution discussion -8. Document agreed resolution -9. Monitor for compliance and follow-up diff --git a/hr/conflict-resolution/metadata.json b/hr/conflict-resolution/metadata.json deleted file mode 100644 index bacf33b692eb00919e4744d03adc59744bfec137..0000000000000000000000000000000000000000 --- a/hr/conflict-resolution/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "conflict-resolution", - "domain": "hr", - "complexity": 4, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "conflict-resolution", - "workplace-dispute", - "mediation", - "hr-investigation", - "employee-relations", - "grievance" - ], - "description": "Workplace conflict resolution workflow with complaint intake, HR investigation, mediation sessions, resolution documentation, and follow-up monitoring." -} \ No newline at end of file diff --git a/hr/diversity-initiative/README.md b/hr/diversity-initiative/README.md deleted file mode 100644 index 30a7932a86a9c2b3c01b553ba5c043574f366603..0000000000000000000000000000000000000000 --- a/hr/diversity-initiative/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Diversity Initiative - -This workflow models promoting workplace diversity. - -**Domain:** hr -**Complexity:** 3/5 -**Tags:** [diversity, initiative, hr] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/hr/diversity-initiative/metadata.json b/hr/diversity-initiative/metadata.json deleted file mode 100644 index 42616e102b66e9dda70f310ffce907be86528da4..0000000000000000000000000000000000000000 --- a/hr/diversity-initiative/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "diversity-initiative", - "domain": "hr", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "diversity", - "initiative", - "hr" - ], - "description": "This workflow models promoting workplace diversity." -} \ No newline at end of file diff --git a/hr/employee-engagement/README.md b/hr/employee-engagement/README.md deleted file mode 100644 index c963dcd89c335b165a08511366809c407be91b8f..0000000000000000000000000000000000000000 --- a/hr/employee-engagement/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Employee Engagement - -This workflow models measuring and improving engagement. - -**Domain:** hr -**Complexity:** 2/5 -**Tags:** [employee, engagement, hr, parallel] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/hr/employee-engagement/metadata.json b/hr/employee-engagement/metadata.json deleted file mode 100644 index b91b3d89ebd798d014913afa26ad2d34ff0bfbe7..0000000000000000000000000000000000000000 --- a/hr/employee-engagement/metadata.json +++ /dev/null @@ -1,14 +0,0 @@ -{ - "workflow_id": "employee-engagement", - "domain": "hr", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "employee", - "engagement", - "hr", - "parallel" - ], - "description": "This workflow models measuring and improving engagement." -} \ No newline at end of file diff --git a/hr/expense-approval/README.md b/hr/expense-approval/README.md deleted file mode 100644 index 4a36ea84b3767bc723d898a40c263a5f39219301..0000000000000000000000000000000000000000 --- a/hr/expense-approval/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Expense Approval - -Employee expense approval workflow with receipt validation, policy compliance check, tiered approval based on amount, and reimbursement processing. - -**Domain:** hr -**Complexity:** 3/5 -**Tags:** [expense-approval, travel-expenses, receipt-validation, policy-compliance, tiered-approval, reimbursement] - -## Lanes -- **Employee** - Submits expense report with receipts -- **Manager** - Reviews and approves within limit -- **Finance** - Validates policy, processes reimbursement - -## Process Flow -1. Employee submits expense report -2. Attach receipts and categorize expenses -3. System validates against expense policy -4. Route to manager for approval -5. If over manager limit, escalate to director -6. Finance reviews for policy compliance -7. Flag any out-of-policy items -8. Process approved reimbursement -9. Deposit to employee account diff --git a/hr/expense-approval/metadata.json b/hr/expense-approval/metadata.json deleted file mode 100644 index 98aab4e6ff004427a500bef7504b33c1f180cf39..0000000000000000000000000000000000000000 --- a/hr/expense-approval/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "expense-approval", - "domain": "hr", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "expense-approval", - "travel-expenses", - "receipt-validation", - "policy-compliance", - "tiered-approval", - "reimbursement" - ], - "description": "Employee expense approval workflow with receipt validation, policy compliance check, tiered approval based on amount, and reimbursement processing." -} \ No newline at end of file diff --git a/hr/internship-program/README.md b/hr/internship-program/README.md deleted file mode 100644 index 997a5f719672ccb710f38c8a8f14ded0dce7fd0a..0000000000000000000000000000000000000000 --- a/hr/internship-program/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Internship Program - -This workflow models managing an internship program. - -**Domain:** hr -**Complexity:** 2/5 -**Tags:** [internship, program, hr] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/hr/internship-program/metadata.json b/hr/internship-program/metadata.json deleted file mode 100644 index 8e0c9e853546f0767297d496a36a9927c89a6016..0000000000000000000000000000000000000000 --- a/hr/internship-program/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "internship-program", - "domain": "hr", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "internship", - "program", - "hr" - ], - "description": "This workflow models managing an internship program." -} \ No newline at end of file diff --git a/hr/interview-process/README.md b/hr/interview-process/README.md deleted file mode 100644 index 37ff8057a651ffea9f2c1d3d79342e8a49ab6688..0000000000000000000000000000000000000000 --- a/hr/interview-process/README.md +++ /dev/null @@ -1,24 +0,0 @@ -# Interview Process - -Multi-stage interview process with resume screening, phone screen, technical interview, onsite panel, team consensus decision, and offer/rejection handling. - -**Domain:** hr -**Complexity:** 4/5 -**Tags:** [interview-process, hiring, phone-screen, technical-interview, onsite-panel, talent-acquisition, offer-management] - -## Lanes -- **Candidate** - Submits application, completes interviews, receives decision -- **Recruiter** - Reviews resumes, conducts phone screens, schedules interviews -- **Hiring Team** - Conducts technical and onsite interviews, makes hiring decision - -## Process Flow -1. Candidate submits application -2. Recruiter reviews resume against requirements -3. If qualified, schedule phone screen -4. Conduct phone screen and evaluate fit -5. If passed, schedule technical interview -6. Hiring team conducts technical assessment -7. If technical skills sufficient, schedule onsite panel -8. Conduct onsite interviews with multiple team members -9. Team reaches consensus on hire/no-hire decision -10. Extend offer or send rejection notification diff --git a/hr/job-posting/README.md b/hr/job-posting/README.md deleted file mode 100644 index 4c02d2dc5bf2d07006224e16b256f81aafb2a58a..0000000000000000000000000000000000000000 --- a/hr/job-posting/README.md +++ /dev/null @@ -1,24 +0,0 @@ -# Job Posting - -Job posting workflow with requisition approval, job description drafting, multi-channel posting (LinkedIn, Indeed, career sites), AI resume screening, and ATS candidate tracking. - -**Domain:** hr -**Complexity:** 4/5 -**Tags:** [job-posting, job-requisition, ats, linkedin, indeed, ai-screening, talent-acquisition] - -## Lanes -- **Hiring Manager** - Submits requisition, defines requirements, reviews candidates -- **Recruiter** - Reviews requisition, drafts job description, posts to job boards -- **Applicant Tracking System** - Collects applications, AI screens resumes, notifies recruiter - -## Process Flow -1. Hiring manager submits job requisition -2. Recruiter reviews and checks headcount approval -3. Draft job description with requirements -4. Select job boards for posting -5. Post to career sites, LinkedIn, and Indeed -6. ATS collects incoming applications -7. AI screens resumes against minimum qualifications -8. Qualified candidates added to candidate pool -9. Unqualified candidates receive auto-rejection -10. Notify recruiter when candidates are ready for review diff --git a/hr/offboarding/README.md b/hr/offboarding/README.md deleted file mode 100644 index 59dc705a9ae5b3b5060417a863f9ad1e4acaf660..0000000000000000000000000000000000000000 --- a/hr/offboarding/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Offboarding - -Employee offboarding workflow with exit interview, knowledge transfer, asset collection, access revocation, final pay processing, and benefits continuation. - -**Domain:** hr -**Complexity:** 4/5 -**Tags:** [employee-offboarding, exit-interview, access-revocation, asset-return, knowledge-transfer, final-paycheck] - -## Lanes -- **Employee** - Completes exit tasks, returns assets -- **Manager** - Conducts exit interview, manages knowledge transfer -- **HR/IT** - Revokes access, processes final pay, handles benefits - -## Process Flow -1. Initiate offboarding upon resignation/termination -2. Schedule exit interview with manager -3. Begin knowledge transfer to team members -4. Collect company assets (laptop, badge, keys) -5. IT revokes system access and email -6. Process final paycheck with accrued PTO -7. Provide COBRA and benefits continuation info -8. Conduct exit interview for feedback -9. Complete offboarding checklist diff --git a/hr/offboarding/metadata.json b/hr/offboarding/metadata.json deleted file mode 100644 index c93f04cec70744fcea020584fea7edf34c053b47..0000000000000000000000000000000000000000 --- a/hr/offboarding/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "offboarding", - "domain": "hr", - "complexity": 4, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "employee-offboarding", - "exit-interview", - "access-revocation", - "asset-return", - "knowledge-transfer", - "final-paycheck" - ], - "description": "Employee offboarding workflow with exit interview, knowledge transfer, asset collection, access revocation, final pay processing, and benefits continuation." -} \ No newline at end of file diff --git a/hr/onboarding/README.md b/hr/onboarding/README.md deleted file mode 100644 index d7056857a56670a1418b1f91cc03ee8da22fe2a2..0000000000000000000000000000000000000000 --- a/hr/onboarding/README.md +++ /dev/null @@ -1,24 +0,0 @@ -# Employee Onboarding - -Complete employee onboarding workflow covering offer acceptance, HR record creation, benefits enrollment, background check verification, IT account provisioning, equipment setup, and first day orientation. - -**Domain:** hr -**Complexity:** 4/5 -**Tags:** [employee-onboarding, new-hire, hr-workflow, background-check, it-provisioning, benefits-enrollment] - -## Lanes -- **New Hire** - Accepts offer, completes forms, attends orientation -- **Human Resources** - Creates records, enrolls benefits, verifies background -- **IT Department** - Provisions accounts, sets up equipment, grants access - -## Process Flow -1. New hire accepts offer letter -2. HR creates employee record and enrolls in benefits -3. Assign to department and schedule orientation -4. Background check verification (rescind offer if failed) -5. New hire completes I-9 and W-4 forms -6. IT creates user accounts and provisions laptop -7. Set up email, Slack, and grant system access -8. Check equipment availability (order if needed) -9. Ship equipment to employee -10. New hire sets up direct deposit and completes orientation diff --git a/hr/performance-review/README.md b/hr/performance-review/README.md deleted file mode 100644 index 0f0bfdcfd9125c35995e95d71696dc626002db4e..0000000000000000000000000000000000000000 --- a/hr/performance-review/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Performance Review - -Annual performance review workflow with self-assessment, manager evaluation, 360 feedback collection, calibration sessions, and merit increase recommendations. - -**Domain:** hr -**Complexity:** 4/5 -**Tags:** [performance-review, annual-evaluation, goal-setting, 360-feedback, calibration, merit-increase] - -## Lanes -- **Employee** - Completes self-assessment, reviews feedback -- **Manager** - Evaluates performance, recommends rating -- **HR/Leadership** - Facilitates calibration, approves increases - -## Process Flow -1. HR initiates annual review cycle -2. Employee completes self-assessment -3. Collect 360 feedback from peers -4. Manager completes evaluation -5. Conduct calibration session across teams -6. Finalize performance ratings -7. Determine merit increase recommendations -8. Manager delivers feedback to employee -9. Set goals for next review period diff --git a/hr/performance-review/metadata.json b/hr/performance-review/metadata.json deleted file mode 100644 index ff0648c9851b2e5a8d6716041404c96750a78ade..0000000000000000000000000000000000000000 --- a/hr/performance-review/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "performance-review", - "domain": "hr", - "complexity": 4, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "performance-review", - "annual-evaluation", - "goal-setting", - "360-feedback", - "calibration", - "merit-increase" - ], - "description": "Annual performance review workflow with self-assessment, manager evaluation, 360 feedback collection, calibration sessions, and merit increase recommendations." -} \ No newline at end of file diff --git a/hr/promotion-process/README.md b/hr/promotion-process/README.md deleted file mode 100644 index cf6da29bddebcd832996393e3d1e3d061148f6b8..0000000000000000000000000000000000000000 --- a/hr/promotion-process/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# Promotion Process - -Employee promotion workflow with performance validation, job level assessment, compensation adjustment, title change, and announcement coordination. - -**Domain:** hr -**Complexity:** 3/5 -**Tags:** [promotion-process, career-advancement, job-leveling, title-change, compensation-adjustment, succession-planning] - -## Lanes -- **Manager** - Nominates employee, provides justification -- **HR** - Validates eligibility, processes changes - -## Process Flow -1. Manager nominates employee for promotion -2. Validate performance history meets criteria -3. Assess readiness for next job level -4. Determine new title and job code -5. Calculate compensation adjustment -6. Obtain required approvals -7. Update HRIS with new role and salary -8. Coordinate announcement timing -9. Communicate promotion to employee diff --git a/hr/pto-request/README.md b/hr/pto-request/README.md deleted file mode 100644 index 27a392aa07841be728c61b94d2f7f52a18abb5d8..0000000000000000000000000000000000000000 --- a/hr/pto-request/README.md +++ /dev/null @@ -1,21 +0,0 @@ -# PTO Request - -PTO request workflow with balance verification, manager approval, calendar blocking, and team coverage check before approval. - -**Domain:** hr -**Complexity:** 2/5 -**Tags:** [pto-request, time-off, vacation, leave-management, manager-approval, accrual-balance] - -## Lanes -- **Employee** - Submits request, receives approval notification -- **Manager** - Reviews request, checks coverage, approves/denies - -## Process Flow -1. Employee submits PTO request with dates -2. System checks available PTO balance -3. Manager receives approval request -4. Check team calendar for conflicts -5. Verify adequate coverage during absence -6. Approve or deny with reason -7. Update employee calendar -8. Deduct hours from PTO balance diff --git a/hr/reference-check/README.md b/hr/reference-check/README.md deleted file mode 100644 index 5b18aaa7c87d67d81d8e6ef42bdd6f9a652a8bed..0000000000000000000000000000000000000000 --- a/hr/reference-check/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Reference Check - -Professional reference check workflow with reference collection, outreach scheduling, structured interview questions, feedback documentation, and hiring recommendation. - -**Domain:** hr -**Complexity:** 3/5 -**Tags:** [reference-check, employment-verification, professional-references, hiring-decision, candidate-vetting, feedback-collection] - -## Lanes -- **Candidate** - Provides reference contact information -- **Recruiter** - Conducts reference calls, documents feedback -- **Hiring Manager** - Reviews feedback, makes final decision - -## Process Flow -1. Request reference list from candidate -2. Verify references are professional contacts -3. Schedule reference calls -4. Conduct structured reference interview -5. Ask about performance, strengths, areas for growth -6. Verify employment dates and title -7. Document feedback and ratings -8. Compile reference summary -9. Share with hiring manager for decision diff --git a/hr/relocation-assistance/README.md b/hr/relocation-assistance/README.md deleted file mode 100644 index 9de582a19f0018a4ea35f3775645b1ce35666574..0000000000000000000000000000000000000000 --- a/hr/relocation-assistance/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Relocation Assistance - -This workflow models helping employees relocate. - -**Domain:** hr -**Complexity:** 3/5 -**Tags:** [relocation, assistance, hr, decision] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/hr/relocation-assistance/metadata.json b/hr/relocation-assistance/metadata.json deleted file mode 100644 index 44573919084c129f3b99e02305ffc0b02bb93c41..0000000000000000000000000000000000000000 --- a/hr/relocation-assistance/metadata.json +++ /dev/null @@ -1,14 +0,0 @@ -{ - "workflow_id": "relocation-assistance", - "domain": "hr", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "relocation", - "assistance", - "hr", - "decision" - ], - "description": "This workflow models helping employees relocate." -} \ No newline at end of file diff --git a/hr/salary-increase/README.md b/hr/salary-increase/README.md deleted file mode 100644 index 96a5ac8d21bc99b9f6881f054c2a72a56eef0061..0000000000000000000000000000000000000000 --- a/hr/salary-increase/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Salary Increase - -Salary increase workflow with market analysis, comp ratio review, budget validation, tiered approval based on increase percentage, and payroll system update. - -**Domain:** hr -**Complexity:** 3/5 -**Tags:** [salary-increase, compensation, merit-raise, market-adjustment, budget-approval, comp-ratio] - -## Lanes -- **Manager** - Submits increase request with justification -- **HR/Compensation** - Reviews market data, validates budget -- **Executive** - Approves increases above threshold - -## Process Flow -1. Manager submits salary increase request -2. HR reviews current comp ratio vs market -3. Validate budget availability -4. Route based on increase percentage -5. < 10%: Manager + HR approval -6. 10-20%: Director approval required -7. > 20%: VP/Executive approval required -8. Update payroll system with new salary -9. Generate offer letter for employee diff --git a/hr/salary-increase/metadata.json b/hr/salary-increase/metadata.json deleted file mode 100644 index 064324425acca258edc0b18d3f9dd986deae3643..0000000000000000000000000000000000000000 --- a/hr/salary-increase/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "salary-increase", - "domain": "hr", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "salary-increase", - "compensation", - "merit-raise", - "market-adjustment", - "budget-approval", - "comp-ratio" - ], - "description": "Salary increase workflow with market analysis, comp ratio review, budget validation, tiered approval based on increase percentage, and payroll system update." -} \ No newline at end of file diff --git a/hr/termination-process/README.md b/hr/termination-process/README.md deleted file mode 100644 index 26d864f30f47533eda2035fbd391784884075909..0000000000000000000000000000000000000000 --- a/hr/termination-process/README.md +++ /dev/null @@ -1,26 +0,0 @@ -# Termination Process - -Employee termination workflow handling voluntary and involuntary separations with legal review, separation agreements, final pay calculation, COBRA notices, and severance processing. - -**Domain:** hr -**Complexity:** 4/5 -**Tags:** [employee-termination, offboarding, separation-agreement, final-pay, cobra, severance, legal-review] - -## Lanes -- **Manager** - Initiates termination, documents issues, conducts final meeting -- **Human Resources** - Reviews request, handles legal routing, prepares agreements -- **Payroll** - Calculates final pay, PTO payout, COBRA, severance - -## Process Flow -1. Manager initiates termination request -2. HR reviews and determines termination type -3. Involuntary: Verify cause documentation -4. Voluntary: Process resignation -5. Route to legal counsel if required -6. Prepare separation agreement -7. Calculate final pay and accrued PTO -8. Process final paycheck -9. Generate COBRA continuation notice -10. Issue W-2 instructions -11. Process severance if applicable -12. Manager conducts final meeting diff --git a/hr/training-enrollment/README.md b/hr/training-enrollment/README.md deleted file mode 100644 index 4163ae8bcd8b11c31e054fa7c4758d75869148ff..0000000000000000000000000000000000000000 --- a/hr/training-enrollment/README.md +++ /dev/null @@ -1,21 +0,0 @@ -# Training Enrollment - -Training enrollment workflow with course catalog browsing, manager approval, LMS registration, completion tracking, and certification management. - -**Domain:** hr -**Complexity:** 2/5 -**Tags:** [training-enrollment, learning-management, lms, professional-development, compliance-training, certification] - -## Lanes -- **Employee** - Requests training, completes courses -- **Manager/LMS** - Approves enrollment, tracks completion - -## Process Flow -1. Employee browses training catalog -2. Select course and submit enrollment request -3. Manager reviews and approves (if required) -4. Register employee in LMS -5. Employee completes training modules -6. Track completion and assessment scores -7. Issue certificate upon completion -8. Update employee training record diff --git a/incident/architecture/api-composition-pattern-architecture/README.md b/incident/architecture/api-composition-pattern-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..6447cbee54584fd3e82bb5d2ea40ee37b9180276 --- /dev/null +++ b/incident/architecture/api-composition-pattern-architecture/README.md @@ -0,0 +1,19 @@ +# API Composition Pattern Architecture + +An API composition architecture diagram with a composer service that fans out parallel requests to multiple microservices, collects responses with timeout handling, and merges results into a single unified response with partial fallback support. This template models the API composition pattern used when a single client query requires data from multiple services, avoiding the need for direct service-to-service calls. Useful for teams building aggregation layers in microservices architectures. + +**Template ID:** `api-composition-pattern-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** incident +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 16 +**Lanes:** 3 +**Tags:** [api-composition, response-aggregation, fan-out, parallel-requests, timeout-handling, partial-response, microservices, architecture-diagram] +**Source path:** `` +**Repo path:** `incident/architecture/api-composition-pattern-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/incident/architecture/api-composition-pattern-architecture/metadata.json b/incident/architecture/api-composition-pattern-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..3d2868d7051bcfc418c05267baea23091a1facb1 --- /dev/null +++ b/incident/architecture/api-composition-pattern-architecture/metadata.json @@ -0,0 +1,28 @@ +{ + "template_id": "api-composition-pattern-architecture", + "workflow_id": "api-composition-pattern-architecture", + "title": "API Composition Pattern Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "incident", + "secondary_use_cases": [], + "use_cases": [ + "incident" + ], + "complexity": 3, + "num_nodes": 16, + "num_lanes": 3, + "tags": [ + "api-composition", + "response-aggregation", + "fan-out", + "parallel-requests", + "timeout-handling", + "partial-response", + "microservices", + "architecture-diagram" + ], + "description": "An API composition architecture diagram with a composer service that fans out parallel requests to multiple microservices, collects responses with timeout handling, and merges results into a single unified response with partial fallback support. This template models the API composition pattern used when a single client query requires data from multiple services, avoiding the need for direct service-to-service calls. Useful for teams building aggregation layers in microservices architectures.", + "source_path": "", + "repo_path": "incident/architecture/api-composition-pattern-architecture" +} diff --git a/incident/architecture/api-composition-pattern-architecture/workflow.fz b/incident/architecture/api-composition-pattern-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..dd1807bf2d44ad8af0830859d26fa8aa5080ad44 --- /dev/null +++ b/incident/architecture/api-composition-pattern-architecture/workflow.fz @@ -0,0 +1,44 @@ +Client { # Client Application +n1: circle label:"Complex Query Request" +n2: rectangle label:"API Composer Service" +n19: rectangle label:"Receive Composed Response" +n20: circle label:"Display Result" +n1.handle(right) -> n2.handle(left) +n2.handle(bottom) -> Composer.n3.handle(top) [label="Compose"] +n19.handle(right) -> n20.handle(left) +} +Composer { # API Composition Layer +n3: rectangle label:"Parse Query Requirements" +n4: rectangle label:"Fan-Out Parallel Requests" +n13: rectangle label:"Collect Responses" +n14: diamond label:"All Responses Received?" +n15: rectangle label:"Merge and Transform" +n16: rectangle label:"Return Partial with Fallback" +n3.handle(right) -> n4.handle(left) [label="Decompose"] +n4.handle(bottom) -> Services.n5.handle(top) [label="GET /users"] +n4.handle(bottom) -> Services.n7.handle(top) [label="GET /orders"] +n4.handle(bottom) -> Services.n9.handle(top) [label="GET /products"] +n13.handle(right) -> n14.handle(left) +n14.handle(right) -> n15.handle(left) [label="Yes"] +n14.handle(bottom) -> n16.handle(top) [label="Timeout"] +n15.handle(top) -> Client.n19.handle(bottom) [label="Composed JSON"] +n16.handle(top) -> Client.n19.handle(bottom) [label="Partial JSON"] +} +Services { # Microservices +n5: rectangle label:"User Service" +n6: rectangle label:"User Response" +n7: rectangle label:"Order Service" +n8: rectangle label:"Order Response" +n9: rectangle label:"Product Service" +n10: rectangle label:"Product Response" +n11: rectangle label:"Aggregate Results" +n12: rectangle label:"Send to Composer" +n5.handle(right) -> n6.handle(left) [label="Query"] +n7.handle(right) -> n8.handle(left) [label="Query"] +n9.handle(right) -> n10.handle(left) [label="Query"] +n6.handle(bottom) -> n11.handle(top) [label="User Data"] +n8.handle(bottom) -> n11.handle(top) [label="Order Data"] +n10.handle(right) -> n11.handle(left) [label="Product Data"] +n11.handle(right) -> n12.handle(left) +n12.handle(top) -> Composer.n13.handle(bottom) [label="All Data"] +} diff --git a/incident/architecture/event-driven-dead-letter-queue-architecture/README.md b/incident/architecture/event-driven-dead-letter-queue-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..8a672b4a4cb723584e152b0b1154708d700b17f4 --- /dev/null +++ b/incident/architecture/event-driven-dead-letter-queue-architecture/README.md @@ -0,0 +1,19 @@ +# Event-Driven Dead Letter Queue Architecture + +A dead letter queue architecture diagram with retry policies, exponential backoff, max retry thresholds, DLQ routing for failed messages, operations alerting, and manual reprocessing workflows. This template models the critical error handling pattern for asynchronous messaging systems, ensuring no message is silently lost when processing fails. Essential for building reliable event-driven systems with proper failure recovery mechanisms. + +**Template ID:** `event-driven-dead-letter-queue-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** incident +**Secondary use cases:** compliance +**Complexity:** 3/5 +**Nodes:** 16 +**Lanes:** 3 +**Tags:** [dead-letter-queue, dlq, retry-policy, message-processing, error-handling, operations-alerting, message-reliability, architecture-diagram] +**Source path:** `` +**Repo path:** `incident/architecture/event-driven-dead-letter-queue-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/incident/architecture/event-driven-dead-letter-queue-architecture/metadata.json b/incident/architecture/event-driven-dead-letter-queue-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..567192bdc49280163665e3882d7496f470e83804 --- /dev/null +++ b/incident/architecture/event-driven-dead-letter-queue-architecture/metadata.json @@ -0,0 +1,31 @@ +{ + "template_id": "event-driven-dead-letter-queue-architecture", + "workflow_id": "event-driven-dead-letter-queue-architecture", + "title": "Event-Driven Dead Letter Queue Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "incident", + "secondary_use_cases": [ + "compliance" + ], + "use_cases": [ + "incident", + "compliance" + ], + "complexity": 3, + "num_nodes": 16, + "num_lanes": 3, + "tags": [ + "dead-letter-queue", + "dlq", + "retry-policy", + "message-processing", + "error-handling", + "operations-alerting", + "message-reliability", + "architecture-diagram" + ], + "description": "A dead letter queue architecture diagram with retry policies, exponential backoff, max retry thresholds, DLQ routing for failed messages, operations alerting, and manual reprocessing workflows. This template models the critical error handling pattern for asynchronous messaging systems, ensuring no message is silently lost when processing fails. Essential for building reliable event-driven systems with proper failure recovery mechanisms.", + "source_path": "", + "repo_path": "incident/architecture/event-driven-dead-letter-queue-architecture" +} diff --git a/incident/architecture/event-driven-dead-letter-queue-architecture/workflow.fz b/incident/architecture/event-driven-dead-letter-queue-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..92edd67f08d1da7940efda08385e12054091a9e6 --- /dev/null +++ b/incident/architecture/event-driven-dead-letter-queue-architecture/workflow.fz @@ -0,0 +1,39 @@ +Producer { # Message Producer +n1: circle label:"Publish Message" +n2: rectangle label:"Serialize Payload" +n3: rectangle label:"Send to Main Queue" +n1.handle(right) -> n2.handle(left) +n2.handle(right) -> n3.handle(left) [label="Enqueue"] +n3.handle(bottom) -> MainQueue.n4.handle(top) [label="Deliver"] +} +MainQueue { # Main Processing Queue +n4: rectangle label:"Receive Message" +n5: rectangle label:"Attempt Processing" +n6: diamond label:"Processing Succeeded?" +n7: rectangle label:"Acknowledge Message" +n8: rectangle label:"Increment Retry Count" +n9: diamond label:"Max Retries Exceeded?" +n10: rectangle label:"Schedule Retry" +n4.handle(right) -> n5.handle(left) +n5.handle(right) -> n6.handle(left) +n6.handle(right) -> n7.handle(left) [label="Yes"] +n6.handle(bottom) -> n8.handle(top) [label="No"] +n8.handle(right) -> n9.handle(left) +n9.handle(right) -> n10.handle(left) [label="Retry"] +n9.handle(bottom) -> DLQ.n11.handle(top) [label="Exceeded"] +} +DLQ { # Dead Letter Queue +n11: rectangle label:"Route to DLQ" +n12: rectangle label:"Store Failed Message" +n13: rectangle label:"Alert Operations Team" +n14: rectangle label:"Manual Review Dashboard" +n15: diamond label:"Reprocessable?" +n16: rectangle label:"Requeue to Main" +n17: rectangle label:"Archive and Close" +n11.handle(right) -> n12.handle(left) [label="Preserve Context"] +n12.handle(right) -> n13.handle(left) [label="PagerDuty"] +n13.handle(right) -> n14.handle(left) +n14.handle(right) -> n15.handle(left) [label="Investigate"] +n15.handle(right) -> n16.handle(left) [label="Yes"] +n15.handle(bottom) -> n17.handle(top) [label="No"] +} diff --git a/incident/architecture/health-check-pattern-architecture/README.md b/incident/architecture/health-check-pattern-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..fd26cb37d73724cc600f85df131d1dcd52bda15c --- /dev/null +++ b/incident/architecture/health-check-pattern-architecture/README.md @@ -0,0 +1,19 @@ +# Health Check Pattern Architecture + +A health check pattern architecture diagram with load balancer probes, deep health checks verifying database, cache, disk, and dependency status, automatic instance rotation, and alerting integration with PagerDuty for consecutive failures. This template models the health monitoring infrastructure that enables self-healing systems, where unhealthy instances are automatically removed from rotation and operations teams are alerted. Key for building production-ready services with proper observability. + +**Template ID:** `health-check-pattern-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** incident +**Secondary use cases:** security +**Complexity:** 3/5 +**Nodes:** 19 +**Lanes:** 4 +**Tags:** [health-check, load-balancer, self-healing, monitoring, pagerduty, instance-rotation, deep-health-check, architecture-diagram] +**Source path:** `` +**Repo path:** `incident/architecture/health-check-pattern-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/incident/architecture/health-check-pattern-architecture/metadata.json b/incident/architecture/health-check-pattern-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..54b12b5d23c2d5b48d735b7314610bae28683bfa --- /dev/null +++ b/incident/architecture/health-check-pattern-architecture/metadata.json @@ -0,0 +1,31 @@ +{ + "template_id": "health-check-pattern-architecture", + "workflow_id": "health-check-pattern-architecture", + "title": "Health Check Pattern Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "incident", + "secondary_use_cases": [ + "security" + ], + "use_cases": [ + "incident", + "security" + ], + "complexity": 3, + "num_nodes": 19, + "num_lanes": 4, + "tags": [ + "health-check", + "load-balancer", + "self-healing", + "monitoring", + "pagerduty", + "instance-rotation", + "deep-health-check", + "architecture-diagram" + ], + "description": "A health check pattern architecture diagram with load balancer probes, deep health checks verifying database, cache, disk, and dependency status, automatic instance rotation, and alerting integration with PagerDuty for consecutive failures. This template models the health monitoring infrastructure that enables self-healing systems, where unhealthy instances are automatically removed from rotation and operations teams are alerted. Key for building production-ready services with proper observability.", + "source_path": "", + "repo_path": "incident/architecture/health-check-pattern-architecture" +} diff --git a/incident/architecture/health-check-pattern-architecture/workflow.fz b/incident/architecture/health-check-pattern-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..4a153cbda3904be5f0b0a6da9498a7bf618cdcb9 --- /dev/null +++ b/incident/architecture/health-check-pattern-architecture/workflow.fz @@ -0,0 +1,59 @@ +LoadBalancer { # Load Balancer +n1: circle label:"Health Check Timer" +n2: rectangle label:"Send Health Probe" +n17: rectangle label:"Evaluate Response" +n18: diamond label:"Instance Healthy?" +n19: rectangle label:"Keep in Rotation" +n20: rectangle label:"Remove from Rotation" +n21: rectangle label:"Update Routing Table" +n1.handle(right) -> n2.handle(left) [label="Every 10s"] +n2.handle(bottom) -> ServiceA.n3.handle(top) [label="GET /health"] +n2.handle(bottom) -> ServiceB.n10.handle(top) [label="GET /health"] +n17.handle(right) -> n18.handle(left) +n18.handle(right) -> n19.handle(left) [label="200 OK"] +n18.handle(bottom) -> n20.handle(top) [label="Timeout/5xx"] +n19.handle(right) -> n21.handle(left) +n20.handle(right) -> n21.handle(left) +n21.handle(bottom) -> Alerting.n22.handle(top) [label="Status Change"] +} +ServiceA { # Service A +n3: rectangle label:"Check Database Connection" +n4: rectangle label:"Check Redis Connection" +n5: rectangle label:"Check Disk Space" +n6: rectangle label:"Return Health Status" +n7: rectangle label:"Send Status to LB" +n8: rectangle label:"Forward Service A Status" +n9: rectangle label:"Deliver A Result" +n3.handle(right) -> n4.handle(left) [label="DB OK"] +n4.handle(right) -> n5.handle(left) [label="Cache OK"] +n5.handle(right) -> n6.handle(left) [label="Disk OK"] +n6.handle(right) -> n7.handle(left) +n7.handle(right) -> n8.handle(left) +n8.handle(right) -> n9.handle(left) +n9.handle(top) -> LoadBalancer.n17.handle(bottom) [label="Status JSON"] +} +ServiceB { # Service B +n10: rectangle label:"Check API Dependencies" +n11: rectangle label:"Check Message Queue" +n12: rectangle label:"Check Memory Usage" +n13: rectangle label:"Return Health Status" +n14: rectangle label:"Send Status to LB" +n15: rectangle label:"Forward Service B Status" +n16: rectangle label:"Deliver B Result" +n10.handle(right) -> n11.handle(left) [label="APIs OK"] +n11.handle(right) -> n12.handle(left) [label="Queue OK"] +n12.handle(right) -> n13.handle(left) [label="Disk OK"] +n13.handle(right) -> n14.handle(left) +n14.handle(right) -> n15.handle(left) +n15.handle(right) -> n16.handle(left) +n16.handle(top) -> LoadBalancer.n17.handle(bottom) [label="Status JSON"] +} +Alerting { # Alerting System +n22: rectangle label:"Monitor Health Trends" +n23: diamond label:"Consecutive Failures?" +n24: rectangle label:"Send PagerDuty Alert" +n25: rectangle label:"Log Health Metric" +n22.handle(right) -> n23.handle(left) +n23.handle(right) -> n24.handle(left) [label="3+ Failures"] +n23.handle(bottom) -> n25.handle(top) [label="Below Threshold"] +} diff --git a/incident/architecture/serverless-step-functions-orchestration-architecture/README.md b/incident/architecture/serverless-step-functions-orchestration-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..9b7bcc6ebe9fdf72cc731849047e3e24ab50965d --- /dev/null +++ b/incident/architecture/serverless-step-functions-orchestration-architecture/README.md @@ -0,0 +1,19 @@ +# Serverless Step Functions Orchestration Architecture + +An AWS Step Functions orchestration architecture diagram with state machine workflows including choice states, parallel processing, wait-for-callback patterns, and compensation rollback for failed steps. This template models serverless workflow orchestration where complex multi-step processes are defined as state machines with built-in error handling and retry logic. Critical for teams building reliable serverless workflows that require human approval or long-running processes. + +**Template ID:** `serverless-step-functions-orchestration-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** incident +**Secondary use cases:** ai-orchestration +**Complexity:** 4/5 +**Nodes:** 17 +**Lanes:** 3 +**Tags:** [step-functions, serverless-orchestration, state-machine, workflow-automation, callback-pattern, compensation, aws, architecture-diagram] +**Source path:** `` +**Repo path:** `incident/architecture/serverless-step-functions-orchestration-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/incident/architecture/serverless-step-functions-orchestration-architecture/metadata.json b/incident/architecture/serverless-step-functions-orchestration-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..a8f1b0974994bf2d16dd84583c0d7563902f873d --- /dev/null +++ b/incident/architecture/serverless-step-functions-orchestration-architecture/metadata.json @@ -0,0 +1,31 @@ +{ + "template_id": "serverless-step-functions-orchestration-architecture", + "workflow_id": "serverless-step-functions-orchestration-architecture", + "title": "Serverless Step Functions Orchestration Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "incident", + "secondary_use_cases": [ + "ai-orchestration" + ], + "use_cases": [ + "incident", + "ai-orchestration" + ], + "complexity": 4, + "num_nodes": 17, + "num_lanes": 3, + "tags": [ + "step-functions", + "serverless-orchestration", + "state-machine", + "workflow-automation", + "callback-pattern", + "compensation", + "aws", + "architecture-diagram" + ], + "description": "An AWS Step Functions orchestration architecture diagram with state machine workflows including choice states, parallel processing, wait-for-callback patterns, and compensation rollback for failed steps. This template models serverless workflow orchestration where complex multi-step processes are defined as state machines with built-in error handling and retry logic. Critical for teams building reliable serverless workflows that require human approval or long-running processes.", + "source_path": "", + "repo_path": "incident/architecture/serverless-step-functions-orchestration-architecture" +} diff --git a/incident/architecture/serverless-step-functions-orchestration-architecture/workflow.fz b/incident/architecture/serverless-step-functions-orchestration-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..17257aff1d0e957f01a3406c1ea4cd69cace3b34 --- /dev/null +++ b/incident/architecture/serverless-step-functions-orchestration-architecture/workflow.fz @@ -0,0 +1,53 @@ +Trigger { # Trigger +n1: circle label:"Start Execution" +n2: rectangle label:"API Gateway / EventBridge" +n3: rectangle label:"Invoke Step Function" +n22: rectangle label:"Receive Execution Result" +n23: circle label:"Execution Complete" +n1.handle(right) -> n2.handle(left) +n2.handle(right) -> n3.handle(left) [label="StartExecution"] +n3.handle(bottom) -> StateMachine.n4.handle(top) [label="Input JSON"] +n22.handle(right) -> n23.handle(left) +} +StateMachine { # AWS Step Functions +n4: rectangle label:"Validate Input (Task)" +n5: diamond label:"Order Type?" +n6: rectangle label:"Standard Order Path" +n7: rectangle label:"Express Order Path" +n8: rectangle label:"Parallel Processing" +n20: rectangle label:"Receive Lambda Results" +n9: rectangle label:"Wait for Approval" +n10: diamond label:"Approved?" +n11: rectangle label:"Execute Final Step" +n12: rectangle label:"Compensation Rollback" +n13: rectangle label:"Report to Trigger" +n21: rectangle label:"Send Execution Result" +n4.handle(right) -> n5.handle(left) +n5.handle(right) -> n6.handle(left) [label="Standard"] +n5.handle(bottom) -> n7.handle(top) [label="Express"] +n6.handle(right) -> n8.handle(left) +n7.handle(right) -> n8.handle(left) +n8.handle(bottom) -> Lambdas.n14.handle(top) [label="Invoke"] +n20.handle(right) -> n9.handle(left) [label="Map State"] +n9.handle(right) -> n10.handle(left) [label="Callback"] +n10.handle(right) -> n11.handle(left) [label="Yes"] +n10.handle(bottom) -> n12.handle(top) [label="No"] +n11.handle(right) -> n13.handle(left) +n12.handle(right) -> n13.handle(left) [label="Rolled Back"] +n13.handle(right) -> n21.handle(left) +n21.handle(top) -> Trigger.n22.handle(bottom) [label="Result"] +} +Lambdas { # Lambda Functions +n14: rectangle label:"Payment Lambda" +n15: rectangle label:"Inventory Lambda" +n16: rectangle label:"Notification Lambda" +n17: rectangle label:"Error Catcher Lambda" +n18: rectangle label:"Collect Lambda Results" +n19: rectangle label:"Return to State Machine" +n14.handle(right) -> n15.handle(left) [label="Charge"] +n15.handle(right) -> n16.handle(left) [label="Reserve"] +n16.handle(right) -> n17.handle(left) +n17.handle(right) -> n18.handle(left) +n18.handle(right) -> n19.handle(left) +n19.handle(top) -> StateMachine.n20.handle(bottom) [label="Lambda Results"] +} diff --git a/incident/devops/deployment-rollback-workflow/README.md b/incident/devops/deployment-rollback-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..1159e8de569f58b87d7b19eb4c07be18b622e284 --- /dev/null +++ b/incident/devops/deployment-rollback-workflow/README.md @@ -0,0 +1,19 @@ +# Deployment Rollback Workflow + +Deployment rollback workflow with issue detection, rollback decision, previous version restoration, health verification, and post-mortem documentation. + +**Template ID:** `deployment-rollback-workflow` +**Kind:** workflow +**Source domain:** devops +**Primary use case:** incident +**Secondary use cases:** delivery +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [deployment-rollback, version-revert, incident-response, kubernetes, helm-rollback, service-recovery] +**Source path:** `devops/deployment-rollback` +**Repo path:** `incident/devops/deployment-rollback-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/incident/devops/deployment-rollback-workflow/metadata.json b/incident/devops/deployment-rollback-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..a758241dcda5989c4e10fe5207e700562218f503 --- /dev/null +++ b/incident/devops/deployment-rollback-workflow/metadata.json @@ -0,0 +1,29 @@ +{ + "template_id": "deployment-rollback-workflow", + "workflow_id": "deployment-rollback", + "title": "Deployment Rollback Workflow", + "kind": "workflow", + "source_domain": "devops", + "primary_use_case": "incident", + "secondary_use_cases": [ + "delivery" + ], + "use_cases": [ + "incident", + "delivery" + ], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "deployment-rollback", + "version-revert", + "incident-response", + "kubernetes", + "helm-rollback", + "service-recovery" + ], + "description": "Deployment rollback workflow with issue detection, rollback decision, previous version restoration, health verification, and post-mortem documentation.", + "source_path": "devops/deployment-rollback", + "repo_path": "incident/devops/deployment-rollback-workflow" +} diff --git a/devops/deployment-rollback/workflow.fz b/incident/devops/deployment-rollback-workflow/workflow.fz similarity index 100% rename from devops/deployment-rollback/workflow.fz rename to incident/devops/deployment-rollback-workflow/workflow.fz diff --git a/incident/devops/incident-response-workflow/README.md b/incident/devops/incident-response-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..ed340e23f27537e6fbdffa14ae60ce16acd58848 --- /dev/null +++ b/incident/devops/incident-response-workflow/README.md @@ -0,0 +1,19 @@ +# Incident Response Workflow + +Production incident response workflow with severity-based routing, war room coordination, incident commander assignment, customer communication, root cause analysis, and postmortem scheduling. + +**Template ID:** `incident-response-workflow` +**Kind:** workflow +**Source domain:** devops +**Primary use case:** incident +**Secondary use cases:** None +**Complexity:** 5/5 +**Nodes:** 23 +**Lanes:** 4 +**Tags:** [incident-management, on-call, pagerduty, war-room, severity-levels, postmortem, sre] +**Source path:** `devops/incident-response` +**Repo path:** `incident/devops/incident-response-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/devops/incident-response/metadata.json b/incident/devops/incident-response-workflow/metadata.json similarity index 54% rename from devops/incident-response/metadata.json rename to incident/devops/incident-response-workflow/metadata.json index ba454e6ef5874ef0e7b2d3ef98db49574693f2df..edbfac73cf4f5d1ec607e2c4ce63e8f652df639a 100644 --- a/devops/incident-response/metadata.json +++ b/incident/devops/incident-response-workflow/metadata.json @@ -1,6 +1,14 @@ { + "template_id": "incident-response-workflow", "workflow_id": "incident-response", - "domain": "devops", + "title": "Incident Response Workflow", + "kind": "workflow", + "source_domain": "devops", + "primary_use_case": "incident", + "secondary_use_cases": [], + "use_cases": [ + "incident" + ], "complexity": 5, "num_nodes": 23, "num_lanes": 4, @@ -13,5 +21,7 @@ "postmortem", "sre" ], - "description": "Production incident response workflow with severity-based routing, war room coordination, incident commander assignment, customer communication, root cause analysis, and postmortem scheduling." -} \ No newline at end of file + "description": "Production incident response workflow with severity-based routing, war room coordination, incident commander assignment, customer communication, root cause analysis, and postmortem scheduling.", + "source_path": "devops/incident-response", + "repo_path": "incident/devops/incident-response-workflow" +} diff --git a/devops/incident-response/workflow.fz b/incident/devops/incident-response-workflow/workflow.fz similarity index 100% rename from devops/incident-response/workflow.fz rename to incident/devops/incident-response-workflow/workflow.fz diff --git a/incident/devops/monitoring-alert-workflow/README.md b/incident/devops/monitoring-alert-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..b8cb1a84189cfb08e9e40db4baeb7fa0c303ed64 --- /dev/null +++ b/incident/devops/monitoring-alert-workflow/README.md @@ -0,0 +1,19 @@ +# Monitoring Alert Workflow + +Monitoring and alerting workflow with metric collection, threshold evaluation, alert routing, escalation policies, and incident creation. + +**Template ID:** `monitoring-alert-workflow` +**Kind:** workflow +**Source domain:** devops +**Primary use case:** incident +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [monitoring-alerting, prometheus, pagerduty, threshold-alerts, anomaly-detection, on-call] +**Source path:** `devops/monitoring-alert` +**Repo path:** `incident/devops/monitoring-alert-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/incident/devops/monitoring-alert-workflow/metadata.json b/incident/devops/monitoring-alert-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..29cf6ebe581c8a7715f650cc74a9799a2395fc4b --- /dev/null +++ b/incident/devops/monitoring-alert-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "monitoring-alert-workflow", + "workflow_id": "monitoring-alert", + "title": "Monitoring Alert Workflow", + "kind": "workflow", + "source_domain": "devops", + "primary_use_case": "incident", + "secondary_use_cases": [], + "use_cases": [ + "incident" + ], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "monitoring-alerting", + "prometheus", + "pagerduty", + "threshold-alerts", + "anomaly-detection", + "on-call" + ], + "description": "Monitoring and alerting workflow with metric collection, threshold evaluation, alert routing, escalation policies, and incident creation.", + "source_path": "devops/monitoring-alert", + "repo_path": "incident/devops/monitoring-alert-workflow" +} diff --git a/devops/monitoring-alert/workflow.fz b/incident/devops/monitoring-alert-workflow/workflow.fz similarity index 100% rename from devops/monitoring-alert/workflow.fz rename to incident/devops/monitoring-alert-workflow/workflow.fz diff --git a/incident/logistics/cold-chain-monitoring-workflow/README.md b/incident/logistics/cold-chain-monitoring-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..486b46da679551d14d0c142867cd6cb0edbd67ca --- /dev/null +++ b/incident/logistics/cold-chain-monitoring-workflow/README.md @@ -0,0 +1,19 @@ +# Cold Chain Monitoring Workflow + +Cold chain monitoring workflow with IoT temperature sensors, real-time alerts, excursion documentation, corrective action triggers, and compliance reporting. + +**Template ID:** `cold-chain-monitoring-workflow` +**Kind:** workflow +**Source domain:** logistics +**Primary use case:** incident +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [cold-chain, temperature-monitoring, iot-sensors, excursion-alert, pharmaceutical, perishables] +**Source path:** `logistics/cold-chain-monitoring` +**Repo path:** `incident/logistics/cold-chain-monitoring-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/incident/logistics/cold-chain-monitoring-workflow/metadata.json b/incident/logistics/cold-chain-monitoring-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..e1ed2fdbd240a431911602b8c50ca9b7b04484b9 --- /dev/null +++ b/incident/logistics/cold-chain-monitoring-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "cold-chain-monitoring-workflow", + "workflow_id": "cold-chain-monitoring", + "title": "Cold Chain Monitoring Workflow", + "kind": "workflow", + "source_domain": "logistics", + "primary_use_case": "incident", + "secondary_use_cases": [], + "use_cases": [ + "incident" + ], + "complexity": 3, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "cold-chain", + "temperature-monitoring", + "iot-sensors", + "excursion-alert", + "pharmaceutical", + "perishables" + ], + "description": "Cold chain monitoring workflow with IoT temperature sensors, real-time alerts, excursion documentation, corrective action triggers, and compliance reporting.", + "source_path": "logistics/cold-chain-monitoring", + "repo_path": "incident/logistics/cold-chain-monitoring-workflow" +} diff --git a/logistics/cold-chain-monitoring/workflow.fz b/incident/logistics/cold-chain-monitoring-workflow/workflow.fz similarity index 100% rename from logistics/cold-chain-monitoring/workflow.fz rename to incident/logistics/cold-chain-monitoring-workflow/workflow.fz diff --git a/incident/logistics/hazmat-handling-workflow/README.md b/incident/logistics/hazmat-handling-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..941028133045335fd90e34b4277b251df2d521a3 --- /dev/null +++ b/incident/logistics/hazmat-handling-workflow/README.md @@ -0,0 +1,19 @@ +# Hazmat Handling Workflow + +Hazardous materials handling workflow with UN classification, SDS documentation, proper labeling, certified handler assignment, and emergency response procedures. + +**Template ID:** `hazmat-handling-workflow` +**Kind:** workflow +**Source domain:** logistics +**Primary use case:** incident +**Secondary use cases:** compliance +**Complexity:** 4/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [hazmat-handling, dangerous-goods, un-classification, sds-documentation, dot-compliance, emergency-response] +**Source path:** `logistics/hazmat-handling` +**Repo path:** `incident/logistics/hazmat-handling-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/incident/logistics/hazmat-handling-workflow/metadata.json b/incident/logistics/hazmat-handling-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..520cadbd0cb9cc4e75c1e6648a7192e8ab30d27f --- /dev/null +++ b/incident/logistics/hazmat-handling-workflow/metadata.json @@ -0,0 +1,29 @@ +{ + "template_id": "hazmat-handling-workflow", + "workflow_id": "hazmat-handling", + "title": "Hazmat Handling Workflow", + "kind": "workflow", + "source_domain": "logistics", + "primary_use_case": "incident", + "secondary_use_cases": [ + "compliance" + ], + "use_cases": [ + "incident", + "compliance" + ], + "complexity": 4, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "hazmat-handling", + "dangerous-goods", + "un-classification", + "sds-documentation", + "dot-compliance", + "emergency-response" + ], + "description": "Hazardous materials handling workflow with UN classification, SDS documentation, proper labeling, certified handler assignment, and emergency response procedures.", + "source_path": "logistics/hazmat-handling", + "repo_path": "incident/logistics/hazmat-handling-workflow" +} diff --git a/logistics/hazmat-handling/workflow.fz b/incident/logistics/hazmat-handling-workflow/workflow.fz similarity index 100% rename from logistics/hazmat-handling/workflow.fz rename to incident/logistics/hazmat-handling-workflow/workflow.fz diff --git a/incident/patterns/canary-deploy-workflow/README.md b/incident/patterns/canary-deploy-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..3317953ebc61cea6f50c91d691433e74eec2370c --- /dev/null +++ b/incident/patterns/canary-deploy-workflow/README.md @@ -0,0 +1,19 @@ +# Canary Deploy Workflow + +Canary deployment pattern with gradual traffic shifting, real-time metrics monitoring, automatic rollback triggers, and progressive rollout to full production. + +**Template ID:** `canary-deploy-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** incident +**Secondary use cases:** delivery +**Complexity:** 3/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [canary-deployment, progressive-rollout, traffic-splitting, metrics-monitoring, gradual-release, feature-flags] +**Source path:** `patterns/canary-deploy` +**Repo path:** `incident/patterns/canary-deploy-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/incident/patterns/canary-deploy-workflow/metadata.json b/incident/patterns/canary-deploy-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..1660f1eac083384a055065e425ff5a490fb6415e --- /dev/null +++ b/incident/patterns/canary-deploy-workflow/metadata.json @@ -0,0 +1,29 @@ +{ + "template_id": "canary-deploy-workflow", + "workflow_id": "canary-deploy", + "title": "Canary Deploy Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "incident", + "secondary_use_cases": [ + "delivery" + ], + "use_cases": [ + "incident", + "delivery" + ], + "complexity": 3, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "canary-deployment", + "progressive-rollout", + "traffic-splitting", + "metrics-monitoring", + "gradual-release", + "feature-flags" + ], + "description": "Canary deployment pattern with gradual traffic shifting, real-time metrics monitoring, automatic rollback triggers, and progressive rollout to full production.", + "source_path": "patterns/canary-deploy", + "repo_path": "incident/patterns/canary-deploy-workflow" +} diff --git a/patterns/canary-deploy/workflow.fz b/incident/patterns/canary-deploy-workflow/workflow.fz similarity index 100% rename from patterns/canary-deploy/workflow.fz rename to incident/patterns/canary-deploy-workflow/workflow.fz diff --git a/logistics/carrier-selection/README.md b/logistics/carrier-selection/README.md deleted file mode 100644 index c9f1cbf08ebb622f47d2c4330c8fa20cfd6dd48d..0000000000000000000000000000000000000000 --- a/logistics/carrier-selection/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Carrier Selection - -Carrier selection workflow with rate shopping, transit time comparison, service level matching, carrier performance scoring, and optimal carrier assignment. - -**Domain:** logistics -**Complexity:** 3/5 -**Tags:** [carrier-selection, rate-shopping, transit-time, service-level, tms, freight-optimization] - -## Lanes -- **Order System** - Provides shipment requirements -- **TMS** - Shops rates, selects carrier -- **Carrier Network** - Provides rates and capacity - -## Process Flow -1. Receive shipment requirements (weight, dimensions, destination) -2. Determine required service level (ground, express, freight) -3. Query carrier network for rates -4. Compare transit times vs delivery requirement -5. Factor in carrier performance scores -6. Apply business rules (preferred carriers, contracts) -7. Select optimal carrier -8. Book shipment with carrier -9. Generate shipping documents diff --git a/logistics/carrier-selection/metadata.json b/logistics/carrier-selection/metadata.json deleted file mode 100644 index a3ddaa9c91c9df24319f57ab0f5b05e319953e9d..0000000000000000000000000000000000000000 --- a/logistics/carrier-selection/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "carrier-selection", - "domain": "logistics", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "carrier-selection", - "rate-shopping", - "transit-time", - "service-level", - "tms", - "freight-optimization" - ], - "description": "Carrier selection workflow with rate shopping, transit time comparison, service level matching, carrier performance scoring, and optimal carrier assignment." -} \ No newline at end of file diff --git a/logistics/cold-chain-monitoring/README.md b/logistics/cold-chain-monitoring/README.md deleted file mode 100644 index c843ae3969644e191f115a68b3c562e9aa1001c6..0000000000000000000000000000000000000000 --- a/logistics/cold-chain-monitoring/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# Cold Chain Monitoring - -Cold chain monitoring workflow with IoT temperature sensors, real-time alerts, excursion documentation, corrective action triggers, and compliance reporting. - -**Domain:** logistics -**Complexity:** 3/5 -**Tags:** [cold-chain, temperature-monitoring, iot-sensors, excursion-alert, pharmaceutical, perishables] - -## Lanes -- **IoT Sensors** - Monitors temperature, sends data -- **Monitoring System** - Analyzes data, triggers alerts - -## Process Flow -1. Attach IoT temperature sensor to shipment -2. Configure temperature thresholds -3. Monitor temperature continuously -4. Detect temperature excursion -5. Send immediate alert to stakeholders -6. Document excursion details -7. Assess product impact -8. Trigger corrective action if needed -9. Generate compliance report diff --git a/logistics/cold-chain-monitoring/metadata.json b/logistics/cold-chain-monitoring/metadata.json deleted file mode 100644 index a35b1030621d447abb1e3d4715b22a75b27f7cea..0000000000000000000000000000000000000000 --- a/logistics/cold-chain-monitoring/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "cold-chain-monitoring", - "domain": "logistics", - "complexity": 3, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "cold-chain", - "temperature-monitoring", - "iot-sensors", - "excursion-alert", - "pharmaceutical", - "perishables" - ], - "description": "Cold chain monitoring workflow with IoT temperature sensors, real-time alerts, excursion documentation, corrective action triggers, and compliance reporting." -} \ No newline at end of file diff --git a/logistics/container-loading/README.md b/logistics/container-loading/README.md deleted file mode 100644 index 2fb58f23bb54605e7ea18491f3697cc3f0ad8048..0000000000000000000000000000000000000000 --- a/logistics/container-loading/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# Container Loading - -Container loading workflow with load plan optimization, weight distribution, cube utilization maximization, seal application, and bill of lading generation. - -**Domain:** logistics -**Complexity:** 3/5 -**Tags:** [container-loading, load-planning, weight-distribution, cube-utilization, seal-verification, ocean-freight] - -## Lanes -- **Load Planner** - Creates load plan, optimizes space -- **Loading Crew** - Executes loading, applies seal - -## Process Flow -1. Generate container load plan -2. Optimize for weight distribution -3. Maximize cube utilization -4. Stage cargo at loading dock -5. Load cargo per plan sequence -6. Verify weight limits not exceeded -7. Secure cargo with dunnage -8. Apply container seal -9. Generate bill of lading diff --git a/logistics/container-loading/metadata.json b/logistics/container-loading/metadata.json deleted file mode 100644 index 10eaf3d4cfed0d70d7a5d2eef36da2986d88612a..0000000000000000000000000000000000000000 --- a/logistics/container-loading/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "container-loading", - "domain": "logistics", - "complexity": 3, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "container-loading", - "load-planning", - "weight-distribution", - "cube-utilization", - "seal-verification", - "ocean-freight" - ], - "description": "Container loading workflow with load plan optimization, weight distribution, cube utilization maximization, seal application, and bill of lading generation." -} \ No newline at end of file diff --git a/logistics/cross-docking/README.md b/logistics/cross-docking/README.md deleted file mode 100644 index 20d5b62fd9835f406f876f056379b9c01ea69d28..0000000000000000000000000000000000000000 --- a/logistics/cross-docking/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Cross Docking - -Cross-docking workflow with inbound scheduling, sortation by destination, outbound consolidation, and direct transfer without storage for just-in-time delivery. - -**Domain:** logistics -**Complexity:** 3/5 -**Tags:** [cross-docking, flow-through, dock-scheduling, sortation, consolidation, just-in-time] - -## Lanes -- **Inbound Dock** - Receives and unloads shipments -- **Sortation** - Sorts by destination, stages for outbound -- **Outbound Dock** - Consolidates and loads for delivery - -## Process Flow -1. Schedule inbound arrival at dock door -2. Unload inbound shipment -3. Scan and verify contents -4. Sort items by outbound destination -5. Move to outbound staging area -6. Consolidate with other items for same destination -7. Load onto outbound vehicle -8. Dispatch for delivery -9. Update tracking for all items diff --git a/logistics/cross-docking/metadata.json b/logistics/cross-docking/metadata.json deleted file mode 100644 index 03b197eab72dda41641ec9257f3f194c539d762d..0000000000000000000000000000000000000000 --- a/logistics/cross-docking/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "cross-docking", - "domain": "logistics", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "cross-docking", - "flow-through", - "dock-scheduling", - "sortation", - "consolidation", - "just-in-time" - ], - "description": "Cross-docking workflow with inbound scheduling, sortation by destination, outbound consolidation, and direct transfer without storage for just-in-time delivery." -} \ No newline at end of file diff --git a/logistics/customs-clearance/README.md b/logistics/customs-clearance/README.md deleted file mode 100644 index 606c8f13a4639bdcd311bbfe44ca3ee8f565208a..0000000000000000000000000000000000000000 --- a/logistics/customs-clearance/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Customs Clearance - -International customs clearance workflow with importer documentation, customs broker HS code classification, duty calculation, customs authority inspection, and clearance certificate issuance. - -**Domain:** logistics -**Complexity:** 4/5 -**Tags:** [customs-clearance, international-trade, customs-broker, hs-codes, import-export, duties-taxes, inspection] - -## Lanes -- **Importer** - Submits shipment details and commercial invoices -- **Customs Broker** - Reviews docs, classifies HS codes, files entry -- **Customs Authority** - Inspects shipment, issues clearance certificate - -## Process Flow -1. Importer submits shipment details and commercial invoice -2. Customs broker reviews documentation for completeness -3. Classify goods using HS (Harmonized System) codes -4. Calculate applicable duties and taxes -5. File customs entry with authorities -6. Customs determines if physical inspection required -7. Conduct inspection or document review only -8. Decision: cleared or held for investigation -9. Release shipment and issue clearance certificate diff --git a/logistics/cycle-counting/README.md b/logistics/cycle-counting/README.md deleted file mode 100644 index dcc7696150422adc0e40dad62d0dcad913dcd147..0000000000000000000000000000000000000000 --- a/logistics/cycle-counting/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Cycle Counting - -Inventory cycle counting workflow with ABC classification, count scheduling, variance investigation, adjustment approval, and inventory accuracy tracking. - -**Domain:** logistics -**Complexity:** 3/5 -**Tags:** [cycle-counting, inventory-accuracy, abc-analysis, variance-investigation, perpetual-inventory, audit] - -## Lanes -- **WMS System** - Schedules counts, tracks accuracy -- **Counter** - Performs physical counts -- **Supervisor** - Investigates variances, approves adjustments - -## Process Flow -1. Generate cycle count schedule based on ABC class -2. Assign locations to counters -3. Freeze location for counting -4. Perform physical count -5. Compare to system quantity -6. If variance, perform recount -7. Investigate significant variances -8. Approve inventory adjustment -9. Update inventory accuracy metrics diff --git a/logistics/cycle-counting/metadata.json b/logistics/cycle-counting/metadata.json deleted file mode 100644 index 6e4212226263d03962f192e9882af53080bae40f..0000000000000000000000000000000000000000 --- a/logistics/cycle-counting/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "cycle-counting", - "domain": "logistics", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "cycle-counting", - "inventory-accuracy", - "abc-analysis", - "variance-investigation", - "perpetual-inventory", - "audit" - ], - "description": "Inventory cycle counting workflow with ABC classification, count scheduling, variance investigation, adjustment approval, and inventory accuracy tracking." -} \ No newline at end of file diff --git a/logistics/damaged-goods/README.md b/logistics/damaged-goods/README.md deleted file mode 100644 index db80a7427030d24cb4eb7a88425a3491ca0f6ce9..0000000000000000000000000000000000000000 --- a/logistics/damaged-goods/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# Damaged Goods - -Damaged goods processing workflow with damage documentation, carrier claim filing, disposition decision (salvage/dispose), inventory adjustment, and loss tracking. - -**Domain:** logistics -**Complexity:** 3/5 -**Tags:** [damaged-goods, damage-claim, inventory-write-off, carrier-claim, disposition, loss-prevention] - -## Lanes -- **Warehouse** - Identifies damage, documents, disposes -- **Claims/Finance** - Files carrier claims, tracks losses - -## Process Flow -1. Identify damaged goods during receiving or handling -2. Document damage with photos and description -3. Determine cause of damage (carrier, handling, vendor) -4. File carrier claim if transit damage -5. Assess salvage value -6. Decide disposition (salvage, donate, dispose) -7. Adjust inventory for write-off -8. Track loss for reporting -9. Update loss prevention metrics diff --git a/logistics/damaged-goods/metadata.json b/logistics/damaged-goods/metadata.json deleted file mode 100644 index ee829a338f038a8c0d32a4ff1119395622598da6..0000000000000000000000000000000000000000 --- a/logistics/damaged-goods/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "damaged-goods", - "domain": "logistics", - "complexity": 3, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "damaged-goods", - "damage-claim", - "inventory-write-off", - "carrier-claim", - "disposition", - "loss-prevention" - ], - "description": "Damaged goods processing workflow with damage documentation, carrier claim filing, disposition decision (salvage/dispose), inventory adjustment, and loss tracking." -} \ No newline at end of file diff --git a/logistics/delivery-confirmation/README.md b/logistics/delivery-confirmation/README.md deleted file mode 100644 index 98a40852211d54e1f49e628049fed72d18780b17..0000000000000000000000000000000000000000 --- a/logistics/delivery-confirmation/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# Delivery Confirmation - -Delivery confirmation workflow with proof of delivery capture, signature collection, photo documentation, order status update, and customer notification. - -**Domain:** logistics -**Complexity:** 2/5 -**Tags:** [delivery-confirmation, pod, signature-capture, order-completion, customer-notification, tracking-update] - -## Lanes -- **Driver/Carrier** - Delivers package, captures POD -- **Order System** - Updates status, notifies customer - -## Process Flow -1. Arrive at delivery location -2. Verify recipient or safe location -3. Capture signature on mobile device -4. Take photo of delivered package -5. Record GPS coordinates and timestamp -6. Upload proof of delivery -7. Update order status to delivered -8. Send delivery confirmation to customer -9. Close delivery task diff --git a/logistics/delivery-confirmation/metadata.json b/logistics/delivery-confirmation/metadata.json deleted file mode 100644 index 7d55356448270d6efd2aa3ef4d2cc93befd69d9a..0000000000000000000000000000000000000000 --- a/logistics/delivery-confirmation/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "delivery-confirmation", - "domain": "logistics", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "delivery-confirmation", - "pod", - "signature-capture", - "order-completion", - "customer-notification", - "tracking-update" - ], - "description": "Delivery confirmation workflow with proof of delivery capture, signature collection, photo documentation, order status update, and customer notification." -} \ No newline at end of file diff --git a/logistics/fleet-maintenance/README.md b/logistics/fleet-maintenance/README.md deleted file mode 100644 index ed82bdb7bd5b79957083d39f89f775267dbd23da..0000000000000000000000000000000000000000 --- a/logistics/fleet-maintenance/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# Fleet Maintenance - -Fleet maintenance workflow with preventive maintenance scheduling, vehicle inspection, work order creation, parts ordering, and DOT compliance tracking. - -**Domain:** logistics -**Complexity:** 3/5 -**Tags:** [fleet-maintenance, preventive-maintenance, vehicle-inspection, work-order, dot-compliance, telematics] - -## Lanes -- **Fleet System** - Schedules maintenance, tracks compliance -- **Maintenance Shop** - Performs inspections and repairs - -## Process Flow -1. Monitor vehicle mileage and service intervals -2. Generate preventive maintenance alert -3. Schedule vehicle for service -4. Perform pre-service inspection -5. Create work order for required repairs -6. Order parts if needed -7. Complete maintenance work -8. Update service records -9. Return vehicle to active fleet diff --git a/logistics/fleet-maintenance/metadata.json b/logistics/fleet-maintenance/metadata.json deleted file mode 100644 index 0d7771b31dccddd799fccbb862d2f774aee8137b..0000000000000000000000000000000000000000 --- a/logistics/fleet-maintenance/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "fleet-maintenance", - "domain": "logistics", - "complexity": 3, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "fleet-maintenance", - "preventive-maintenance", - "vehicle-inspection", - "work-order", - "dot-compliance", - "telematics" - ], - "description": "Fleet maintenance workflow with preventive maintenance scheduling, vehicle inspection, work order creation, parts ordering, and DOT compliance tracking." -} \ No newline at end of file diff --git a/logistics/hazmat-handling/README.md b/logistics/hazmat-handling/README.md deleted file mode 100644 index 866534f13dc718e0794e5b6ecee6a08af8d99289..0000000000000000000000000000000000000000 --- a/logistics/hazmat-handling/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Hazmat Handling - -Hazardous materials handling workflow with UN classification, SDS documentation, proper labeling, certified handler assignment, and emergency response procedures. - -**Domain:** logistics -**Complexity:** 4/5 -**Tags:** [hazmat-handling, dangerous-goods, un-classification, sds-documentation, dot-compliance, emergency-response] - -## Lanes -- **Receiving** - Identifies hazmat, verifies documentation -- **Safety/Compliance** - Validates classification, ensures compliance -- **Certified Handler** - Handles, stores, and ships hazmat - -## Process Flow -1. Identify hazardous material by UN number -2. Verify Safety Data Sheet (SDS) available -3. Confirm proper DOT classification -4. Assign certified hazmat handler -5. Verify proper PPE and equipment -6. Apply required labels and placards -7. Store in designated hazmat area -8. Document chain of custody -9. Prepare emergency response info for shipping diff --git a/logistics/hazmat-handling/metadata.json b/logistics/hazmat-handling/metadata.json deleted file mode 100644 index f79cfba7e27d4196aa7f51238e023a051c3bdfae..0000000000000000000000000000000000000000 --- a/logistics/hazmat-handling/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "hazmat-handling", - "domain": "logistics", - "complexity": 4, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "hazmat-handling", - "dangerous-goods", - "un-classification", - "sds-documentation", - "dot-compliance", - "emergency-response" - ], - "description": "Hazardous materials handling workflow with UN classification, SDS documentation, proper labeling, certified handler assignment, and emergency response procedures." -} \ No newline at end of file diff --git a/logistics/inventory-receipt/README.md b/logistics/inventory-receipt/README.md deleted file mode 100644 index 16223a4822b55f615b176dd7bb367b7e294ea4d4..0000000000000000000000000000000000000000 --- a/logistics/inventory-receipt/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# Inventory Receipt - -Inventory receiving workflow with ASN verification, PO matching, quantity count, damage inspection, and WMS inventory update. - -**Domain:** logistics -**Complexity:** 3/5 -**Tags:** [inventory-receipt, goods-receiving, po-matching, asn-verification, dock-scheduling, wms] - -## Lanes -- **Receiving Dock** - Unloads shipments, counts items -- **WMS System** - Matches to PO, updates inventory - -## Process Flow -1. Receive advance shipping notice (ASN) -2. Schedule dock door and unload time -3. Unload shipment at receiving dock -4. Verify against ASN and purchase order -5. Count items and check for damage -6. Report discrepancies if any -7. Label items with location barcodes -8. Update WMS with received quantities -9. Stage for put-away diff --git a/logistics/inventory-receipt/metadata.json b/logistics/inventory-receipt/metadata.json deleted file mode 100644 index d79dc5a888f5e4c3339fb5c7c4605f1cedf35e7b..0000000000000000000000000000000000000000 --- a/logistics/inventory-receipt/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "inventory-receipt", - "domain": "logistics", - "complexity": 3, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "inventory-receipt", - "goods-receiving", - "po-matching", - "asn-verification", - "dock-scheduling", - "wms" - ], - "description": "Inventory receiving workflow with ASN verification, PO matching, quantity count, damage inspection, and WMS inventory update." -} \ No newline at end of file diff --git a/logistics/kitting-process/README.md b/logistics/kitting-process/README.md deleted file mode 100644 index 7609bcbd5510c3f4969aa11ed1d9e4d742d7527a..0000000000000000000000000000000000000000 --- a/logistics/kitting-process/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# Kitting Process - -Kit assembly workflow with BOM explosion, component picking, assembly verification, kit labeling, and inventory conversion from components to finished kit. - -**Domain:** logistics -**Complexity:** 2/5 -**Tags:** [kitting-process, kit-assembly, bom, component-picking, value-added-services, bundling] - -## Lanes -- **WMS System** - Explodes BOM, generates pick list -- **Kitting Station** - Assembles kit, verifies components - -## Process Flow -1. Receive kit assembly order -2. Explode bill of materials (BOM) -3. Generate component pick list -4. Pick all required components -5. Deliver components to kitting station -6. Assemble kit per instructions -7. Verify all components present -8. Apply kit label and barcode -9. Convert inventory to finished kit SKU diff --git a/logistics/kitting-process/metadata.json b/logistics/kitting-process/metadata.json deleted file mode 100644 index d6689b7906a62f3bca448a2bdba7efb0f2f1b48b..0000000000000000000000000000000000000000 --- a/logistics/kitting-process/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "kitting-process", - "domain": "logistics", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "kitting-process", - "kit-assembly", - "bom", - "component-picking", - "value-added-services", - "bundling" - ], - "description": "Kit assembly workflow with BOM explosion, component picking, assembly verification, kit labeling, and inventory conversion from components to finished kit." -} \ No newline at end of file diff --git a/logistics/last-mile-delivery/README.md b/logistics/last-mile-delivery/README.md deleted file mode 100644 index a4af7040630ac28df2cb736d8eab0b0f776aac0d..0000000000000000000000000000000000000000 --- a/logistics/last-mile-delivery/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# Last Mile Delivery - -Last mile delivery workflow with route optimization, real-time GPS tracking, delivery attempt handling, proof of delivery capture, and customer notification. - -**Domain:** logistics -**Complexity:** 3/5 -**Tags:** [last-mile-delivery, route-optimization, proof-of-delivery, delivery-exception, customer-notification, gps-tracking] - -## Lanes -- **Dispatch System** - Optimizes routes, tracks drivers -- **Driver** - Executes deliveries, captures POD - -## Process Flow -1. Load packages onto delivery vehicle -2. Generate optimized delivery route -3. Send customer delivery window notification -4. Navigate to delivery address -5. Attempt delivery -6. If customer unavailable, handle exception -7. Capture proof of delivery (signature/photo) -8. Update delivery status in real-time -9. Complete route and return to depot diff --git a/logistics/last-mile-delivery/metadata.json b/logistics/last-mile-delivery/metadata.json deleted file mode 100644 index e33624d64cf40ad013de407574e2f6152a80903b..0000000000000000000000000000000000000000 --- a/logistics/last-mile-delivery/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "last-mile-delivery", - "domain": "logistics", - "complexity": 3, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "last-mile-delivery", - "route-optimization", - "proof-of-delivery", - "delivery-exception", - "customer-notification", - "gps-tracking" - ], - "description": "Last mile delivery workflow with route optimization, real-time GPS tracking, delivery attempt handling, proof of delivery capture, and customer notification." -} \ No newline at end of file diff --git a/logistics/packing-process/README.md b/logistics/packing-process/README.md deleted file mode 100644 index d245d4a0ec2ee31b1926d26f130214744b4f8418..0000000000000000000000000000000000000000 --- a/logistics/packing-process/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# Packing Process - -Order packing workflow with carton selection, item verification, packing slip insertion, weight check, and package sealing for shipment. - -**Domain:** logistics -**Complexity:** 2/5 -**Tags:** [order-packing, box-selection, packing-slip, weight-verification, cartonization, fulfillment] - -## Lanes -- **Packer** - Selects box, packs items, seals package -- **System** - Verifies contents, prints packing slip - -## Process Flow -1. Receive picked items at packing station -2. Scan order to retrieve packing instructions -3. Select appropriate box size -4. Verify all items present -5. Add packing materials for protection -6. Insert packing slip -7. Seal package -8. Weigh package and verify -9. Move to shipping staging area diff --git a/logistics/packing-process/metadata.json b/logistics/packing-process/metadata.json deleted file mode 100644 index 1c10c4a51a3e60d900c947a9f0d5fd3bf4244cae..0000000000000000000000000000000000000000 --- a/logistics/packing-process/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "packing-process", - "domain": "logistics", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "order-packing", - "box-selection", - "packing-slip", - "weight-verification", - "cartonization", - "fulfillment" - ], - "description": "Order packing workflow with carton selection, item verification, packing slip insertion, weight check, and package sealing for shipment." -} \ No newline at end of file diff --git a/logistics/picking-process/README.md b/logistics/picking-process/README.md deleted file mode 100644 index d72df2b215f60ede9b9966cb7f6333043a6123ca..0000000000000000000000000000000000000000 --- a/logistics/picking-process/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Picking Process - -Warehouse order picking workflow with pick list generation, zone routing, batch picking optimization, barcode scanning verification, and pick completion confirmation. - -**Domain:** logistics -**Complexity:** 3/5 -**Tags:** [order-picking, warehouse-management, pick-list, batch-picking, wave-picking, wms] - -## Lanes -- **WMS System** - Generates pick lists, optimizes routes -- **Picker** - Navigates warehouse, picks items -- **Quality Check** - Verifies picks, resolves discrepancies - -## Process Flow -1. Receive orders for picking wave -2. Generate optimized pick list -3. Route picker through warehouse zones -4. Navigate to pick location -5. Scan location barcode to verify -6. Pick item and scan product barcode -7. Confirm quantity picked -8. Handle stock-outs or discrepancies -9. Complete pick and stage for packing diff --git a/logistics/picking-process/metadata.json b/logistics/picking-process/metadata.json deleted file mode 100644 index ab24f0ed077c0d80aebe864ee9bfcea60b8ae713..0000000000000000000000000000000000000000 --- a/logistics/picking-process/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "picking-process", - "domain": "logistics", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "order-picking", - "warehouse-management", - "pick-list", - "batch-picking", - "wave-picking", - "wms" - ], - "description": "Warehouse order picking workflow with pick list generation, zone routing, batch picking optimization, barcode scanning verification, and pick completion confirmation." -} \ No newline at end of file diff --git a/logistics/put-away-process/README.md b/logistics/put-away-process/README.md deleted file mode 100644 index 9bb1706e19ac939f26a60fb2ac9c1a746423d429..0000000000000000000000000000000000000000 --- a/logistics/put-away-process/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# Put Away Process - -Warehouse put-away workflow with location assignment, slotting optimization, forklift routing, barcode confirmation, and WMS location update. - -**Domain:** logistics -**Complexity:** 2/5 -**Tags:** [put-away, warehouse-storage, location-assignment, slotting, wms, inventory-placement] - -## Lanes -- **WMS System** - Assigns locations, optimizes slotting -- **Warehouse Worker** - Transports and stores items - -## Process Flow -1. Receive items staged for put-away -2. Scan item barcode -3. WMS assigns optimal storage location -4. Generate put-away task -5. Transport item to assigned location -6. Scan location barcode to verify -7. Place item in location -8. Confirm put-away complete -9. Update WMS inventory location diff --git a/logistics/put-away-process/metadata.json b/logistics/put-away-process/metadata.json deleted file mode 100644 index fad437638d676890df59ffc52979ebbbf7dc3c75..0000000000000000000000000000000000000000 --- a/logistics/put-away-process/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "put-away-process", - "domain": "logistics", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "put-away", - "warehouse-storage", - "location-assignment", - "slotting", - "wms", - "inventory-placement" - ], - "description": "Warehouse put-away workflow with location assignment, slotting optimization, forklift routing, barcode confirmation, and WMS location update." -} \ No newline at end of file diff --git a/logistics/quality-inspection/README.md b/logistics/quality-inspection/README.md deleted file mode 100644 index a537d0026480a021b0f307cb05191dfe4a1e579a..0000000000000000000000000000000000000000 --- a/logistics/quality-inspection/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Quality Inspection - -Incoming quality inspection workflow with AQL sampling, defect classification, hold/release decision, supplier notification, and quality metrics tracking. - -**Domain:** logistics -**Complexity:** 3/5 -**Tags:** [quality-inspection, incoming-inspection, aql-sampling, defect-tracking, supplier-quality, hold-release] - -## Lanes -- **Receiving** - Stages items for inspection -- **Quality Inspector** - Samples and inspects items -- **Quality System** - Records results, notifies supplier - -## Process Flow -1. Receive items requiring inspection -2. Determine sample size based on AQL level -3. Pull random samples for inspection -4. Inspect against quality specifications -5. Classify any defects found -6. Calculate defect rate -7. Make hold/release decision -8. Notify supplier of quality issues -9. Update supplier quality scorecard diff --git a/logistics/quality-inspection/metadata.json b/logistics/quality-inspection/metadata.json deleted file mode 100644 index 83d4330f9b85d39fc2a717b254f45b7d8a97b25a..0000000000000000000000000000000000000000 --- a/logistics/quality-inspection/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "quality-inspection", - "domain": "logistics", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "quality-inspection", - "incoming-inspection", - "aql-sampling", - "defect-tracking", - "supplier-quality", - "hold-release" - ], - "description": "Incoming quality inspection workflow with AQL sampling, defect classification, hold/release decision, supplier notification, and quality metrics tracking." -} \ No newline at end of file diff --git a/logistics/reorder-process/README.md b/logistics/reorder-process/README.md deleted file mode 100644 index a1140a80641ee331318afffbc346ea73172dc3c2..0000000000000000000000000000000000000000 --- a/logistics/reorder-process/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# Reorder Process - -Inventory reorder workflow with reorder point monitoring, economic order quantity calculation, safety stock consideration, and automatic purchase requisition generation. - -**Domain:** logistics -**Complexity:** 3/5 -**Tags:** [reorder-process, reorder-point, safety-stock, eoq, demand-planning, auto-replenishment] - -## Lanes -- **Inventory System** - Monitors levels, triggers reorders -- **Procurement** - Reviews and places purchase orders - -## Process Flow -1. Monitor inventory levels continuously -2. Compare to reorder point threshold -3. Trigger reorder alert when below ROP -4. Calculate economic order quantity (EOQ) -5. Factor in safety stock requirements -6. Generate purchase requisition -7. Route for approval if needed -8. Convert to purchase order -9. Send to supplier diff --git a/logistics/reorder-process/metadata.json b/logistics/reorder-process/metadata.json deleted file mode 100644 index 4ef3540d7ca3c024ca1b9041f9bc87e20396142d..0000000000000000000000000000000000000000 --- a/logistics/reorder-process/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "reorder-process", - "domain": "logistics", - "complexity": 3, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "reorder-process", - "reorder-point", - "safety-stock", - "eoq", - "demand-planning", - "auto-replenishment" - ], - "description": "Inventory reorder workflow with reorder point monitoring, economic order quantity calculation, safety stock consideration, and automatic purchase requisition generation." -} \ No newline at end of file diff --git a/logistics/returns-processing/README.md b/logistics/returns-processing/README.md deleted file mode 100644 index c6baed653b8d3fcc0315fe1af828e9d2dde0d0f1..0000000000000000000000000000000000000000 --- a/logistics/returns-processing/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# Returns Processing - -Customer returns processing workflow with RMA generation, return receipt, quality inspection, disposition decision, and refund or exchange processing. - -**Domain:** logistics -**Complexity:** 3/5 -**Tags:** [returns-processing, rma, refund, restocking, quality-inspection, reverse-logistics] - -## Lanes -- **Customer Service** - Initiates RMA, processes refund/exchange -- **Warehouse** - Receives return, inspects, restocks or disposes - -## Process Flow -1. Customer requests return -2. Generate RMA (Return Merchandise Authorization) -3. Send return shipping label -4. Receive returned item at warehouse -5. Inspect item condition -6. Determine disposition (restock, refurbish, dispose) -7. Update inventory if restocking -8. Process refund or ship exchange -9. Close RMA and notify customer diff --git a/logistics/returns-processing/metadata.json b/logistics/returns-processing/metadata.json deleted file mode 100644 index 23736bfd42a22c2c58f888d0c2dd4b70966cfe68..0000000000000000000000000000000000000000 --- a/logistics/returns-processing/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "returns-processing", - "domain": "logistics", - "complexity": 3, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "returns-processing", - "rma", - "refund", - "restocking", - "quality-inspection", - "reverse-logistics" - ], - "description": "Customer returns processing workflow with RMA generation, return receipt, quality inspection, disposition decision, and refund or exchange processing." -} \ No newline at end of file diff --git a/logistics/reverse-logistics/README.md b/logistics/reverse-logistics/README.md deleted file mode 100644 index 43dec29840411863ea3b78d281d0377bccdc03f1..0000000000000000000000000000000000000000 --- a/logistics/reverse-logistics/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Reverse Logistics - -Reverse logistics workflow with return authorization, product grading, refurbishment decision, recycling coordination, and secondary market disposition. - -**Domain:** logistics -**Complexity:** 4/5 -**Tags:** [reverse-logistics, product-returns, refurbishment, recycling, disposition, sustainability] - -## Lanes -- **Returns Center** - Receives returns, grades condition -- **Refurbishment** - Repairs and reconditions products -- **Disposition** - Routes to resale, recycle, or dispose - -## Process Flow -1. Receive returned product -2. Inspect and grade condition (A/B/C/D) -3. Determine disposition path -4. Grade A: Return to primary inventory -5. Grade B: Send to refurbishment -6. Refurbish and repackage -7. Grade C: Sell to secondary market -8. Grade D: Send to recycling -9. Track sustainability metrics diff --git a/logistics/reverse-logistics/metadata.json b/logistics/reverse-logistics/metadata.json deleted file mode 100644 index a0f273a4ec4a7f0e385251008fd724f09982b547..0000000000000000000000000000000000000000 --- a/logistics/reverse-logistics/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "reverse-logistics", - "domain": "logistics", - "complexity": 4, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "reverse-logistics", - "product-returns", - "refurbishment", - "recycling", - "disposition", - "sustainability" - ], - "description": "Reverse logistics workflow with return authorization, product grading, refurbishment decision, recycling coordination, and secondary market disposition." -} \ No newline at end of file diff --git a/logistics/shipping-process/README.md b/logistics/shipping-process/README.md deleted file mode 100644 index 11463170e265c3ef1ab55266f11d57d4a755951d..0000000000000000000000000000000000000000 --- a/logistics/shipping-process/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Shipping Process - -Order shipping workflow with carrier selection, rate shopping, label generation, tracking number assignment, and dispatch confirmation. - -**Domain:** logistics -**Complexity:** 3/5 -**Tags:** [shipping-process, order-fulfillment, carrier-selection, label-generation, tracking-number, dispatch] - -## Lanes -- **Warehouse** - Picks, packs, and stages orders for shipping -- **Shipping System** - Selects carrier, generates labels -- **Carrier** - Picks up and delivers packages - -## Process Flow -1. Receive packed order ready for shipping -2. Determine shipping method (ground, express, freight) -3. Rate shop across carriers for best price -4. Select carrier and service level -5. Generate shipping label -6. Assign tracking number -7. Stage for carrier pickup -8. Confirm dispatch and update order status -9. Send tracking notification to customer diff --git a/logistics/shipping-process/metadata.json b/logistics/shipping-process/metadata.json deleted file mode 100644 index 15134e524f1494c139c5f6ffae38975a82dece3a..0000000000000000000000000000000000000000 --- a/logistics/shipping-process/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "shipping-process", - "domain": "logistics", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "shipping-process", - "order-fulfillment", - "carrier-selection", - "label-generation", - "tracking-number", - "dispatch" - ], - "description": "Order shipping workflow with carrier selection, rate shopping, label generation, tracking number assignment, and dispatch confirmation." -} \ No newline at end of file diff --git a/logistics/stock-transfer/README.md b/logistics/stock-transfer/README.md deleted file mode 100644 index 5d385d9453b2da03c1f74fb9419df8e575f7d577..0000000000000000000000000000000000000000 --- a/logistics/stock-transfer/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Stock Transfer - -Internal stock transfer workflow with transfer request, source location pick, destination put-away, and inventory record updates across locations. - -**Domain:** logistics -**Complexity:** 3/5 -**Tags:** [stock-transfer, inventory-movement, location-transfer, bin-to-bin, wms, inventory-rebalancing] - -## Lanes -- **Requester** - Initiates transfer request -- **Source Location** - Picks and ships inventory -- **Destination Location** - Receives and puts away - -## Process Flow -1. Create stock transfer request -2. Verify source location has available stock -3. Generate pick task at source -4. Pick items from source location -5. Update source inventory (decrement) -6. Ship to destination location -7. Receive at destination -8. Put away at destination location -9. Update destination inventory (increment) diff --git a/logistics/stock-transfer/metadata.json b/logistics/stock-transfer/metadata.json deleted file mode 100644 index bf67dc29eca951b4a1daead92347e8b39c527106..0000000000000000000000000000000000000000 --- a/logistics/stock-transfer/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "stock-transfer", - "domain": "logistics", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "stock-transfer", - "inventory-movement", - "location-transfer", - "bin-to-bin", - "wms", - "inventory-rebalancing" - ], - "description": "Internal stock transfer workflow with transfer request, source location pick, destination put-away, and inventory record updates across locations." -} \ No newline at end of file diff --git a/logistics/warehouse-transfer/README.md b/logistics/warehouse-transfer/README.md deleted file mode 100644 index 03b66742a8a38193b4d58bf891fc691f67fd33ed..0000000000000000000000000000000000000000 --- a/logistics/warehouse-transfer/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Warehouse Transfer - -Inter-warehouse transfer workflow with transfer order creation, shipping from source DC, in-transit tracking, and receiving at destination warehouse. - -**Domain:** logistics -**Complexity:** 3/5 -**Tags:** [warehouse-transfer, inter-facility, transfer-order, in-transit-inventory, network-optimization, distribution] - -## Lanes -- **Planning** - Creates transfer order, optimizes network -- **Source Warehouse** - Picks, packs, ships transfer -- **Destination Warehouse** - Receives and puts away - -## Process Flow -1. Identify inventory imbalance across network -2. Create inter-warehouse transfer order -3. Pick items at source warehouse -4. Pack for inter-facility shipment -5. Ship via internal or carrier transport -6. Track in-transit inventory -7. Receive at destination warehouse -8. Verify quantities match transfer order -9. Put away and update inventory diff --git a/logistics/warehouse-transfer/metadata.json b/logistics/warehouse-transfer/metadata.json deleted file mode 100644 index 9ff945a92b408004abe6abcf66e8215f26b8fb1a..0000000000000000000000000000000000000000 --- a/logistics/warehouse-transfer/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "warehouse-transfer", - "domain": "logistics", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "warehouse-transfer", - "inter-facility", - "transfer-order", - "in-transit-inventory", - "network-optimization", - "distribution" - ], - "description": "Inter-warehouse transfer workflow with transfer order creation, shipping from source DC, in-transit tracking, and receiving at destination warehouse." -} \ No newline at end of file diff --git a/mcp/architecture/ambassador-pattern-architecture/README.md b/mcp/architecture/ambassador-pattern-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..13a6ac3448b4edd886817b503ba644f9391c4c2f --- /dev/null +++ b/mcp/architecture/ambassador-pattern-architecture/README.md @@ -0,0 +1,19 @@ +# Ambassador Pattern Architecture + +An ambassador pattern architecture diagram with a local proxy sidecar handling authentication header injection, circuit breaking, retry logic, and metrics collection for outbound requests to external third-party APIs. This template models the ambassador pattern where a helper service running alongside the application offloads cross-cutting concerns for external communication. Useful for teams integrating with unreliable third-party services that need resilience wrappers. + +**Template ID:** `ambassador-pattern-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** mcp +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 15 +**Lanes:** 3 +**Tags:** [ambassador-pattern, sidecar-proxy, external-api, retry-logic, circuit-breaker, metrics-collection, cross-cutting-concerns, architecture-diagram] +**Source path:** `` +**Repo path:** `mcp/architecture/ambassador-pattern-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/mcp/architecture/ambassador-pattern-architecture/metadata.json b/mcp/architecture/ambassador-pattern-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..4cfe3b6d756ff70f067a6e73e187db027406a56c --- /dev/null +++ b/mcp/architecture/ambassador-pattern-architecture/metadata.json @@ -0,0 +1,28 @@ +{ + "template_id": "ambassador-pattern-architecture", + "workflow_id": "ambassador-pattern-architecture", + "title": "Ambassador Pattern Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "mcp", + "secondary_use_cases": [], + "use_cases": [ + "mcp" + ], + "complexity": 3, + "num_nodes": 15, + "num_lanes": 3, + "tags": [ + "ambassador-pattern", + "sidecar-proxy", + "external-api", + "retry-logic", + "circuit-breaker", + "metrics-collection", + "cross-cutting-concerns", + "architecture-diagram" + ], + "description": "An ambassador pattern architecture diagram with a local proxy sidecar handling authentication header injection, circuit breaking, retry logic, and metrics collection for outbound requests to external third-party APIs. This template models the ambassador pattern where a helper service running alongside the application offloads cross-cutting concerns for external communication. Useful for teams integrating with unreliable third-party services that need resilience wrappers.", + "source_path": "", + "repo_path": "mcp/architecture/ambassador-pattern-architecture" +} diff --git a/mcp/architecture/ambassador-pattern-architecture/workflow.fz b/mcp/architecture/ambassador-pattern-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..8b2b0fc1fe41d0eff19a876618a7648b20c8dc84 --- /dev/null +++ b/mcp/architecture/ambassador-pattern-architecture/workflow.fz @@ -0,0 +1,36 @@ +Application { # Application Container +n1: circle label:"Outbound Request" +n2: rectangle label:"Application Code" +n3: rectangle label:"Ambassador Proxy" +n14: rectangle label:"Receive Proxied Response" +n15: circle label:"End" +n1.handle(right) -> n2.handle(left) +n2.handle(right) -> n3.handle(left) [label="localhost:9000"] +n3.handle(bottom) -> AmbassadorLogic.n4.handle(top) [label="Intercept"] +n14.handle(right) -> n15.handle(left) +} +AmbassadorLogic { # Ambassador Logic +n4: rectangle label:"Add Auth Headers" +n5: rectangle label:"Apply Circuit Breaker" +n6: diamond label:"Circuit Open?" +n7: rectangle label:"Enable Retry Logic" +n8: rectangle label:"Return Cached Fallback" +n12: rectangle label:"Collect Metrics" +n13: rectangle label:"Forward Response" +n4.handle(right) -> n5.handle(left) [label="Bearer Token"] +n5.handle(right) -> n6.handle(left) +n6.handle(right) -> n7.handle(left) [label="Closed"] +n6.handle(bottom) -> n8.handle(top) [label="Open"] +n7.handle(bottom) -> ExternalService.n9.handle(top) [label="HTTPS + Retry"] +n8.handle(top) -> Application.n14.handle(bottom) [label="Fallback"] +n12.handle(right) -> n13.handle(left) +n13.handle(top) -> Application.n14.handle(bottom) [label="Proxied Response"] +} +ExternalService { # External API +n9: rectangle label:"Third-Party API" +n10: rectangle label:"Process Request" +n11: rectangle label:"Return Response" +n9.handle(right) -> n10.handle(left) +n10.handle(right) -> n11.handle(left) +n11.handle(top) -> AmbassadorLogic.n12.handle(bottom) [label="Response + Metrics"] +} diff --git a/mcp/architecture/circuit-breaker-resilience-architecture/README.md b/mcp/architecture/circuit-breaker-resilience-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..5291515db00c5f0100e3d7916eb0bb9edbacd4df --- /dev/null +++ b/mcp/architecture/circuit-breaker-resilience-architecture/README.md @@ -0,0 +1,19 @@ +# Circuit Breaker Resilience Architecture + +A circuit breaker resilience architecture diagram showing the complete state machine with closed, open, and half-open states, failure threshold tracking, recovery timer, and fallback response strategies for protecting services from cascading failures. This template visualizes the circuit breaker pattern in detail, including how the breaker transitions between states based on success and failure counts. Essential for building fault-tolerant microservices that degrade gracefully under load. + +**Template ID:** `circuit-breaker-resilience-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** mcp +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 18 +**Lanes:** 3 +**Tags:** [circuit-breaker, resilience, fault-tolerance, cascading-failure, half-open-state, fallback, state-machine, architecture-diagram] +**Source path:** `` +**Repo path:** `mcp/architecture/circuit-breaker-resilience-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/mcp/architecture/circuit-breaker-resilience-architecture/metadata.json b/mcp/architecture/circuit-breaker-resilience-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..7656192a13df6be2944e1f6751a9f0f539673fa9 --- /dev/null +++ b/mcp/architecture/circuit-breaker-resilience-architecture/metadata.json @@ -0,0 +1,28 @@ +{ + "template_id": "circuit-breaker-resilience-architecture", + "workflow_id": "circuit-breaker-resilience-architecture", + "title": "Circuit Breaker Resilience Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "mcp", + "secondary_use_cases": [], + "use_cases": [ + "mcp" + ], + "complexity": 4, + "num_nodes": 18, + "num_lanes": 3, + "tags": [ + "circuit-breaker", + "resilience", + "fault-tolerance", + "cascading-failure", + "half-open-state", + "fallback", + "state-machine", + "architecture-diagram" + ], + "description": "A circuit breaker resilience architecture diagram showing the complete state machine with closed, open, and half-open states, failure threshold tracking, recovery timer, and fallback response strategies for protecting services from cascading failures. This template visualizes the circuit breaker pattern in detail, including how the breaker transitions between states based on success and failure counts. Essential for building fault-tolerant microservices that degrade gracefully under load.", + "source_path": "", + "repo_path": "mcp/architecture/circuit-breaker-resilience-architecture" +} diff --git a/mcp/architecture/circuit-breaker-resilience-architecture/workflow.fz b/mcp/architecture/circuit-breaker-resilience-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..e269e5b0d8f27e5f5587900dd6e81e641d42519b --- /dev/null +++ b/mcp/architecture/circuit-breaker-resilience-architecture/workflow.fz @@ -0,0 +1,52 @@ +Client { # Client Service +n1: circle label:"Service Call" +n2: rectangle label:"Circuit Breaker Proxy" +n21: rectangle label:"Receive Response" +n22: circle label:"End" +n1.handle(right) -> n2.handle(left) +n2.handle(bottom) -> Breaker.n3.handle(top) [label="Check State"] +n21.handle(right) -> n22.handle(left) +} +Breaker { # Circuit Breaker +n3: diamond label:"Circuit State?" +n4: rectangle label:"Forward Request (Closed)" +n5: rectangle label:"Return Fallback (Open)" +n6: rectangle label:"Test Request (Half-Open)" +n13: rectangle label:"Track Success" +n14: rectangle label:"Track Failure" +n15: diamond label:"Failure Threshold?" +n16: rectangle label:"Trip Circuit Open" +n17: rectangle label:"Reset to Closed" +n18: rectangle label:"Start Recovery Timer" +n19: rectangle label:"Forward Success Response" +n20: rectangle label:"Forward Error Response" +n3.handle(right) -> n4.handle(left) [label="Closed"] +n3.handle(bottom) -> n5.handle(top) [label="Open"] +n3.handle(left) -> n6.handle(right) [label="Half-Open"] +n4.handle(bottom) -> Downstream.n7.handle(top) [label="Forward"] +n5.handle(top) -> Client.n21.handle(bottom) [label="Cached/Default"] +n6.handle(bottom) -> Downstream.n7.handle(top) [label="Probe"] +n13.handle(right) -> n17.handle(left) [label="Healthy"] +n14.handle(right) -> n15.handle(left) +n15.handle(right) -> n16.handle(left) [label="Exceeded"] +n16.handle(right) -> n18.handle(left) [label="Cooldown"] +n17.handle(right) -> n19.handle(left) +n19.handle(top) -> Client.n21.handle(bottom) [label="Success"] +n18.handle(right) -> n20.handle(left) +n20.handle(top) -> Client.n21.handle(bottom) [label="Error"] +} +Downstream { # Downstream Service +n7: rectangle label:"Process Request" +n8: diamond label:"Response OK?" +n9: rectangle label:"Return Success" +n10: rectangle label:"Return Error/Timeout" +n11: rectangle label:"Send Success Signal" +n12: rectangle label:"Send Failure Signal" +n7.handle(right) -> n8.handle(left) +n8.handle(right) -> n9.handle(left) [label="200"] +n8.handle(bottom) -> n10.handle(top) [label="5xx/Timeout"] +n9.handle(right) -> n11.handle(left) +n10.handle(right) -> n12.handle(left) +n11.handle(top) -> Breaker.n13.handle(bottom) [label="Success"] +n12.handle(top) -> Breaker.n14.handle(bottom) [label="Failure"] +} diff --git a/mcp/architecture/graphql-federation-architecture/README.md b/mcp/architecture/graphql-federation-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..3126c69ed82bb14529c200746a685d0f6bf9df95 --- /dev/null +++ b/mcp/architecture/graphql-federation-architecture/README.md @@ -0,0 +1,19 @@ +# GraphQL Federation Architecture + +A GraphQL federation architecture diagram with an Apollo Gateway building query plans and fanning out to User, Product, and Review subgraphs, each owning its schema and database, with response stitching into a unified GraphQL result. This template models the federated GraphQL approach where multiple teams independently develop and deploy their subgraphs while clients see a single unified API. Ideal for organizations scaling GraphQL across multiple teams and services. + +**Template ID:** `graphql-federation-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** mcp +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 15 +**Lanes:** 3 +**Tags:** [graphql-federation, apollo-gateway, subgraph, schema-stitching, query-plan, federated-api, graphql, architecture-diagram] +**Source path:** `` +**Repo path:** `mcp/architecture/graphql-federation-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/mcp/architecture/graphql-federation-architecture/metadata.json b/mcp/architecture/graphql-federation-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..abcf4365fb678adc1707e970deb00e84aa774fbb --- /dev/null +++ b/mcp/architecture/graphql-federation-architecture/metadata.json @@ -0,0 +1,28 @@ +{ + "template_id": "graphql-federation-architecture", + "workflow_id": "graphql-federation-architecture", + "title": "GraphQL Federation Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "mcp", + "secondary_use_cases": [], + "use_cases": [ + "mcp" + ], + "complexity": 3, + "num_nodes": 15, + "num_lanes": 3, + "tags": [ + "graphql-federation", + "apollo-gateway", + "subgraph", + "schema-stitching", + "query-plan", + "federated-api", + "graphql", + "architecture-diagram" + ], + "description": "A GraphQL federation architecture diagram with an Apollo Gateway building query plans and fanning out to User, Product, and Review subgraphs, each owning its schema and database, with response stitching into a unified GraphQL result. This template models the federated GraphQL approach where multiple teams independently develop and deploy their subgraphs while clients see a single unified API. Ideal for organizations scaling GraphQL across multiple teams and services.", + "source_path": "", + "repo_path": "mcp/architecture/graphql-federation-architecture" +} diff --git a/mcp/architecture/graphql-federation-architecture/workflow.fz b/mcp/architecture/graphql-federation-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..1609e411d9b161b0341297d77ee9a6555c8e47ba --- /dev/null +++ b/mcp/architecture/graphql-federation-architecture/workflow.fz @@ -0,0 +1,51 @@ +Client { # Client Application +n1: circle label:"GraphQL Query" +n2: rectangle label:"Send to Gateway" +n21: rectangle label:"Receive Unified Response" +n22: circle label:"Render UI" +n1.handle(right) -> n2.handle(left) +n2.handle(bottom) -> Gateway.n3.handle(top) [label="POST /graphql"] +n21.handle(right) -> n22.handle(left) +} +Gateway { # Apollo Federation Gateway +n3: rectangle label:"Parse GraphQL Query" +n4: rectangle label:"Build Query Plan" +n5: rectangle label:"Fan-Out to Subgraphs" +n18: rectangle label:"Merge Responses" +n19: rectangle label:"Return Unified Result" +n20: rectangle label:"Send to Client" +n3.handle(right) -> n4.handle(left) [label="AST"] +n4.handle(right) -> n5.handle(left) [label="Execution Plan"] +n5.handle(bottom) -> Subgraphs.n6.handle(top) [label="User Fields"] +n5.handle(bottom) -> Subgraphs.n8.handle(top) [label="Product Fields"] +n5.handle(bottom) -> Subgraphs.n10.handle(top) [label="Review Fields"] +n18.handle(right) -> n19.handle(left) [label="Stitched"] +n19.handle(right) -> n20.handle(left) +n20.handle(top) -> Client.n21.handle(bottom) [label="JSON"] +} +Subgraphs { # Federated Subgraphs +n6: rectangle label:"User Subgraph" +n7: rectangle label:"User Database" +n8: rectangle label:"Product Subgraph" +n9: rectangle label:"Product Database" +n10: rectangle label:"Review Subgraph" +n11: rectangle label:"Review Database" +n12: rectangle label:"Collect User Data" +n13: rectangle label:"Collect Product Data" +n14: rectangle label:"Collect Review Data" +n15: rectangle label:"Aggregate All Results" +n16: rectangle label:"Prepare Response" +n17: rectangle label:"Send Combined Data" +n6.handle(right) -> n7.handle(left) [label="Query"] +n8.handle(right) -> n9.handle(left) [label="Query"] +n10.handle(right) -> n11.handle(left) [label="Query"] +n7.handle(right) -> n12.handle(left) +n9.handle(right) -> n13.handle(left) +n11.handle(right) -> n14.handle(left) +n12.handle(bottom) -> n15.handle(top) [label="User Data"] +n13.handle(bottom) -> n15.handle(top) [label="Product Data"] +n14.handle(right) -> n15.handle(left) [label="Review Data"] +n15.handle(right) -> n16.handle(left) +n16.handle(right) -> n17.handle(left) +n17.handle(top) -> Gateway.n18.handle(bottom) [label="All Data"] +} diff --git a/mcp/architecture/microservices-service-mesh-architecture/README.md b/mcp/architecture/microservices-service-mesh-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..c42c15af5a54ddf0c30e1afb4f30ae5be95cbc0f --- /dev/null +++ b/mcp/architecture/microservices-service-mesh-architecture/README.md @@ -0,0 +1,19 @@ +# Microservices Service Mesh Architecture + +A service mesh architecture diagram with Istio or Linkerd sidecar proxies handling mTLS encryption, traffic policies, circuit breaking, and distributed tracing across microservices. This template visualizes how a service mesh abstracts networking concerns away from application code, enabling zero-trust communication between services. Essential for teams adopting service mesh infrastructure to improve observability and security. + +**Template ID:** `microservices-service-mesh-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** mcp +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 18 +**Lanes:** 3 +**Tags:** [service-mesh, istio, linkerd, mtls, sidecar-proxy, distributed-tracing, traffic-management, architecture-diagram] +**Source path:** `` +**Repo path:** `mcp/architecture/microservices-service-mesh-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/mcp/architecture/microservices-service-mesh-architecture/metadata.json b/mcp/architecture/microservices-service-mesh-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..f72fb5e3d42046c3bbec811c35149dc2785bfd3a --- /dev/null +++ b/mcp/architecture/microservices-service-mesh-architecture/metadata.json @@ -0,0 +1,28 @@ +{ + "template_id": "microservices-service-mesh-architecture", + "workflow_id": "microservices-service-mesh-architecture", + "title": "Microservices Service Mesh Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "mcp", + "secondary_use_cases": [], + "use_cases": [ + "mcp" + ], + "complexity": 4, + "num_nodes": 18, + "num_lanes": 3, + "tags": [ + "service-mesh", + "istio", + "linkerd", + "mtls", + "sidecar-proxy", + "distributed-tracing", + "traffic-management", + "architecture-diagram" + ], + "description": "A service mesh architecture diagram with Istio or Linkerd sidecar proxies handling mTLS encryption, traffic policies, circuit breaking, and distributed tracing across microservices. This template visualizes how a service mesh abstracts networking concerns away from application code, enabling zero-trust communication between services. Essential for teams adopting service mesh infrastructure to improve observability and security.", + "source_path": "", + "repo_path": "mcp/architecture/microservices-service-mesh-architecture" +} diff --git a/mcp/architecture/microservices-service-mesh-architecture/workflow.fz b/mcp/architecture/microservices-service-mesh-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..f467b371c30316135d986d745d7fca5c745ca00b --- /dev/null +++ b/mcp/architecture/microservices-service-mesh-architecture/workflow.fz @@ -0,0 +1,52 @@ +Ingress { # Ingress Controller +n1: circle label:"External Traffic" +n2: rectangle label:"TLS Termination" +n3: rectangle label:"Route to Service Mesh" +n22: rectangle label:"Receive Mesh Response" +n23: circle label:"Response to Client" +n1.handle(right) -> n2.handle(left) +n2.handle(right) -> n3.handle(left) +n3.handle(bottom) -> Mesh.n4.handle(top) [label="Enter Mesh"] +n22.handle(right) -> n23.handle(left) +} +Mesh { # Service Mesh (Istio/Linkerd) +n4: rectangle label:"Sidecar Proxy Intercept" +n5: rectangle label:"mTLS Encryption" +n6: rectangle label:"Traffic Policy Check" +n7: diamond label:"Circuit Breaker Open?" +n8: rectangle label:"Load Balance Request" +n9: rectangle label:"Return Fallback" +n18: rectangle label:"Receive Service Response" +n19: rectangle label:"Collect Telemetry" +n20: rectangle label:"Distributed Tracing" +n21: rectangle label:"Forward to Ingress" +n4.handle(right) -> n5.handle(left) +n5.handle(right) -> n6.handle(left) +n6.handle(right) -> n7.handle(left) +n7.handle(right) -> n8.handle(left) [label="Closed"] +n7.handle(bottom) -> n9.handle(top) [label="Open"] +n8.handle(bottom) -> Services.n10.handle(top) [label="Forward"] +n9.handle(bottom) -> Services.n16.handle(top) [label="Fallback"] +n18.handle(right) -> n19.handle(left) +n19.handle(right) -> n20.handle(left) +n20.handle(right) -> n21.handle(left) +n21.handle(top) -> Ingress.n22.handle(bottom) [label="Mesh Response"] +} +Services { # Backend Services +n10: rectangle label:"Product Catalog Service" +n11: rectangle label:"Pricing Service" +n12: rectangle label:"Recommendation Engine" +n13: rectangle label:"Response Aggregation" +n14: rectangle label:"Sidecar Proxy Egress" +n15: rectangle label:"Return to Mesh" +n16: rectangle label:"Cached Fallback Response" +n17: rectangle label:"Return Fallback to Mesh" +n10.handle(right) -> n11.handle(left) [label="Get Prices"] +n11.handle(right) -> n12.handle(left) [label="Enrich"] +n12.handle(right) -> n13.handle(left) +n13.handle(right) -> n14.handle(left) +n14.handle(right) -> n15.handle(left) +n15.handle(top) -> Mesh.n18.handle(bottom) [label="Service Response"] +n16.handle(right) -> n17.handle(left) [label="Stale Data"] +n17.handle(top) -> Mesh.n18.handle(bottom) [label="Fallback Response"] +} diff --git a/mcp/architecture/microservices-sidecar-pattern-architecture/README.md b/mcp/architecture/microservices-sidecar-pattern-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..152a61c00b44d6db2639fef62dd423f3e3e38698 --- /dev/null +++ b/mcp/architecture/microservices-sidecar-pattern-architecture/README.md @@ -0,0 +1,19 @@ +# Microservices Sidecar Pattern Architecture + +A sidecar pattern architecture diagram showing Envoy proxy, log collector, and config watcher sidecars running alongside application containers in a Kubernetes pod, with a control plane managing configuration. This template demonstrates how auxiliary concerns like logging, monitoring, and configuration are deployed as co-located containers. Foundational for teams adopting cloud-native container orchestration patterns. + +**Template ID:** `microservices-sidecar-pattern-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** mcp +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 13 +**Lanes:** 3 +**Tags:** [sidecar-pattern, envoy-proxy, kubernetes, container-pattern, observability, control-plane, cloud-native, architecture-diagram] +**Source path:** `` +**Repo path:** `mcp/architecture/microservices-sidecar-pattern-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/mcp/architecture/microservices-sidecar-pattern-architecture/metadata.json b/mcp/architecture/microservices-sidecar-pattern-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..56fc7838fca177d9313de26afc61f5b4f9b511a3 --- /dev/null +++ b/mcp/architecture/microservices-sidecar-pattern-architecture/metadata.json @@ -0,0 +1,28 @@ +{ + "template_id": "microservices-sidecar-pattern-architecture", + "workflow_id": "microservices-sidecar-pattern-architecture", + "title": "Microservices Sidecar Pattern Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "mcp", + "secondary_use_cases": [], + "use_cases": [ + "mcp" + ], + "complexity": 4, + "num_nodes": 13, + "num_lanes": 3, + "tags": [ + "sidecar-pattern", + "envoy-proxy", + "kubernetes", + "container-pattern", + "observability", + "control-plane", + "cloud-native", + "architecture-diagram" + ], + "description": "A sidecar pattern architecture diagram showing Envoy proxy, log collector, and config watcher sidecars running alongside application containers in a Kubernetes pod, with a control plane managing configuration. This template demonstrates how auxiliary concerns like logging, monitoring, and configuration are deployed as co-located containers. Foundational for teams adopting cloud-native container orchestration patterns.", + "source_path": "", + "repo_path": "mcp/architecture/microservices-sidecar-pattern-architecture" +} diff --git a/mcp/architecture/microservices-sidecar-pattern-architecture/workflow.fz b/mcp/architecture/microservices-sidecar-pattern-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..a84e901cc155eea925b59fb4aa538ed98fec76bb --- /dev/null +++ b/mcp/architecture/microservices-sidecar-pattern-architecture/workflow.fz @@ -0,0 +1,37 @@ +ControlPlane { # Control Plane +n1: rectangle label:"Service Mesh Control Plane" +n2: rectangle label:"Push Configuration" +n3: rectangle label:"Certificate Authority" +n15: rectangle label:"Receive Config Ack" +n16: rectangle label:"Config Confirmed" +n1.handle(right) -> n2.handle(left) [label="Policy"] +n2.handle(bottom) -> Pod.n4.handle(top) [label="xDS Config"] +n3.handle(bottom) -> Pod.n4.handle(top) [label="mTLS Cert"] +n15.handle(right) -> n16.handle(left) +} +Pod { # Kubernetes Pod +n4: rectangle label:"Envoy Sidecar Proxy" +n5: rectangle label:"Config Watcher Sidecar" +n6: rectangle label:"Application Container" +n7: rectangle label:"Log Collector Sidecar" +n8: rectangle label:"Send Log Batch" +n13: rectangle label:"Receive Log Ack" +n14: rectangle label:"Acknowledge Config" +n4.handle(right) -> n5.handle(left) +n5.handle(right) -> n6.handle(left) [label="Config Applied"] +n6.handle(right) -> n7.handle(left) [label="Logs"] +n7.handle(right) -> n8.handle(left) +n8.handle(bottom) -> Observability.n9.handle(top) [label="Ship Logs"] +n13.handle(right) -> n14.handle(left) +n14.handle(top) -> ControlPlane.n15.handle(bottom) [label="Config Ack"] +} +Observability { # Observability Stack +n9: rectangle label:"ELK Log Aggregation" +n10: rectangle label:"Prometheus Metrics" +n11: rectangle label:"Jaeger Tracing" +n12: rectangle label:"Return Log Ack" +n9.handle(right) -> n10.handle(left) +n10.handle(right) -> n11.handle(left) [label="Traces"] +n11.handle(right) -> n12.handle(left) +n12.handle(top) -> Pod.n13.handle(bottom) [label="Logs Received"] +} diff --git a/mcp/architecture/serverless-api-backend-architecture/README.md b/mcp/architecture/serverless-api-backend-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..26d261b6a7c968e82343624bb5d559b96d73417e --- /dev/null +++ b/mcp/architecture/serverless-api-backend-architecture/README.md @@ -0,0 +1,19 @@ +# Serverless API Backend Architecture + +A serverless API backend architecture diagram with API Gateway, Lambda authorizer functions, business logic functions, and managed cloud services including DynamoDB, S3, SQS, and SNS for a fully managed, auto-scaling backend. This template models the serverless-first approach where infrastructure management is eliminated entirely, with pay-per-invocation pricing and automatic scaling to zero. Essential for startups and teams building cost-efficient, event-driven API backends. + +**Template ID:** `serverless-api-backend-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** mcp +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 15 +**Lanes:** 3 +**Tags:** [serverless, aws-lambda, api-gateway, dynamodb, cloud-architecture, auto-scaling, pay-per-use, architecture-diagram] +**Source path:** `` +**Repo path:** `mcp/architecture/serverless-api-backend-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/mcp/architecture/serverless-api-backend-architecture/metadata.json b/mcp/architecture/serverless-api-backend-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..3690fadde4a4c03a92c38cf1bb97a20400f2a938 --- /dev/null +++ b/mcp/architecture/serverless-api-backend-architecture/metadata.json @@ -0,0 +1,28 @@ +{ + "template_id": "serverless-api-backend-architecture", + "workflow_id": "serverless-api-backend-architecture", + "title": "Serverless API Backend Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "mcp", + "secondary_use_cases": [], + "use_cases": [ + "mcp" + ], + "complexity": 3, + "num_nodes": 15, + "num_lanes": 3, + "tags": [ + "serverless", + "aws-lambda", + "api-gateway", + "dynamodb", + "cloud-architecture", + "auto-scaling", + "pay-per-use", + "architecture-diagram" + ], + "description": "A serverless API backend architecture diagram with API Gateway, Lambda authorizer functions, business logic functions, and managed cloud services including DynamoDB, S3, SQS, and SNS for a fully managed, auto-scaling backend. This template models the serverless-first approach where infrastructure management is eliminated entirely, with pay-per-invocation pricing and automatic scaling to zero. Essential for startups and teams building cost-efficient, event-driven API backends.", + "source_path": "", + "repo_path": "mcp/architecture/serverless-api-backend-architecture" +} diff --git a/mcp/architecture/serverless-api-backend-architecture/workflow.fz b/mcp/architecture/serverless-api-backend-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..179b96a0d249f5b134b1d102f7cbc164a8ba7359 --- /dev/null +++ b/mcp/architecture/serverless-api-backend-architecture/workflow.fz @@ -0,0 +1,39 @@ +Client { # Client Application +n1: circle label:"API Request" +n2: rectangle label:"API Gateway (AWS/Azure)" +n16: rectangle label:"Receive Response" +n17: circle label:"End" +n1.handle(right) -> n2.handle(left) +n2.handle(bottom) -> Functions.n3.handle(top) [label="Invoke Lambda"] +n16.handle(right) -> n17.handle(left) +} +Functions { # Serverless Functions +n3: rectangle label:"Auth Authorizer Lambda" +n4: diamond label:"Token Valid?" +n5: rectangle label:"Business Logic Lambda" +n6: rectangle label:"Return 401" +n13: rectangle label:"Receive Data" +n14: rectangle label:"Data Validation Lambda" +n15: rectangle label:"Response Formatter" +n3.handle(right) -> n4.handle(left) +n4.handle(right) -> n5.handle(left) [label="Authorized"] +n4.handle(bottom) -> n6.handle(top) [label="Denied"] +n5.handle(bottom) -> ManagedServices.n7.handle(top) [label="Read/Write"] +n6.handle(top) -> Client.n16.handle(bottom) [label="401"] +n13.handle(right) -> n14.handle(left) +n14.handle(right) -> n15.handle(left) [label="Validated"] +n15.handle(top) -> Client.n16.handle(bottom) [label="200 JSON"] +} +ManagedServices { # Managed Cloud Services +n7: rectangle label:"DynamoDB / CosmosDB" +n8: rectangle label:"S3 Object Storage" +n9: rectangle label:"SQS Message Queue" +n10: rectangle label:"SNS Notification" +n11: rectangle label:"CloudWatch Logs" +n12: rectangle label:"Return Data" +n7.handle(right) -> n8.handle(left) [label="Store Assets"] +n9.handle(right) -> n10.handle(left) [label="Trigger"] +n10.handle(right) -> n11.handle(left) [label="Log"] +n11.handle(right) -> n12.handle(left) +n12.handle(top) -> Functions.n13.handle(bottom) [label="Data Response"] +} diff --git a/mcp/devops/mcp-circuit-breaker/README.md b/mcp/devops/mcp-circuit-breaker/README.md new file mode 100644 index 0000000000000000000000000000000000000000..35462f6041e81c56450b23e197256b9885fd44fe --- /dev/null +++ b/mcp/devops/mcp-circuit-breaker/README.md @@ -0,0 +1,19 @@ +# MCP Circuit Breaker Architecture + +A resilience pattern that wraps MCP calls with health-aware gates using three states: Closed (normal), Open (failures detected, fast-fail), and Half-Open (testing recovery). Prevents cascading failures when tools become unresponsive. Essential for production-grade reliability. + +**Template ID:** `mcp-circuit-breaker` +**Kind:** architecture +**Source domain:** DevOps +**Primary use case:** mcp +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 9 +**Lanes:** 3 +**Tags:** [mcp, circuit-breaker, resilience, fault-tolerance, health-check, architecture-diagram, production-grade] +**Source path:** `` +**Repo path:** `mcp/devops/mcp-circuit-breaker` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/mcp/devops/mcp-circuit-breaker/metadata.json b/mcp/devops/mcp-circuit-breaker/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..4d0aae77eb64d276e74c5511875738ed2e07bda5 --- /dev/null +++ b/mcp/devops/mcp-circuit-breaker/metadata.json @@ -0,0 +1,27 @@ +{ + "template_id": "mcp-circuit-breaker", + "workflow_id": "mcp-circuit-breaker", + "title": "MCP Circuit Breaker Architecture", + "kind": "architecture", + "source_domain": "DevOps", + "primary_use_case": "mcp", + "secondary_use_cases": [], + "use_cases": [ + "mcp" + ], + "complexity": 3, + "num_nodes": 9, + "num_lanes": 3, + "tags": [ + "mcp", + "circuit-breaker", + "resilience", + "fault-tolerance", + "health-check", + "architecture-diagram", + "production-grade" + ], + "description": "A resilience pattern that wraps MCP calls with health-aware gates using three states: Closed (normal), Open (failures detected, fast-fail), and Half-Open (testing recovery). Prevents cascading failures when tools become unresponsive. Essential for production-grade reliability.", + "source_path": "", + "repo_path": "mcp/devops/mcp-circuit-breaker" +} diff --git a/mcp/devops/mcp-circuit-breaker/workflow.fz b/mcp/devops/mcp-circuit-breaker/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..b0bfadc18df8d8f7c42dd2e5e69ce4469c6ef27e --- /dev/null +++ b/mcp/devops/mcp-circuit-breaker/workflow.fz @@ -0,0 +1,37 @@ +Host { # Host Application + n1: circle label="User sends prompt" + n2: rectangle label="Agent prepares MCP call" + n3: rectangle label="Pass call to circuit breaker" + n4: rectangle label="Receive result or error" + n5: rectangle label="Agent responds to user" + n1.handle(right) -> n2.handle(left) + n2.handle(right) -> n3.handle(left) + n3.handle(bottom) -> CB.n6.handle(top) [label="MCP tool call"] + n4.handle(right) -> n5.handle(left) +} + +CB { # Circuit Breaker + n6: rectangle label="Check circuit state" + n7: diamond label="Circuit open?" + n8: rectangle label="Forward to MCP server" + n9: rectangle label="Fast-fail with error" + n10: diamond label="Call succeeded?" + n11: rectangle label="Record success" + n12: rectangle label="Record failure and check threshold" + n6.handle(right) -> n7.handle(left) + n7.handle(right) -> n8.handle(left) [label="Closed"] + n7.handle(bottom) -> n9.handle(top) [label="Open"] + n8.handle(bottom) -> MCPServer.n13.handle(top) [label="Forward request"] + n9.handle(top) -> Host.n4.handle(bottom) [label="CircuitOpenError"] + n10.handle(right) -> n11.handle(left) [label="Yes"] + n10.handle(bottom) -> n12.handle(top) [label="No"] + n11.handle(top) -> Host.n4.handle(left) [label="Return result"] + n12.handle(top) -> Host.n4.handle(right) [label="Return error"] +} + +MCPServer { # MCP Server + n13: rectangle label="Attempt tool execution" + n14: rectangle label="Return result or error" + n13.handle(right) -> n14.handle(left) + n14.handle(top) -> CB.n10.handle(bottom) [label="Execution outcome"] +} diff --git a/mcp/devops/mcp-context-proxy/README.md b/mcp/devops/mcp-context-proxy/README.md new file mode 100644 index 0000000000000000000000000000000000000000..e63a6c6cf4c0ef520f7d6a113d6b7a00955474a7 --- /dev/null +++ b/mcp/devops/mcp-context-proxy/README.md @@ -0,0 +1,19 @@ +# MCP Context Proxy Architecture + +A caching and compression layer that sits between agents and MCP servers, intercepting redundant context requests before they hit the wire. Uses TTL-based cache invalidation, Brotli compression, and semantic caching. Can achieve up to 95%+ token reduction and significantly lower LLM bills. + +**Template ID:** `mcp-context-proxy` +**Kind:** architecture +**Source domain:** DevOps +**Primary use case:** mcp +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 7 +**Lanes:** 3 +**Tags:** [mcp, context-proxy, caching, compression, token-optimization, architecture-diagram, production-grade] +**Source path:** `` +**Repo path:** `mcp/devops/mcp-context-proxy` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/mcp/devops/mcp-context-proxy/metadata.json b/mcp/devops/mcp-context-proxy/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..b6252cdb00d310cbb81566ffe1840de61bf43ba2 --- /dev/null +++ b/mcp/devops/mcp-context-proxy/metadata.json @@ -0,0 +1,27 @@ +{ + "template_id": "mcp-context-proxy", + "workflow_id": "mcp-context-proxy", + "title": "MCP Context Proxy Architecture", + "kind": "architecture", + "source_domain": "DevOps", + "primary_use_case": "mcp", + "secondary_use_cases": [], + "use_cases": [ + "mcp" + ], + "complexity": 3, + "num_nodes": 7, + "num_lanes": 3, + "tags": [ + "mcp", + "context-proxy", + "caching", + "compression", + "token-optimization", + "architecture-diagram", + "production-grade" + ], + "description": "A caching and compression layer that sits between agents and MCP servers, intercepting redundant context requests before they hit the wire. Uses TTL-based cache invalidation, Brotli compression, and semantic caching. Can achieve up to 95%+ token reduction and significantly lower LLM bills.", + "source_path": "", + "repo_path": "mcp/devops/mcp-context-proxy" +} diff --git a/mcp/devops/mcp-context-proxy/workflow.fz b/mcp/devops/mcp-context-proxy/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..e3792d9f0157d848227bd518dec3fccaba144452 --- /dev/null +++ b/mcp/devops/mcp-context-proxy/workflow.fz @@ -0,0 +1,32 @@ +Host { # Host Application + n1: circle label="User sends prompt" + n2: rectangle label="Agent requests context" + n3: rectangle label="Receive context" + n4: rectangle label="Agent responds to user" + n1.handle(right) -> n2.handle(left) + n2.handle(bottom) -> Proxy.n5.handle(top) [label="Context request"] + n3.handle(right) -> n4.handle(left) +} + +Proxy { # Context Proxy + n5: rectangle label="Receive context request" + n6: rectangle label="Check cache with TTL" + n7: diamond label="Cache hit?" + n8: rectangle label="Return cached context" + n9: rectangle label="Fetch fresh from MCP server" + n10: rectangle label="Compress and cache response" + n5.handle(right) -> n6.handle(left) + n6.handle(right) -> n7.handle(left) + n7.handle(right) -> n8.handle(left) [label="Hit"] + n7.handle(bottom) -> n9.handle(top) [label="Miss"] + n8.handle(top) -> Host.n3.handle(bottom) [label="Cached context"] + n9.handle(bottom) -> MCPServer.n11.handle(top) [label="Fetch request"] + n10.handle(top) -> Host.n3.handle(left) [label="Fresh context"] +} + +MCPServer { # MCP Server + n11: rectangle label="Fetch full context" + n12: rectangle label="Return fresh data" + n11.handle(right) -> n12.handle(left) + n12.handle(top) -> Proxy.n10.handle(bottom) [label="Fresh data"] +} diff --git a/mcp/devops/mcp-direct-connect/README.md b/mcp/devops/mcp-direct-connect/README.md new file mode 100644 index 0000000000000000000000000000000000000000..78ebda51b04137bfae08b4ad740bf3c1aff5856b --- /dev/null +++ b/mcp/devops/mcp-direct-connect/README.md @@ -0,0 +1,19 @@ +# MCP Direct Connect Architecture + +The simplest MCP pattern — direct connection between host application and MCP server over stdio or HTTP. No extra hops, lowest latency, easiest debugging. Perfect for MVPs, hackathons, and single-team setups where security governance is not yet a concern. + +**Template ID:** `mcp-direct-connect` +**Kind:** architecture +**Source domain:** DevOps +**Primary use case:** mcp +**Secondary use cases:** None +**Complexity:** 1/5 +**Nodes:** 6 +**Lanes:** 2 +**Tags:** [mcp, direct-connect, stdio, http, architecture-diagram, production-grade] +**Source path:** `` +**Repo path:** `mcp/devops/mcp-direct-connect` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/mcp/devops/mcp-direct-connect/metadata.json b/mcp/devops/mcp-direct-connect/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..4c8f591bb01375c83bd27bf6f7ca422d1eddbdb1 --- /dev/null +++ b/mcp/devops/mcp-direct-connect/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "mcp-direct-connect", + "workflow_id": "mcp-direct-connect", + "title": "MCP Direct Connect Architecture", + "kind": "architecture", + "source_domain": "DevOps", + "primary_use_case": "mcp", + "secondary_use_cases": [], + "use_cases": [ + "mcp" + ], + "complexity": 1, + "num_nodes": 6, + "num_lanes": 2, + "tags": [ + "mcp", + "direct-connect", + "stdio", + "http", + "architecture-diagram", + "production-grade" + ], + "description": "The simplest MCP pattern — direct connection between host application and MCP server over stdio or HTTP. No extra hops, lowest latency, easiest debugging. Perfect for MVPs, hackathons, and single-team setups where security governance is not yet a concern.", + "source_path": "", + "repo_path": "mcp/devops/mcp-direct-connect" +} diff --git a/mcp/devops/mcp-direct-connect/workflow.fz b/mcp/devops/mcp-direct-connect/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..7bb53133a5859927204b66da941e632056de349a --- /dev/null +++ b/mcp/devops/mcp-direct-connect/workflow.fz @@ -0,0 +1,20 @@ +Host { # Host Application + n1: circle label="User sends prompt" + n2: rectangle label="Agent builds JSON-RPC request" + n3: rectangle label="Send request via stdio" + n4: rectangle label="Receive JSON-RPC result" + n5: rectangle label="Agent responds to user" + n1.handle(right) -> n2.handle(left) + n2.handle(right) -> n3.handle(left) + n3.handle(bottom) -> MCPServer.n6.handle(top) [label="JSON-RPC request"] + n4.handle(right) -> n5.handle(left) +} + +MCPServer { # MCP Server + n6: rectangle label="Parse incoming request" + n7: rectangle label="Execute tool or resource" + n8: rectangle label="Build JSON-RPC response" + n6.handle(right) -> n7.handle(left) + n7.handle(right) -> n8.handle(left) + n8.handle(top) -> Host.n4.handle(bottom) [label="JSON-RPC response"] +} diff --git a/mcp/patterns/circuit-breaker-workflow/README.md b/mcp/patterns/circuit-breaker-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..e3127702766e4508643106ffcdaed28c2c6ac6e5 --- /dev/null +++ b/mcp/patterns/circuit-breaker-workflow/README.md @@ -0,0 +1,19 @@ +# Circuit Breaker Workflow + +Circuit breaker resilience pattern with closed, open, and half-open states for protecting services from cascading failures with automatic recovery testing. + +**Template ID:** `circuit-breaker-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** mcp +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 19 +**Lanes:** 3 +**Tags:** [circuit-breaker, resilience, fault-tolerance, microservices, hystrix, half-open, fallback] +**Source path:** `patterns/circuit-breaker` +**Repo path:** `mcp/patterns/circuit-breaker-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/mcp/patterns/circuit-breaker-workflow/metadata.json b/mcp/patterns/circuit-breaker-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..88be354e8145441895533d05970c59102ca47244 --- /dev/null +++ b/mcp/patterns/circuit-breaker-workflow/metadata.json @@ -0,0 +1,27 @@ +{ + "template_id": "circuit-breaker-workflow", + "workflow_id": "circuit-breaker", + "title": "Circuit Breaker Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "mcp", + "secondary_use_cases": [], + "use_cases": [ + "mcp" + ], + "complexity": 4, + "num_nodes": 19, + "num_lanes": 3, + "tags": [ + "circuit-breaker", + "resilience", + "fault-tolerance", + "microservices", + "hystrix", + "half-open", + "fallback" + ], + "description": "Circuit breaker resilience pattern with closed, open, and half-open states for protecting services from cascading failures with automatic recovery testing.", + "source_path": "patterns/circuit-breaker", + "repo_path": "mcp/patterns/circuit-breaker-workflow" +} diff --git a/patterns/circuit-breaker/workflow.fz b/mcp/patterns/circuit-breaker-workflow/workflow.fz similarity index 100% rename from patterns/circuit-breaker/workflow.fz rename to mcp/patterns/circuit-breaker-workflow/workflow.fz diff --git a/metadata.csv b/metadata.csv index 49e5c73ab8ceb73695752eef63f2a4048dba5c5a..7d02f0559db18cf304299a4ecd99c1f49029e1bc 100644 --- a/metadata.csv +++ b/metadata.csv @@ -1,201 +1,243 @@ -workflow_id,domain,complexity,num_nodes,num_lanes,tags,description -ab-test-setup,business-operations,3,10,3,ab-testing;experimentation;split-testing;statistical-significance;conversion-optimization;optimizely,"A/B test setup workflow with hypothesis definition, variant creation, traffic allocation, statistical analysis, and winner deployment." -account-deletion,business-operations,3,7,2,account-deletion;user-offboarding;data-cleanup;subscription-cancel;retention-offer;exit-survey,"Account deletion workflow with cancellation reason capture, retention offer, subscription termination, data cleanup, and confirmation email." -api-key-rotation,business-operations,3,10,3,api-key-rotation;security;credential-management;zero-downtime;secrets-manager;compliance,"API key rotation workflow with new key generation, dual-key transition period, client notification, old key deprecation, and audit logging." -billing-dispute,business-operations,4,13,4,billing-dispute;chargeback;refund-request;dispute-resolution;fraud-review;stripe,"Billing dispute workflow with dispute intake, transaction review, fraud analysis, resolution decision, and chargeback response handling." -cohort-analysis,business-operations,4,13,4,cohort-analysis;retention-analysis;user-behavior;ltv;churn-prediction;analytics,"Cohort analysis workflow with user segmentation by signup date, retention curve calculation, LTV projection, and behavioral pattern identification." -community-moderation,business-operations,3,7,2,community-moderation;content-moderation;user-reports;trust-safety;ai-moderation;appeals,"Community content moderation workflow with AI auto-flagging, user reports, human review queue, action enforcement, and appeals handling." -consent-management,business-operations,3,7,2,consent-management;gdpr;cookie-consent;privacy-preferences;opt-in-opt-out;compliance,"User consent management workflow with cookie banner, preference center, consent recording, downstream system sync, and audit trail." -data-export,business-operations,3,10,3,data-export;data-portability;gdpr;bulk-export;async-job;download-link,"User data export workflow with export request, async job processing, data aggregation, secure file generation, and download link delivery." -dunning-flow,business-operations,3,10,3,dunning-flow;collections;overdue-payment;payment-reminder;account-suspension;revenue-recovery,"Dunning collection workflow with escalating reminder emails, grace period management, account suspension, and payment recovery tracking." -email-campaign,business-operations,4,13,4,email-campaign;marketing-automation;mailchimp;segmentation;a-b-testing;deliverability,"Email marketing campaign workflow with audience segmentation, A/B testing, send scheduling, deliverability monitoring, and engagement analytics." -gdpr-deletion,business-operations,4,13,4,gdpr-deletion;right-to-be-forgotten;data-privacy;pii-removal;compliance;dsar,"GDPR data deletion workflow with identity verification, data inventory scan, PII removal across systems, backup purging, and deletion confirmation." -in-app-message,business-operations,2,7,2,in-app-message;product-tours;tooltips;announcements;user-engagement;intercom,"In-app messaging workflow with trigger conditions, audience targeting, message display, user interaction tracking, and conversion measurement." -knowledge-base,business-operations,3,13,4,knowledge-base;help-center;documentation;self-service;article-management;zendesk,"Knowledge base management workflow with article creation, review approval, SEO optimization, version control, and search analytics tracking." -oauth-flow,business-operations,4,13,4,oauth-flow;oauth2;authorization-code;token-exchange;sso;third-party-auth,"OAuth 2.0 authorization code flow with redirect handling, code exchange, token storage, refresh token rotation, and scope management." -payment-failure,business-operations,3,7,2,payment-failure;dunning;retry-logic;card-decline;revenue-recovery;stripe,"Failed payment recovery workflow with smart retry scheduling, dunning email sequence, payment method update prompts, and involuntary churn prevention." -personalization-engine,business-operations,4,20,3,make-com;personalization;segment;braze;ml-recommendations;content-delivery;marketing-automation,"Make.com automation scenario for real-time personalization using Segment events, ML recommendation API, and Braze campaign delivery across email and push channels." -plan-downgrade,business-operations,3,13,4,plan-downgrade;retention;feature-restriction;data-migration;churn-prevention;billing,"Subscription plan downgrade workflow with retention offer, feature restriction warning, data migration handling, and end-of-period scheduling." -plan-upgrade,business-operations,3,10,3,plan-upgrade;upsell;proration;feature-unlock;expansion-revenue;billing,"Subscription plan upgrade workflow with feature comparison, proration calculation, immediate feature unlock, and billing adjustment." -push-notification,business-operations,3,10,3,push-notification;mobile-engagement;firebase-fcm;apns;segmentation;deep-linking,"Mobile push notification workflow with audience targeting, platform routing (iOS/Android), delivery tracking, and engagement analytics." -referral-program,business-operations,3,13,4,referral-program;viral-growth;referral-tracking;reward-fulfillment;affiliate;word-of-mouth,"Customer referral program workflow with unique link generation, referral tracking, conversion validation, and dual-sided reward fulfillment." -review-collection,business-operations,2,7,2,review-collection;customer-feedback;nps;ratings;social-proof;testimonials,"Customer review collection workflow with post-purchase trigger, review request email, rating submission, moderation, and public display." -search-optimization,business-operations,4,13,4,search-optimization;elasticsearch;relevance-tuning;query-analysis;algolia;search-analytics,"Search optimization workflow with query analysis, relevance tuning, synonym management, click-through tracking, and A/B testing of ranking algorithms." -sms-verification,business-operations,3,13,4,sms-verification;otp;twilio;phone-verification;2fa;fraud-prevention,"SMS phone verification workflow with OTP generation, rate limiting, code validation, retry handling, and verification status tracking." -subscription-lifecycle,business-operations,4,10,3,subscription-lifecycle;saas;trial-conversion;renewal;churn-prevention;stripe,"SaaS subscription lifecycle workflow with trial signup, conversion nurturing, payment processing, renewal management, and churn prevention campaigns." -support-ticket,business-operations,3,10,3,support-ticket;helpdesk;zendesk;sla;ticket-routing;customer-service,"Customer support ticket workflow with auto-categorization, SLA tracking, agent assignment, escalation rules, and satisfaction survey." -two-factor-setup,business-operations,2,7,2,two-factor-auth;mfa;totp;authenticator-app;security;account-protection,"Two-factor authentication setup workflow with method selection (TOTP/SMS), QR code generation, backup codes, and verification confirmation." -user-onboarding,business-operations,2,7,2,user-onboarding;activation;product-tour;welcome-email;first-time-user;time-to-value,"New user onboarding workflow with welcome email, profile setup, product tour, first action prompt, and activation milestone tracking." -user-segmentation,business-operations,2,7,2,user-segmentation;audience-targeting;behavioral-cohorts;customer-segments;segment;marketing-automation,"User segmentation workflow with attribute collection, behavioral event tracking, segment rule definition, dynamic membership, and downstream sync." -webhook-integration,business-operations,2,7,2,webhook;event-driven;http-callback;integration;retry-logic;payload-signing,"Webhook integration workflow with endpoint registration, payload signing, delivery attempt, retry with backoff, and delivery status tracking." -webinar-registration,business-operations,3,10,3,webinar;event-registration;zoom;calendar-invite;reminder-sequence;lead-capture,"Webinar registration workflow with signup form, calendar invite, reminder email sequence, attendance tracking, and post-event follow-up." -access-review,devops,4,18,3,access-review;user-access-certification;quarterly-review;manager-approval;compliance;sod-violations;audit,"Quarterly user access review workflow with manager certification, separation of duties validation, remediation tracking, and compliance reporting for audit purposes." -backup-restore,devops,3,10,3,backup-restore;disaster-recovery;rpo-rto;snapshot;data-protection;recovery-testing,"Backup and restore workflow with scheduled backups, offsite replication, retention policy enforcement, restore testing, and RTO/RPO validation." -certificate-renewal,devops,4,19,3,ssl-certificate;tls-renewal;lets-encrypt;certificate-authority;domain-validation;load-balancer;health-check,"SSL/TLS certificate renewal workflow with expiration monitoring, certificate request by type (DV/OV/EV), domain validation, deployment to load balancers, and health check verification with rollback." -chaos-engineering,devops,4,13,4,chaos-engineering;fault-injection;resilience-testing;game-day;blast-radius;steady-state,"Chaos engineering workflow with hypothesis definition, steady-state monitoring, controlled fault injection, blast radius limitation, and resilience validation." -ci-cd-pipeline,devops,4,22,3,ci-cd;continuous-integration;continuous-deployment;github-actions;artifact-registry;staging;production;rollback,"Full CI/CD pipeline with code checkout, linting, unit tests, artifact building, staging deployment, smoke tests, production deployment, and automatic rollback on failure." -database-migration,devops,4,20,4,database-migration;schema-changes;flyway;liquibase;rollback;dba-approval;maintenance-window,"Database schema migration workflow with CI testing, DBA review and approval, maintenance window scheduling, backup snapshots, migration execution, data integrity verification, and automatic rollback." -deployment-rollback,devops,3,10,3,deployment-rollback;version-revert;incident-response;kubernetes;helm-rollback;service-recovery,"Deployment rollback workflow with issue detection, rollback decision, previous version restoration, health verification, and post-mortem documentation." -incident-response,devops,5,23,4,incident-management;on-call;pagerduty;war-room;severity-levels;postmortem;sre,"Production incident response workflow with severity-based routing, war room coordination, incident commander assignment, customer communication, root cause analysis, and postmortem scheduling." -infrastructure-provisioning,devops,4,10,3,infrastructure-provisioning;terraform;iac;cloud-resources;gitops;state-management,"Infrastructure as Code provisioning workflow with Terraform plan, approval gates, state management, resource creation, and drift detection." -load-testing,devops,4,13,4,load-testing;performance-testing;stress-testing;k6;jmeter;capacity-planning,"Load testing workflow with test scenario design, gradual ramp-up, performance metrics collection, bottleneck identification, and capacity recommendations." -monitoring-alert,devops,3,10,3,monitoring-alerting;prometheus;pagerduty;threshold-alerts;anomaly-detection;on-call,"Monitoring and alerting workflow with metric collection, threshold evaluation, alert routing, escalation policies, and incident creation." -on-call-rotation,devops,3,13,4,on-call-rotation;incident-management;pagerduty;escalation;schedule-management;handoff,"On-call rotation workflow with schedule creation, shift handoffs, override management, escalation policies, and fair rotation distribution." -secret-rotation,devops,4,18,3,secret-rotation;vault;kubernetes-secrets;api-keys;database-passwords;certificates;security,"Automated secret rotation workflow with HashiCorp Vault for API keys, database passwords, and certificates including Kubernetes secret updates and rolling service restarts." -security-scan,devops,3,10,3,security-scanning;sast;dast;dependency-check;snyk;devsecops,"Security scanning workflow with SAST, DAST, dependency vulnerability scanning, finding triage, and remediation tracking in CI/CD pipeline." -vulnerability-patch,devops,4,19,3,vulnerability-management;security-patching;cve-triage;cvss-scoring;patch-testing;rollback;compliance,"Security vulnerability patching workflow with CVE scanning, severity-based triage (critical/high/medium), patch testing, staging deployment, and production rollout with rollback capability." -bidirectional-loop,edge-cases,5,16,4,bidirectional;loop;decision,This workflow models circular references between nodes in both directions. -comment-like-labels,edge-cases,1,5,1,comment;like;labels,This workflow models labels that look like code comments. -cross-lane-circular,edge-cases,4,13,4,cross;lane;circular,This workflow models arrows that loop across lanes. -deep-nesting,edge-cases,4,13,4,deep;nesting;parallel,This workflow models lanes that are conceptually nested within each other. -disconnected-lanes,edge-cases,2,7,2,disconnected;lanes;decision;loop,This workflow models lanes that never connect to each other. -duplicate-node-ids,edge-cases,3,10,3,duplicate;node;ids,This workflow models the same node IDs reused in different lanes. -empty-lane,edge-cases,3,10,3,empty;lane,This workflow models a lane with no nodes. -extra-whitespace,edge-cases,5,16,4,extra;whitespace,This workflow models labels that include leading and trailing spaces. -json-in-label,edge-cases,4,13,4,json;in;label,This workflow models a label that contains JSON text. -label-escaping,edge-cases,5,16,4,label;escaping,This workflow models labels containing quotes and special characters. -markdown-in-label,edge-cases,1,5,1,markdown;in;label,This workflow models a label that contains markdown formatting. -max-lanes,edge-cases,3,10,10,max;lanes,This workflow models 10 lanes with simple cross-lane arrows. -max-nodes,edge-cases,2,50,2,max;nodes,This workflow models 50 nodes in a single lane as a parser stress test. -minimal-workflow,edge-cases,2,1,2,minimal;workflow,This workflow models a workflow with a single node only. -missing-labels,edge-cases,4,13,4,missing;labels;decision,This workflow models nodes without label parameters. -orphan-node,edge-cases,1,5,1,orphan;node,This workflow models a node with no connections. -sql-injection-label,edge-cases,2,7,2,sql;injection;label,This workflow models a label that looks like an SQL injection attempt. -unicode-labels,edge-cases,1,5,1,unicode;labels,This workflow models emoji and international characters in labels. -very-long-label,edge-cases,1,5,1,very;long;label;decision;loop,This workflow models labels with very long text. -xml-in-label,edge-cases,5,16,4,xml;in;label,This workflow models a label that contains XML text. -xss-label,edge-cases,3,10,3,xss;label,This workflow models a label that looks like an XSS script. -bank-reconciliation,finance,4,18,3,bank-reconciliation;gl-matching;variance-analysis;journal-entries;auto-matching;discrepancy-resolution,"Bank reconciliation workflow with automated transaction matching, variance reporting, discrepancy research, and journal entry creation for timing differences and bank errors." -budget-approval,finance,4,19,3,budget-approval;financial-planning;tiered-approval;cfo-approval;ceo-approval;board-approval;fund-allocation,"Corporate budget approval workflow with tiered approval routing based on amount thresholds (CFO < $100K, CEO $100K-$1M, Board > $1M), prior year comparison, and fund allocation." -cash-flow-forecast,finance,3,7,2,cash-flow-forecast;liquidity-planning;working-capital;ar-collections;ap-disbursements;treasury,"Cash flow forecasting workflow with AR/AP projections, working capital analysis, liquidity gap identification, and short-term financing recommendations." -cost-center,finance,2,7,2,cost;center;finance;decision,This workflow models managing cost center budgets. -credit-control,finance,3,10,3,credit-control;credit-limit;customer-credit;credit-scoring;collections;accounts-receivable,"Customer credit control workflow with credit limit assessment, credit scoring, order hold management, collections escalation, and payment plan negotiation." -expense-allocation,finance,3,10,3,expense;allocation;finance,This workflow models allocating costs to departments. -expense-claim,finance,3,10,3,expense-reimbursement;employee-expenses;receipt-upload;manager-approval;finance-review;direct-deposit,"Employee expense reimbursement workflow with receipt submission, manager approval, finance review, policy compliance check, and direct deposit payment." -financial-reporting,finance,4,10,3,financial-reporting;gaap-compliance;income-statement;balance-sheet;cash-flow-statement;sec-filing,"Financial reporting workflow with GAAP-compliant statement preparation, management review, audit committee approval, and SEC filing for public companies." -fixed-assets,finance,3,7,2,fixed-assets;asset-tracking;depreciation;capitalization;asset-disposal;physical-inventory,"Fixed asset management workflow with asset capitalization, depreciation scheduling, physical inventory verification, and asset disposal/retirement processing." -insurance-claim,finance,3,7,2,insurance-claim;claim-filing;adjuster-review;settlement;property-damage;liability,"Insurance claim processing workflow with incident documentation, claim filing, adjuster assignment, damage assessment, and settlement negotiation." -internal-controls,finance,4,10,3,internal-controls;sox-compliance;control-testing;segregation-of-duties;risk-assessment;remediation,"Internal controls testing workflow with risk assessment, control design evaluation, operating effectiveness testing, deficiency identification, and remediation tracking." -invoice-processing,finance,4,19,4,accounts-payable;invoice-automation;ocr;po-matching;approval-workflow;payment-processing;three-way-match,"Accounts payable invoice automation with OCR data extraction, three-way PO matching, tiered approval workflow, and automated payment processing with GL updates." -monthly-close,finance,4,22,4,monthly-close;financial-reporting;accounting;reconciliation;trial-balance;period-close,"Corporate month-end financial close process including transaction posting, bank reconciliation, accruals, depreciation, trial balance validation, and financial statement generation." -payment-run,finance,4,18,3,payment-run;accounts-payable;ach-payments;check-run;dual-approval;bank-transfer;vendor-payments,"Accounts payable payment run workflow with batch creation, tiered approval (single/dual based on amount), ACH file generation, check printing, and vendor record updates." -payroll-processing,finance,5,24,4,payroll-processing;salary-calculation;tax-withholding;fica;ach-direct-deposit;benefits-deductions;compliance,"Complete payroll processing workflow with timesheet collection, gross pay calculation, overtime, tax withholding (federal, state, FICA), benefits deductions, compliance validation, and ACH direct deposit." -procurement-card,finance,3,10,3,procurement;card;finance,This workflow models managing company credit cards. -purchase-order,finance,4,22,3,purchase-order;procurement;requisition;vendor-sourcing;competitive-bidding;tiered-approval;budget-validation,"Procurement purchase order workflow with requisition creation, budget validation, vendor sourcing, competitive bidding, and tiered approval routing based on amount thresholds." -tax-filing,finance,4,19,3,tax-filing;corporate-tax;tax-calculation;irs-efile;tax-credits;deductions;compliance,"Corporate tax filing workflow with taxable income calculation, deductions, tax credits, variance review, and electronic or paper filing to IRS with receipt confirmation." -treasury-management,finance,3,7,2,treasury-management;cash-pooling;fx-hedging;investment-portfolio;bank-relationships;liquidity,"Corporate treasury management workflow with cash pooling, FX exposure hedging, short-term investment decisions, and bank relationship management." -vendor-onboarding,finance,4,19,3,vendor-onboarding;supplier-management;w9-verification;insurance-compliance;background-check;payment-terms;procurement,"Vendor onboarding workflow with application review, W-9/W-8BEN verification, insurance certificate validation, background checks, and compliance approval before vendor activation." -yearly-audit,finance,4,10,3,annual-audit;external-auditors;sox-compliance;financial-statements;audit-findings;management-letter,"Annual financial audit workflow with external auditor engagement, document preparation, fieldwork coordination, findings remediation, and management letter response." -background-check,hr,3,7,2,background-check;pre-employment;criminal-history;employment-verification;education-verification;drug-screening,"Pre-employment background check workflow with criminal history search, employment verification, education verification, and drug screening coordination." -bonus-allocation,hr,3,7,2,bonus-allocation;annual-bonus;performance-bonus;budget-pool;calibration;payout,"Annual bonus allocation workflow with budget pool distribution, performance-based calculation, manager calibration, executive approval, and payroll processing." -candidate-rejection,hr,3,10,3,candidate-rejection;hiring-decision;rejection-letter;talent-pool;candidate-experience;ats-update,"Candidate rejection workflow with stage-appropriate messaging, personalized rejection letters, talent pool consideration, ATS status update, and candidate experience feedback." -conflict-resolution,hr,4,10,3,conflict-resolution;workplace-dispute;mediation;hr-investigation;employee-relations;grievance,"Workplace conflict resolution workflow with complaint intake, HR investigation, mediation sessions, resolution documentation, and follow-up monitoring." -diversity-initiative,hr,3,10,3,diversity;initiative;hr,This workflow models promoting workplace diversity. -employee-engagement,hr,2,7,2,employee;engagement;hr;parallel,This workflow models measuring and improving engagement. -expense-approval,hr,3,10,3,expense-approval;travel-expenses;receipt-validation;policy-compliance;tiered-approval;reimbursement,"Employee expense approval workflow with receipt validation, policy compliance check, tiered approval based on amount, and reimbursement processing." -internship-program,hr,2,7,2,internship;program;hr,This workflow models managing an internship program. -interview-process,hr,4,22,3,interview-process;hiring;phone-screen;technical-interview;onsite-panel;talent-acquisition;offer-management,"Multi-stage interview process with resume screening, phone screen, technical interview, onsite panel, team consensus decision, and offer/rejection handling." -job-posting,hr,4,19,3,job-posting;job-requisition;ats;linkedin;indeed;ai-screening;talent-acquisition,"Job posting workflow with requisition approval, job description drafting, multi-channel posting (LinkedIn, Indeed, career sites), AI resume screening, and ATS candidate tracking." -offboarding,hr,4,10,3,employee-offboarding;exit-interview;access-revocation;asset-return;knowledge-transfer;final-paycheck,"Employee offboarding workflow with exit interview, knowledge transfer, asset collection, access revocation, final pay processing, and benefits continuation." -onboarding,hr,4,20,3,employee-onboarding;new-hire;hr-workflow;background-check;it-provisioning;benefits-enrollment,"Complete employee onboarding workflow covering offer acceptance, HR record creation, benefits enrollment, background check verification, IT account provisioning, equipment setup, and first day orientation." -performance-review,hr,4,10,3,performance-review;annual-evaluation;goal-setting;360-feedback;calibration;merit-increase,"Annual performance review workflow with self-assessment, manager evaluation, 360 feedback collection, calibration sessions, and merit increase recommendations." -promotion-process,hr,3,7,2,promotion-process;career-advancement;job-leveling;title-change;compensation-adjustment;succession-planning,"Employee promotion workflow with performance validation, job level assessment, compensation adjustment, title change, and announcement coordination." -pto-request,hr,2,7,2,pto-request;time-off;vacation;leave-management;manager-approval;accrual-balance,"PTO request workflow with balance verification, manager approval, calendar blocking, and team coverage check before approval." -reference-check,hr,3,10,3,reference-check;employment-verification;professional-references;hiring-decision;candidate-vetting;feedback-collection,"Professional reference check workflow with reference collection, outreach scheduling, structured interview questions, feedback documentation, and hiring recommendation." -relocation-assistance,hr,3,10,3,relocation;assistance;hr;decision,This workflow models helping employees relocate. -salary-increase,hr,3,10,3,salary-increase;compensation;merit-raise;market-adjustment;budget-approval;comp-ratio,"Salary increase workflow with market analysis, comp ratio review, budget validation, tiered approval based on increase percentage, and payroll system update." -termination-process,hr,4,20,3,employee-termination;offboarding;separation-agreement;final-pay;cobra;severance;legal-review,"Employee termination workflow handling voluntary and involuntary separations with legal review, separation agreements, final pay calculation, COBRA notices, and severance processing." -training-enrollment,hr,2,7,2,training-enrollment;learning-management;lms;professional-development;compliance-training;certification,"Training enrollment workflow with course catalog browsing, manager approval, LMS registration, completion tracking, and certification management." -carrier-selection,logistics,3,10,3,carrier-selection;rate-shopping;transit-time;service-level;tms;freight-optimization,"Carrier selection workflow with rate shopping, transit time comparison, service level matching, carrier performance scoring, and optimal carrier assignment." -cold-chain-monitoring,logistics,3,7,2,cold-chain;temperature-monitoring;iot-sensors;excursion-alert;pharmaceutical;perishables,"Cold chain monitoring workflow with IoT temperature sensors, real-time alerts, excursion documentation, corrective action triggers, and compliance reporting." -container-loading,logistics,3,7,2,container-loading;load-planning;weight-distribution;cube-utilization;seal-verification;ocean-freight,"Container loading workflow with load plan optimization, weight distribution, cube utilization maximization, seal application, and bill of lading generation." -cross-docking,logistics,3,10,3,cross-docking;flow-through;dock-scheduling;sortation;consolidation;just-in-time,"Cross-docking workflow with inbound scheduling, sortation by destination, outbound consolidation, and direct transfer without storage for just-in-time delivery." -customs-clearance,logistics,4,19,3,customs-clearance;international-trade;customs-broker;hs-codes;import-export;duties-taxes;inspection,"International customs clearance workflow with importer documentation, customs broker HS code classification, duty calculation, customs authority inspection, and clearance certificate issuance." -cycle-counting,logistics,3,10,3,cycle-counting;inventory-accuracy;abc-analysis;variance-investigation;perpetual-inventory;audit,"Inventory cycle counting workflow with ABC classification, count scheduling, variance investigation, adjustment approval, and inventory accuracy tracking." -damaged-goods,logistics,3,7,2,damaged-goods;damage-claim;inventory-write-off;carrier-claim;disposition;loss-prevention,"Damaged goods processing workflow with damage documentation, carrier claim filing, disposition decision (salvage/dispose), inventory adjustment, and loss tracking." -delivery-confirmation,logistics,2,7,2,delivery-confirmation;pod;signature-capture;order-completion;customer-notification;tracking-update,"Delivery confirmation workflow with proof of delivery capture, signature collection, photo documentation, order status update, and customer notification." -fleet-maintenance,logistics,3,7,2,fleet-maintenance;preventive-maintenance;vehicle-inspection;work-order;dot-compliance;telematics,"Fleet maintenance workflow with preventive maintenance scheduling, vehicle inspection, work order creation, parts ordering, and DOT compliance tracking." -hazmat-handling,logistics,4,10,3,hazmat-handling;dangerous-goods;un-classification;sds-documentation;dot-compliance;emergency-response,"Hazardous materials handling workflow with UN classification, SDS documentation, proper labeling, certified handler assignment, and emergency response procedures." -inventory-receipt,logistics,3,7,2,inventory-receipt;goods-receiving;po-matching;asn-verification;dock-scheduling;wms,"Inventory receiving workflow with ASN verification, PO matching, quantity count, damage inspection, and WMS inventory update." -kitting-process,logistics,2,7,2,kitting-process;kit-assembly;bom;component-picking;value-added-services;bundling,"Kit assembly workflow with BOM explosion, component picking, assembly verification, kit labeling, and inventory conversion from components to finished kit." -last-mile-delivery,logistics,3,7,2,last-mile-delivery;route-optimization;proof-of-delivery;delivery-exception;customer-notification;gps-tracking,"Last mile delivery workflow with route optimization, real-time GPS tracking, delivery attempt handling, proof of delivery capture, and customer notification." -packing-process,logistics,2,7,2,order-packing;box-selection;packing-slip;weight-verification;cartonization;fulfillment,"Order packing workflow with carton selection, item verification, packing slip insertion, weight check, and package sealing for shipment." -picking-process,logistics,3,10,3,order-picking;warehouse-management;pick-list;batch-picking;wave-picking;wms,"Warehouse order picking workflow with pick list generation, zone routing, batch picking optimization, barcode scanning verification, and pick completion confirmation." -put-away-process,logistics,2,7,2,put-away;warehouse-storage;location-assignment;slotting;wms;inventory-placement,"Warehouse put-away workflow with location assignment, slotting optimization, forklift routing, barcode confirmation, and WMS location update." -quality-inspection,logistics,3,10,3,quality-inspection;incoming-inspection;aql-sampling;defect-tracking;supplier-quality;hold-release,"Incoming quality inspection workflow with AQL sampling, defect classification, hold/release decision, supplier notification, and quality metrics tracking." -reorder-process,logistics,3,7,2,reorder-process;reorder-point;safety-stock;eoq;demand-planning;auto-replenishment,"Inventory reorder workflow with reorder point monitoring, economic order quantity calculation, safety stock consideration, and automatic purchase requisition generation." -returns-processing,logistics,3,7,2,returns-processing;rma;refund;restocking;quality-inspection;reverse-logistics,"Customer returns processing workflow with RMA generation, return receipt, quality inspection, disposition decision, and refund or exchange processing." -reverse-logistics,logistics,4,10,3,reverse-logistics;product-returns;refurbishment;recycling;disposition;sustainability,"Reverse logistics workflow with return authorization, product grading, refurbishment decision, recycling coordination, and secondary market disposition." -shipping-process,logistics,3,10,3,shipping-process;order-fulfillment;carrier-selection;label-generation;tracking-number;dispatch,"Order shipping workflow with carrier selection, rate shopping, label generation, tracking number assignment, and dispatch confirmation." -stock-transfer,logistics,3,10,3,stock-transfer;inventory-movement;location-transfer;bin-to-bin;wms;inventory-rebalancing,"Internal stock transfer workflow with transfer request, source location pick, destination put-away, and inventory record updates across locations." -warehouse-transfer,logistics,3,10,3,warehouse-transfer;inter-facility;transfer-order;in-transit-inventory;network-optimization;distribution,"Inter-warehouse transfer workflow with transfer order creation, shipping from source DC, in-transit tracking, and receiving at destination warehouse." -a-b-testing,patterns,3,10,3,a;b;testing;patterns,This workflow models comparing two versions to see which performs better. -api-gateway,patterns,3,7,2,api-gateway;microservices;rate-limiting;request-routing;authentication;load-balancing,"API Gateway pattern with request authentication, rate limiting, request routing to backend services, response aggregation, and error handling." -audit-trail,patterns,4,13,4,audit;trail;patterns;decision;loop,This workflow models logging all important actions for compliance. -authentication-flow,patterns,3,7,2,authentication;login;jwt;oauth;mfa;session-management,"User authentication workflow with credential validation, MFA challenge, JWT token generation, session creation, and failed attempt tracking." -authorization-flow,patterns,3,10,3,authorization;flow;patterns,This workflow models checking user permissions before actions run. -batch-processing,patterns,3,7,2,batch-processing;scheduled-jobs;bulk-operations;etl;chunk-processing;job-scheduler,"Batch processing pattern with job scheduling, chunk-based processing, checkpoint/restart capability, error handling, and completion reporting." -blue-green-deploy,patterns,4,13,4,blue-green-deployment;zero-downtime;traffic-switching;rollback;load-balancer;release-management,"Blue-green deployment pattern with parallel environment setup, smoke testing, load balancer traffic switch, and instant rollback capability." -cache-aside,patterns,3,10,3,cache-aside;lazy-loading;cache-miss;cache-invalidation;redis;performance,"Cache-aside pattern with cache lookup, database fallback on miss, cache population, TTL-based expiration, and write-through invalidation." -callback-pattern,patterns,3,10,3,callback;pattern;patterns;decision;loop,This workflow models an async operation that notifies a callback when done. -canary-deploy,patterns,3,7,2,canary-deployment;progressive-rollout;traffic-splitting;metrics-monitoring;gradual-release;feature-flags,"Canary deployment pattern with gradual traffic shifting, real-time metrics monitoring, automatic rollback triggers, and progressive rollout to full production." -circuit-breaker,patterns,4,19,3,circuit-breaker;resilience;fault-tolerance;microservices;hystrix;half-open;fallback,"Circuit breaker resilience pattern with closed, open, and half-open states for protecting services from cascading failures with automatic recovery testing." -claim-check,patterns,2,7,2,claim;check;patterns,This workflow models keeping large payloads external and only passing references. -compensation-transaction,patterns,2,7,2,compensation;transaction;patterns;decision;loop,This workflow models rolling back work when a later step fails. -content-enricher,patterns,3,10,3,content;enricher;patterns;decision,This workflow models adding extra data from other sources. -cqrs,patterns,4,19,4,cqrs;command-query-separation;event-sourcing;read-model;write-model;domain-events;eventual-consistency,"CQRS (Command Query Responsibility Segregation) pattern with separate command and query paths, domain event publishing, read model synchronization, and DTO transformation." -crud-user-browser-server,patterns,2,7,2,crud;user;browser;server;patterns,"This workflow models user creates, reads, updates, and deletes data through a browser and server." -dead-letter-queue,patterns,3,7,2,dead-letter-queue;dlq;message-retry;poison-message;error-handling;message-queue,"Dead letter queue pattern for handling failed messages with retry exhaustion detection, DLQ routing, manual inspection, and reprocessing capability." -decision-diamond,patterns,3,10,3,decision;diamond;patterns,This workflow models an if or then style branch for approval or rejection. -enricher,patterns,3,10,3,enricher;patterns,This workflow models adding metadata to messages before passing them on. -error-retry-loop,patterns,2,7,2,error;retry;loop;patterns,This workflow models a failed operation that retries with backoff. -escalation-pattern,patterns,3,10,3,escalation;pattern;patterns,This workflow models escalating issues to higher authority when needed. -event-driven,patterns,3,10,3,event;driven;patterns,This workflow models reacting to incoming business events. -event-sourcing,patterns,4,10,3,event-sourcing;event-store;aggregate;replay;audit-log;temporal-query,"Event sourcing pattern with event capture, event store persistence, aggregate reconstruction, snapshot optimization, and temporal state queries." -fan-out-fan-in,patterns,4,13,4,fan-out-fan-in;scatter-gather;parallel-processing;aggregation;map-reduce;concurrency,"Fan-out/fan-in pattern with work distribution to parallel workers, concurrent execution, result aggregation, and error handling for partial failures." -feature-toggle,patterns,3,10,3,feature-toggle;feature-flags;dark-launch;a-b-testing;gradual-rollout;kill-switch,"Feature toggle pattern with flag configuration, user targeting rules, percentage rollouts, and instant kill-switch capability for production features." -filter,patterns,4,13,4,filter;patterns;decision;loop,This workflow models removing items that do not meet criteria. -idempotent-consumer,patterns,3,10,3,idempotent;consumer;patterns,This workflow models processing each message safely only once. -materialized-view,patterns,4,13,4,materialized;view;patterns;decision;loop,This workflow models serving queries from a precomputed view. -message-queue,patterns,3,10,3,message;queue;patterns;decision,This workflow models asynchronous processing of work via a queue. -nested-decisions,patterns,3,10,3,nested;decisions;patterns;decision;loop,This workflow models multiple layers of decisions before completion. -normalizer,patterns,4,13,4,normalizer;patterns,This workflow models converting varied inputs to a standard format. -notification-pattern,patterns,2,7,2,notification;pattern;patterns,This workflow models sending alerts via multiple channels. -parallel-execution,patterns,4,13,4,parallel;execution;patterns;loop,This workflow models multiple tasks that run at the same time. -polling-pattern,patterns,4,13,4,polling;pattern;patterns;loop,This workflow models periodically checking status until work is done. -process-manager,patterns,3,10,3,process;manager;patterns,This workflow models orchestrating multiple services to complete a process. -pub-sub,patterns,4,13,4,pub;sub;patterns,This workflow models one publisher notifying many subscribers of events. -rate-limiter,patterns,4,13,4,rate;limiter;patterns,This workflow models preventing too many requests from being processed. -request-reply,patterns,2,7,2,request;reply;patterns,This workflow models a synchronous request that waits for a reply. -retry-with-backoff,patterns,4,20,3,retry-pattern;exponential-backoff;fault-tolerance;api-resilience;transient-errors;http-retry;jitter,"Exponential backoff retry pattern for API calls with configurable retry limits, delay calculation, retryable error detection, and graceful degradation on permanent failures." -router,patterns,3,10,3,router;patterns;decision,This workflow models routing messages based on their content. -routing-slip,patterns,4,13,4,routing;slip;patterns,This workflow models having messages carry their own routing instructions. -saga-pattern,patterns,5,20,4,saga-pattern;distributed-transactions;microservices;compensation;orchestration;eventual-consistency;rollback,"Saga orchestration pattern for distributed transactions across Order, Payment, and Shipping services with automatic compensation rollback on failures." -snapshot-pattern,patterns,2,7,2,snapshot;pattern;patterns;decision;loop,This workflow models taking periodic snapshots of important state. -state-machine,patterns,4,13,4,state;machine;patterns;parallel,This workflow models tracking object state changes over time. -strangler-fig,patterns,2,7,2,strangler;fig;patterns;decision,This workflow models gradually replacing an old system with a new one. -timeout-pattern,patterns,4,13,4,timeout;pattern;patterns,This workflow models an operation that times out after a delay. -transactional-outbox,patterns,4,13,4,transactional;outbox;patterns;parallel,This workflow models writing data and publishing messages in one transaction. -transform,patterns,2,7,2,transform;patterns,This workflow models converting messages into a new shape. -validator,patterns,2,7,2,validator;patterns;parallel,This workflow models checking that incoming data is valid. -webhook-pattern,patterns,2,7,2,webhook;pattern;patterns;decision;loop,This workflow models an HTTP callback when an event occurs. -01-basic-lane,syntax-primitives,1,5,1,01;basic;lane,This workflow models two connected nodes in a single lane showing basic flow. -02-handle-positions,syntax-primitives,1,5,1,02;handle;positions,"This workflow models nodes with explicit top, bottom, left, and right handle connections." -03-all-shapes,syntax-primitives,1,5,1,03;all;shapes,"This workflow models a workflow that demonstrates circle, rectangle, diamond, and taskbox shapes." -04-labeled-arrows,syntax-primitives,1,5,1,04;labeled;arrows,This workflow models connections with descriptive labels between nodes. -05-multiple-lanes,syntax-primitives,1,5,3,05;multiple;lanes,This workflow models three lanes with cross-lane communication. -06-nested-lanes,syntax-primitives,1,5,3,06;nested;lanes,This workflow models lanes that conceptually contain other lanes. -07-unicode-labels,syntax-primitives,1,5,1,07;unicode;labels,This workflow models a workflow with emoji and international characters in labels. -08-empty-lane,syntax-primitives,1,5,1,08;empty;lane,This workflow models a lane with no nodes to test empty-lane handling. -09-cross-lane-circular,syntax-primitives,1,5,1,09;cross;lane;circular,This workflow models an arrow that loops back across lanes in a circular fashion. -10-long-labels,syntax-primitives,1,5,1,10;long;labels,This workflow models labels with extra-long descriptive text. -11-taskbox-complete,syntax-primitives,2,7,2,11;taskbox;complete,"This workflow models a taskbox with owner, description, and system parameters." -12-bidirectional-arrows,syntax-primitives,2,7,2,12;bidirectional;arrows,This workflow models two-way connections between the same pair of nodes. -13-parallel-flows,syntax-primitives,2,7,2,13;parallel;flows,This workflow models one node splitting into three parallel tasks. -14-error-handling,syntax-primitives,2,7,2,14;error;handling,This workflow models a try and retry style pattern for handling errors. -15-optional-parameters,syntax-primitives,2,7,2,15;optional;parameters,This workflow models a taskbox with some optional fields left out. -16-max-nodes,syntax-primitives,2,50,2,16;max;nodes,This workflow models 50 nodes in one lane as a stress test. -17-minimal-nodes,syntax-primitives,2,1,1,17;minimal;nodes,This workflow models a workflow with a single start node only. -18-complex-handles,syntax-primitives,2,7,2,18;complex;handles,This workflow models a workflow that uses every handle position in one diagram. -19-label-escaping,syntax-primitives,2,7,2,19;label;escaping,This workflow models labels that include quotes and special characters. -20-syntax-complete,syntax-primitives,2,7,3,20;syntax;complete,This workflow models one workflow using most available language features. +template_id,workflow_id,title,kind,source_domain,primary_use_case,secondary_use_cases,use_cases,complexity,num_nodes,num_lanes,tags,description,source_path,repo_path +a-b-testing-workflow,a-b-testing,A B Testing Workflow,workflow,patterns,uncategorized,,,3,10,3,a;b;testing;patterns,This workflow models comparing two versions to see which performs better.,patterns/a-b-testing,uncategorized/patterns/a-b-testing-workflow +ab-test-setup-workflow,ab-test-setup,Ab Test Setup Workflow,workflow,business-operations,onboarding,,onboarding,3,10,3,ab-testing;experimentation;split-testing;statistical-significance;conversion-optimization;optimizely,"A/B test setup workflow with hypothesis definition, variant creation, traffic allocation, statistical analysis, and winner deployment.",business-operations/ab-test-setup,onboarding/business-operations/ab-test-setup-workflow +access-review-workflow,access-review,Access Review Workflow,workflow,devops,approval,compliance,approval;compliance,4,18,3,access-review;user-access-certification;quarterly-review;manager-approval;compliance;sod-violations;audit,"Quarterly user access review workflow with manager certification, separation of duties validation, remediation tracking, and compliance reporting for audit purposes.",devops/access-review,approval/devops/access-review-workflow +account-deletion-workflow,account-deletion,Account Deletion Workflow,workflow,business-operations,offboarding,billing,offboarding;billing,3,7,2,account-deletion;user-offboarding;data-cleanup;subscription-cancel;retention-offer;exit-survey,"Account deletion workflow with cancellation reason capture, retention offer, subscription termination, data cleanup, and confirmation email.",business-operations/account-deletion,offboarding/business-operations/account-deletion-workflow +api-gateway-workflow,api-gateway,Api Gateway Workflow,workflow,patterns,handoff,security;mcp,handoff;security;mcp,3,7,2,api-gateway;microservices;rate-limiting;request-routing;authentication;load-balancing,"API Gateway pattern with request authentication, rate limiting, request routing to backend services, response aggregation, and error handling.",patterns/api-gateway,handoff/patterns/api-gateway-workflow +api-key-rotation-workflow,api-key-rotation,Api Key Rotation Workflow,workflow,business-operations,security,compliance,security;compliance,3,10,3,api-key-rotation;security;credential-management;zero-downtime;secrets-manager;compliance,"API key rotation workflow with new key generation, dual-key transition period, client notification, old key deprecation, and audit logging.",business-operations/api-key-rotation,security/business-operations/api-key-rotation-workflow +audit-trail-workflow,audit-trail,Audit Trail Workflow,workflow,patterns,compliance,,compliance,4,13,4,audit;trail;patterns;decision;loop,This workflow models logging all important actions for compliance.,patterns/audit-trail,compliance/patterns/audit-trail-workflow +authentication-flow-workflow,authentication-flow,Authentication Flow Workflow,workflow,patterns,security,,security,3,7,2,authentication;login;jwt;oauth;mfa;session-management,"User authentication workflow with credential validation, MFA challenge, JWT token generation, session creation, and failed attempt tracking.",patterns/authentication-flow,security/patterns/authentication-flow-workflow +authorization-flow-workflow,authorization-flow,Authorization Flow Workflow,workflow,patterns,approval,security,approval;security,3,10,3,authorization;flow;patterns,This workflow models checking user permissions before actions run.,patterns/authorization-flow,approval/patterns/authorization-flow-workflow +background-check-workflow,background-check,Background Check Workflow,workflow,hr,uncategorized,,,3,7,2,background-check;pre-employment;criminal-history;employment-verification;education-verification;drug-screening,"Pre-employment background check workflow with criminal history search, employment verification, education verification, and drug screening coordination.",hr/background-check,uncategorized/hr/background-check-workflow +backup-restore-workflow,backup-restore,Backup Restore Workflow,workflow,devops,delivery,,delivery,3,10,3,backup-restore;disaster-recovery;rpo-rto;snapshot;data-protection;recovery-testing,"Backup and restore workflow with scheduled backups, offsite replication, retention policy enforcement, restore testing, and RTO/RPO validation.",devops/backup-restore,delivery/devops/backup-restore-workflow +bank-reconciliation-workflow,bank-reconciliation,Bank Reconciliation Workflow,workflow,finance,uncategorized,,,4,18,3,bank-reconciliation;gl-matching;variance-analysis;journal-entries;auto-matching;discrepancy-resolution,"Bank reconciliation workflow with automated transaction matching, variance reporting, discrepancy research, and journal entry creation for timing differences and bank errors.",finance/bank-reconciliation,uncategorized/finance/bank-reconciliation-workflow +batch-processing-workflow,batch-processing,Batch Processing Workflow,workflow,patterns,uncategorized,,,3,7,2,batch-processing;scheduled-jobs;bulk-operations;etl;chunk-processing;job-scheduler,"Batch processing pattern with job scheduling, chunk-based processing, checkpoint/restart capability, error handling, and completion reporting.",patterns/batch-processing,uncategorized/patterns/batch-processing-workflow +billing-dispute-workflow,billing-dispute,Billing Dispute Workflow,workflow,business-operations,approval,billing,approval;billing,4,13,4,billing-dispute;chargeback;refund-request;dispute-resolution;fraud-review;stripe,"Billing dispute workflow with dispute intake, transaction review, fraud analysis, resolution decision, and chargeback response handling.",business-operations/billing-dispute,approval/business-operations/billing-dispute-workflow +blue-green-deploy-workflow,blue-green-deploy,Blue Green Deploy Workflow,workflow,patterns,delivery,,delivery,4,13,4,blue-green-deployment;zero-downtime;traffic-switching;rollback;load-balancer;release-management,"Blue-green deployment pattern with parallel environment setup, smoke testing, load balancer traffic switch, and instant rollback capability.",patterns/blue-green-deploy,delivery/patterns/blue-green-deploy-workflow +bonus-allocation-workflow,bonus-allocation,Bonus Allocation Workflow,workflow,hr,uncategorized,,,3,7,2,bonus-allocation;annual-bonus;performance-bonus;budget-pool;calibration;payout,"Annual bonus allocation workflow with budget pool distribution, performance-based calculation, manager calibration, executive approval, and payroll processing.",hr/bonus-allocation,uncategorized/hr/bonus-allocation-workflow +budget-approval-workflow,budget-approval,Budget Approval Workflow,workflow,finance,approval,,approval,4,19,3,budget-approval;financial-planning;tiered-approval;cfo-approval;ceo-approval;board-approval;fund-allocation,"Corporate budget approval workflow with tiered approval routing based on amount thresholds (CFO < $100K, CEO $100K-$1M, Board > $1M), prior year comparison, and fund allocation.",finance/budget-approval,approval/finance/budget-approval-workflow +cache-aside-workflow,cache-aside,Cache Aside Workflow,workflow,patterns,uncategorized,,,3,10,3,cache-aside;lazy-loading;cache-miss;cache-invalidation;redis;performance,"Cache-aside pattern with cache lookup, database fallback on miss, cache population, TTL-based expiration, and write-through invalidation.",patterns/cache-aside,uncategorized/patterns/cache-aside-workflow +callback-pattern-workflow,callback-pattern,Callback Pattern Workflow,workflow,patterns,uncategorized,,,3,10,3,callback;pattern;patterns;decision;loop,This workflow models an async operation that notifies a callback when done.,patterns/callback-pattern,uncategorized/patterns/callback-pattern-workflow +canary-deploy-workflow,canary-deploy,Canary Deploy Workflow,workflow,patterns,incident,delivery,incident;delivery,3,7,2,canary-deployment;progressive-rollout;traffic-splitting;metrics-monitoring;gradual-release;feature-flags,"Canary deployment pattern with gradual traffic shifting, real-time metrics monitoring, automatic rollback triggers, and progressive rollout to full production.",patterns/canary-deploy,incident/patterns/canary-deploy-workflow +candidate-rejection-workflow,candidate-rejection,Candidate Rejection Workflow,workflow,hr,uncategorized,,,3,10,3,candidate-rejection;hiring-decision;rejection-letter;talent-pool;candidate-experience;ats-update,"Candidate rejection workflow with stage-appropriate messaging, personalized rejection letters, talent pool consideration, ATS status update, and candidate experience feedback.",hr/candidate-rejection,uncategorized/hr/candidate-rejection-workflow +carrier-selection-workflow,carrier-selection,Carrier Selection Workflow,workflow,logistics,uncategorized,,,3,10,3,carrier-selection;rate-shopping;transit-time;service-level;tms;freight-optimization,"Carrier selection workflow with rate shopping, transit time comparison, service level matching, carrier performance scoring, and optimal carrier assignment.",logistics/carrier-selection,uncategorized/logistics/carrier-selection-workflow +cash-flow-forecast-workflow,cash-flow-forecast,Cash Flow Forecast Workflow,workflow,finance,uncategorized,,,3,7,2,cash-flow-forecast;liquidity-planning;working-capital;ar-collections;ap-disbursements;treasury,"Cash flow forecasting workflow with AR/AP projections, working capital analysis, liquidity gap identification, and short-term financing recommendations.",finance/cash-flow-forecast,uncategorized/finance/cash-flow-forecast-workflow +certificate-renewal-workflow,certificate-renewal,Certificate Renewal Workflow,workflow,devops,security,,security,4,19,3,ssl-certificate;tls-renewal;lets-encrypt;certificate-authority;domain-validation;load-balancer;health-check,"SSL/TLS certificate renewal workflow with expiration monitoring, certificate request by type (DV/OV/EV), domain validation, deployment to load balancers, and health check verification with rollback.",devops/certificate-renewal,security/devops/certificate-renewal-workflow +chaos-engineering-workflow,chaos-engineering,Chaos Engineering Workflow,workflow,devops,uncategorized,,,4,13,4,chaos-engineering;fault-injection;resilience-testing;game-day;blast-radius;steady-state,"Chaos engineering workflow with hypothesis definition, steady-state monitoring, controlled fault injection, blast radius limitation, and resilience validation.",devops/chaos-engineering,uncategorized/devops/chaos-engineering-workflow +ci-cd-pipeline-workflow,ci-cd-pipeline,Ci Cd Pipeline Workflow,workflow,devops,delivery,,delivery,4,22,3,ci-cd;continuous-integration;continuous-deployment;github-actions;artifact-registry;staging;production;rollback,"Full CI/CD pipeline with code checkout, linting, unit tests, artifact building, staging deployment, smoke tests, production deployment, and automatic rollback on failure.",devops/ci-cd-pipeline,delivery/devops/ci-cd-pipeline-workflow +circuit-breaker-workflow,circuit-breaker,Circuit Breaker Workflow,workflow,patterns,mcp,,mcp,4,19,3,circuit-breaker;resilience;fault-tolerance;microservices;hystrix;half-open;fallback,"Circuit breaker resilience pattern with closed, open, and half-open states for protecting services from cascading failures with automatic recovery testing.",patterns/circuit-breaker,mcp/patterns/circuit-breaker-workflow +claim-check-workflow,claim-check,Claim Check Workflow,workflow,patterns,uncategorized,,,2,7,2,claim;check;patterns,This workflow models keeping large payloads external and only passing references.,patterns/claim-check,uncategorized/patterns/claim-check-workflow +cohort-analysis-workflow,cohort-analysis,Cohort Analysis Workflow,workflow,business-operations,uncategorized,,,4,13,4,cohort-analysis;retention-analysis;user-behavior;ltv;churn-prediction;analytics,"Cohort analysis workflow with user segmentation by signup date, retention curve calculation, LTV projection, and behavioral pattern identification.",business-operations/cohort-analysis,uncategorized/business-operations/cohort-analysis-workflow +cold-chain-monitoring-workflow,cold-chain-monitoring,Cold Chain Monitoring Workflow,workflow,logistics,incident,,incident,3,7,2,cold-chain;temperature-monitoring;iot-sensors;excursion-alert;pharmaceutical;perishables,"Cold chain monitoring workflow with IoT temperature sensors, real-time alerts, excursion documentation, corrective action triggers, and compliance reporting.",logistics/cold-chain-monitoring,incident/logistics/cold-chain-monitoring-workflow +community-moderation-workflow,community-moderation,Community Moderation Workflow,workflow,business-operations,uncategorized,,,3,7,2,community-moderation;content-moderation;user-reports;trust-safety;ai-moderation;appeals,"Community content moderation workflow with AI auto-flagging, user reports, human review queue, action enforcement, and appeals handling.",business-operations/community-moderation,uncategorized/business-operations/community-moderation-workflow +compensation-transaction-workflow,compensation-transaction,Compensation Transaction Workflow,workflow,patterns,uncategorized,,,2,7,2,compensation;transaction;patterns;decision;loop,This workflow models rolling back work when a later step fails.,patterns/compensation-transaction,uncategorized/patterns/compensation-transaction-workflow +conflict-resolution-workflow,conflict-resolution,Conflict Resolution Workflow,workflow,hr,billing,,billing,4,10,3,conflict-resolution;workplace-dispute;mediation;hr-investigation;employee-relations;grievance,"Workplace conflict resolution workflow with complaint intake, HR investigation, mediation sessions, resolution documentation, and follow-up monitoring.",hr/conflict-resolution,billing/hr/conflict-resolution-workflow +consent-management-workflow,consent-management,Consent Management Workflow,workflow,business-operations,compliance,,compliance,3,7,2,consent-management;gdpr;cookie-consent;privacy-preferences;opt-in-opt-out;compliance,"User consent management workflow with cookie banner, preference center, consent recording, downstream system sync, and audit trail.",business-operations/consent-management,compliance/business-operations/consent-management-workflow +container-loading-workflow,container-loading,Container Loading Workflow,workflow,logistics,uncategorized,,,3,7,2,container-loading;load-planning;weight-distribution;cube-utilization;seal-verification;ocean-freight,"Container loading workflow with load plan optimization, weight distribution, cube utilization maximization, seal application, and bill of lading generation.",logistics/container-loading,uncategorized/logistics/container-loading-workflow +content-enricher-workflow,content-enricher,Content Enricher Workflow,workflow,patterns,uncategorized,,,3,10,3,content;enricher;patterns;decision,This workflow models adding extra data from other sources.,patterns/content-enricher,uncategorized/patterns/content-enricher-workflow +cost-center-workflow,cost-center,Cost Center Workflow,workflow,finance,uncategorized,,,2,7,2,cost;center;finance;decision,This workflow models managing cost center budgets.,finance/cost-center,uncategorized/finance/cost-center-workflow +cqrs-workflow,cqrs,Cqrs Workflow,workflow,patterns,uncategorized,,,4,19,4,cqrs;command-query-separation;event-sourcing;read-model;write-model;domain-events;eventual-consistency,"CQRS (Command Query Responsibility Segregation) pattern with separate command and query paths, domain event publishing, read model synchronization, and DTO transformation.",patterns/cqrs,uncategorized/patterns/cqrs-workflow +credit-control-workflow,credit-control,Credit Control Workflow,workflow,finance,uncategorized,,,3,10,3,credit-control;credit-limit;customer-credit;credit-scoring;collections;accounts-receivable,"Customer credit control workflow with credit limit assessment, credit scoring, order hold management, collections escalation, and payment plan negotiation.",finance/credit-control,uncategorized/finance/credit-control-workflow +cross-docking-workflow,cross-docking,Cross Docking Workflow,workflow,logistics,uncategorized,,,3,10,3,cross-docking;flow-through;dock-scheduling;sortation;consolidation;just-in-time,"Cross-docking workflow with inbound scheduling, sortation by destination, outbound consolidation, and direct transfer without storage for just-in-time delivery.",logistics/cross-docking,uncategorized/logistics/cross-docking-workflow +crud-user-browser-server-workflow,crud-user-browser-server,Crud User Browser Server Workflow,workflow,patterns,uncategorized,,,2,7,2,crud;user;browser;server;patterns,"This workflow models user creates, reads, updates, and deletes data through a browser and server.",patterns/crud-user-browser-server,uncategorized/patterns/crud-user-browser-server-workflow +customs-clearance-workflow,customs-clearance,Customs Clearance Workflow,workflow,logistics,uncategorized,,,4,19,3,customs-clearance;international-trade;customs-broker;hs-codes;import-export;duties-taxes;inspection,"International customs clearance workflow with importer documentation, customs broker HS code classification, duty calculation, customs authority inspection, and clearance certificate issuance.",logistics/customs-clearance,uncategorized/logistics/customs-clearance-workflow +cycle-counting-workflow,cycle-counting,Cycle Counting Workflow,workflow,logistics,compliance,,compliance,3,10,3,cycle-counting;inventory-accuracy;abc-analysis;variance-investigation;perpetual-inventory;audit,"Inventory cycle counting workflow with ABC classification, count scheduling, variance investigation, adjustment approval, and inventory accuracy tracking.",logistics/cycle-counting,compliance/logistics/cycle-counting-workflow +damaged-goods-workflow,damaged-goods,Damaged Goods Workflow,workflow,logistics,uncategorized,,,3,7,2,damaged-goods;damage-claim;inventory-write-off;carrier-claim;disposition;loss-prevention,"Damaged goods processing workflow with damage documentation, carrier claim filing, disposition decision (salvage/dispose), inventory adjustment, and loss tracking.",logistics/damaged-goods,uncategorized/logistics/damaged-goods-workflow +data-export-workflow,data-export,Data Export Workflow,workflow,business-operations,compliance,,compliance,3,10,3,data-export;data-portability;gdpr;bulk-export;async-job;download-link,"User data export workflow with export request, async job processing, data aggregation, secure file generation, and download link delivery.",business-operations/data-export,compliance/business-operations/data-export-workflow +database-migration-workflow,database-migration,Database Migration Workflow,workflow,devops,approval,delivery,approval;delivery,4,20,4,database-migration;schema-changes;flyway;liquibase;rollback;dba-approval;maintenance-window,"Database schema migration workflow with CI testing, DBA review and approval, maintenance window scheduling, backup snapshots, migration execution, data integrity verification, and automatic rollback.",devops/database-migration,approval/devops/database-migration-workflow +dead-letter-queue-workflow,dead-letter-queue,Dead Letter Queue Workflow,workflow,patterns,uncategorized,,,3,7,2,dead-letter-queue;dlq;message-retry;poison-message;error-handling;message-queue,"Dead letter queue pattern for handling failed messages with retry exhaustion detection, DLQ routing, manual inspection, and reprocessing capability.",patterns/dead-letter-queue,uncategorized/patterns/dead-letter-queue-workflow +decision-diamond-workflow,decision-diamond,Decision Diamond Workflow,workflow,patterns,uncategorized,,,3,10,3,decision;diamond;patterns,This workflow models an if or then style branch for approval or rejection.,patterns/decision-diamond,uncategorized/patterns/decision-diamond-workflow +delivery-confirmation-workflow,delivery-confirmation,Delivery Confirmation Workflow,workflow,logistics,uncategorized,,,2,7,2,delivery-confirmation;pod;signature-capture;order-completion;customer-notification;tracking-update,"Delivery confirmation workflow with proof of delivery capture, signature collection, photo documentation, order status update, and customer notification.",logistics/delivery-confirmation,uncategorized/logistics/delivery-confirmation-workflow +deployment-rollback-workflow,deployment-rollback,Deployment Rollback Workflow,workflow,devops,incident,delivery,incident;delivery,3,10,3,deployment-rollback;version-revert;incident-response;kubernetes;helm-rollback;service-recovery,"Deployment rollback workflow with issue detection, rollback decision, previous version restoration, health verification, and post-mortem documentation.",devops/deployment-rollback,incident/devops/deployment-rollback-workflow +diversity-initiative-workflow,diversity-initiative,Diversity Initiative Workflow,workflow,hr,uncategorized,,,3,10,3,diversity;initiative;hr,This workflow models promoting workplace diversity.,hr/diversity-initiative,uncategorized/hr/diversity-initiative-workflow +dunning-flow-workflow,dunning-flow,Dunning Flow Workflow,workflow,business-operations,billing,,billing,3,10,3,dunning-flow;collections;overdue-payment;payment-reminder;account-suspension;revenue-recovery,"Dunning collection workflow with escalating reminder emails, grace period management, account suspension, and payment recovery tracking.",business-operations/dunning-flow,billing/business-operations/dunning-flow-workflow +email-campaign-workflow,email-campaign,Email Campaign Workflow,workflow,business-operations,uncategorized,,,4,13,4,email-campaign;marketing-automation;mailchimp;segmentation;a-b-testing;deliverability,"Email marketing campaign workflow with audience segmentation, A/B testing, send scheduling, deliverability monitoring, and engagement analytics.",business-operations/email-campaign,uncategorized/business-operations/email-campaign-workflow +employee-engagement-workflow,employee-engagement,Employee Engagement Workflow,workflow,hr,uncategorized,,,2,7,2,employee;engagement;hr;parallel,This workflow models measuring and improving engagement.,hr/employee-engagement,uncategorized/hr/employee-engagement-workflow +enricher-workflow,enricher,Enricher Workflow,workflow,patterns,uncategorized,,,3,10,3,enricher;patterns,This workflow models adding metadata to messages before passing them on.,patterns/enricher,uncategorized/patterns/enricher-workflow +error-retry-loop-workflow,error-retry-loop,Error Retry Loop Workflow,workflow,patterns,uncategorized,,,2,7,2,error;retry;loop;patterns,This workflow models a failed operation that retries with backoff.,patterns/error-retry-loop,uncategorized/patterns/error-retry-loop-workflow +escalation-pattern-workflow,escalation-pattern,Escalation Pattern Workflow,workflow,patterns,handoff,,handoff,3,10,3,escalation;pattern;patterns,This workflow models escalating issues to higher authority when needed.,patterns/escalation-pattern,handoff/patterns/escalation-pattern-workflow +event-driven-workflow,event-driven,Event Driven Workflow,workflow,patterns,uncategorized,,,3,10,3,event;driven;patterns,This workflow models reacting to incoming business events.,patterns/event-driven,uncategorized/patterns/event-driven-workflow +event-sourcing-workflow,event-sourcing,Event Sourcing Workflow,workflow,patterns,compliance,,compliance,4,10,3,event-sourcing;event-store;aggregate;replay;audit-log;temporal-query,"Event sourcing pattern with event capture, event store persistence, aggregate reconstruction, snapshot optimization, and temporal state queries.",patterns/event-sourcing,compliance/patterns/event-sourcing-workflow +expense-allocation-workflow,expense-allocation,Expense Allocation Workflow,workflow,finance,uncategorized,,,3,10,3,expense;allocation;finance,This workflow models allocating costs to departments.,finance/expense-allocation,uncategorized/finance/expense-allocation-workflow +expense-approval-workflow,expense-approval,Expense Approval Workflow,workflow,hr,approval,compliance,approval;compliance,3,10,3,expense-approval;travel-expenses;receipt-validation;policy-compliance;tiered-approval;reimbursement,"Employee expense approval workflow with receipt validation, policy compliance check, tiered approval based on amount, and reimbursement processing.",hr/expense-approval,approval/hr/expense-approval-workflow +expense-claim-workflow,expense-claim,Expense Claim Workflow,workflow,finance,approval,,approval,3,10,3,expense-reimbursement;employee-expenses;receipt-upload;manager-approval;finance-review;direct-deposit,"Employee expense reimbursement workflow with receipt submission, manager approval, finance review, policy compliance check, and direct deposit payment.",finance/expense-claim,approval/finance/expense-claim-workflow +fan-out-fan-in-workflow,fan-out-fan-in,Fan Out Fan In Workflow,workflow,patterns,ai-orchestration,,ai-orchestration,4,13,4,fan-out-fan-in;scatter-gather;parallel-processing;aggregation;map-reduce;concurrency,"Fan-out/fan-in pattern with work distribution to parallel workers, concurrent execution, result aggregation, and error handling for partial failures.",patterns/fan-out-fan-in,ai-orchestration/patterns/fan-out-fan-in-workflow +feature-toggle-workflow,feature-toggle,Feature Toggle Workflow,workflow,patterns,uncategorized,,,3,10,3,feature-toggle;feature-flags;dark-launch;a-b-testing;gradual-rollout;kill-switch,"Feature toggle pattern with flag configuration, user targeting rules, percentage rollouts, and instant kill-switch capability for production features.",patterns/feature-toggle,uncategorized/patterns/feature-toggle-workflow +filter-workflow,filter,Filter Workflow,workflow,patterns,uncategorized,,,4,13,4,filter;patterns;decision;loop,This workflow models removing items that do not meet criteria.,patterns/filter,uncategorized/patterns/filter-workflow +financial-reporting-workflow,financial-reporting,Financial Reporting Workflow,workflow,finance,compliance,,compliance,4,10,3,financial-reporting;gaap-compliance;income-statement;balance-sheet;cash-flow-statement;sec-filing,"Financial reporting workflow with GAAP-compliant statement preparation, management review, audit committee approval, and SEC filing for public companies.",finance/financial-reporting,compliance/finance/financial-reporting-workflow +fixed-assets-workflow,fixed-assets,Fixed Assets Workflow,workflow,finance,uncategorized,,,3,7,2,fixed-assets;asset-tracking;depreciation;capitalization;asset-disposal;physical-inventory,"Fixed asset management workflow with asset capitalization, depreciation scheduling, physical inventory verification, and asset disposal/retirement processing.",finance/fixed-assets,uncategorized/finance/fixed-assets-workflow +fleet-maintenance-workflow,fleet-maintenance,Fleet Maintenance Workflow,workflow,logistics,compliance,,compliance,3,7,2,fleet-maintenance;preventive-maintenance;vehicle-inspection;work-order;dot-compliance;telematics,"Fleet maintenance workflow with preventive maintenance scheduling, vehicle inspection, work order creation, parts ordering, and DOT compliance tracking.",logistics/fleet-maintenance,compliance/logistics/fleet-maintenance-workflow +gdpr-deletion-workflow,gdpr-deletion,Gdpr Deletion Workflow,workflow,business-operations,compliance,,compliance,4,13,4,gdpr-deletion;right-to-be-forgotten;data-privacy;pii-removal;compliance;dsar,"GDPR data deletion workflow with identity verification, data inventory scan, PII removal across systems, backup purging, and deletion confirmation.",business-operations/gdpr-deletion,compliance/business-operations/gdpr-deletion-workflow +hazmat-handling-workflow,hazmat-handling,Hazmat Handling Workflow,workflow,logistics,incident,compliance,incident;compliance,4,10,3,hazmat-handling;dangerous-goods;un-classification;sds-documentation;dot-compliance;emergency-response,"Hazardous materials handling workflow with UN classification, SDS documentation, proper labeling, certified handler assignment, and emergency response procedures.",logistics/hazmat-handling,incident/logistics/hazmat-handling-workflow +idempotent-consumer-workflow,idempotent-consumer,Idempotent Consumer Workflow,workflow,patterns,uncategorized,,,3,10,3,idempotent;consumer;patterns,This workflow models processing each message safely only once.,patterns/idempotent-consumer,uncategorized/patterns/idempotent-consumer-workflow +in-app-message-workflow,in-app-message,In App Message Workflow,workflow,business-operations,uncategorized,,,2,7,2,in-app-message;product-tours;tooltips;announcements;user-engagement;intercom,"In-app messaging workflow with trigger conditions, audience targeting, message display, user interaction tracking, and conversion measurement.",business-operations/in-app-message,uncategorized/business-operations/in-app-message-workflow +incident-response-workflow,incident-response,Incident Response Workflow,workflow,devops,incident,,incident,5,23,4,incident-management;on-call;pagerduty;war-room;severity-levels;postmortem;sre,"Production incident response workflow with severity-based routing, war room coordination, incident commander assignment, customer communication, root cause analysis, and postmortem scheduling.",devops/incident-response,incident/devops/incident-response-workflow +infrastructure-provisioning-workflow,infrastructure-provisioning,Infrastructure Provisioning Workflow,workflow,devops,delivery,,delivery,4,10,3,infrastructure-provisioning;terraform;iac;cloud-resources;gitops;state-management,"Infrastructure as Code provisioning workflow with Terraform plan, approval gates, state management, resource creation, and drift detection.",devops/infrastructure-provisioning,delivery/devops/infrastructure-provisioning-workflow +insurance-claim-workflow,insurance-claim,Insurance Claim Workflow,workflow,finance,approval,,approval,3,7,2,insurance-claim;claim-filing;adjuster-review;settlement;property-damage;liability,"Insurance claim processing workflow with incident documentation, claim filing, adjuster assignment, damage assessment, and settlement negotiation.",finance/insurance-claim,approval/finance/insurance-claim-workflow +internal-controls-workflow,internal-controls,Internal Controls Workflow,workflow,finance,compliance,,compliance,4,10,3,internal-controls;sox-compliance;control-testing;segregation-of-duties;risk-assessment;remediation,"Internal controls testing workflow with risk assessment, control design evaluation, operating effectiveness testing, deficiency identification, and remediation tracking.",finance/internal-controls,compliance/finance/internal-controls-workflow +internship-program-workflow,internship-program,Internship Program Workflow,workflow,hr,uncategorized,,,2,7,2,internship;program;hr,This workflow models managing an internship program.,hr/internship-program,uncategorized/hr/internship-program-workflow +interview-process-workflow,interview-process,Interview Process Workflow,workflow,hr,uncategorized,,,4,22,3,interview-process;hiring;phone-screen;technical-interview;onsite-panel;talent-acquisition;offer-management,"Multi-stage interview process with resume screening, phone screen, technical interview, onsite panel, team consensus decision, and offer/rejection handling.",hr/interview-process,uncategorized/hr/interview-process-workflow +inventory-receipt-workflow,inventory-receipt,Inventory Receipt Workflow,workflow,logistics,uncategorized,,,3,7,2,inventory-receipt;goods-receiving;po-matching;asn-verification;dock-scheduling;wms,"Inventory receiving workflow with ASN verification, PO matching, quantity count, damage inspection, and WMS inventory update.",logistics/inventory-receipt,uncategorized/logistics/inventory-receipt-workflow +invoice-processing-workflow,invoice-processing,Invoice Processing Workflow,workflow,finance,approval,billing,approval;billing,4,19,4,accounts-payable;invoice-automation;ocr;po-matching;approval-workflow;payment-processing;three-way-match,"Accounts payable invoice automation with OCR data extraction, three-way PO matching, tiered approval workflow, and automated payment processing with GL updates.",finance/invoice-processing,approval/finance/invoice-processing-workflow +job-posting-workflow,job-posting,Job Posting Workflow,workflow,hr,uncategorized,,,4,19,3,job-posting;job-requisition;ats;linkedin;indeed;ai-screening;talent-acquisition,"Job posting workflow with requisition approval, job description drafting, multi-channel posting (LinkedIn, Indeed, career sites), AI resume screening, and ATS candidate tracking.",hr/job-posting,uncategorized/hr/job-posting-workflow +kitting-process-workflow,kitting-process,Kitting Process Workflow,workflow,logistics,uncategorized,,,2,7,2,kitting-process;kit-assembly;bom;component-picking;value-added-services;bundling,"Kit assembly workflow with BOM explosion, component picking, assembly verification, kit labeling, and inventory conversion from components to finished kit.",logistics/kitting-process,uncategorized/logistics/kitting-process-workflow +knowledge-base-workflow,knowledge-base,Knowledge Base Workflow,workflow,business-operations,support,,support,3,13,4,knowledge-base;help-center;documentation;self-service;article-management;zendesk,"Knowledge base management workflow with article creation, review approval, SEO optimization, version control, and search analytics tracking.",business-operations/knowledge-base,support/business-operations/knowledge-base-workflow +last-mile-delivery-workflow,last-mile-delivery,Last Mile Delivery Workflow,workflow,logistics,uncategorized,,,3,7,2,last-mile-delivery;route-optimization;proof-of-delivery;delivery-exception;customer-notification;gps-tracking,"Last mile delivery workflow with route optimization, real-time GPS tracking, delivery attempt handling, proof of delivery capture, and customer notification.",logistics/last-mile-delivery,uncategorized/logistics/last-mile-delivery-workflow +load-testing-workflow,load-testing,Load Testing Workflow,workflow,devops,delivery,,delivery,4,13,4,load-testing;performance-testing;stress-testing;k6;jmeter;capacity-planning,"Load testing workflow with test scenario design, gradual ramp-up, performance metrics collection, bottleneck identification, and capacity recommendations.",devops/load-testing,delivery/devops/load-testing-workflow +materialized-view-workflow,materialized-view,Materialized View Workflow,workflow,patterns,uncategorized,,,4,13,4,materialized;view;patterns;decision;loop,This workflow models serving queries from a precomputed view.,patterns/materialized-view,uncategorized/patterns/materialized-view-workflow +message-queue-workflow,message-queue,Message Queue Workflow,workflow,patterns,uncategorized,,,3,10,3,message;queue;patterns;decision,This workflow models asynchronous processing of work via a queue.,patterns/message-queue,uncategorized/patterns/message-queue-workflow +monitoring-alert-workflow,monitoring-alert,Monitoring Alert Workflow,workflow,devops,incident,,incident,3,10,3,monitoring-alerting;prometheus;pagerduty;threshold-alerts;anomaly-detection;on-call,"Monitoring and alerting workflow with metric collection, threshold evaluation, alert routing, escalation policies, and incident creation.",devops/monitoring-alert,incident/devops/monitoring-alert-workflow +monthly-close-workflow,monthly-close,Monthly Close Workflow,workflow,finance,uncategorized,,,4,22,4,monthly-close;financial-reporting;accounting;reconciliation;trial-balance;period-close,"Corporate month-end financial close process including transaction posting, bank reconciliation, accruals, depreciation, trial balance validation, and financial statement generation.",finance/monthly-close,uncategorized/finance/monthly-close-workflow +nested-decisions-workflow,nested-decisions,Nested Decisions Workflow,workflow,patterns,uncategorized,,,3,10,3,nested;decisions;patterns;decision;loop,This workflow models multiple layers of decisions before completion.,patterns/nested-decisions,uncategorized/patterns/nested-decisions-workflow +normalizer-workflow,normalizer,Normalizer Workflow,workflow,patterns,uncategorized,,,4,13,4,normalizer;patterns,This workflow models converting varied inputs to a standard format.,patterns/normalizer,uncategorized/patterns/normalizer-workflow +notification-pattern-workflow,notification-pattern,Notification Pattern Workflow,workflow,patterns,uncategorized,,,2,7,2,notification;pattern;patterns,This workflow models sending alerts via multiple channels.,patterns/notification-pattern,uncategorized/patterns/notification-pattern-workflow +oauth-flow-workflow,oauth-flow,Oauth Flow Workflow,workflow,business-operations,approval,security,approval;security,4,13,4,oauth-flow;oauth2;authorization-code;token-exchange;sso;third-party-auth,"OAuth 2.0 authorization code flow with redirect handling, code exchange, token storage, refresh token rotation, and scope management.",business-operations/oauth-flow,approval/business-operations/oauth-flow-workflow +offboarding-workflow,offboarding,Offboarding Workflow,workflow,hr,handoff,offboarding,handoff;offboarding,4,10,3,employee-offboarding;exit-interview;access-revocation;asset-return;knowledge-transfer;final-paycheck,"Employee offboarding workflow with exit interview, knowledge transfer, asset collection, access revocation, final pay processing, and benefits continuation.",hr/offboarding,handoff/hr/offboarding-workflow +on-call-rotation-workflow,on-call-rotation,On Call Rotation Workflow,workflow,devops,handoff,incident;security,handoff;incident;security,3,13,4,on-call-rotation;incident-management;pagerduty;escalation;schedule-management;handoff,"On-call rotation workflow with schedule creation, shift handoffs, override management, escalation policies, and fair rotation distribution.",devops/on-call-rotation,handoff/devops/on-call-rotation-workflow +onboarding-workflow,onboarding,Onboarding Workflow,workflow,hr,onboarding,delivery,onboarding;delivery,4,20,3,employee-onboarding;new-hire;hr-workflow;background-check;it-provisioning;benefits-enrollment,"Complete employee onboarding workflow covering offer acceptance, HR record creation, benefits enrollment, background check verification, IT account provisioning, equipment setup, and first day orientation.",hr/onboarding,onboarding/hr/onboarding-workflow +packing-process-workflow,packing-process,Packing Process Workflow,workflow,logistics,uncategorized,,,2,7,2,order-packing;box-selection;packing-slip;weight-verification;cartonization;fulfillment,"Order packing workflow with carton selection, item verification, packing slip insertion, weight check, and package sealing for shipment.",logistics/packing-process,uncategorized/logistics/packing-process-workflow +parallel-execution-workflow,parallel-execution,Parallel Execution Workflow,workflow,patterns,uncategorized,,,4,13,4,parallel;execution;patterns;loop,This workflow models multiple tasks that run at the same time.,patterns/parallel-execution,uncategorized/patterns/parallel-execution-workflow +payment-failure-workflow,payment-failure,Payment Failure Workflow,workflow,business-operations,billing,,billing,3,7,2,payment-failure;dunning;retry-logic;card-decline;revenue-recovery;stripe,"Failed payment recovery workflow with smart retry scheduling, dunning email sequence, payment method update prompts, and involuntary churn prevention.",business-operations/payment-failure,billing/business-operations/payment-failure-workflow +payment-run-workflow,payment-run,Payment Run Workflow,workflow,finance,handoff,approval;billing,handoff;approval;billing,4,18,3,payment-run;accounts-payable;ach-payments;check-run;dual-approval;bank-transfer;vendor-payments,"Accounts payable payment run workflow with batch creation, tiered approval (single/dual based on amount), ACH file generation, check printing, and vendor record updates.",finance/payment-run,handoff/finance/payment-run-workflow +payroll-processing-workflow,payroll-processing,Payroll Processing Workflow,workflow,finance,compliance,,compliance,5,24,4,payroll-processing;salary-calculation;tax-withholding;fica;ach-direct-deposit;benefits-deductions;compliance,"Complete payroll processing workflow with timesheet collection, gross pay calculation, overtime, tax withholding (federal, state, FICA), benefits deductions, compliance validation, and ACH direct deposit.",finance/payroll-processing,compliance/finance/payroll-processing-workflow +performance-review-workflow,performance-review,Performance Review Workflow,workflow,hr,approval,,approval,4,10,3,performance-review;annual-evaluation;goal-setting;360-feedback;calibration;merit-increase,"Annual performance review workflow with self-assessment, manager evaluation, 360 feedback collection, calibration sessions, and merit increase recommendations.",hr/performance-review,approval/hr/performance-review-workflow +personalization-engine-workflow,personalization-engine,Personalization Engine Workflow,workflow,business-operations,uncategorized,,,4,20,3,make-com;personalization;segment;braze;ml-recommendations;content-delivery;marketing-automation,"Make.com automation scenario for real-time personalization using Segment events, ML recommendation API, and Braze campaign delivery across email and push channels.",business-operations/personalization-engine,uncategorized/business-operations/personalization-engine-workflow +picking-process-workflow,picking-process,Picking Process Workflow,workflow,logistics,uncategorized,,,3,10,3,order-picking;warehouse-management;pick-list;batch-picking;wave-picking;wms,"Warehouse order picking workflow with pick list generation, zone routing, batch picking optimization, barcode scanning verification, and pick completion confirmation.",logistics/picking-process,uncategorized/logistics/picking-process-workflow +plan-downgrade-workflow,plan-downgrade,Plan Downgrade Workflow,workflow,business-operations,billing,delivery,billing;delivery,3,13,4,plan-downgrade;retention;feature-restriction;data-migration;churn-prevention;billing,"Subscription plan downgrade workflow with retention offer, feature restriction warning, data migration handling, and end-of-period scheduling.",business-operations/plan-downgrade,billing/business-operations/plan-downgrade-workflow +plan-upgrade-workflow,plan-upgrade,Plan Upgrade Workflow,workflow,business-operations,billing,,billing,3,10,3,plan-upgrade;upsell;proration;feature-unlock;expansion-revenue;billing,"Subscription plan upgrade workflow with feature comparison, proration calculation, immediate feature unlock, and billing adjustment.",business-operations/plan-upgrade,billing/business-operations/plan-upgrade-workflow +polling-pattern-workflow,polling-pattern,Polling Pattern Workflow,workflow,patterns,uncategorized,,,4,13,4,polling;pattern;patterns;loop,This workflow models periodically checking status until work is done.,patterns/polling-pattern,uncategorized/patterns/polling-pattern-workflow +process-manager-workflow,process-manager,Process Manager Workflow,workflow,patterns,uncategorized,,,3,10,3,process;manager;patterns,This workflow models orchestrating multiple services to complete a process.,patterns/process-manager,uncategorized/patterns/process-manager-workflow +procurement-card-workflow,procurement-card,Procurement Card Workflow,workflow,finance,uncategorized,,,3,10,3,procurement;card;finance,This workflow models managing company credit cards.,finance/procurement-card,uncategorized/finance/procurement-card-workflow +promotion-process-workflow,promotion-process,Promotion Process Workflow,workflow,hr,uncategorized,,,3,7,2,promotion-process;career-advancement;job-leveling;title-change;compensation-adjustment;succession-planning,"Employee promotion workflow with performance validation, job level assessment, compensation adjustment, title change, and announcement coordination.",hr/promotion-process,uncategorized/hr/promotion-process-workflow +pto-request-workflow,pto-request,Pto Request Workflow,workflow,hr,approval,,approval,2,7,2,pto-request;time-off;vacation;leave-management;manager-approval;accrual-balance,"PTO request workflow with balance verification, manager approval, calendar blocking, and team coverage check before approval.",hr/pto-request,approval/hr/pto-request-workflow +pub-sub-workflow,pub-sub,Pub Sub Workflow,workflow,patterns,uncategorized,,,4,13,4,pub;sub;patterns,This workflow models one publisher notifying many subscribers of events.,patterns/pub-sub,uncategorized/patterns/pub-sub-workflow +purchase-order-workflow,purchase-order,Purchase Order Workflow,workflow,finance,approval,ai-orchestration,approval;ai-orchestration,4,22,3,purchase-order;procurement;requisition;vendor-sourcing;competitive-bidding;tiered-approval;budget-validation,"Procurement purchase order workflow with requisition creation, budget validation, vendor sourcing, competitive bidding, and tiered approval routing based on amount thresholds.",finance/purchase-order,approval/finance/purchase-order-workflow +push-notification-workflow,push-notification,Push Notification Workflow,workflow,business-operations,uncategorized,,,3,10,3,push-notification;mobile-engagement;firebase-fcm;apns;segmentation;deep-linking,"Mobile push notification workflow with audience targeting, platform routing (iOS/Android), delivery tracking, and engagement analytics.",business-operations/push-notification,uncategorized/business-operations/push-notification-workflow +put-away-process-workflow,put-away-process,Put Away Process Workflow,workflow,logistics,uncategorized,,,2,7,2,put-away;warehouse-storage;location-assignment;slotting;wms;inventory-placement,"Warehouse put-away workflow with location assignment, slotting optimization, forklift routing, barcode confirmation, and WMS location update.",logistics/put-away-process,uncategorized/logistics/put-away-process-workflow +quality-inspection-workflow,quality-inspection,Quality Inspection Workflow,workflow,logistics,uncategorized,,,3,10,3,quality-inspection;incoming-inspection;aql-sampling;defect-tracking;supplier-quality;hold-release,"Incoming quality inspection workflow with AQL sampling, defect classification, hold/release decision, supplier notification, and quality metrics tracking.",logistics/quality-inspection,uncategorized/logistics/quality-inspection-workflow +rate-limiter-workflow,rate-limiter,Rate Limiter Workflow,workflow,patterns,uncategorized,,,4,13,4,rate;limiter;patterns,This workflow models preventing too many requests from being processed.,patterns/rate-limiter,uncategorized/patterns/rate-limiter-workflow +reference-check-workflow,reference-check,Reference Check Workflow,workflow,hr,uncategorized,,,3,10,3,reference-check;employment-verification;professional-references;hiring-decision;candidate-vetting;feedback-collection,"Professional reference check workflow with reference collection, outreach scheduling, structured interview questions, feedback documentation, and hiring recommendation.",hr/reference-check,uncategorized/hr/reference-check-workflow +referral-program-workflow,referral-program,Referral Program Workflow,workflow,business-operations,uncategorized,,,3,13,4,referral-program;viral-growth;referral-tracking;reward-fulfillment;affiliate;word-of-mouth,"Customer referral program workflow with unique link generation, referral tracking, conversion validation, and dual-sided reward fulfillment.",business-operations/referral-program,uncategorized/business-operations/referral-program-workflow +relocation-assistance-workflow,relocation-assistance,Relocation Assistance Workflow,workflow,hr,uncategorized,,,3,10,3,relocation;assistance;hr;decision,This workflow models helping employees relocate.,hr/relocation-assistance,uncategorized/hr/relocation-assistance-workflow +reorder-process-workflow,reorder-process,Reorder Process Workflow,workflow,logistics,uncategorized,,,3,7,2,reorder-process;reorder-point;safety-stock;eoq;demand-planning;auto-replenishment,"Inventory reorder workflow with reorder point monitoring, economic order quantity calculation, safety stock consideration, and automatic purchase requisition generation.",logistics/reorder-process,uncategorized/logistics/reorder-process-workflow +request-reply-workflow,request-reply,Request Reply Workflow,workflow,patterns,uncategorized,,,2,7,2,request;reply;patterns,This workflow models a synchronous request that waits for a reply.,patterns/request-reply,uncategorized/patterns/request-reply-workflow +retry-with-backoff-workflow,retry-with-backoff,Retry With Backoff Workflow,workflow,patterns,uncategorized,,,4,20,3,retry-pattern;exponential-backoff;fault-tolerance;api-resilience;transient-errors;http-retry;jitter,"Exponential backoff retry pattern for API calls with configurable retry limits, delay calculation, retryable error detection, and graceful degradation on permanent failures.",patterns/retry-with-backoff,uncategorized/patterns/retry-with-backoff-workflow +returns-processing-workflow,returns-processing,Returns Processing Workflow,workflow,logistics,billing,,billing,3,7,2,returns-processing;rma;refund;restocking;quality-inspection;reverse-logistics,"Customer returns processing workflow with RMA generation, return receipt, quality inspection, disposition decision, and refund or exchange processing.",logistics/returns-processing,billing/logistics/returns-processing-workflow +reverse-logistics-workflow,reverse-logistics,Reverse Logistics Workflow,workflow,logistics,uncategorized,,,4,10,3,reverse-logistics;product-returns;refurbishment;recycling;disposition;sustainability,"Reverse logistics workflow with return authorization, product grading, refurbishment decision, recycling coordination, and secondary market disposition.",logistics/reverse-logistics,uncategorized/logistics/reverse-logistics-workflow +review-collection-workflow,review-collection,Review Collection Workflow,workflow,business-operations,approval,,approval,2,7,2,review-collection;customer-feedback;nps;ratings;social-proof;testimonials,"Customer review collection workflow with post-purchase trigger, review request email, rating submission, moderation, and public display.",business-operations/review-collection,approval/business-operations/review-collection-workflow +router-workflow,router,Router Workflow,workflow,patterns,uncategorized,,,3,10,3,router;patterns;decision,This workflow models routing messages based on their content.,patterns/router,uncategorized/patterns/router-workflow +routing-slip-workflow,routing-slip,Routing Slip Workflow,workflow,patterns,handoff,,handoff,4,13,4,routing;slip;patterns,This workflow models having messages carry their own routing instructions.,patterns/routing-slip,handoff/patterns/routing-slip-workflow +saga-pattern-workflow,saga-pattern,Saga Pattern Workflow,workflow,patterns,delivery,ai-orchestration,delivery;ai-orchestration,5,20,4,saga-pattern;distributed-transactions;microservices;compensation;orchestration;eventual-consistency;rollback,"Saga orchestration pattern for distributed transactions across Order, Payment, and Shipping services with automatic compensation rollback on failures.",patterns/saga-pattern,delivery/patterns/saga-pattern-workflow +salary-increase-workflow,salary-increase,Salary Increase Workflow,workflow,hr,approval,,approval,3,10,3,salary-increase;compensation;merit-raise;market-adjustment;budget-approval;comp-ratio,"Salary increase workflow with market analysis, comp ratio review, budget validation, tiered approval based on increase percentage, and payroll system update.",hr/salary-increase,approval/hr/salary-increase-workflow +search-optimization-workflow,search-optimization,Search Optimization Workflow,workflow,business-operations,uncategorized,,,4,13,4,search-optimization;elasticsearch;relevance-tuning;query-analysis;algolia;search-analytics,"Search optimization workflow with query analysis, relevance tuning, synonym management, click-through tracking, and A/B testing of ranking algorithms.",business-operations/search-optimization,uncategorized/business-operations/search-optimization-workflow +secret-rotation-workflow,secret-rotation,Secret Rotation Workflow,workflow,devops,security,,security,4,18,3,secret-rotation;vault;kubernetes-secrets;api-keys;database-passwords;certificates;security,"Automated secret rotation workflow with HashiCorp Vault for API keys, database passwords, and certificates including Kubernetes secret updates and rolling service restarts.",devops/secret-rotation,security/devops/secret-rotation-workflow +security-scan-workflow,security-scan,Security Scan Workflow,workflow,devops,security,,security,3,10,3,security-scanning;sast;dast;dependency-check;snyk;devsecops,"Security scanning workflow with SAST, DAST, dependency vulnerability scanning, finding triage, and remediation tracking in CI/CD pipeline.",devops/security-scan,security/devops/security-scan-workflow +shipping-process-workflow,shipping-process,Shipping Process Workflow,workflow,logistics,security,,security,3,10,3,shipping-process;order-fulfillment;carrier-selection;label-generation;tracking-number;dispatch,"Order shipping workflow with carrier selection, rate shopping, label generation, tracking number assignment, and dispatch confirmation.",logistics/shipping-process,security/logistics/shipping-process-workflow +sms-verification-workflow,sms-verification,Sms Verification Workflow,workflow,business-operations,security,,security,3,13,4,sms-verification;otp;twilio;phone-verification;2fa;fraud-prevention,"SMS phone verification workflow with OTP generation, rate limiting, code validation, retry handling, and verification status tracking.",business-operations/sms-verification,security/business-operations/sms-verification-workflow +snapshot-pattern-workflow,snapshot-pattern,Snapshot Pattern Workflow,workflow,patterns,uncategorized,,,2,7,2,snapshot;pattern;patterns;decision;loop,This workflow models taking periodic snapshots of important state.,patterns/snapshot-pattern,uncategorized/patterns/snapshot-pattern-workflow +state-machine-workflow,state-machine,State Machine Workflow,workflow,patterns,uncategorized,,,4,13,4,state;machine;patterns;parallel,This workflow models tracking object state changes over time.,patterns/state-machine,uncategorized/patterns/state-machine-workflow +stock-transfer-workflow,stock-transfer,Stock Transfer Workflow,workflow,logistics,handoff,,handoff,3,10,3,stock-transfer;inventory-movement;location-transfer;bin-to-bin;wms;inventory-rebalancing,"Internal stock transfer workflow with transfer request, source location pick, destination put-away, and inventory record updates across locations.",logistics/stock-transfer,handoff/logistics/stock-transfer-workflow +strangler-fig-workflow,strangler-fig,Strangler Fig Workflow,workflow,patterns,uncategorized,,,2,7,2,strangler;fig;patterns;decision,This workflow models gradually replacing an old system with a new one.,patterns/strangler-fig,uncategorized/patterns/strangler-fig-workflow +subscription-lifecycle-workflow,subscription-lifecycle,Subscription Lifecycle Workflow,workflow,business-operations,billing,,billing,4,10,3,subscription-lifecycle;saas;trial-conversion;renewal;churn-prevention;stripe,"SaaS subscription lifecycle workflow with trial signup, conversion nurturing, payment processing, renewal management, and churn prevention campaigns.",business-operations/subscription-lifecycle,billing/business-operations/subscription-lifecycle-workflow +support-ticket-workflow,support-ticket,Support Ticket Workflow,workflow,business-operations,handoff,support,handoff;support,3,10,3,support-ticket;helpdesk;zendesk;sla;ticket-routing;customer-service,"Customer support ticket workflow with auto-categorization, SLA tracking, agent assignment, escalation rules, and satisfaction survey.",business-operations/support-ticket,handoff/business-operations/support-ticket-workflow +tax-filing-workflow,tax-filing,Tax Filing Workflow,workflow,finance,compliance,,compliance,4,19,3,tax-filing;corporate-tax;tax-calculation;irs-efile;tax-credits;deductions;compliance,"Corporate tax filing workflow with taxable income calculation, deductions, tax credits, variance review, and electronic or paper filing to IRS with receipt confirmation.",finance/tax-filing,compliance/finance/tax-filing-workflow +termination-process-workflow,termination-process,Termination Process Workflow,workflow,hr,approval,offboarding,approval;offboarding,4,20,3,employee-termination;offboarding;separation-agreement;final-pay;cobra;severance;legal-review,"Employee termination workflow handling voluntary and involuntary separations with legal review, separation agreements, final pay calculation, COBRA notices, and severance processing.",hr/termination-process,approval/hr/termination-process-workflow +timeout-pattern-workflow,timeout-pattern,Timeout Pattern Workflow,workflow,patterns,uncategorized,,,4,13,4,timeout;pattern;patterns,This workflow models an operation that times out after a delay.,patterns/timeout-pattern,uncategorized/patterns/timeout-pattern-workflow +training-enrollment-workflow,training-enrollment,Training Enrollment Workflow,workflow,hr,compliance,,compliance,2,7,2,training-enrollment;learning-management;lms;professional-development;compliance-training;certification,"Training enrollment workflow with course catalog browsing, manager approval, LMS registration, completion tracking, and certification management.",hr/training-enrollment,compliance/hr/training-enrollment-workflow +transactional-outbox-workflow,transactional-outbox,Transactional Outbox Workflow,workflow,patterns,uncategorized,,,4,13,4,transactional;outbox;patterns;parallel,This workflow models writing data and publishing messages in one transaction.,patterns/transactional-outbox,uncategorized/patterns/transactional-outbox-workflow +transform-workflow,transform,Transform Workflow,workflow,patterns,uncategorized,,,2,7,2,transform;patterns,This workflow models converting messages into a new shape.,patterns/transform,uncategorized/patterns/transform-workflow +treasury-management-workflow,treasury-management,Treasury Management Workflow,workflow,finance,uncategorized,,,3,7,2,treasury-management;cash-pooling;fx-hedging;investment-portfolio;bank-relationships;liquidity,"Corporate treasury management workflow with cash pooling, FX exposure hedging, short-term investment decisions, and bank relationship management.",finance/treasury-management,uncategorized/finance/treasury-management-workflow +two-factor-setup-workflow,two-factor-setup,Two Factor Setup Workflow,workflow,business-operations,onboarding,security,onboarding;security,2,7,2,two-factor-auth;mfa;totp;authenticator-app;security;account-protection,"Two-factor authentication setup workflow with method selection (TOTP/SMS), QR code generation, backup codes, and verification confirmation.",business-operations/two-factor-setup,onboarding/business-operations/two-factor-setup-workflow +user-onboarding-workflow,user-onboarding,User Onboarding Workflow,workflow,business-operations,onboarding,,onboarding,2,7,2,user-onboarding;activation;product-tour;welcome-email;first-time-user;time-to-value,"New user onboarding workflow with welcome email, profile setup, product tour, first action prompt, and activation milestone tracking.",business-operations/user-onboarding,onboarding/business-operations/user-onboarding-workflow +user-segmentation-workflow,user-segmentation,User Segmentation Workflow,workflow,business-operations,uncategorized,,,2,7,2,user-segmentation;audience-targeting;behavioral-cohorts;customer-segments;segment;marketing-automation,"User segmentation workflow with attribute collection, behavioral event tracking, segment rule definition, dynamic membership, and downstream sync.",business-operations/user-segmentation,uncategorized/business-operations/user-segmentation-workflow +validator-workflow,validator,Validator Workflow,workflow,patterns,uncategorized,,,2,7,2,validator;patterns;parallel,This workflow models checking that incoming data is valid.,patterns/validator,uncategorized/patterns/validator-workflow +vendor-onboarding-workflow,vendor-onboarding,Vendor Onboarding Workflow,workflow,finance,onboarding,billing;compliance,onboarding;billing;compliance,4,19,3,vendor-onboarding;supplier-management;w9-verification;insurance-compliance;background-check;payment-terms;procurement,"Vendor onboarding workflow with application review, W-9/W-8BEN verification, insurance certificate validation, background checks, and compliance approval before vendor activation.",finance/vendor-onboarding,onboarding/finance/vendor-onboarding-workflow +vulnerability-patch-workflow,vulnerability-patch,Vulnerability Patch Workflow,workflow,devops,security,compliance;delivery,security;compliance;delivery,4,19,3,vulnerability-management;security-patching;cve-triage;cvss-scoring;patch-testing;rollback;compliance,"Security vulnerability patching workflow with CVE scanning, severity-based triage (critical/high/medium), patch testing, staging deployment, and production rollout with rollback capability.",devops/vulnerability-patch,security/devops/vulnerability-patch-workflow +warehouse-transfer-workflow,warehouse-transfer,Warehouse Transfer Workflow,workflow,logistics,handoff,,handoff,3,10,3,warehouse-transfer;inter-facility;transfer-order;in-transit-inventory;network-optimization;distribution,"Inter-warehouse transfer workflow with transfer order creation, shipping from source DC, in-transit tracking, and receiving at destination warehouse.",logistics/warehouse-transfer,handoff/logistics/warehouse-transfer-workflow +webhook-integration-workflow,webhook-integration,Webhook Integration Workflow,workflow,business-operations,uncategorized,,,2,7,2,webhook;event-driven;http-callback;integration;retry-logic;payload-signing,"Webhook integration workflow with endpoint registration, payload signing, delivery attempt, retry with backoff, and delivery status tracking.",business-operations/webhook-integration,uncategorized/business-operations/webhook-integration-workflow +webhook-pattern-workflow,webhook-pattern,Webhook Pattern Workflow,workflow,patterns,uncategorized,,,2,7,2,webhook;pattern;patterns;decision;loop,This workflow models an HTTP callback when an event occurs.,patterns/webhook-pattern,uncategorized/patterns/webhook-pattern-workflow +webinar-registration-workflow,webinar-registration,Webinar Registration Workflow,workflow,business-operations,onboarding,,onboarding,3,10,3,webinar;event-registration;zoom;calendar-invite;reminder-sequence;lead-capture,"Webinar registration workflow with signup form, calendar invite, reminder email sequence, attendance tracking, and post-event follow-up.",business-operations/webinar-registration,onboarding/business-operations/webinar-registration-workflow +yearly-audit-workflow,yearly-audit,Yearly Audit Workflow,workflow,finance,compliance,,compliance,4,10,3,annual-audit;external-auditors;sox-compliance;financial-statements;audit-findings;management-letter,"Annual financial audit workflow with external auditor engagement, document preparation, fieldwork coordination, findings remediation, and management letter response.",finance/yearly-audit,compliance/finance/yearly-audit-workflow +shopify-universal-commerce-protocol,shopify-universal-commerce-protocol,Shopify Universal Commerce Protocol,workflow,business-operations,billing,agentic,billing;agentic,4,47,5,shopify;ucp;universal-commerce-protocol;agentic-commerce;ai-shopping;chatgpt;e-commerce;checkout;payment,"End-to-end agentic commerce workflow showing how an AI assistant (ChatGPT) orchestrates product search, checkout, and payment through Shopify's Universal Commerce Protocol (UCP) gateway, enabling conversational shopping experiences.",business-operations/shopify-universal-commerce-protocol,billing/business-operations/shopify-universal-commerce-protocol +microservices-api-gateway-architecture,microservices-api-gateway-architecture,Microservices API Gateway Architecture,architecture,Architecture,security,mcp,security;mcp,4,17,3,microservices;api-gateway;jwt-authentication;rate-limiting;service-discovery;load-balancing;architecture-diagram;distributed-systems,"A microservices API gateway architecture diagram showing request routing, JWT authentication, rate limiting, service discovery, and response aggregation across distributed backend services. This template models the entry point for all client traffic in a microservices ecosystem, enforcing security policies before requests reach internal services. Ideal for platform engineers designing scalable API infrastructure with centralized cross-cutting concerns.",,security/architecture/microservices-api-gateway-architecture +microservices-service-mesh-architecture,microservices-service-mesh-architecture,Microservices Service Mesh Architecture,architecture,Architecture,mcp,,mcp,4,18,3,service-mesh;istio;linkerd;mtls;sidecar-proxy;distributed-tracing;traffic-management;architecture-diagram,"A service mesh architecture diagram with Istio or Linkerd sidecar proxies handling mTLS encryption, traffic policies, circuit breaking, and distributed tracing across microservices. This template visualizes how a service mesh abstracts networking concerns away from application code, enabling zero-trust communication between services. Essential for teams adopting service mesh infrastructure to improve observability and security.",,mcp/architecture/microservices-service-mesh-architecture +microservices-database-per-service-architecture,microservices-database-per-service-architecture,Microservices Database-Per-Service Architecture,architecture,Architecture,uncategorized,,,4,16,4,database-per-service;polyglot-persistence;microservices;kafka;event-driven;data-isolation;eventual-consistency;architecture-diagram,"A database-per-service architecture diagram where each microservice owns its dedicated data store, with event-driven synchronization via Kafka for cross-service data consistency. This template demonstrates the core microservices data isolation principle, showing how PostgreSQL and MongoDB coexist in a polyglot persistence strategy. Critical for architects enforcing service autonomy while maintaining eventual consistency.",,uncategorized/architecture/microservices-database-per-service-architecture +microservices-decomposition-by-business-capability,microservices-decomposition-by-business-capability,Microservices Decomposition by Business Capability,architecture,Architecture,uncategorized,,,4,17,5,microservices-decomposition;business-capability;bff;domain-driven-design;service-boundaries;monolith-to-microservices;architecture-diagram,"A microservices decomposition architecture diagram organized by business capabilities: Identity, Product Catalog, Pricing, and Order Fulfillment, each with independent data stores and APIs. This template shows how to break a monolith into services aligned with business domains, using a Backend-for-Frontend (BFF) pattern for client-specific aggregation. Useful for architects planning domain-driven microservice boundaries.",,uncategorized/architecture/microservices-decomposition-by-business-capability +microservices-strangler-fig-migration,microservices-strangler-fig-migration,Microservices Strangler Fig Migration Architecture,architecture,Architecture,delivery,,delivery,4,16,4,strangler-fig;legacy-migration;monolith-decomposition;anti-corruption-layer;incremental-migration;modernization;architecture-diagram,"A strangler fig migration architecture diagram showing the incremental replacement of a legacy monolith with new microservices, using a routing layer to split traffic between old and new systems. This template models the proven migration strategy where new features are built as microservices while legacy endpoints are gradually retired. Essential for teams modernizing legacy systems without risky big-bang rewrites.",,delivery/architecture/microservices-strangler-fig-migration +microservices-service-discovery-architecture,microservices-service-discovery-architecture,Microservices Service Discovery Architecture,architecture,Architecture,handoff,,handoff,3,16,3,service-discovery;consul;eureka;health-check;client-side-load-balancing;service-registry;dynamic-routing;architecture-diagram,"A service discovery architecture diagram with Consul or Eureka registry, client-side load balancing, health check heartbeats, and automatic instance registration and deregistration. This template visualizes how microservices dynamically locate each other without hardcoded endpoints, enabling elastic scaling and self-healing infrastructure. Key for platform teams building resilient service-to-service communication.",,handoff/architecture/microservices-service-discovery-architecture +microservices-sidecar-pattern-architecture,microservices-sidecar-pattern-architecture,Microservices Sidecar Pattern Architecture,architecture,Architecture,mcp,,mcp,4,13,3,sidecar-pattern;envoy-proxy;kubernetes;container-pattern;observability;control-plane;cloud-native;architecture-diagram,"A sidecar pattern architecture diagram showing Envoy proxy, log collector, and config watcher sidecars running alongside application containers in a Kubernetes pod, with a control plane managing configuration. This template demonstrates how auxiliary concerns like logging, monitoring, and configuration are deployed as co-located containers. Foundational for teams adopting cloud-native container orchestration patterns.",,mcp/architecture/microservices-sidecar-pattern-architecture +microservices-backend-for-frontend-architecture,microservices-backend-for-frontend-architecture,Microservices Backend-for-Frontend (BFF) Architecture,architecture,Architecture,uncategorized,,,3,12,3,backend-for-frontend;bff-pattern;mobile-api;web-api;api-aggregation;payload-optimization;microservices;architecture-diagram,"A Backend-for-Frontend architecture diagram with separate BFF layers for web and mobile clients, each optimizing API responses for their specific platform while sharing common backend microservices. This template shows how to avoid one-size-fits-all APIs by tailoring data aggregation and payload optimization per client type. Recommended for teams serving multiple frontend platforms from a shared microservices backend.",,uncategorized/architecture/microservices-backend-for-frontend-architecture +event-driven-publish-subscribe-architecture,event-driven-publish-subscribe-architecture,Event-Driven Publish-Subscribe Architecture,architecture,Architecture,uncategorized,,,4,17,3,publish-subscribe;event-driven;kafka;rabbitmq;message-broker;fan-out;dead-letter-queue;architecture-diagram,"An event-driven publish-subscribe architecture diagram with Kafka or RabbitMQ message broker, event serialization, topic partitioning, fan-out delivery to multiple consumers, and dead letter queue error handling. This template models the foundational async messaging pattern where producers and consumers are fully decoupled through a message broker. Essential for architects building loosely coupled, scalable event-driven systems.",,uncategorized/architecture/event-driven-publish-subscribe-architecture +event-driven-event-sourcing-architecture,event-driven-event-sourcing-architecture,Event-Driven Event Sourcing Architecture,architecture,Architecture,uncategorized,,,4,18,4,event-sourcing;immutable-events;event-store;projections;snapshot;aggregate;temporal-query;architecture-diagram,"An event sourcing architecture diagram where all state changes are stored as an immutable sequence of domain events, with read projections built from the event stream and snapshot optimization for fast aggregate loading. This template shows how event sourcing eliminates data loss by preserving the complete history of every state transition. Critical for systems requiring full audit trails, temporal queries, and event replay capabilities.",,uncategorized/architecture/event-driven-event-sourcing-architecture +event-driven-cqrs-with-event-store-architecture,event-driven-cqrs-with-event-store-architecture,Event-Driven CQRS with Event Store Architecture,architecture,Architecture,uncategorized,,,4,18,4,cqrs;event-store;command-query-separation;read-model;write-model;projector;eventual-consistency;architecture-diagram,"A CQRS architecture diagram combining separate command and query APIs with an event bus for asynchronous read model synchronization, including projectors that build denormalized views from domain events. This template demonstrates the full CQRS+ES stack where writes go through domain validation and reads are served from optimized materialized views. Ideal for high-throughput systems where read and write workloads have fundamentally different scaling requirements.",,uncategorized/architecture/event-driven-cqrs-with-event-store-architecture +event-driven-choreography-architecture,event-driven-choreography-architecture,Event-Driven Choreography Architecture,architecture,Architecture,uncategorized,,,4,19,5,choreography;event-driven;decentralized-coordination;domain-events;microservices;autonomous-services;pub-sub;architecture-diagram,"An event-driven choreography architecture diagram where microservices coordinate through events without a central orchestrator, with Order, Payment, Inventory, and Shipping services reacting to each other's domain events. This template models the decentralized coordination pattern where each service knows only its own responsibilities and publishes events for others to consume. Best for teams favoring autonomous services over centralized workflow control.",,uncategorized/architecture/event-driven-choreography-architecture +event-driven-event-streaming-pipeline-architecture,event-driven-event-streaming-pipeline-architecture,Event-Driven Streaming Pipeline Architecture,architecture,Architecture,delivery,,delivery,4,18,4,event-streaming;kafka;apache-flink;stream-processing;real-time-analytics;iot;data-pipeline;architecture-diagram,"A real-time event streaming pipeline architecture diagram with IoT sensors, application logs, and clickstream data flowing through Kafka into Apache Flink for window aggregation, anomaly detection, and multi-sink output to data lakes and dashboards. This template visualizes end-to-end stream processing from ingestion through transformation to storage and alerting. Essential for data engineers building real-time analytics and monitoring platforms.",,delivery/architecture/event-driven-event-streaming-pipeline-architecture +event-driven-domain-events-architecture,event-driven-domain-events-architecture,Event-Driven Domain Events Architecture,architecture,Architecture,security,,security,4,17,4,domain-events;ddd;aggregate-root;bounded-context;event-dispatcher;integration-events;domain-driven-design;architecture-diagram,"A domain events architecture diagram showing how aggregate roots raise domain events that are dispatched both in-process to local handlers and cross-boundary to integration event consumers in other bounded contexts. This template models the DDD event pattern where domain logic triggers side effects through a clean event dispatcher, maintaining separation between domain and infrastructure concerns. Key for teams implementing Domain-Driven Design with event-based integration.",,security/architecture/event-driven-domain-events-architecture +event-driven-cdc-change-data-capture-architecture,event-driven-cdc-change-data-capture-architecture,Event-Driven CDC (Change Data Capture) Architecture,architecture,Architecture,uncategorized,,,4,17,4,change-data-capture;cdc;debezium;transaction-log;kafka-connect;data-synchronization;dual-write;architecture-diagram,"A Change Data Capture architecture diagram using Debezium to tail database transaction logs and publish change events to Kafka, feeding downstream consumers that update search indexes, invalidate caches, load data warehouses, and write audit logs. This template shows how CDC eliminates dual-write problems by capturing changes at the database level without modifying application code. Critical for data synchronization across heterogeneous systems.",,uncategorized/architecture/event-driven-cdc-change-data-capture-architecture +event-driven-dead-letter-queue-architecture,event-driven-dead-letter-queue-architecture,Event-Driven Dead Letter Queue Architecture,architecture,Architecture,incident,compliance,incident;compliance,3,16,3,dead-letter-queue;dlq;retry-policy;message-processing;error-handling;operations-alerting;message-reliability;architecture-diagram,"A dead letter queue architecture diagram with retry policies, exponential backoff, max retry thresholds, DLQ routing for failed messages, operations alerting, and manual reprocessing workflows. This template models the critical error handling pattern for asynchronous messaging systems, ensuring no message is silently lost when processing fails. Essential for building reliable event-driven systems with proper failure recovery mechanisms.",,incident/architecture/event-driven-dead-letter-queue-architecture +cqrs-read-write-separation-architecture,cqrs-read-write-separation-architecture,CQRS Read-Write Separation Architecture,architecture,Architecture,uncategorized,,,4,18,4,cqrs;read-write-separation;command-query;postgresql;redis;elasticsearch;read-model-sync;architecture-diagram,"A CQRS read-write separation architecture diagram with dedicated command and query paths, PostgreSQL for writes, Redis or Elasticsearch for optimized reads, and an event-driven synchronization layer with lag monitoring. This template demonstrates the core CQRS principle of separating read and write models to independently scale and optimize each path. Ideal for applications with asymmetric read/write ratios where query performance is critical.",,uncategorized/architecture/cqrs-read-write-separation-architecture +cqrs-materialized-view-architecture,cqrs-materialized-view-architecture,CQRS Materialized View Architecture,architecture,Architecture,uncategorized,,,4,18,4,materialized-view;cqrs;projectors;read-model;denormalization;query-optimization;event-stream;architecture-diagram,"A CQRS materialized view architecture diagram with multiple projectors building purpose-specific read models: order summaries, customer dashboards, analytics cubes, and search indexes, all fed from a single event stream. This template shows how to create multiple optimized query views from the same write events, each tailored to a specific use case with sub-millisecond read latency. Perfect for systems requiring diverse query patterns from a single data source.",,uncategorized/architecture/cqrs-materialized-view-architecture +cqrs-task-based-ui-architecture,cqrs-task-based-ui-architecture,CQRS Task-Based UI Architecture,architecture,Architecture,uncategorized,,,4,19,4,task-based-ui;cqrs;optimistic-update;websocket;command-pattern;idempotency;reactive-ui;architecture-diagram,"A CQRS task-based UI architecture diagram where the frontend captures user intent as explicit commands, submits them asynchronously with optimistic updates, and receives real-time confirmations via WebSocket when the read model is synchronized. This template models the modern UI pattern that replaces CRUD forms with intent-driven commands, enabling responsive user experiences with eventual consistency. Recommended for teams building reactive frontends on CQRS backends.",,uncategorized/architecture/cqrs-task-based-ui-architecture +serverless-api-backend-architecture,serverless-api-backend-architecture,Serverless API Backend Architecture,architecture,Architecture,mcp,,mcp,3,15,3,serverless;aws-lambda;api-gateway;dynamodb;cloud-architecture;auto-scaling;pay-per-use;architecture-diagram,"A serverless API backend architecture diagram with API Gateway, Lambda authorizer functions, business logic functions, and managed cloud services including DynamoDB, S3, SQS, and SNS for a fully managed, auto-scaling backend. This template models the serverless-first approach where infrastructure management is eliminated entirely, with pay-per-invocation pricing and automatic scaling to zero. Essential for startups and teams building cost-efficient, event-driven API backends.",,mcp/architecture/serverless-api-backend-architecture +serverless-event-processing-architecture,serverless-event-processing-architecture,Serverless Event Processing Architecture,architecture,Architecture,uncategorized,,,4,17,4,serverless;event-processing;step-functions;lambda-triggers;sqs;s3-events;dynamodb-streams;architecture-diagram,"A serverless event processing architecture diagram with S3, DynamoDB Streams, API Gateway, and CloudWatch triggers invoking Lambda functions, orchestrated by Step Functions with fan-out via SQS and dead letter queue error handling. This template shows how to build complex event processing pipelines entirely from managed serverless components, with no servers to provision or manage. Ideal for data processing workflows that need elastic scaling and built-in fault tolerance.",,uncategorized/architecture/serverless-event-processing-architecture +serverless-step-functions-orchestration-architecture,serverless-step-functions-orchestration-architecture,Serverless Step Functions Orchestration Architecture,architecture,Architecture,incident,ai-orchestration,incident;ai-orchestration,4,17,3,step-functions;serverless-orchestration;state-machine;workflow-automation;callback-pattern;compensation;aws;architecture-diagram,"An AWS Step Functions orchestration architecture diagram with state machine workflows including choice states, parallel processing, wait-for-callback patterns, and compensation rollback for failed steps. This template models serverless workflow orchestration where complex multi-step processes are defined as state machines with built-in error handling and retry logic. Critical for teams building reliable serverless workflows that require human approval or long-running processes.",,incident/architecture/serverless-step-functions-orchestration-architecture +serverless-edge-computing-architecture,serverless-edge-computing-architecture,Serverless Edge Computing Architecture,architecture,Architecture,handoff,,handoff,3,15,3,edge-computing;lambda-at-edge;cloudfront;cloudflare;cdn;geo-routing;cache-strategy;architecture-diagram,"A serverless edge computing architecture diagram with CloudFront or Cloudflare edge locations, Lambda@Edge functions for A/B testing and geo-personalization, origin shield request collapsing, and cache-first response strategies. This template visualizes how computation moves to the network edge for ultra-low latency responses, with edge functions modifying requests and responses before they reach the origin. Essential for performance-critical applications serving global audiences.",,handoff/architecture/serverless-edge-computing-architecture +serverless-data-pipeline-architecture,serverless-data-pipeline-architecture,Serverless Data Pipeline Architecture,architecture,Architecture,delivery,,delivery,4,17,4,serverless-data-pipeline;kinesis;glue;athena;s3-data-lake;etl;sagemaker;architecture-diagram,"A serverless data pipeline architecture diagram with Kinesis ingestion, Lambda transformation functions, S3 data lake storage zones (raw and curated), Glue catalog registration, and Athena query engine feeding QuickSight dashboards and SageMaker ML models. This template models a complete serverless ETL pipeline from data ingestion through transformation, cataloging, and analytics without managing any infrastructure. Ideal for data teams building cost-effective analytics platforms.",,delivery/architecture/serverless-data-pipeline-architecture +serverless-multi-cloud-architecture,serverless-multi-cloud-architecture,Serverless Multi-Cloud Architecture,architecture,Architecture,handoff,,handoff,4,18,4,multi-cloud;aws;azure;cloud-failover;dns-routing;data-replication;vendor-independence;architecture-diagram,"A multi-cloud serverless architecture diagram with DNS-based traffic routing between AWS and Azure regions, automatic failover on health check failures, and bi-directional data replication with conflict resolution across cloud providers. This template models the multi-cloud strategy for maximum availability and vendor independence, using serverless services from both AWS (Lambda, DynamoDB) and Azure (Functions, Cosmos DB). Critical for enterprises requiring cloud provider redundancy.",,handoff/architecture/serverless-multi-cloud-architecture +saga-orchestration-pattern-architecture,saga-orchestration-pattern-architecture,Saga Orchestration Pattern Architecture,architecture,Architecture,delivery,ai-orchestration,delivery;ai-orchestration,4,19,5,saga-pattern;orchestration;distributed-transaction;compensation;microservices;rollback;consistency;architecture-diagram,"A saga orchestration architecture diagram with a central orchestrator coordinating multi-step distributed transactions across Order, Inventory, and Payment services, with a dedicated compensation chain for rollback on failure. This template models the orchestration-based saga pattern where a single coordinator manages the transaction lifecycle and triggers compensating actions when any step fails. Essential for architects implementing reliable distributed transactions without two-phase commit.",,delivery/architecture/saga-orchestration-pattern-architecture +saga-choreography-pattern-architecture,saga-choreography-pattern-architecture,Saga Choreography Pattern Architecture,architecture,Architecture,uncategorized,,,4,18,5,saga-choreography;event-driven-saga;decentralized;domain-events;compensation;autonomous-services;distributed-transaction;architecture-diagram,"A saga choreography architecture diagram where Order, Payment, and Inventory services coordinate through domain events without a central orchestrator, with each service publishing and subscribing to events that drive the transaction forward or trigger compensation. This template models the decentralized saga approach where services autonomously react to events, reducing single points of failure at the cost of increased complexity in tracking saga state. Best for teams preferring service autonomy over centralized control.",,uncategorized/architecture/saga-choreography-pattern-architecture +saga-distributed-transaction-architecture,saga-distributed-transaction-architecture,Saga Distributed Transaction Architecture,architecture,Architecture,ai-orchestration,,ai-orchestration,4,17,4,distributed-transaction;two-phase-commit;2pc;transaction-coordinator;consensus;strong-consistency;prepare-commit;architecture-diagram,"A distributed transaction architecture diagram implementing the two-phase commit protocol with a transaction coordinator sending prepare and commit messages to participating services, with global abort on any vote failure. This template visualizes the classic 2PC protocol used when strong consistency is required across multiple services, showing the prepare, vote, and commit/abort phases. Important for understanding distributed consensus trade-offs in microservices architectures.",,ai-orchestration/architecture/saga-distributed-transaction-architecture +saga-travel-booking-architecture,saga-travel-booking-architecture,Saga Travel Booking Architecture,architecture,Architecture,ai-orchestration,,ai-orchestration,4,17,5,saga-pattern;travel-booking;flight-reservation;hotel-booking;compensation;distributed-transaction;orchestration;architecture-diagram,"A travel booking saga architecture diagram orchestrating flight, hotel, and car rental reservations as a single distributed transaction, with automatic compensation to cancel all bookings if any reservation step fails. This template models the classic saga use case where multiple independent services must either all succeed or all roll back, ensuring travelers never end up with partial bookings. Perfect for demonstrating saga patterns with a real-world business scenario.",,ai-orchestration/architecture/saga-travel-booking-architecture +saga-order-fulfillment-architecture,saga-order-fulfillment-architecture,Saga Order Fulfillment Architecture,architecture,Architecture,approval,billing;security,approval;billing;security,4,18,3,order-fulfillment;saga-pattern;e-commerce;payment-authorization;inventory-reservation;compensation-chain;distributed-transaction;architecture-diagram,"An order fulfillment saga architecture diagram with four sequential steps: customer verification, inventory reservation, payment authorization, and shipment creation, with a compensation chain that reverses completed steps on failure. This template models the end-to-end order lifecycle as a saga, showing how each service participates in the transaction and how compensating actions maintain data consistency. Ideal for e-commerce architects designing reliable order processing pipelines.",,approval/architecture/saga-order-fulfillment-architecture +circuit-breaker-resilience-architecture,circuit-breaker-resilience-architecture,Circuit Breaker Resilience Architecture,architecture,Architecture,mcp,,mcp,4,18,3,circuit-breaker;resilience;fault-tolerance;cascading-failure;half-open-state;fallback;state-machine;architecture-diagram,"A circuit breaker resilience architecture diagram showing the complete state machine with closed, open, and half-open states, failure threshold tracking, recovery timer, and fallback response strategies for protecting services from cascading failures. This template visualizes the circuit breaker pattern in detail, including how the breaker transitions between states based on success and failure counts. Essential for building fault-tolerant microservices that degrade gracefully under load.",,mcp/architecture/circuit-breaker-resilience-architecture +bulkhead-isolation-architecture,bulkhead-isolation-architecture,Bulkhead Isolation Architecture,architecture,Architecture,handoff,,handoff,4,18,4,bulkhead-pattern;resource-isolation;thread-pool;backpressure;fault-isolation;resilience;priority-routing;architecture-diagram,"A bulkhead isolation architecture diagram with separate thread pools for critical, standard, and batch workloads, each with independent connection pools, exhaustion detection, and backpressure strategies to prevent one workload from starving others. This template models the bulkhead pattern inspired by ship hull compartments, where resource isolation ensures that a failure or overload in one component cannot cascade to others. Critical for systems requiring guaranteed availability for high-priority operations.",,handoff/architecture/bulkhead-isolation-architecture +retry-with-exponential-backoff-architecture,retry-with-exponential-backoff-architecture,Retry with Exponential Backoff Architecture,architecture,Architecture,uncategorized,,,3,17,3,retry-pattern;exponential-backoff;jitter;transient-failure;resilience;error-handling;thundering-herd;architecture-diagram,"A retry with exponential backoff architecture diagram showing the complete retry policy engine with retryable vs non-retryable error classification, exponential delay calculation with jitter, max retry thresholds, and graceful exhaustion handling. This template models the essential resilience pattern for handling transient failures in distributed systems, preventing thundering herd problems through randomized backoff delays. Foundational for any service-to-service communication in cloud architectures.",,uncategorized/architecture/retry-with-exponential-backoff-architecture +rate-limiter-architecture,rate-limiter-architecture,Rate Limiter Architecture,architecture,Architecture,uncategorized,,,3,17,4,rate-limiter;token-bucket;sliding-window;redis;api-protection;throttling;distributed-rate-limiting;architecture-diagram,"A rate limiter architecture diagram implementing the token bucket algorithm with Redis-backed distributed counters, sliding window logs, API key identification, rate limit headers, and multi-node synchronization for consistent enforcement. This template shows how to protect APIs from abuse and ensure fair usage across clients, with proper HTTP 429 responses and Retry-After headers. Essential for API platform teams building production-grade rate limiting infrastructure.",,uncategorized/architecture/rate-limiter-architecture +health-check-pattern-architecture,health-check-pattern-architecture,Health Check Pattern Architecture,architecture,Architecture,incident,security,incident;security,3,19,4,health-check;load-balancer;self-healing;monitoring;pagerduty;instance-rotation;deep-health-check;architecture-diagram,"A health check pattern architecture diagram with load balancer probes, deep health checks verifying database, cache, disk, and dependency status, automatic instance rotation, and alerting integration with PagerDuty for consecutive failures. This template models the health monitoring infrastructure that enables self-healing systems, where unhealthy instances are automatically removed from rotation and operations teams are alerted. Key for building production-ready services with proper observability.",,incident/architecture/health-check-pattern-architecture +hexagonal-ports-adapters-architecture,hexagonal-ports-adapters-architecture,Hexagonal (Ports and Adapters) Architecture,architecture,Architecture,uncategorized,,,4,16,4,hexagonal-architecture;ports-and-adapters;clean-architecture;dependency-inversion;domain-core;testability;technology-agnostic;architecture-diagram,"A hexagonal architecture diagram showing the clean separation between domain core, inbound adapters (REST, GraphQL, CLI, message consumers), outbound adapters (PostgreSQL, Stripe, email, Redis), and the port interfaces that connect them. This template visualizes the ports and adapters pattern where the domain core has zero dependencies on infrastructure, making it fully testable and technology-agnostic. Foundational for teams adopting clean architecture principles in their codebase.",,uncategorized/architecture/hexagonal-ports-adapters-architecture +clean-architecture-layers,clean-architecture-layers,Clean Architecture Layers,architecture,Architecture,uncategorized,,,3,16,4,clean-architecture;uncle-bob;dependency-rule;layered-architecture;use-cases;entities;interface-adapters;architecture-diagram,"A clean architecture layers diagram showing the four concentric layers: Entities (domain), Use Cases (application), Interface Adapters (controllers, presenters, repositories), and Frameworks & Drivers (web server, database, cloud SDK). This template models Uncle Bob's Clean Architecture with the dependency rule where inner layers never depend on outer layers, ensuring the domain model remains pure and framework-independent. Essential reference for software architects enforcing architectural boundaries.",,uncategorized/architecture/clean-architecture-layers +domain-driven-design-bounded-contexts-architecture,domain-driven-design-bounded-contexts-architecture,Domain-Driven Design Bounded Contexts Architecture,architecture,Architecture,uncategorized,,,4,18,5,domain-driven-design;bounded-context;anti-corruption-layer;context-map;shared-kernel;strategic-ddd;aggregate;architecture-diagram,"A DDD bounded contexts architecture diagram with Order, Customer, Shipping, and Billing contexts connected through an anti-corruption layer, shared kernel, and context map defining integration relationships. This template visualizes the strategic DDD patterns for decomposing complex domains into autonomous bounded contexts that communicate through well-defined integration events. Critical for architects applying Domain-Driven Design to large-scale enterprise systems.",,uncategorized/architecture/domain-driven-design-bounded-contexts-architecture +api-composition-pattern-architecture,api-composition-pattern-architecture,API Composition Pattern Architecture,architecture,Architecture,incident,,incident,3,16,3,api-composition;response-aggregation;fan-out;parallel-requests;timeout-handling;partial-response;microservices;architecture-diagram,"An API composition architecture diagram with a composer service that fans out parallel requests to multiple microservices, collects responses with timeout handling, and merges results into a single unified response with partial fallback support. This template models the API composition pattern used when a single client query requires data from multiple services, avoiding the need for direct service-to-service calls. Useful for teams building aggregation layers in microservices architectures.",,incident/architecture/api-composition-pattern-architecture +outbox-pattern-reliable-messaging-architecture,outbox-pattern-reliable-messaging-architecture,Outbox Pattern for Reliable Messaging Architecture,architecture,Architecture,uncategorized,,,4,18,4,outbox-pattern;transactional-outbox;reliable-messaging;dual-write;exactly-once;debezium;event-publishing;architecture-diagram,"A transactional outbox architecture diagram where domain writes and event publishing happen in the same database transaction, with a relay process polling the outbox table and publishing events to a message broker with guaranteed delivery. This template solves the dual-write problem where updating a database and publishing an event are not atomic, ensuring exactly-once event delivery without distributed transactions. Critical for event-driven architectures requiring reliable message publishing.",,uncategorized/architecture/outbox-pattern-reliable-messaging-architecture +ambassador-pattern-architecture,ambassador-pattern-architecture,Ambassador Pattern Architecture,architecture,Architecture,mcp,,mcp,3,15,3,ambassador-pattern;sidecar-proxy;external-api;retry-logic;circuit-breaker;metrics-collection;cross-cutting-concerns;architecture-diagram,"An ambassador pattern architecture diagram with a local proxy sidecar handling authentication header injection, circuit breaking, retry logic, and metrics collection for outbound requests to external third-party APIs. This template models the ambassador pattern where a helper service running alongside the application offloads cross-cutting concerns for external communication. Useful for teams integrating with unreliable third-party services that need resilience wrappers.",,mcp/architecture/ambassador-pattern-architecture +graphql-federation-architecture,graphql-federation-architecture,GraphQL Federation Architecture,architecture,Architecture,mcp,,mcp,3,15,3,graphql-federation;apollo-gateway;subgraph;schema-stitching;query-plan;federated-api;graphql;architecture-diagram,"A GraphQL federation architecture diagram with an Apollo Gateway building query plans and fanning out to User, Product, and Review subgraphs, each owning its schema and database, with response stitching into a unified GraphQL result. This template models the federated GraphQL approach where multiple teams independently develop and deploy their subgraphs while clients see a single unified API. Ideal for organizations scaling GraphQL across multiple teams and services.",,mcp/architecture/graphql-federation-architecture +zero-trust-security-architecture,zero-trust-security-architecture,Zero Trust Security Architecture,architecture,Architecture,security,,security,4,19,4,zero-trust;security-architecture;mfa;micro-segmentation;mtls;least-privilege;continuous-verification;architecture-diagram,"A zero trust security architecture diagram with device posture checks, MFA identity verification, risk-based policy decisions, short-lived JWT tokens, micro-segmentation, mTLS encryption, least-privilege access enforcement, and continuous monitoring. This template models the 'never trust, always verify' security paradigm where every request is authenticated and authorized regardless of network location. Essential for security architects implementing modern zero-trust frameworks in cloud-native environments.",,security/architecture/zero-trust-security-architecture +multi-tenant-saas-architecture,multi-tenant-saas-architecture,Multi-Tenant SaaS Architecture,architecture,Architecture,security,delivery,security;delivery,4,17,4,multi-tenant;saas-architecture;tenant-isolation;row-level-security;shared-infrastructure;enterprise-tier;data-isolation;architecture-diagram,"A multi-tenant SaaS architecture diagram with tenant identification, tier-based routing (shared vs dedicated pools), row-level security, per-tenant encryption keys, and isolated backup strategies for standard and enterprise isolation models. This template models the architecture decisions for building SaaS platforms that serve multiple customers from shared infrastructure while maintaining strict data isolation. Critical for SaaS architects balancing cost efficiency with enterprise security requirements.",,security/architecture/multi-tenant-saas-architecture +kubernetes-container-orchestration-architecture,kubernetes-container-orchestration-architecture,Kubernetes Container Orchestration Architecture,architecture,Architecture,ai-orchestration,,ai-orchestration,4,18,4,kubernetes;container-orchestration;k8s;control-plane;worker-node;ingress;persistent-storage;architecture-diagram,"A Kubernetes container orchestration architecture diagram showing the control plane (API Server, etcd, Scheduler, Controller Manager), worker nodes (Kubelet, container runtime, kube-proxy, pods), networking layer (Ingress, Network Policy, Service Mesh), and persistent storage with CSI drivers. This template provides a comprehensive view of the Kubernetes architecture stack from control plane to storage layer. Foundational reference for DevOps engineers and platform teams managing Kubernetes clusters.",,ai-orchestration/architecture/kubernetes-container-orchestration-architecture +data-mesh-architecture,data-mesh-architecture,Data Mesh Architecture,architecture,Architecture,uncategorized,,,4,17,4,data-mesh;domain-ownership;data-product;self-serve-data;federated-governance;data-platform;data-architecture;architecture-diagram,"A data mesh architecture diagram with domain-oriented data ownership across Sales, Marketing, and Finance domains, each exposing self-serve data products through APIs with quality SLAs, governed by a federated data platform with a shared catalog and cross-domain query engine. This template models the paradigm shift from centralized data teams to domain-owned data products, applying microservices principles to data architecture. Essential for organizations scaling data operations beyond centralized data warehouse bottlenecks.",,uncategorized/architecture/data-mesh-architecture +cell-based-architecture,cell-based-architecture,Cell-Based Architecture,architecture,Architecture,handoff,,handoff,4,20,4,cell-based-architecture;blast-radius;geographic-routing;fault-isolation;independent-cells;cross-cell-replication;hyperscale;architecture-diagram,"A cell-based architecture diagram with geographic routing to independent, self-contained cells (US-East, EU-West), each with its own gateway, compute, database, cache, and message queue, plus shared services for cross-cell replication and global configuration. This template models the cell architecture pattern used by hyperscale systems to achieve blast radius isolation, where failures in one cell cannot affect users in another. Key for architects designing systems that require extreme availability and fault isolation.",,handoff/architecture/cell-based-architecture +observability-three-pillars-architecture,observability-three-pillars-architecture,Observability Three Pillars Architecture,architecture,Architecture,uncategorized,,,4,17,4,observability;three-pillars;opentelemetry;prometheus;jaeger;loki;grafana;slo-sli;architecture-diagram,"An observability architecture diagram implementing the three pillars (metrics, traces, logs) with OpenTelemetry SDK instrumentation, OTLP collector pipeline, Prometheus, Jaeger, and Loki backends, Grafana dashboards, SLO/SLI tracking, and PagerDuty alerting integration. This template provides a complete observability stack reference showing how telemetry data flows from application instrumentation through collection, storage, visualization, and incident response. Essential for SRE teams building production monitoring infrastructure.",,uncategorized/architecture/observability-three-pillars-architecture +gitops-deployment-architecture,gitops-deployment-architecture,GitOps Deployment Architecture,architecture,Architecture,delivery,,delivery,4,19,4,gitops;argocd;flux;kubernetes-deployment;declarative-infrastructure;drift-detection;rolling-update;architecture-diagram,"A GitOps deployment architecture diagram with developer Git workflow, CI/CD pipeline building and pushing container images, ArgoCD or Flux detecting Git manifest changes, drift detection, automatic cluster synchronization, and rolling update deployment to Kubernetes. This template models the GitOps paradigm where Git is the single source of truth for both application code and infrastructure state, enabling declarative, auditable, and reproducible deployments. Critical for teams adopting GitOps practices for Kubernetes deployments.",,delivery/architecture/gitops-deployment-architecture +ai-native-single-agent-architecture,ai-native-single-agent-architecture,AI-Native Single Agent Architecture,architecture,Architecture,agentic,ai-orchestration;mcp,agentic;ai-orchestration;mcp,2,11,3,ai-native;single-agent;agentic-ai;mcp;architecture-diagram,"A single-agent AI architecture where one agent handles everything: parsing requests, reasoning, calling tools via MCP, and generating responses. This is the default architecture for prototypes and simple automations—easy to debug but hits context-window limits quickly and is hard to parallelize. Ideal for MVPs and solo builders shipping fast.",,agentic/architecture/ai-native-single-agent-architecture +ai-native-sequential-pipeline-architecture,ai-native-sequential-pipeline-architecture,AI-Native Sequential Pipeline Architecture,architecture,Architecture,delivery,agentic;ai-orchestration,delivery;agentic;ai-orchestration,2,7,2,ai-native;sequential-pipeline;agentic-ai;llm-microservices;architecture-diagram,"A sequential pipeline architecture chaining multiple agents in a fixed order (parse → enrich → analyze → format), which is a common 'LLM microservices' setup when each step can be isolated. This structure is often used in document processing and ETL-like workflows because each step is testable and predictable.",,delivery/architecture/ai-native-sequential-pipeline-architecture +ai-native-orchestrator-worker-architecture,ai-native-orchestrator-worker-architecture,AI-Native Orchestrator-Worker Architecture,architecture,Architecture,agentic,ai-orchestration,agentic;ai-orchestration,3,14,4,ai-native;orchestrator-worker;agentic-ai;langgraph;multi-agent;architecture-diagram,"An orchestrator-worker architecture where an orchestrator agent breaks a goal into subtasks, dispatches to specialized workers, then synthesizes a final response. This is the most common 'agent orchestration' architecture—powerful but the orchestrator can become a bottleneck as the number of workers grows. Frameworks like LangGraph focus on explicit routing/state to manage this.",,agentic/architecture/ai-native-orchestrator-worker-architecture +ai-native-hierarchical-architecture,ai-native-hierarchical-architecture,AI-Native Hierarchical Architecture,architecture,Architecture,agentic,ai-orchestration,agentic;ai-orchestration,4,16,4,ai-native;hierarchical;agentic-ai;enterprise;multi-agent;architecture-diagram,"A hierarchical multi-agent architecture that scales orchestration by stacking supervisors and team leads (a tree structure), which mirrors enterprise org structures and helps partition context. This is the 'enterprise-grade agentic AI architecture' when a single orchestrator cannot manage all workers directly. Ideal for large enterprises and multi-domain workflows.",,agentic/architecture/ai-native-hierarchical-architecture +ai-native-parallel-fan-out-architecture,ai-native-parallel-fan-out-architecture,AI-Native Parallel Fan-Out Architecture,architecture,Architecture,delivery,agentic;ai-orchestration,delivery;agentic;ai-orchestration,3,11,2,ai-native;parallel-fan-out;agentic-ai;map-reduce;ci-cd;architecture-diagram,"A parallel fan-out architecture that runs multiple agents simultaneously on independent checks (style, security, performance) and then merges results. This is a standard multi-agent design approach for throughput, mapping cleanly to CI/CD, incident response, and research. Fan-in reconciliation becomes the subtle part.",,delivery/architecture/ai-native-parallel-fan-out-architecture +ai-native-event-driven-kafka-architecture,ai-native-event-driven-kafka-architecture,AI-Native Event-Driven Kafka Architecture,architecture,Architecture,agentic,ai-orchestration;mcp,agentic;ai-orchestration;mcp,3,12,5,ai-native;event-driven;agentic-ai;kafka;pub-sub;agent-mesh;architecture-diagram,"An event-driven agentic AI architecture that replaces the central orchestrator with Kafka/PubSub topics: agents subscribe, react, and publish new events. This aligns multi-agent systems with proven microservices choreography and is ideal for real-time, high-throughput systems and 'agent mesh' setups.",,agentic/architecture/ai-native-event-driven-kafka-architecture +ai-native-generator-critic-architecture,ai-native-generator-critic-architecture,AI-Native Generator-Critic Architecture,architecture,Architecture,agentic,ai-orchestration,agentic;ai-orchestration,3,9,3,ai-native;generator-critic;agentic-ai;tournament-mode;multi-agent;architecture-diagram,"A competitive / generator-critic architecture where multiple generators produce independent answers, then an evaluator agent scores and selects the best output. This approach improves quality and reduces single-model brittleness. It's costlier (multiple LLM calls) but pays off when correctness or creativity matters more than latency.",,agentic/architecture/ai-native-generator-critic-architecture +event-driven-notification-hub-architecture,event-driven-notification-hub-architecture,Event-Driven Notification Hub Architecture,architecture,Architecture,uncategorized,,,4,20,3,notification-hub;multi-channel;event-driven;sendgrid;firebase-cloud-messaging;twilio;delivery-tracking;architecture-diagram,"An event-driven notification hub architecture diagram with multi-source event ingestion, template-based message rendering, user preference routing across email (SendGrid/SES), push (FCM), SMS (Twilio), and Slack channels, with delivery tracking and retry mechanisms. This template models a centralized notification system that decouples business services from delivery infrastructure, supporting multi-channel communication with user-controlled preferences. Ideal for platform teams building scalable notification infrastructure.",,uncategorized/architecture/event-driven-notification-hub-architecture +agentic-supervisor-worker,agentic-supervisor-worker,Agentic Supervisor-Worker Architecture,architecture,Architecture,agentic,,agentic,3,10,4,agentic;supervisor-worker;multi-agent;orchestrator;architecture-diagram;ai-team,"A supervisor-worker multi-agent architecture where an orchestrator agent receives a high-level goal, breaks it into subtasks, delegates each to specialist worker agents (researcher, writer, QA), monitors execution, handles failures, and synthesizes results. The orchestrator manages but does not execute tasks itself.",,agentic/architecture/agentic-supervisor-worker +agentic-sequential-pipeline,agentic-sequential-pipeline,Agentic Sequential Pipeline Architecture,architecture,Architecture,delivery,agentic;ai-orchestration,delivery;agentic;ai-orchestration,2,5,5,agentic;sequential-pipeline;multi-agent;assembly-line;architecture-diagram;ai-team,"A sequential pipeline multi-agent architecture where agents are arranged in a strict sequence. Each agent transforms or enriches the output of the previous one, then passes it forward. No central orchestrator — the flow is deterministic like an assembly line.",,delivery/architecture/agentic-sequential-pipeline +agentic-swarm,agentic-swarm,Agentic Swarm Architecture,architecture,Architecture,agentic,,agentic,3,6,5,agentic;swarm;multi-agent;parallel;aggregator;architecture-diagram;ai-team,"A swarm multi-agent architecture where multiple agents work on the same or related tasks simultaneously, with no central coordinator. Their outputs are then aggregated, voted on, or merged by a dedicated aggregator node. Agents may compete — the best output wins.",,agentic/architecture/agentic-swarm +agentic-hierarchical,agentic-hierarchical,Agentic Hierarchical Architecture,architecture,Architecture,agentic,,agentic,4,8,7,agentic;hierarchical;multi-agent;enterprise;architecture-diagram;ai-team,"A hierarchical multi-agent architecture with multi-level organizational structure. A top-level executive agent manages mid-level team lead agents, who each manage their own pool of specialist workers. Teams within teams — the hierarchy maps to domain separation.",,agentic/architecture/agentic-hierarchical +agentic-team-of-rivals,agentic-team-of-rivals,Agentic Team of Rivals Architecture,architecture,Architecture,agentic,,agentic,3,5,3,agentic;team-of-rivals;multi-agent;critic;veto;architecture-diagram;ai-team,The most architecturally sophisticated multi-agent pattern. Agents are assigned not just roles but opposing incentives. A Planner is optimistic about goal completion. A Critic is constitutionally skeptical and holds veto authority. Errors get caught through adversarial pressure rather than trusting a single model's self-assessment.,,agentic/architecture/agentic-team-of-rivals +ai-orchestration-single-agent,ai-orchestration-single-agent,AI Orchestration - Single Agent (Monolith),architecture,Architecture,ai-orchestration,mcp,ai-orchestration;mcp,2,12,3,ai-native;single-agent;monolith;mcp;architecture-diagram;orchestration,"The simplest AI-native architecture — a single agent that receives user input, reasons, plans, decides on tool calls, processes results, and generates responses. Direct MCP connection over stdio or HTTP. Best for MVPs and when low latency matters.",,ai-orchestration/architecture/ai-orchestration-single-agent +ai-orchestration-sequential-pipeline,ai-orchestration-sequential-pipeline,AI Orchestration - Sequential Pipeline,architecture,Architecture,delivery,ai-orchestration,delivery;ai-orchestration,2,5,2,ai-native;sequential-pipeline;assembly-line;architecture-diagram;orchestration,"An assembly-line architecture where agents are arranged in a strict sequence. Each agent transforms or enriches the output of the previous one, then passes it forward. Best for tasks with clear sequential dependencies — document processing, content production pipelines, compliance workflows.",,delivery/architecture/ai-orchestration-sequential-pipeline +ai-orchestration-orchestrator-worker,ai-orchestration-orchestrator-worker,AI Orchestration - Orchestrator-Worker,architecture,Architecture,agentic,ai-orchestration,agentic;ai-orchestration,3,15,5,ai-native;orchestrator-worker;conductor;multi-agent;architecture-diagram;orchestration,"A conductor-style architecture where one orchestrator agent receives a complex task, breaks it into subtasks, dispatches each to specialist worker agents (research, code, review), collects results, and synthesizes the final answer. Best for complex multi-step tasks with dynamic decomposition.",,agentic/architecture/ai-orchestration-orchestrator-worker +ai-orchestration-hierarchical,ai-orchestration-hierarchical,AI Orchestration - Hierarchical (Org Chart),architecture,Architecture,agentic,ai-orchestration,agentic;ai-orchestration,4,17,5,ai-native;hierarchical;org-chart;enterprise;multi-agent;architecture-diagram;orchestration,"An org-chart architecture with multi-level structure. A top-level supervisor manages team leads, who each manage their own pool of specialist workers. Teams within teams. Best for enterprise-scale automation with 10+ specialized agents spanning multiple domains.",,agentic/architecture/ai-orchestration-hierarchical +ai-orchestration-parallel-fan-out,ai-orchestration-parallel-fan-out,AI Orchestration - Parallel Fan-Out (Map-Reduce),architecture,Architecture,agentic,ai-orchestration,agentic;ai-orchestration,3,9,3,ai-native;parallel-fan-out;map-reduce;coordinator;multi-agent;architecture-diagram;orchestration,"A map-reduce style architecture where a coordinator fans out tasks to multiple parallel worker agents (style check, security audit, performance analysis), gathers all results, and makes an aggregate decision. Best for PR reviews, code reviews, and multi-dimensional analysis.",,agentic/architecture/ai-orchestration-parallel-fan-out +ai-orchestration-event-driven-mesh,ai-orchestration-event-driven-mesh,AI Orchestration - Event-Driven Mesh (Kafka-First),architecture,Architecture,ai-orchestration,mcp,ai-orchestration;mcp,3,13,5,ai-native;event-driven;kafka;agent-mesh;pub-sub;architecture-diagram;orchestration,"An event-driven agent mesh architecture using a Kafka-style event broker. Multiple agents subscribe to topics (orders, alerts, analytics), process events independently, and publish results back to the bus. Best for real-time event processing and decoupled service architectures.",,ai-orchestration/architecture/ai-orchestration-event-driven-mesh +ai-orchestration-competitive-generator-critic,ai-orchestration-competitive-generator-critic,AI Orchestration - Competitive Generator-Critic,architecture,Architecture,agentic,ai-orchestration,agentic;ai-orchestration,3,10,3,ai-native;competitive;generator-critic;tournament;multi-agent;architecture-diagram;orchestration,"A tournament-mode architecture where multiple generator agents produce independent outputs in parallel, then an evaluator agent scores and selects the best. Quality threshold checking with refinement loops. Best when correctness or creativity matters more than latency.",,agentic/architecture/ai-orchestration-competitive-generator-critic +mcp-direct-connect,mcp-direct-connect,MCP Direct Connect Architecture,architecture,DevOps,mcp,,mcp,1,6,2,mcp;direct-connect;stdio;http;architecture-diagram;production-grade,"The simplest MCP pattern — direct connection between host application and MCP server over stdio or HTTP. No extra hops, lowest latency, easiest debugging. Perfect for MVPs, hackathons, and single-team setups where security governance is not yet a concern.",,mcp/devops/mcp-direct-connect +mcp-gateway-proxy,mcp-gateway-proxy,MCP Gateway Proxy Architecture,architecture,DevOps,security,compliance;mcp,security;compliance;mcp,3,7,3,mcp;gateway;proxy;oauth;rate-limiting;audit;architecture-diagram;production-grade,"An API gateway pattern that sits between agents and MCP servers to handle authentication, rate limits, and auditing. The gateway enforces OAuth 2.0, SAML, SSO, tool-level rate limiting, and team-based quotas. Essential for multi-team or multi-tenant MCP deployments.",,security/devops/mcp-gateway-proxy +mcp-tool-router,mcp-tool-router,MCP Tool Router Architecture,architecture,DevOps,handoff,mcp,handoff;mcp,3,8,4,mcp;tool-router;semantic-routing;embeddings;token-optimization;architecture-diagram;production-grade,A routing pattern that puts a semantic router in front of MCP tools so the LLM only sees the subset it needs. Uses vector embeddings and cosine similarity to match user intent to tools dynamically. Achieves up to 96% reduction in input tokens when dealing with large tool catalogs.,,handoff/devops/mcp-tool-router +mcp-agent-mesh,mcp-agent-mesh,MCP Agent Mesh Architecture,architecture,DevOps,agentic,mcp,agentic;mcp,4,10,4,mcp;agent-mesh;shared-context;multi-agent;broker;architecture-diagram;production-grade,"A multi-agent mesh pattern where agents communicate through a shared context broker backed by MCP. Enables coordinated tool access and state synchronization across multiple specialized agents (planner, coder, reviewer, operator). Supports both orchestrated and choreographed interaction patterns.",,agentic/devops/mcp-agent-mesh +mcp-circuit-breaker,mcp-circuit-breaker,MCP Circuit Breaker Architecture,architecture,DevOps,mcp,,mcp,3,9,3,mcp;circuit-breaker;resilience;fault-tolerance;health-check;architecture-diagram;production-grade,"A resilience pattern that wraps MCP calls with health-aware gates using three states: Closed (normal), Open (failures detected, fast-fail), and Half-Open (testing recovery). Prevents cascading failures when tools become unresponsive. Essential for production-grade reliability.",,mcp/devops/mcp-circuit-breaker +mcp-context-proxy,mcp-context-proxy,MCP Context Proxy Architecture,architecture,DevOps,mcp,,mcp,3,7,3,mcp;context-proxy;caching;compression;token-optimization;architecture-diagram;production-grade,"A caching and compression layer that sits between agents and MCP servers, intercepting redundant context requests before they hit the wire. Uses TTL-based cache invalidation, Brotli compression, and semantic caching. Can achieve up to 95%+ token reduction and significantly lower LLM bills.",,mcp/devops/mcp-context-proxy +context-session-memory,context-session-memory,Context Management - Session Memory,architecture,Architecture,context-management,,context-management,2,9,3,context-management;session-memory;short-term;memory;architecture-diagram,"Short-term context pattern where the channel sends new messages plus recent history. The agent runtime merges that with local session state, assembles the prompt, and persists the response back into history. Simple but cost and latency grow with history length.",,context-management/architecture/context-session-memory +context-rolling-summary-memory,context-rolling-summary-memory,Context Management - Rolling Summary Memory,architecture,Architecture,context-management,,context-management,3,8,4,context-management;rolling-summary;compression;memory;architecture-diagram,"Compressed history pattern that keeps full history for a while, then when a threshold is hit, summarizes the last chunk and replaces detailed turns with a shorter summary message. Dramatically reduces prompt size on long-running chats while maintaining gist continuity.",,context-management/architecture/context-rolling-summary-memory +context-profile-memory,context-profile-memory,Context Management - Profile Memory,architecture,Architecture,context-management,,context-management,2,7,3,context-management;profile-memory;identity;user-profile;architecture-diagram,"Identity-style memory pattern where profile data is loaded at session start. Each prompt combines system persona, user profile, and current message. New facts can be written back to profile memory. Small predictable overhead with big UX lift — the agent remembers your name, stack, tone, and constraints.",,context-management/architecture/context-profile-memory +context-semantic-memory,context-semantic-memory,Context Management - Semantic Memory,architecture,Architecture,context-management,,context-management,3,9,4,context-management;semantic-memory;vector-db;embeddings;rag;architecture-diagram,"Vector-based memory pattern where text is chunked, embedded, and stored in a vector database. On query, the question is embedded, a vector search is run, candidates are reranked, and top results are injected into the prompt. Where the agent feels like it remembers everything without hallucinating.",,context-management/architecture/context-semantic-memory +context-episodic-memory,context-episodic-memory,Context Management - Episodic Memory,architecture,Architecture,context-management,,context-management,3,11,4,context-management;episodic-memory;learning;experience;architecture-diagram,"Learning-from-experience pattern where every task run becomes an episode with input, actions, and outcome. Before tackling a new task, the agent fetches similar episodes and uses them as hints. Over time, the agent feels like it's learning instead of repeating the same failed plans.",,context-management/architecture/context-episodic-memory +context-hybrid-retrieval-memory,context-hybrid-retrieval-memory,Context Management - Hybrid Retrieval Memory,architecture,Architecture,context-management,,context-management,4,11,5,context-management;hybrid-retrieval;semantic;keyword;recency;architecture-diagram,"Multi-modal retrieval pattern combining semantic search, exact/keyword search, and recency search in parallel. Results are merged and reranked into a single context set. Much higher recall because the agent can find both fuzzy references and exact entities. Essential for comprehensive knowledge retrieval.",,context-management/architecture/context-hybrid-retrieval-memory +context-shared-memory,context-shared-memory,Context Management - Shared Memory,architecture,Architecture,agentic,context-management,agentic;context-management,3,9,4,context-management;shared-memory;multi-agent;orchestrator;architecture-diagram,"Multi-agent coordination pattern where an orchestrator breaks work into subtasks, specialist agents pull from and push to a shared state store, and the orchestrator composes the final answer from that shared state. Multi-agent setups feel coherent instead of each assistant having its own inconsistent memory.",,agentic/architecture/context-shared-memory diff --git a/offboarding/business-operations/account-deletion-workflow/README.md b/offboarding/business-operations/account-deletion-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..05bbe1f37fb68a70f83f8c3e6091900d9b9bdbb5 --- /dev/null +++ b/offboarding/business-operations/account-deletion-workflow/README.md @@ -0,0 +1,19 @@ +# Account Deletion Workflow + +Account deletion workflow with cancellation reason capture, retention offer, subscription termination, data cleanup, and confirmation email. + +**Template ID:** `account-deletion-workflow` +**Kind:** workflow +**Source domain:** business-operations +**Primary use case:** offboarding +**Secondary use cases:** billing +**Complexity:** 3/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [account-deletion, user-offboarding, data-cleanup, subscription-cancel, retention-offer, exit-survey] +**Source path:** `business-operations/account-deletion` +**Repo path:** `offboarding/business-operations/account-deletion-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/offboarding/business-operations/account-deletion-workflow/metadata.json b/offboarding/business-operations/account-deletion-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..55a144cc9f17ee536ef8043e1d8c9c759b511a39 --- /dev/null +++ b/offboarding/business-operations/account-deletion-workflow/metadata.json @@ -0,0 +1,29 @@ +{ + "template_id": "account-deletion-workflow", + "workflow_id": "account-deletion", + "title": "Account Deletion Workflow", + "kind": "workflow", + "source_domain": "business-operations", + "primary_use_case": "offboarding", + "secondary_use_cases": [ + "billing" + ], + "use_cases": [ + "offboarding", + "billing" + ], + "complexity": 3, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "account-deletion", + "user-offboarding", + "data-cleanup", + "subscription-cancel", + "retention-offer", + "exit-survey" + ], + "description": "Account deletion workflow with cancellation reason capture, retention offer, subscription termination, data cleanup, and confirmation email.", + "source_path": "business-operations/account-deletion", + "repo_path": "offboarding/business-operations/account-deletion-workflow" +} diff --git a/business-operations/account-deletion/workflow.fz b/offboarding/business-operations/account-deletion-workflow/workflow.fz similarity index 100% rename from business-operations/account-deletion/workflow.fz rename to offboarding/business-operations/account-deletion-workflow/workflow.fz diff --git a/onboarding/business-operations/ab-test-setup-workflow/README.md b/onboarding/business-operations/ab-test-setup-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..43e06ed600226b75564779c4afd82d7c79abbfd1 --- /dev/null +++ b/onboarding/business-operations/ab-test-setup-workflow/README.md @@ -0,0 +1,19 @@ +# Ab Test Setup Workflow + +A/B test setup workflow with hypothesis definition, variant creation, traffic allocation, statistical analysis, and winner deployment. + +**Template ID:** `ab-test-setup-workflow` +**Kind:** workflow +**Source domain:** business-operations +**Primary use case:** onboarding +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [ab-testing, experimentation, split-testing, statistical-significance, conversion-optimization, optimizely] +**Source path:** `business-operations/ab-test-setup` +**Repo path:** `onboarding/business-operations/ab-test-setup-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/onboarding/business-operations/ab-test-setup-workflow/metadata.json b/onboarding/business-operations/ab-test-setup-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..1824b7b284fb49f118b1ecae5ba8b84fa412763e --- /dev/null +++ b/onboarding/business-operations/ab-test-setup-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "ab-test-setup-workflow", + "workflow_id": "ab-test-setup", + "title": "Ab Test Setup Workflow", + "kind": "workflow", + "source_domain": "business-operations", + "primary_use_case": "onboarding", + "secondary_use_cases": [], + "use_cases": [ + "onboarding" + ], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "ab-testing", + "experimentation", + "split-testing", + "statistical-significance", + "conversion-optimization", + "optimizely" + ], + "description": "A/B test setup workflow with hypothesis definition, variant creation, traffic allocation, statistical analysis, and winner deployment.", + "source_path": "business-operations/ab-test-setup", + "repo_path": "onboarding/business-operations/ab-test-setup-workflow" +} diff --git a/business-operations/ab-test-setup/workflow.fz b/onboarding/business-operations/ab-test-setup-workflow/workflow.fz similarity index 100% rename from business-operations/ab-test-setup/workflow.fz rename to onboarding/business-operations/ab-test-setup-workflow/workflow.fz diff --git a/onboarding/business-operations/two-factor-setup-workflow/README.md b/onboarding/business-operations/two-factor-setup-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..47d2b4f05b2d0fee8832d3fddb2cc11b9d57b6db --- /dev/null +++ b/onboarding/business-operations/two-factor-setup-workflow/README.md @@ -0,0 +1,19 @@ +# Two Factor Setup Workflow + +Two-factor authentication setup workflow with method selection (TOTP/SMS), QR code generation, backup codes, and verification confirmation. + +**Template ID:** `two-factor-setup-workflow` +**Kind:** workflow +**Source domain:** business-operations +**Primary use case:** onboarding +**Secondary use cases:** security +**Complexity:** 2/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [two-factor-auth, mfa, totp, authenticator-app, security, account-protection] +**Source path:** `business-operations/two-factor-setup` +**Repo path:** `onboarding/business-operations/two-factor-setup-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/onboarding/business-operations/two-factor-setup-workflow/metadata.json b/onboarding/business-operations/two-factor-setup-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..c1640f0d172ed1f4e7d11ce90b4aebd6809ce91b --- /dev/null +++ b/onboarding/business-operations/two-factor-setup-workflow/metadata.json @@ -0,0 +1,29 @@ +{ + "template_id": "two-factor-setup-workflow", + "workflow_id": "two-factor-setup", + "title": "Two Factor Setup Workflow", + "kind": "workflow", + "source_domain": "business-operations", + "primary_use_case": "onboarding", + "secondary_use_cases": [ + "security" + ], + "use_cases": [ + "onboarding", + "security" + ], + "complexity": 2, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "two-factor-auth", + "mfa", + "totp", + "authenticator-app", + "security", + "account-protection" + ], + "description": "Two-factor authentication setup workflow with method selection (TOTP/SMS), QR code generation, backup codes, and verification confirmation.", + "source_path": "business-operations/two-factor-setup", + "repo_path": "onboarding/business-operations/two-factor-setup-workflow" +} diff --git a/business-operations/two-factor-setup/workflow.fz b/onboarding/business-operations/two-factor-setup-workflow/workflow.fz similarity index 100% rename from business-operations/two-factor-setup/workflow.fz rename to onboarding/business-operations/two-factor-setup-workflow/workflow.fz diff --git a/onboarding/business-operations/user-onboarding-workflow/README.md b/onboarding/business-operations/user-onboarding-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..1df6973aa69e728593408baeab34dfaa8d1c2631 --- /dev/null +++ b/onboarding/business-operations/user-onboarding-workflow/README.md @@ -0,0 +1,19 @@ +# User Onboarding Workflow + +New user onboarding workflow with welcome email, profile setup, product tour, first action prompt, and activation milestone tracking. + +**Template ID:** `user-onboarding-workflow` +**Kind:** workflow +**Source domain:** business-operations +**Primary use case:** onboarding +**Secondary use cases:** None +**Complexity:** 2/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [user-onboarding, activation, product-tour, welcome-email, first-time-user, time-to-value] +**Source path:** `business-operations/user-onboarding` +**Repo path:** `onboarding/business-operations/user-onboarding-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/onboarding/business-operations/user-onboarding-workflow/metadata.json b/onboarding/business-operations/user-onboarding-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..54084f2c0b9027ecfbfed739c7591c7928012b4d --- /dev/null +++ b/onboarding/business-operations/user-onboarding-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "user-onboarding-workflow", + "workflow_id": "user-onboarding", + "title": "User Onboarding Workflow", + "kind": "workflow", + "source_domain": "business-operations", + "primary_use_case": "onboarding", + "secondary_use_cases": [], + "use_cases": [ + "onboarding" + ], + "complexity": 2, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "user-onboarding", + "activation", + "product-tour", + "welcome-email", + "first-time-user", + "time-to-value" + ], + "description": "New user onboarding workflow with welcome email, profile setup, product tour, first action prompt, and activation milestone tracking.", + "source_path": "business-operations/user-onboarding", + "repo_path": "onboarding/business-operations/user-onboarding-workflow" +} diff --git a/business-operations/user-onboarding/workflow.fz b/onboarding/business-operations/user-onboarding-workflow/workflow.fz similarity index 100% rename from business-operations/user-onboarding/workflow.fz rename to onboarding/business-operations/user-onboarding-workflow/workflow.fz diff --git a/onboarding/business-operations/webinar-registration-workflow/README.md b/onboarding/business-operations/webinar-registration-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..ea179d79af45cecd2d00b9b36f7498be5a9435b2 --- /dev/null +++ b/onboarding/business-operations/webinar-registration-workflow/README.md @@ -0,0 +1,19 @@ +# Webinar Registration Workflow + +Webinar registration workflow with signup form, calendar invite, reminder email sequence, attendance tracking, and post-event follow-up. + +**Template ID:** `webinar-registration-workflow` +**Kind:** workflow +**Source domain:** business-operations +**Primary use case:** onboarding +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [webinar, event-registration, zoom, calendar-invite, reminder-sequence, lead-capture] +**Source path:** `business-operations/webinar-registration` +**Repo path:** `onboarding/business-operations/webinar-registration-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/onboarding/business-operations/webinar-registration-workflow/metadata.json b/onboarding/business-operations/webinar-registration-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..ffd52089f7dbedbf35d2696f3947b16f8a3ad00e --- /dev/null +++ b/onboarding/business-operations/webinar-registration-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "webinar-registration-workflow", + "workflow_id": "webinar-registration", + "title": "Webinar Registration Workflow", + "kind": "workflow", + "source_domain": "business-operations", + "primary_use_case": "onboarding", + "secondary_use_cases": [], + "use_cases": [ + "onboarding" + ], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "webinar", + "event-registration", + "zoom", + "calendar-invite", + "reminder-sequence", + "lead-capture" + ], + "description": "Webinar registration workflow with signup form, calendar invite, reminder email sequence, attendance tracking, and post-event follow-up.", + "source_path": "business-operations/webinar-registration", + "repo_path": "onboarding/business-operations/webinar-registration-workflow" +} diff --git a/business-operations/webinar-registration/workflow.fz b/onboarding/business-operations/webinar-registration-workflow/workflow.fz similarity index 100% rename from business-operations/webinar-registration/workflow.fz rename to onboarding/business-operations/webinar-registration-workflow/workflow.fz diff --git a/onboarding/finance/vendor-onboarding-workflow/README.md b/onboarding/finance/vendor-onboarding-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..fe38d18b39919795aaad2634c5928d679c7947ff --- /dev/null +++ b/onboarding/finance/vendor-onboarding-workflow/README.md @@ -0,0 +1,19 @@ +# Vendor Onboarding Workflow + +Vendor onboarding workflow with application review, W-9/W-8BEN verification, insurance certificate validation, background checks, and compliance approval before vendor activation. + +**Template ID:** `vendor-onboarding-workflow` +**Kind:** workflow +**Source domain:** finance +**Primary use case:** onboarding +**Secondary use cases:** billing, compliance +**Complexity:** 4/5 +**Nodes:** 19 +**Lanes:** 3 +**Tags:** [vendor-onboarding, supplier-management, w9-verification, insurance-compliance, background-check, payment-terms, procurement] +**Source path:** `finance/vendor-onboarding` +**Repo path:** `onboarding/finance/vendor-onboarding-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/finance/vendor-onboarding/metadata.json b/onboarding/finance/vendor-onboarding-workflow/metadata.json similarity index 52% rename from finance/vendor-onboarding/metadata.json rename to onboarding/finance/vendor-onboarding-workflow/metadata.json index 5ff2b626f007975eb126e4a8593d3f3c74b5432c..3253b132e37eb35780ab4ecb42a019ee088f742c 100644 --- a/finance/vendor-onboarding/metadata.json +++ b/onboarding/finance/vendor-onboarding-workflow/metadata.json @@ -1,6 +1,19 @@ { + "template_id": "vendor-onboarding-workflow", "workflow_id": "vendor-onboarding", - "domain": "finance", + "title": "Vendor Onboarding Workflow", + "kind": "workflow", + "source_domain": "finance", + "primary_use_case": "onboarding", + "secondary_use_cases": [ + "billing", + "compliance" + ], + "use_cases": [ + "onboarding", + "billing", + "compliance" + ], "complexity": 4, "num_nodes": 19, "num_lanes": 3, @@ -13,5 +26,7 @@ "payment-terms", "procurement" ], - "description": "Vendor onboarding workflow with application review, W-9/W-8BEN verification, insurance certificate validation, background checks, and compliance approval before vendor activation." -} \ No newline at end of file + "description": "Vendor onboarding workflow with application review, W-9/W-8BEN verification, insurance certificate validation, background checks, and compliance approval before vendor activation.", + "source_path": "finance/vendor-onboarding", + "repo_path": "onboarding/finance/vendor-onboarding-workflow" +} diff --git a/finance/vendor-onboarding/workflow.fz b/onboarding/finance/vendor-onboarding-workflow/workflow.fz similarity index 100% rename from finance/vendor-onboarding/workflow.fz rename to onboarding/finance/vendor-onboarding-workflow/workflow.fz diff --git a/onboarding/hr/onboarding-workflow/README.md b/onboarding/hr/onboarding-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..fe90d3203f0d3d1cb34e7cb38983e2195069d93b --- /dev/null +++ b/onboarding/hr/onboarding-workflow/README.md @@ -0,0 +1,19 @@ +# Onboarding Workflow + +Complete employee onboarding workflow covering offer acceptance, HR record creation, benefits enrollment, background check verification, IT account provisioning, equipment setup, and first day orientation. + +**Template ID:** `onboarding-workflow` +**Kind:** workflow +**Source domain:** hr +**Primary use case:** onboarding +**Secondary use cases:** delivery +**Complexity:** 4/5 +**Nodes:** 20 +**Lanes:** 3 +**Tags:** [employee-onboarding, new-hire, hr-workflow, background-check, it-provisioning, benefits-enrollment] +**Source path:** `hr/onboarding` +**Repo path:** `onboarding/hr/onboarding-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/hr/onboarding/metadata.json b/onboarding/hr/onboarding-workflow/metadata.json similarity index 53% rename from hr/onboarding/metadata.json rename to onboarding/hr/onboarding-workflow/metadata.json index 5df7e2f1ae0859f3e736591cbdcd417b4d280a1d..ca35cfc00c2ec155c685a891a5527e519cc06a89 100644 --- a/hr/onboarding/metadata.json +++ b/onboarding/hr/onboarding-workflow/metadata.json @@ -1,6 +1,17 @@ { + "template_id": "onboarding-workflow", "workflow_id": "onboarding", - "domain": "hr", + "title": "Onboarding Workflow", + "kind": "workflow", + "source_domain": "hr", + "primary_use_case": "onboarding", + "secondary_use_cases": [ + "delivery" + ], + "use_cases": [ + "onboarding", + "delivery" + ], "complexity": 4, "num_nodes": 20, "num_lanes": 3, @@ -12,5 +23,7 @@ "it-provisioning", "benefits-enrollment" ], - "description": "Complete employee onboarding workflow covering offer acceptance, HR record creation, benefits enrollment, background check verification, IT account provisioning, equipment setup, and first day orientation." -} \ No newline at end of file + "description": "Complete employee onboarding workflow covering offer acceptance, HR record creation, benefits enrollment, background check verification, IT account provisioning, equipment setup, and first day orientation.", + "source_path": "hr/onboarding", + "repo_path": "onboarding/hr/onboarding-workflow" +} diff --git a/hr/onboarding/workflow.fz b/onboarding/hr/onboarding-workflow/workflow.fz similarity index 100% rename from hr/onboarding/workflow.fz rename to onboarding/hr/onboarding-workflow/workflow.fz diff --git a/patterns/a-b-testing/README.md b/patterns/a-b-testing/README.md deleted file mode 100644 index c12c657bd15502d10235be3f004ef7e83a337368..0000000000000000000000000000000000000000 --- a/patterns/a-b-testing/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# A B Testing - -This workflow models comparing two versions to see which performs better. - -**Domain:** patterns -**Complexity:** 3/5 -**Tags:** [a, b, testing, patterns] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/a-b-testing/metadata.json b/patterns/a-b-testing/metadata.json deleted file mode 100644 index 53749108f0be641e0377992c1c9ea77ec2a5c72d..0000000000000000000000000000000000000000 --- a/patterns/a-b-testing/metadata.json +++ /dev/null @@ -1,14 +0,0 @@ -{ - "workflow_id": "a-b-testing", - "domain": "patterns", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "a", - "b", - "testing", - "patterns" - ], - "description": "This workflow models comparing two versions to see which performs better." -} \ No newline at end of file diff --git a/patterns/api-gateway/README.md b/patterns/api-gateway/README.md deleted file mode 100644 index b2f19e8a96278ae2d4edea20f12c65d2151627bb..0000000000000000000000000000000000000000 --- a/patterns/api-gateway/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# API Gateway - -API Gateway pattern with request authentication, rate limiting, request routing to backend services, response aggregation, and error handling. - -**Domain:** patterns -**Complexity:** 3/5 -**Tags:** [api-gateway, microservices, rate-limiting, request-routing, authentication, load-balancing] - -## Lanes -- **Client** - Sends API requests -- **Gateway** - Authenticates, routes, aggregates responses - -## Process Flow -1. Receive incoming API request -2. Validate API key or JWT token -3. Check rate limits for client -4. Parse request and determine target service -5. Route request to appropriate microservice -6. Aggregate responses if multiple services -7. Transform response format -8. Return response to client -9. Log request metrics diff --git a/patterns/api-gateway/metadata.json b/patterns/api-gateway/metadata.json deleted file mode 100644 index a8f4a01f8e36ccde2dabe1d25f130c9e8c0e3d75..0000000000000000000000000000000000000000 --- a/patterns/api-gateway/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "api-gateway", - "domain": "patterns", - "complexity": 3, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "api-gateway", - "microservices", - "rate-limiting", - "request-routing", - "authentication", - "load-balancing" - ], - "description": "API Gateway pattern with request authentication, rate limiting, request routing to backend services, response aggregation, and error handling." -} \ No newline at end of file diff --git a/patterns/audit-trail/README.md b/patterns/audit-trail/README.md deleted file mode 100644 index 337860f44cb98bd7079e0d4b0c079ea31c957735..0000000000000000000000000000000000000000 --- a/patterns/audit-trail/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Audit Trail - -This workflow models logging all important actions for compliance. - -**Domain:** patterns -**Complexity:** 4/5 -**Tags:** [audit, trail, patterns, decision, loop] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/audit-trail/metadata.json b/patterns/audit-trail/metadata.json deleted file mode 100644 index 0df9eaf281f3040402f8bcadc0b64b1e69027a8b..0000000000000000000000000000000000000000 --- a/patterns/audit-trail/metadata.json +++ /dev/null @@ -1,15 +0,0 @@ -{ - "workflow_id": "audit-trail", - "domain": "patterns", - "complexity": 4, - "num_nodes": 13, - "num_lanes": 4, - "tags": [ - "audit", - "trail", - "patterns", - "decision", - "loop" - ], - "description": "This workflow models logging all important actions for compliance." -} \ No newline at end of file diff --git a/patterns/authentication-flow/README.md b/patterns/authentication-flow/README.md deleted file mode 100644 index 4a00ad71b8c5206a80deba999616b3292d24db3f..0000000000000000000000000000000000000000 --- a/patterns/authentication-flow/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# Authentication Flow - -User authentication workflow with credential validation, MFA challenge, JWT token generation, session creation, and failed attempt tracking. - -**Domain:** patterns -**Complexity:** 3/5 -**Tags:** [authentication, login, jwt, oauth, mfa, session-management] - -## Lanes -- **User** - Submits credentials, completes MFA -- **Auth Service** - Validates credentials, issues tokens - -## Process Flow -1. User submits username and password -2. Validate credentials against user store -3. Check for account lockout status -4. If MFA enabled, send challenge -5. Verify MFA code -6. Generate JWT access token -7. Create refresh token -8. Establish user session -9. Return tokens to client diff --git a/patterns/authentication-flow/metadata.json b/patterns/authentication-flow/metadata.json deleted file mode 100644 index 479d9b4214485f8ae6ac2a4ed9e4c64ad7c54573..0000000000000000000000000000000000000000 --- a/patterns/authentication-flow/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "authentication-flow", - "domain": "patterns", - "complexity": 3, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "authentication", - "login", - "jwt", - "oauth", - "mfa", - "session-management" - ], - "description": "User authentication workflow with credential validation, MFA challenge, JWT token generation, session creation, and failed attempt tracking." -} \ No newline at end of file diff --git a/patterns/authorization-flow/README.md b/patterns/authorization-flow/README.md deleted file mode 100644 index 0e19211848623c9b2d40e93e920bebb53d3dc706..0000000000000000000000000000000000000000 --- a/patterns/authorization-flow/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Authorization Flow - -This workflow models checking user permissions before actions run. - -**Domain:** patterns -**Complexity:** 3/5 -**Tags:** [authorization, flow, patterns] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/authorization-flow/metadata.json b/patterns/authorization-flow/metadata.json deleted file mode 100644 index 7deb1ee30fd57570a42c8f84192c0be1395e6af6..0000000000000000000000000000000000000000 --- a/patterns/authorization-flow/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "authorization-flow", - "domain": "patterns", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "authorization", - "flow", - "patterns" - ], - "description": "This workflow models checking user permissions before actions run." -} \ No newline at end of file diff --git a/patterns/batch-processing/README.md b/patterns/batch-processing/README.md deleted file mode 100644 index 6c1f143f1a00e91778e5818ba79b57be9115ea61..0000000000000000000000000000000000000000 --- a/patterns/batch-processing/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# Batch Processing - -Batch processing pattern with job scheduling, chunk-based processing, checkpoint/restart capability, error handling, and completion reporting. - -**Domain:** patterns -**Complexity:** 3/5 -**Tags:** [batch-processing, scheduled-jobs, bulk-operations, etl, chunk-processing, job-scheduler] - -## Lanes -- **Scheduler** - Triggers batch jobs on schedule -- **Batch Processor** - Processes items in chunks - -## Process Flow -1. Scheduler triggers batch job -2. Read items to process from source -3. Split into manageable chunks -4. Process each chunk -5. Save checkpoint after each chunk -6. Handle errors with skip or retry -7. If failure, restart from checkpoint -8. Generate completion report -9. Notify stakeholders of results diff --git a/patterns/batch-processing/metadata.json b/patterns/batch-processing/metadata.json deleted file mode 100644 index 97ca011fed6bfd2bd9169225a90667c1bec39999..0000000000000000000000000000000000000000 --- a/patterns/batch-processing/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "batch-processing", - "domain": "patterns", - "complexity": 3, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "batch-processing", - "scheduled-jobs", - "bulk-operations", - "etl", - "chunk-processing", - "job-scheduler" - ], - "description": "Batch processing pattern with job scheduling, chunk-based processing, checkpoint/restart capability, error handling, and completion reporting." -} \ No newline at end of file diff --git a/patterns/blue-green-deploy/README.md b/patterns/blue-green-deploy/README.md deleted file mode 100644 index 38b40bf20c7e100f3f60060a12be82f2af2a9268..0000000000000000000000000000000000000000 --- a/patterns/blue-green-deploy/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Blue-Green Deployment - -Blue-green deployment pattern with parallel environment setup, smoke testing, load balancer traffic switch, and instant rollback capability. - -**Domain:** patterns -**Complexity:** 4/5 -**Tags:** [blue-green-deployment, zero-downtime, traffic-switching, rollback, load-balancer, release-management] - -## Lanes -- **CI/CD Pipeline** - Builds and deploys to inactive environment -- **Blue Environment** - Current production (or standby) -- **Green Environment** - New version (or standby) -- **Load Balancer** - Switches traffic between environments - -## Process Flow -1. Identify inactive environment (blue or green) -2. Deploy new version to inactive environment -3. Run smoke tests on inactive environment -4. Verify health checks pass -5. Switch load balancer to new environment -6. Monitor for errors -7. If issues, instant rollback by switching back -8. Decommission old version after stabilization diff --git a/patterns/blue-green-deploy/metadata.json b/patterns/blue-green-deploy/metadata.json deleted file mode 100644 index 8e0a0047a0578d71ae2857b495d45b6c445ca910..0000000000000000000000000000000000000000 --- a/patterns/blue-green-deploy/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "blue-green-deploy", - "domain": "patterns", - "complexity": 4, - "num_nodes": 13, - "num_lanes": 4, - "tags": [ - "blue-green-deployment", - "zero-downtime", - "traffic-switching", - "rollback", - "load-balancer", - "release-management" - ], - "description": "Blue-green deployment pattern with parallel environment setup, smoke testing, load balancer traffic switch, and instant rollback capability." -} \ No newline at end of file diff --git a/patterns/cache-aside/README.md b/patterns/cache-aside/README.md deleted file mode 100644 index b8e2be3aaa4295a39dc7c5b07cb15ed01281e680..0000000000000000000000000000000000000000 --- a/patterns/cache-aside/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# Cache-Aside Pattern - -Cache-aside pattern with cache lookup, database fallback on miss, cache population, TTL-based expiration, and write-through invalidation. - -**Domain:** patterns -**Complexity:** 3/5 -**Tags:** [cache-aside, lazy-loading, cache-miss, cache-invalidation, redis, performance] - -## Lanes -- **Application** - Requests data, manages cache -- **Cache (Redis)** - Stores cached data -- **Database** - Source of truth for data - -## Process Flow -1. Application requests data by key -2. Check cache for existing entry -3. If cache hit, return cached data -4. If cache miss, query database -5. Store result in cache with TTL -6. Return data to caller -7. On data update, invalidate cache entry -8. Next read will refresh from database diff --git a/patterns/cache-aside/metadata.json b/patterns/cache-aside/metadata.json deleted file mode 100644 index a5f0f70171d91fc18025be8332f079bf128723d0..0000000000000000000000000000000000000000 --- a/patterns/cache-aside/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "cache-aside", - "domain": "patterns", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "cache-aside", - "lazy-loading", - "cache-miss", - "cache-invalidation", - "redis", - "performance" - ], - "description": "Cache-aside pattern with cache lookup, database fallback on miss, cache population, TTL-based expiration, and write-through invalidation." -} \ No newline at end of file diff --git a/patterns/callback-pattern/README.md b/patterns/callback-pattern/README.md deleted file mode 100644 index 6265d09b7c1dfd75f2a26370ba9806de175ee9c2..0000000000000000000000000000000000000000 --- a/patterns/callback-pattern/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Callback Pattern - -This workflow models an async operation that notifies a callback when done. - -**Domain:** patterns -**Complexity:** 3/5 -**Tags:** [callback, pattern, patterns, decision, loop] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/callback-pattern/metadata.json b/patterns/callback-pattern/metadata.json deleted file mode 100644 index 6ed8ac610d5f74e6757c7e5a77eed6541ee3a43a..0000000000000000000000000000000000000000 --- a/patterns/callback-pattern/metadata.json +++ /dev/null @@ -1,15 +0,0 @@ -{ - "workflow_id": "callback-pattern", - "domain": "patterns", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "callback", - "pattern", - "patterns", - "decision", - "loop" - ], - "description": "This workflow models an async operation that notifies a callback when done." -} \ No newline at end of file diff --git a/patterns/canary-deploy/README.md b/patterns/canary-deploy/README.md deleted file mode 100644 index 335fe65d31764657595e0c4ad12b34b39cf46c3d..0000000000000000000000000000000000000000 --- a/patterns/canary-deploy/README.md +++ /dev/null @@ -1,21 +0,0 @@ -# Canary Deployment - -Canary deployment pattern with gradual traffic shifting, real-time metrics monitoring, automatic rollback triggers, and progressive rollout to full production. - -**Domain:** patterns -**Complexity:** 3/5 -**Tags:** [canary-deployment, progressive-rollout, traffic-splitting, metrics-monitoring, gradual-release, feature-flags] - -## Lanes -- **Deployment System** - Manages traffic percentages -- **Monitoring** - Tracks error rates and latency - -## Process Flow -1. Deploy new version alongside current version -2. Route 5% of traffic to canary -3. Monitor error rates and latency -4. If metrics healthy, increase to 25% -5. Continue monitoring -6. Gradually increase to 50%, 75%, 100% -7. If metrics degrade, automatic rollback -8. Decommission old version after full rollout diff --git a/patterns/canary-deploy/metadata.json b/patterns/canary-deploy/metadata.json deleted file mode 100644 index 17577fa67b07b94e8545d5dc43b753c706f78548..0000000000000000000000000000000000000000 --- a/patterns/canary-deploy/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "canary-deploy", - "domain": "patterns", - "complexity": 3, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "canary-deployment", - "progressive-rollout", - "traffic-splitting", - "metrics-monitoring", - "gradual-release", - "feature-flags" - ], - "description": "Canary deployment pattern with gradual traffic shifting, real-time metrics monitoring, automatic rollback triggers, and progressive rollout to full production." -} \ No newline at end of file diff --git a/patterns/circuit-breaker/README.md b/patterns/circuit-breaker/README.md deleted file mode 100644 index fa85b41e8e20c0f8570d475da134939188515821..0000000000000000000000000000000000000000 --- a/patterns/circuit-breaker/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Circuit Breaker - -Circuit breaker resilience pattern with closed, open, and half-open states for protecting services from cascading failures with automatic recovery testing. - -**Domain:** patterns -**Complexity:** 4/5 -**Tags:** [circuit-breaker, resilience, fault-tolerance, microservices, hystrix, half-open, fallback] - -## Lanes -- **Client** - Makes service requests, receives responses or fallbacks -- **CircuitBreaker** - Manages state transitions (closed/open/half-open) -- **Service** - Downstream service that may fail - -## Process Flow -1. Client initiates request to downstream service -2. Circuit breaker checks current state -3. **Closed state**: Forward request to service, track success/failure -4. If failure threshold exceeded, trip circuit to open state -5. **Open state**: Return fallback response immediately, start timeout -6. After timeout expires, transition to half-open state -7. **Half-open state**: Allow single test request through -8. If test succeeds, reset to closed state -9. If test fails, return to open state with new timeout diff --git a/patterns/circuit-breaker/metadata.json b/patterns/circuit-breaker/metadata.json deleted file mode 100644 index 46c0897fa8e55d2146e16dbef9dd72dbbdb7eea2..0000000000000000000000000000000000000000 --- a/patterns/circuit-breaker/metadata.json +++ /dev/null @@ -1,17 +0,0 @@ -{ - "workflow_id": "circuit-breaker", - "domain": "patterns", - "complexity": 4, - "num_nodes": 19, - "num_lanes": 3, - "tags": [ - "circuit-breaker", - "resilience", - "fault-tolerance", - "microservices", - "hystrix", - "half-open", - "fallback" - ], - "description": "Circuit breaker resilience pattern with closed, open, and half-open states for protecting services from cascading failures with automatic recovery testing." -} \ No newline at end of file diff --git a/patterns/claim-check/README.md b/patterns/claim-check/README.md deleted file mode 100644 index 06e3c23227deef6c27e681d4e5c25b30b22c45e2..0000000000000000000000000000000000000000 --- a/patterns/claim-check/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Claim Check - -This workflow models keeping large payloads external and only passing references. - -**Domain:** patterns -**Complexity:** 2/5 -**Tags:** [claim, check, patterns] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/claim-check/metadata.json b/patterns/claim-check/metadata.json deleted file mode 100644 index 7978aef42bd11bd2c71d5adf675e1a1509a7301d..0000000000000000000000000000000000000000 --- a/patterns/claim-check/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "claim-check", - "domain": "patterns", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "claim", - "check", - "patterns" - ], - "description": "This workflow models keeping large payloads external and only passing references." -} \ No newline at end of file diff --git a/patterns/compensation-transaction/README.md b/patterns/compensation-transaction/README.md deleted file mode 100644 index d62aa9ae2ecedb3f8b17c77ce9df7f5b06785c5f..0000000000000000000000000000000000000000 --- a/patterns/compensation-transaction/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Compensation Transaction - -This workflow models rolling back work when a later step fails. - -**Domain:** patterns -**Complexity:** 2/5 -**Tags:** [compensation, transaction, patterns, decision, loop] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/compensation-transaction/metadata.json b/patterns/compensation-transaction/metadata.json deleted file mode 100644 index 5dd1e15d235a0c4f8d8a50c54ae37391e3d8e8aa..0000000000000000000000000000000000000000 --- a/patterns/compensation-transaction/metadata.json +++ /dev/null @@ -1,15 +0,0 @@ -{ - "workflow_id": "compensation-transaction", - "domain": "patterns", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "compensation", - "transaction", - "patterns", - "decision", - "loop" - ], - "description": "This workflow models rolling back work when a later step fails." -} \ No newline at end of file diff --git a/patterns/content-enricher/README.md b/patterns/content-enricher/README.md deleted file mode 100644 index f7a0cd72a65c1c92e8aa64f97f4c30f7640cc3f5..0000000000000000000000000000000000000000 --- a/patterns/content-enricher/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Content Enricher - -This workflow models adding extra data from other sources. - -**Domain:** patterns -**Complexity:** 3/5 -**Tags:** [content, enricher, patterns, decision] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/content-enricher/metadata.json b/patterns/content-enricher/metadata.json deleted file mode 100644 index 0225cb77b68de9ea6c3f084c96670b9349946f5b..0000000000000000000000000000000000000000 --- a/patterns/content-enricher/metadata.json +++ /dev/null @@ -1,14 +0,0 @@ -{ - "workflow_id": "content-enricher", - "domain": "patterns", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "content", - "enricher", - "patterns", - "decision" - ], - "description": "This workflow models adding extra data from other sources." -} \ No newline at end of file diff --git a/patterns/cqrs/README.md b/patterns/cqrs/README.md deleted file mode 100644 index 5a1e4dc3d4438f3eb4b091e370599c62fdf5ed35..0000000000000000000000000000000000000000 --- a/patterns/cqrs/README.md +++ /dev/null @@ -1,25 +0,0 @@ -# CQRS (Command Query Responsibility Segregation) - -CQRS pattern with separate command and query paths, domain event publishing, read model synchronization, and DTO transformation. - -**Domain:** patterns -**Complexity:** 4/5 -**Tags:** [cqrs, command-query-separation, event-sourcing, read-model, write-model, domain-events, eventual-consistency] - -## Lanes -- **Client Application** - Initiates actions, routes to command or query side -- **Command Side** - Validates commands, executes domain logic, persists to write store -- **Event Handler** - Receives domain events, updates read model -- **Query Side** - Parses queries, reads from optimized read store, returns DTOs - -## Process Flow -1. Client initiates user action -2. Determine if action is read or write operation -3. **Write path**: Send command to command side -4. Validate command against business rules -5. Execute domain logic and persist to write store -6. Publish domain event for read model sync -7. Event handler updates read model asynchronously -8. **Read path**: Send query to query side -9. Query optimized read store -10. Transform results to DTO and return to client diff --git a/patterns/crud-user-browser-server/README.md b/patterns/crud-user-browser-server/README.md deleted file mode 100644 index bcda096e522d45633c1944be7832fc36b3d59b8c..0000000000000000000000000000000000000000 --- a/patterns/crud-user-browser-server/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Crud User Browser Server - -This workflow models user creates, reads, updates, and deletes data through a browser and server. - -**Domain:** patterns -**Complexity:** 2/5 -**Tags:** [crud, user, browser, server, patterns] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/crud-user-browser-server/metadata.json b/patterns/crud-user-browser-server/metadata.json deleted file mode 100644 index 20999b33fcdfb3a6f021ce9d34472336ee921c4a..0000000000000000000000000000000000000000 --- a/patterns/crud-user-browser-server/metadata.json +++ /dev/null @@ -1,15 +0,0 @@ -{ - "workflow_id": "crud-user-browser-server", - "domain": "patterns", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "crud", - "user", - "browser", - "server", - "patterns" - ], - "description": "This workflow models user creates, reads, updates, and deletes data through a browser and server." -} \ No newline at end of file diff --git a/patterns/dead-letter-queue/README.md b/patterns/dead-letter-queue/README.md deleted file mode 100644 index 26e1804452e78c147e4ad5306b7a8e3ddc6c16f7..0000000000000000000000000000000000000000 --- a/patterns/dead-letter-queue/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# Dead Letter Queue - -Dead letter queue pattern for handling failed messages with retry exhaustion detection, DLQ routing, manual inspection, and reprocessing capability. - -**Domain:** patterns -**Complexity:** 3/5 -**Tags:** [dead-letter-queue, dlq, message-retry, poison-message, error-handling, message-queue] - -## Lanes -- **Message Consumer** - Processes messages, handles failures -- **DLQ Handler** - Stores and manages failed messages - -## Process Flow -1. Consumer receives message from queue -2. Attempt to process message -3. If processing fails, increment retry count -4. Retry up to max attempts with backoff -5. If retries exhausted, route to DLQ -6. Store message with error details -7. Alert operations team -8. Manual inspection and fix -9. Reprocess or discard message diff --git a/patterns/dead-letter-queue/metadata.json b/patterns/dead-letter-queue/metadata.json deleted file mode 100644 index 5697c0cfd2fc3db5f5a7ab52cc96dc145cbf7248..0000000000000000000000000000000000000000 --- a/patterns/dead-letter-queue/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "dead-letter-queue", - "domain": "patterns", - "complexity": 3, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "dead-letter-queue", - "dlq", - "message-retry", - "poison-message", - "error-handling", - "message-queue" - ], - "description": "Dead letter queue pattern for handling failed messages with retry exhaustion detection, DLQ routing, manual inspection, and reprocessing capability." -} \ No newline at end of file diff --git a/patterns/decision-diamond/README.md b/patterns/decision-diamond/README.md deleted file mode 100644 index bf4e08a6d611960c151718f291314af30758a058..0000000000000000000000000000000000000000 --- a/patterns/decision-diamond/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Decision Diamond - -This workflow models an if or then style branch for approval or rejection. - -**Domain:** patterns -**Complexity:** 3/5 -**Tags:** [decision, diamond, patterns] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/decision-diamond/metadata.json b/patterns/decision-diamond/metadata.json deleted file mode 100644 index 8a2c8eaeeb12d830f12943895e77034aa942ef5a..0000000000000000000000000000000000000000 --- a/patterns/decision-diamond/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "decision-diamond", - "domain": "patterns", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "decision", - "diamond", - "patterns" - ], - "description": "This workflow models an if or then style branch for approval or rejection." -} \ No newline at end of file diff --git a/patterns/enricher/README.md b/patterns/enricher/README.md deleted file mode 100644 index b981fb115e8e930b294f94fc144db88be42d01e0..0000000000000000000000000000000000000000 --- a/patterns/enricher/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Enricher - -This workflow models adding metadata to messages before passing them on. - -**Domain:** patterns -**Complexity:** 3/5 -**Tags:** [enricher, patterns] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/enricher/metadata.json b/patterns/enricher/metadata.json deleted file mode 100644 index bec7585ac52f233e0f0b0ce98e554fba611ba5a2..0000000000000000000000000000000000000000 --- a/patterns/enricher/metadata.json +++ /dev/null @@ -1,12 +0,0 @@ -{ - "workflow_id": "enricher", - "domain": "patterns", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "enricher", - "patterns" - ], - "description": "This workflow models adding metadata to messages before passing them on." -} \ No newline at end of file diff --git a/patterns/error-retry-loop/README.md b/patterns/error-retry-loop/README.md deleted file mode 100644 index 7d948d053824d7f93b202b66afbe87da364ef742..0000000000000000000000000000000000000000 --- a/patterns/error-retry-loop/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Error Retry Loop - -This workflow models a failed operation that retries with backoff. - -**Domain:** patterns -**Complexity:** 2/5 -**Tags:** [error, retry, loop, patterns] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/error-retry-loop/metadata.json b/patterns/error-retry-loop/metadata.json deleted file mode 100644 index 97bf133da2fff0f98565e4e8e9786fc61b4e381a..0000000000000000000000000000000000000000 --- a/patterns/error-retry-loop/metadata.json +++ /dev/null @@ -1,14 +0,0 @@ -{ - "workflow_id": "error-retry-loop", - "domain": "patterns", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "error", - "retry", - "loop", - "patterns" - ], - "description": "This workflow models a failed operation that retries with backoff." -} \ No newline at end of file diff --git a/patterns/escalation-pattern/README.md b/patterns/escalation-pattern/README.md deleted file mode 100644 index dd9d16c10bad934ce457c8859b1994cbb64dd83e..0000000000000000000000000000000000000000 --- a/patterns/escalation-pattern/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Escalation Pattern - -This workflow models escalating issues to higher authority when needed. - -**Domain:** patterns -**Complexity:** 3/5 -**Tags:** [escalation, pattern, patterns] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/escalation-pattern/metadata.json b/patterns/escalation-pattern/metadata.json deleted file mode 100644 index 4828dc7ddf775331ebda2ed0b8e2da7b92122449..0000000000000000000000000000000000000000 --- a/patterns/escalation-pattern/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "escalation-pattern", - "domain": "patterns", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "escalation", - "pattern", - "patterns" - ], - "description": "This workflow models escalating issues to higher authority when needed." -} \ No newline at end of file diff --git a/patterns/event-driven/README.md b/patterns/event-driven/README.md deleted file mode 100644 index 33163cf952fdee99e1d42b456ce3df78f4d2a906..0000000000000000000000000000000000000000 --- a/patterns/event-driven/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Event Driven - -This workflow models reacting to incoming business events. - -**Domain:** patterns -**Complexity:** 3/5 -**Tags:** [event, driven, patterns] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/event-driven/metadata.json b/patterns/event-driven/metadata.json deleted file mode 100644 index dcda0b097febd1cb0854b8d306087d35fff01502..0000000000000000000000000000000000000000 --- a/patterns/event-driven/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "event-driven", - "domain": "patterns", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "event", - "driven", - "patterns" - ], - "description": "This workflow models reacting to incoming business events." -} \ No newline at end of file diff --git a/patterns/event-sourcing/README.md b/patterns/event-sourcing/README.md deleted file mode 100644 index 21d882da0b6b606d182ddcbf6242dbd674fccc84..0000000000000000000000000000000000000000 --- a/patterns/event-sourcing/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Event Sourcing - -Event sourcing pattern with event capture, event store persistence, aggregate reconstruction, snapshot optimization, and temporal state queries. - -**Domain:** patterns -**Complexity:** 4/5 -**Tags:** [event-sourcing, event-store, aggregate, replay, audit-log, temporal-query] - -## Lanes -- **Command Handler** - Validates and processes commands -- **Event Store** - Persists immutable event stream -- **Projection** - Builds read models from events - -## Process Flow -1. Receive command to modify aggregate -2. Load aggregate from event store -3. Replay events to rebuild current state -4. Validate command against current state -5. Generate new domain event -6. Append event to event store -7. Publish event to subscribers -8. Update read model projections -9. Return success to caller diff --git a/patterns/event-sourcing/metadata.json b/patterns/event-sourcing/metadata.json deleted file mode 100644 index 9e7ec096c5924e92dba153d541ec62fa09eda4f1..0000000000000000000000000000000000000000 --- a/patterns/event-sourcing/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "event-sourcing", - "domain": "patterns", - "complexity": 4, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "event-sourcing", - "event-store", - "aggregate", - "replay", - "audit-log", - "temporal-query" - ], - "description": "Event sourcing pattern with event capture, event store persistence, aggregate reconstruction, snapshot optimization, and temporal state queries." -} \ No newline at end of file diff --git a/patterns/fan-out-fan-in/README.md b/patterns/fan-out-fan-in/README.md deleted file mode 100644 index a96836d8723c2da9d02f971cc7319cf48f666477..0000000000000000000000000000000000000000 --- a/patterns/fan-out-fan-in/README.md +++ /dev/null @@ -1,24 +0,0 @@ -# Fan-Out/Fan-In Pattern - -Fan-out/fan-in pattern with work distribution to parallel workers, concurrent execution, result aggregation, and error handling for partial failures. - -**Domain:** patterns -**Complexity:** 4/5 -**Tags:** [fan-out-fan-in, scatter-gather, parallel-processing, aggregation, map-reduce, concurrency] - -## Lanes -- **Orchestrator** - Splits work, aggregates results -- **Worker 1** - Processes subset of work -- **Worker 2** - Processes subset of work -- **Worker N** - Processes subset of work - -## Process Flow -1. Receive large task or dataset -2. Split into smaller chunks -3. Fan-out: Distribute to parallel workers -4. Workers process concurrently -5. Track completion of each worker -6. Handle worker failures gracefully -7. Fan-in: Collect all results -8. Aggregate into final result -9. Return combined output diff --git a/patterns/fan-out-fan-in/metadata.json b/patterns/fan-out-fan-in/metadata.json deleted file mode 100644 index aac412227367975c1ef847dfb207cb96d530759a..0000000000000000000000000000000000000000 --- a/patterns/fan-out-fan-in/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "fan-out-fan-in", - "domain": "patterns", - "complexity": 4, - "num_nodes": 13, - "num_lanes": 4, - "tags": [ - "fan-out-fan-in", - "scatter-gather", - "parallel-processing", - "aggregation", - "map-reduce", - "concurrency" - ], - "description": "Fan-out/fan-in pattern with work distribution to parallel workers, concurrent execution, result aggregation, and error handling for partial failures." -} \ No newline at end of file diff --git a/patterns/feature-toggle/README.md b/patterns/feature-toggle/README.md deleted file mode 100644 index eba3337a24cbebd06904d095345ed8854c2ecb0d..0000000000000000000000000000000000000000 --- a/patterns/feature-toggle/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Feature Toggle - -Feature toggle pattern with flag configuration, user targeting rules, percentage rollouts, and instant kill-switch capability for production features. - -**Domain:** patterns -**Complexity:** 3/5 -**Tags:** [feature-toggle, feature-flags, dark-launch, a-b-testing, gradual-rollout, kill-switch] - -## Lanes -- **Feature Flag Service** - Stores and evaluates flags -- **Application** - Checks flags, renders features -- **Admin Console** - Configures flag rules - -## Process Flow -1. Define feature flag with default state -2. Configure targeting rules (user, %, environment) -3. Application requests flag evaluation -4. Evaluate rules against user context -5. Return flag state (on/off/variant) -6. Application renders appropriate experience -7. Track feature usage metrics -8. Adjust rollout percentage as needed -9. Kill-switch: Instantly disable if issues diff --git a/patterns/feature-toggle/metadata.json b/patterns/feature-toggle/metadata.json deleted file mode 100644 index d435d786c30d936d3759b9bb14cab1c2c679f89f..0000000000000000000000000000000000000000 --- a/patterns/feature-toggle/metadata.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "workflow_id": "feature-toggle", - "domain": "patterns", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "feature-toggle", - "feature-flags", - "dark-launch", - "a-b-testing", - "gradual-rollout", - "kill-switch" - ], - "description": "Feature toggle pattern with flag configuration, user targeting rules, percentage rollouts, and instant kill-switch capability for production features." -} \ No newline at end of file diff --git a/patterns/filter/README.md b/patterns/filter/README.md deleted file mode 100644 index ea6345a1edb94e072a2798365635189ebef1fdf3..0000000000000000000000000000000000000000 --- a/patterns/filter/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Filter - -This workflow models removing items that do not meet criteria. - -**Domain:** patterns -**Complexity:** 4/5 -**Tags:** [filter, patterns, decision, loop] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/filter/metadata.json b/patterns/filter/metadata.json deleted file mode 100644 index 2199e165353256cef6596fb6d7844d211aacc51d..0000000000000000000000000000000000000000 --- a/patterns/filter/metadata.json +++ /dev/null @@ -1,14 +0,0 @@ -{ - "workflow_id": "filter", - "domain": "patterns", - "complexity": 4, - "num_nodes": 13, - "num_lanes": 4, - "tags": [ - "filter", - "patterns", - "decision", - "loop" - ], - "description": "This workflow models removing items that do not meet criteria." -} \ No newline at end of file diff --git a/patterns/idempotent-consumer/README.md b/patterns/idempotent-consumer/README.md deleted file mode 100644 index 2c1dd84a913bacfffef8c31fea99dd84de4b5f17..0000000000000000000000000000000000000000 --- a/patterns/idempotent-consumer/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Idempotent Consumer - -This workflow models processing each message safely only once. - -**Domain:** patterns -**Complexity:** 3/5 -**Tags:** [idempotent, consumer, patterns] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/idempotent-consumer/metadata.json b/patterns/idempotent-consumer/metadata.json deleted file mode 100644 index 9553bcd8b0d479809d2f158f026c6a6d3102ea7f..0000000000000000000000000000000000000000 --- a/patterns/idempotent-consumer/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "idempotent-consumer", - "domain": "patterns", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "idempotent", - "consumer", - "patterns" - ], - "description": "This workflow models processing each message safely only once." -} \ No newline at end of file diff --git a/patterns/materialized-view/README.md b/patterns/materialized-view/README.md deleted file mode 100644 index bef0be25c57cbdb42d4ba3c3ac85a0f309c34925..0000000000000000000000000000000000000000 --- a/patterns/materialized-view/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Materialized View - -This workflow models serving queries from a precomputed view. - -**Domain:** patterns -**Complexity:** 4/5 -**Tags:** [materialized, view, patterns, decision, loop] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/materialized-view/metadata.json b/patterns/materialized-view/metadata.json deleted file mode 100644 index 755d21524c302b529a501f07c56dae2b4e570665..0000000000000000000000000000000000000000 --- a/patterns/materialized-view/metadata.json +++ /dev/null @@ -1,15 +0,0 @@ -{ - "workflow_id": "materialized-view", - "domain": "patterns", - "complexity": 4, - "num_nodes": 13, - "num_lanes": 4, - "tags": [ - "materialized", - "view", - "patterns", - "decision", - "loop" - ], - "description": "This workflow models serving queries from a precomputed view." -} \ No newline at end of file diff --git a/patterns/message-queue/README.md b/patterns/message-queue/README.md deleted file mode 100644 index 646309af7e38b9b0b9f0c6714be6ba4fbf769c88..0000000000000000000000000000000000000000 --- a/patterns/message-queue/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Message Queue - -This workflow models asynchronous processing of work via a queue. - -**Domain:** patterns -**Complexity:** 3/5 -**Tags:** [message, queue, patterns, decision] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/message-queue/metadata.json b/patterns/message-queue/metadata.json deleted file mode 100644 index 8b79821729476e40127c0bd9165f1abd340c8114..0000000000000000000000000000000000000000 --- a/patterns/message-queue/metadata.json +++ /dev/null @@ -1,14 +0,0 @@ -{ - "workflow_id": "message-queue", - "domain": "patterns", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "message", - "queue", - "patterns", - "decision" - ], - "description": "This workflow models asynchronous processing of work via a queue." -} \ No newline at end of file diff --git a/patterns/nested-decisions/README.md b/patterns/nested-decisions/README.md deleted file mode 100644 index b09c9db35bbc938c4cfc144305d52688777fdddf..0000000000000000000000000000000000000000 --- a/patterns/nested-decisions/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Nested Decisions - -This workflow models multiple layers of decisions before completion. - -**Domain:** patterns -**Complexity:** 3/5 -**Tags:** [nested, decisions, patterns, decision, loop] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/nested-decisions/metadata.json b/patterns/nested-decisions/metadata.json deleted file mode 100644 index 59c8e74135d299eed5cc867a52737ca1fdff2806..0000000000000000000000000000000000000000 --- a/patterns/nested-decisions/metadata.json +++ /dev/null @@ -1,15 +0,0 @@ -{ - "workflow_id": "nested-decisions", - "domain": "patterns", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "nested", - "decisions", - "patterns", - "decision", - "loop" - ], - "description": "This workflow models multiple layers of decisions before completion." -} \ No newline at end of file diff --git a/patterns/normalizer/README.md b/patterns/normalizer/README.md deleted file mode 100644 index af0fca19f877b57c723a82e04be372c9f9c1f560..0000000000000000000000000000000000000000 --- a/patterns/normalizer/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Normalizer - -This workflow models converting varied inputs to a standard format. - -**Domain:** patterns -**Complexity:** 4/5 -**Tags:** [normalizer, patterns] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/normalizer/metadata.json b/patterns/normalizer/metadata.json deleted file mode 100644 index 1981c784a52447a623cf0c0a5d2a4cdd0a29d9be..0000000000000000000000000000000000000000 --- a/patterns/normalizer/metadata.json +++ /dev/null @@ -1,12 +0,0 @@ -{ - "workflow_id": "normalizer", - "domain": "patterns", - "complexity": 4, - "num_nodes": 13, - "num_lanes": 4, - "tags": [ - "normalizer", - "patterns" - ], - "description": "This workflow models converting varied inputs to a standard format." -} \ No newline at end of file diff --git a/patterns/notification-pattern/README.md b/patterns/notification-pattern/README.md deleted file mode 100644 index 713288843cf028ef19604bc7706faa3031bfa62b..0000000000000000000000000000000000000000 --- a/patterns/notification-pattern/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Notification Pattern - -This workflow models sending alerts via multiple channels. - -**Domain:** patterns -**Complexity:** 2/5 -**Tags:** [notification, pattern, patterns] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/notification-pattern/metadata.json b/patterns/notification-pattern/metadata.json deleted file mode 100644 index 5fa78c8ff175cd3d6680d52c527e2d7025473abf..0000000000000000000000000000000000000000 --- a/patterns/notification-pattern/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "notification-pattern", - "domain": "patterns", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "notification", - "pattern", - "patterns" - ], - "description": "This workflow models sending alerts via multiple channels." -} \ No newline at end of file diff --git a/patterns/parallel-execution/README.md b/patterns/parallel-execution/README.md deleted file mode 100644 index 2c646dfea659656aa00e6e7edb6e4029443c862a..0000000000000000000000000000000000000000 --- a/patterns/parallel-execution/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Parallel Execution - -This workflow models multiple tasks that run at the same time. - -**Domain:** patterns -**Complexity:** 4/5 -**Tags:** [parallel, execution, patterns, loop] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/parallel-execution/metadata.json b/patterns/parallel-execution/metadata.json deleted file mode 100644 index a1e186e918928d8840e3b2d5e0f75110664eea74..0000000000000000000000000000000000000000 --- a/patterns/parallel-execution/metadata.json +++ /dev/null @@ -1,14 +0,0 @@ -{ - "workflow_id": "parallel-execution", - "domain": "patterns", - "complexity": 4, - "num_nodes": 13, - "num_lanes": 4, - "tags": [ - "parallel", - "execution", - "patterns", - "loop" - ], - "description": "This workflow models multiple tasks that run at the same time." -} \ No newline at end of file diff --git a/patterns/polling-pattern/README.md b/patterns/polling-pattern/README.md deleted file mode 100644 index 477ebc2bef79ca23d2b0654c538a940dd6a7d935..0000000000000000000000000000000000000000 --- a/patterns/polling-pattern/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Polling Pattern - -This workflow models periodically checking status until work is done. - -**Domain:** patterns -**Complexity:** 4/5 -**Tags:** [polling, pattern, patterns, loop] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/polling-pattern/metadata.json b/patterns/polling-pattern/metadata.json deleted file mode 100644 index cd02f42e8c85434ad3ab2caefa62bcfaf58d55c3..0000000000000000000000000000000000000000 --- a/patterns/polling-pattern/metadata.json +++ /dev/null @@ -1,14 +0,0 @@ -{ - "workflow_id": "polling-pattern", - "domain": "patterns", - "complexity": 4, - "num_nodes": 13, - "num_lanes": 4, - "tags": [ - "polling", - "pattern", - "patterns", - "loop" - ], - "description": "This workflow models periodically checking status until work is done." -} \ No newline at end of file diff --git a/patterns/process-manager/README.md b/patterns/process-manager/README.md deleted file mode 100644 index 2387137d579ab4ccc57a7199298909fdd04f901c..0000000000000000000000000000000000000000 --- a/patterns/process-manager/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Process Manager - -This workflow models orchestrating multiple services to complete a process. - -**Domain:** patterns -**Complexity:** 3/5 -**Tags:** [process, manager, patterns] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/process-manager/metadata.json b/patterns/process-manager/metadata.json deleted file mode 100644 index 3713c3aec73e371edaf62c1333357298e3ff0fee..0000000000000000000000000000000000000000 --- a/patterns/process-manager/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "process-manager", - "domain": "patterns", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "process", - "manager", - "patterns" - ], - "description": "This workflow models orchestrating multiple services to complete a process." -} \ No newline at end of file diff --git a/patterns/pub-sub/README.md b/patterns/pub-sub/README.md deleted file mode 100644 index 697943338c29afe80d7aa2e849c4a5a75e257617..0000000000000000000000000000000000000000 --- a/patterns/pub-sub/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Pub Sub - -This workflow models one publisher notifying many subscribers of events. - -**Domain:** patterns -**Complexity:** 4/5 -**Tags:** [pub, sub, patterns] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/pub-sub/metadata.json b/patterns/pub-sub/metadata.json deleted file mode 100644 index 434b0e0af06eaccb4a5b899a4b67d710a46d8482..0000000000000000000000000000000000000000 --- a/patterns/pub-sub/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "pub-sub", - "domain": "patterns", - "complexity": 4, - "num_nodes": 13, - "num_lanes": 4, - "tags": [ - "pub", - "sub", - "patterns" - ], - "description": "This workflow models one publisher notifying many subscribers of events." -} \ No newline at end of file diff --git a/patterns/rate-limiter/README.md b/patterns/rate-limiter/README.md deleted file mode 100644 index d22edc78a0a65b9f4db87d9900d49b3c1b0c35c6..0000000000000000000000000000000000000000 --- a/patterns/rate-limiter/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Rate Limiter - -This workflow models preventing too many requests from being processed. - -**Domain:** patterns -**Complexity:** 4/5 -**Tags:** [rate, limiter, patterns] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/rate-limiter/metadata.json b/patterns/rate-limiter/metadata.json deleted file mode 100644 index 475e5081b04ffe32539874139c2582e9598655de..0000000000000000000000000000000000000000 --- a/patterns/rate-limiter/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "rate-limiter", - "domain": "patterns", - "complexity": 4, - "num_nodes": 13, - "num_lanes": 4, - "tags": [ - "rate", - "limiter", - "patterns" - ], - "description": "This workflow models preventing too many requests from being processed." -} \ No newline at end of file diff --git a/patterns/request-reply/README.md b/patterns/request-reply/README.md deleted file mode 100644 index 16baa120bcd5222c4b421b1d7096a4fdc4725069..0000000000000000000000000000000000000000 --- a/patterns/request-reply/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Request Reply - -This workflow models a synchronous request that waits for a reply. - -**Domain:** patterns -**Complexity:** 2/5 -**Tags:** [request, reply, patterns] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/request-reply/metadata.json b/patterns/request-reply/metadata.json deleted file mode 100644 index 16e2dbf5709a19fb6d39f19ea82b6c7efc28206d..0000000000000000000000000000000000000000 --- a/patterns/request-reply/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "request-reply", - "domain": "patterns", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "request", - "reply", - "patterns" - ], - "description": "This workflow models a synchronous request that waits for a reply." -} \ No newline at end of file diff --git a/patterns/retry-with-backoff/README.md b/patterns/retry-with-backoff/README.md deleted file mode 100644 index 3f679487c791e1145855e5f0b547145c52975c63..0000000000000000000000000000000000000000 --- a/patterns/retry-with-backoff/README.md +++ /dev/null @@ -1,24 +0,0 @@ -# Retry With Backoff - -Exponential backoff retry pattern for API calls with configurable retry limits, delay calculation, retryable error detection, and graceful degradation on permanent failures. - -**Domain:** patterns -**Complexity:** 4/5 -**Tags:** [retry-pattern, exponential-backoff, fault-tolerance, api-resilience, transient-errors, http-retry, jitter] - -## Lanes -- **Client** - Prepares requests, processes responses, handles failures -- **Retry Handler** - Manages retry state, calculates delays, executes retries -- **API Server** - Receives requests, returns success or error responses - -## Process Flow -1. Client prepares API request -2. Retry handler initializes retry state (counter, max retries) -3. Execute HTTP request to API server -4. Check response status code -5. 2xx: Return success to client -6. 4xx/5xx: Check if error is retryable (503, 429, etc.) -7. If retryable and retries remaining, calculate backoff delay -8. Wait exponential delay (e.g., 1s, 2s, 4s, 8s) -9. Increment retry counter and retry request -10. If max retries exceeded, return permanent failure diff --git a/patterns/router/README.md b/patterns/router/README.md deleted file mode 100644 index eb2dbf88a17610d982966b73cfbc481b8be32144..0000000000000000000000000000000000000000 --- a/patterns/router/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Router - -This workflow models routing messages based on their content. - -**Domain:** patterns -**Complexity:** 3/5 -**Tags:** [router, patterns, decision] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/router/metadata.json b/patterns/router/metadata.json deleted file mode 100644 index 7fad1f1e12783c6b32d872220895a10364706b6f..0000000000000000000000000000000000000000 --- a/patterns/router/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "router", - "domain": "patterns", - "complexity": 3, - "num_nodes": 10, - "num_lanes": 3, - "tags": [ - "router", - "patterns", - "decision" - ], - "description": "This workflow models routing messages based on their content." -} \ No newline at end of file diff --git a/patterns/routing-slip/README.md b/patterns/routing-slip/README.md deleted file mode 100644 index 9b0999bf6c71cf44946fb1fe5ad59788f996fc16..0000000000000000000000000000000000000000 --- a/patterns/routing-slip/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Routing Slip - -This workflow models having messages carry their own routing instructions. - -**Domain:** patterns -**Complexity:** 4/5 -**Tags:** [routing, slip, patterns] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/routing-slip/metadata.json b/patterns/routing-slip/metadata.json deleted file mode 100644 index 8a69765b4e810c3127817a6f17c7ae4ad9837564..0000000000000000000000000000000000000000 --- a/patterns/routing-slip/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "routing-slip", - "domain": "patterns", - "complexity": 4, - "num_nodes": 13, - "num_lanes": 4, - "tags": [ - "routing", - "slip", - "patterns" - ], - "description": "This workflow models having messages carry their own routing instructions." -} \ No newline at end of file diff --git a/patterns/saga-pattern/README.md b/patterns/saga-pattern/README.md deleted file mode 100644 index b98b4a3a586f51e9e01cf1c7bc5a15bd03e16037..0000000000000000000000000000000000000000 --- a/patterns/saga-pattern/README.md +++ /dev/null @@ -1,24 +0,0 @@ -# Saga Pattern - -Saga orchestration pattern for distributed transactions across Order, Payment, and Shipping services with automatic compensation rollback on failures. - -**Domain:** patterns -**Complexity:** 5/5 -**Tags:** [saga-pattern, distributed-transactions, microservices, compensation, orchestration, eventual-consistency, rollback] - -## Lanes -- **Saga Orchestrator** - Coordinates transaction steps, triggers compensations -- **Order Service** - Creates orders, reserves inventory -- **Payment Service** - Processes payments, handles refunds -- **Shipping Service** - Schedules shipments, generates tracking - -## Process Flow -1. Orchestrator begins distributed transaction -2. **Step 1**: Order Service creates order and reserves inventory -3. If order fails, trigger compensation chain -4. **Step 2**: Payment Service processes payment -5. If payment fails, refund and release inventory -6. **Step 3**: Shipping Service schedules shipment -7. If shipping fails, compensate payment and order -8. On success, commit saga and generate tracking number -9. Compensation chain: Refund → Release inventory → Cancel order diff --git a/patterns/saga-pattern/metadata.json b/patterns/saga-pattern/metadata.json deleted file mode 100644 index 2c115d50db79970c5724d12a8674777379c41eb4..0000000000000000000000000000000000000000 --- a/patterns/saga-pattern/metadata.json +++ /dev/null @@ -1,17 +0,0 @@ -{ - "workflow_id": "saga-pattern", - "domain": "patterns", - "complexity": 5, - "num_nodes": 20, - "num_lanes": 4, - "tags": [ - "saga-pattern", - "distributed-transactions", - "microservices", - "compensation", - "orchestration", - "eventual-consistency", - "rollback" - ], - "description": "Saga orchestration pattern for distributed transactions across Order, Payment, and Shipping services with automatic compensation rollback on failures." -} \ No newline at end of file diff --git a/patterns/snapshot-pattern/README.md b/patterns/snapshot-pattern/README.md deleted file mode 100644 index ba8389d9b63d42f63fb039978c049d2368e24884..0000000000000000000000000000000000000000 --- a/patterns/snapshot-pattern/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Snapshot Pattern - -This workflow models taking periodic snapshots of important state. - -**Domain:** patterns -**Complexity:** 2/5 -**Tags:** [snapshot, pattern, patterns, decision, loop] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/snapshot-pattern/metadata.json b/patterns/snapshot-pattern/metadata.json deleted file mode 100644 index 1d22f5ff26d9e233869d268beb8a971098bbbfe9..0000000000000000000000000000000000000000 --- a/patterns/snapshot-pattern/metadata.json +++ /dev/null @@ -1,15 +0,0 @@ -{ - "workflow_id": "snapshot-pattern", - "domain": "patterns", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "snapshot", - "pattern", - "patterns", - "decision", - "loop" - ], - "description": "This workflow models taking periodic snapshots of important state." -} \ No newline at end of file diff --git a/patterns/state-machine/README.md b/patterns/state-machine/README.md deleted file mode 100644 index 5908660cdbd2e720b1adbf29db38a03df4c2b583..0000000000000000000000000000000000000000 --- a/patterns/state-machine/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# State Machine - -This workflow models tracking object state changes over time. - -**Domain:** patterns -**Complexity:** 4/5 -**Tags:** [state, machine, patterns, parallel] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/state-machine/metadata.json b/patterns/state-machine/metadata.json deleted file mode 100644 index 00a47d9628c5ca0587e79b25e133d600cf6ba760..0000000000000000000000000000000000000000 --- a/patterns/state-machine/metadata.json +++ /dev/null @@ -1,14 +0,0 @@ -{ - "workflow_id": "state-machine", - "domain": "patterns", - "complexity": 4, - "num_nodes": 13, - "num_lanes": 4, - "tags": [ - "state", - "machine", - "patterns", - "parallel" - ], - "description": "This workflow models tracking object state changes over time." -} \ No newline at end of file diff --git a/patterns/strangler-fig/README.md b/patterns/strangler-fig/README.md deleted file mode 100644 index 494f5bc330fd081bd5f0c4c4398803b97c605741..0000000000000000000000000000000000000000 --- a/patterns/strangler-fig/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Strangler Fig - -This workflow models gradually replacing an old system with a new one. - -**Domain:** patterns -**Complexity:** 2/5 -**Tags:** [strangler, fig, patterns, decision] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/strangler-fig/metadata.json b/patterns/strangler-fig/metadata.json deleted file mode 100644 index 1d4a63a9a30ecc9683798496341dc81e7978ab7c..0000000000000000000000000000000000000000 --- a/patterns/strangler-fig/metadata.json +++ /dev/null @@ -1,14 +0,0 @@ -{ - "workflow_id": "strangler-fig", - "domain": "patterns", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "strangler", - "fig", - "patterns", - "decision" - ], - "description": "This workflow models gradually replacing an old system with a new one." -} \ No newline at end of file diff --git a/patterns/timeout-pattern/README.md b/patterns/timeout-pattern/README.md deleted file mode 100644 index 230a71d0c4761e1018a4dd9050e8354d1e8053e5..0000000000000000000000000000000000000000 --- a/patterns/timeout-pattern/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Timeout Pattern - -This workflow models an operation that times out after a delay. - -**Domain:** patterns -**Complexity:** 4/5 -**Tags:** [timeout, pattern, patterns] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/timeout-pattern/metadata.json b/patterns/timeout-pattern/metadata.json deleted file mode 100644 index a0bf8c369fbd602d9e7d5d12515650dab37b67e1..0000000000000000000000000000000000000000 --- a/patterns/timeout-pattern/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "timeout-pattern", - "domain": "patterns", - "complexity": 4, - "num_nodes": 13, - "num_lanes": 4, - "tags": [ - "timeout", - "pattern", - "patterns" - ], - "description": "This workflow models an operation that times out after a delay." -} \ No newline at end of file diff --git a/patterns/transactional-outbox/README.md b/patterns/transactional-outbox/README.md deleted file mode 100644 index 0046977aabbabbe9301d83503d14f7b406543207..0000000000000000000000000000000000000000 --- a/patterns/transactional-outbox/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Transactional Outbox - -This workflow models writing data and publishing messages in one transaction. - -**Domain:** patterns -**Complexity:** 4/5 -**Tags:** [transactional, outbox, patterns, parallel] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/transactional-outbox/metadata.json b/patterns/transactional-outbox/metadata.json deleted file mode 100644 index 752c0b0588c26ffa6c6ff515546238bfaed38684..0000000000000000000000000000000000000000 --- a/patterns/transactional-outbox/metadata.json +++ /dev/null @@ -1,14 +0,0 @@ -{ - "workflow_id": "transactional-outbox", - "domain": "patterns", - "complexity": 4, - "num_nodes": 13, - "num_lanes": 4, - "tags": [ - "transactional", - "outbox", - "patterns", - "parallel" - ], - "description": "This workflow models writing data and publishing messages in one transaction." -} \ No newline at end of file diff --git a/patterns/transform/README.md b/patterns/transform/README.md deleted file mode 100644 index 4aa76d5d45eb9a49df569a4d8773fb13147467b6..0000000000000000000000000000000000000000 --- a/patterns/transform/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Transform - -This workflow models converting messages into a new shape. - -**Domain:** patterns -**Complexity:** 2/5 -**Tags:** [transform, patterns] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/transform/metadata.json b/patterns/transform/metadata.json deleted file mode 100644 index 7ff9b0930c0c9926c6e2f3fe3974d7d137d856b1..0000000000000000000000000000000000000000 --- a/patterns/transform/metadata.json +++ /dev/null @@ -1,12 +0,0 @@ -{ - "workflow_id": "transform", - "domain": "patterns", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "transform", - "patterns" - ], - "description": "This workflow models converting messages into a new shape." -} \ No newline at end of file diff --git a/patterns/validator/README.md b/patterns/validator/README.md deleted file mode 100644 index 7d2d158998ea9f5d0f1412b190803a9f0fa876d2..0000000000000000000000000000000000000000 --- a/patterns/validator/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Validator - -This workflow models checking that incoming data is valid. - -**Domain:** patterns -**Complexity:** 2/5 -**Tags:** [validator, patterns, parallel] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/validator/metadata.json b/patterns/validator/metadata.json deleted file mode 100644 index ef61abc1598cd909dfd327fa50175ada7e564a4f..0000000000000000000000000000000000000000 --- a/patterns/validator/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "validator", - "domain": "patterns", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "validator", - "patterns", - "parallel" - ], - "description": "This workflow models checking that incoming data is valid." -} \ No newline at end of file diff --git a/patterns/webhook-pattern/README.md b/patterns/webhook-pattern/README.md deleted file mode 100644 index dae54648123f95411814a8cf2087f2717d7d5fde..0000000000000000000000000000000000000000 --- a/patterns/webhook-pattern/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# Webhook Pattern - -This workflow models an HTTP callback when an event occurs. - -**Domain:** patterns -**Complexity:** 2/5 -**Tags:** [webhook, pattern, patterns, decision, loop] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/patterns/webhook-pattern/metadata.json b/patterns/webhook-pattern/metadata.json deleted file mode 100644 index 4f8959551bfff2fb0855393ea7f26986cccafdd0..0000000000000000000000000000000000000000 --- a/patterns/webhook-pattern/metadata.json +++ /dev/null @@ -1,15 +0,0 @@ -{ - "workflow_id": "webhook-pattern", - "domain": "patterns", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "webhook", - "pattern", - "patterns", - "decision", - "loop" - ], - "description": "This workflow models an HTTP callback when an event occurs." -} \ No newline at end of file diff --git a/scripts/sync_templates.py b/scripts/sync_templates.py new file mode 100644 index 0000000000000000000000000000000000000000..9e75059af62776d0e690c8313d1855bbebf8ce9f --- /dev/null +++ b/scripts/sync_templates.py @@ -0,0 +1,381 @@ +from __future__ import annotations + +import csv +import json +import re +import shutil +import urllib.request +import xml.etree.ElementTree as ET +from collections import Counter +from pathlib import Path + +REPO_ROOT = Path(__file__).resolve().parents[1] +FLOWZAP_APP_ROOT = REPO_ROOT.parent / 'FlowZap-App-v5' +TEMPLATES_INDEX_PATH = FLOWZAP_APP_ROOT / 'src' / 'templateLibrary' / 'templatesIndex.json' +TEMPLATE_FILES_DIR = FLOWZAP_APP_ROOT / 'public' / 'template-files' +SITEMAP_URL = 'https://flowzap.xyz/sitemap-templates.xml' + +USE_CASES = [ + { + 'id': 'handoff', + 'labels': {'en': 'Handoff', 'fr': 'Transfert', 'zh': '交接'}, + 'keywords': ['handoff', 'handover', 'transfer', 'escalation', 'routing', 'handoff degradation'], + }, + { + 'id': 'approval', + 'labels': {'en': 'Approval', 'fr': 'Approbation', 'zh': '审批'}, + 'keywords': ['approval', 'approve', 'sign-off', 'review', 'authorize', 'authorization'], + }, + { + 'id': 'incident', + 'labels': {'en': 'Incident', 'fr': 'Incident', 'zh': '事故'}, + 'keywords': ['incident', 'outage', 'alert', 'on-call', 'monitoring', 'response'], + }, + { + 'id': 'onboarding', + 'labels': {'en': 'Onboarding', 'fr': 'Intégration', 'zh': '入职'}, + 'keywords': ['onboarding', 'onboard', 'welcome', 'setup', 'activation', 'registration'], + }, + { + 'id': 'offboarding', + 'labels': {'en': 'Offboarding', 'fr': 'Départ', 'zh': '离职'}, + 'keywords': ['offboarding', 'termination', 'account deletion', 'deprovision', 'deactivate'], + }, + { + 'id': 'billing', + 'labels': {'en': 'Billing & Payments', 'fr': 'Facturation & paiements', 'zh': '计费与支付'}, + 'keywords': ['billing', 'invoice', 'payment', 'subscription', 'dunning', 'refund', 'dispute', 'chargeback'], + }, + { + 'id': 'security', + 'labels': {'en': 'Security & Access', 'fr': 'Sécurité & accès', 'zh': '安全与访问'}, + 'keywords': ['security', 'auth', 'authentication', 'oauth', '2fa', 'two-factor', 'mfa', 'certificate', 'rotation', 'secret', 'vulnerability', 'patch'], + }, + { + 'id': 'compliance', + 'labels': {'en': 'Compliance', 'fr': 'Conformité', 'zh': '合规'}, + 'keywords': ['gdpr', 'audit', 'compliance', 'consent', 'policy', 'risk', 'controls'], + }, + { + 'id': 'delivery', + 'labels': {'en': 'Delivery & DevOps', 'fr': 'Livraison & DevOps', 'zh': '交付与 DevOps'}, + 'keywords': ['ci/cd', 'ci-cd', 'pipeline', 'deploy', 'deployment', 'rollback', 'migration', 'backup', 'restore', 'provisioning', 'infrastructure', 'load testing'], + }, + { + 'id': 'support', + 'labels': {'en': 'Support', 'fr': 'Support', 'zh': '支持'}, + 'keywords': ['support', 'ticket', 'knowledge base', 'knowledge-base'], + }, + { + 'id': 'agentic', + 'labels': {'en': 'Agentic Teams', 'fr': 'Équipes Agentiques', 'zh': '智能体团队'}, + 'keywords': ['agentic', 'supervisor-worker', 'swarm', 'hierarchical', 'team-of-rivals', 'multi-agent', 'ai-team', 'orchestrator', 'planner', 'critic'], + }, + { + 'id': 'ai-orchestration', + 'labels': {'en': 'AI Orchestration', 'fr': 'Orchestration IA', 'zh': 'AI编排'}, + 'keywords': ['ai-native', 'orchestration', 'single-agent', 'sequential-pipeline', 'parallel-fan-out', 'map-reduce', 'event-driven-mesh', 'competitive', 'generator-critic', 'coordinator'], + }, + { + 'id': 'mcp', + 'labels': {'en': 'MCP Architecture', 'fr': 'Architecture MCP', 'zh': 'MCP架构'}, + 'keywords': ['mcp', 'direct-connect', 'gateway', 'proxy', 'tool-router', 'agent-mesh', 'circuit-breaker', 'context-proxy', 'stdio', 'production-grade'], + }, + { + 'id': 'context-management', + 'labels': {'en': 'Context Management', 'fr': 'Gestion de Contexte', 'zh': '上下文管理'}, + 'keywords': ['context-management', 'session-memory', 'rolling-summary', 'profile-memory', 'semantic-memory', 'episodic-memory', 'hybrid-retrieval', 'shared-memory', 'vector-db', 'memory'], + }, +] + +LEGACY_TOP_LEVEL_DIRS = [ + 'business-operations', + 'devops', + 'edge-cases', + 'finance', + 'hr', + 'logistics', + 'patterns', + 'syntax-primitives', + 'handoff', + 'approval', + 'incident', + 'onboarding', + 'offboarding', + 'billing', + 'security', + 'compliance', + 'delivery', + 'support', + 'agentic', + 'ai-orchestration', + 'mcp', + 'context-management', + 'uncategorized', + 'indexes', +] + + +def normalize_text(value: str) -> str: + return re.sub(r'\s+', ' ', value.lower().replace('_', ' ').replace('-', ' ')).strip() + + +def slugify(value: str) -> str: + return re.sub(r'[^a-z0-9]+', '-', value.lower()).strip('-') or 'unknown' + + +def load_canonical_slugs() -> list[str]: + with urllib.request.urlopen(SITEMAP_URL, timeout=30) as response: + xml_text = response.read().decode('utf-8') + root = ET.fromstring(xml_text) + ns = {'sm': 'http://www.sitemaps.org/schemas/sitemap/0.9'} + slugs: list[str] = [] + seen: set[str] = set() + for loc_node in root.findall('sm:url/sm:loc', ns): + loc = (loc_node.text or '').strip() + if '/fr/templates/' in loc or '/zh/templates/' in loc: + continue + marker = '/templates/' + if marker not in loc: + continue + slug = loc.split(marker, 1)[1].strip('/').removesuffix('.html') + if slug and slug not in seen: + slugs.append(slug) + seen.add(slug) + return slugs + + +def load_app_index() -> dict[str, dict]: + data = json.loads(TEMPLATES_INDEX_PATH.read_text(encoding='utf-8')) + return {entry['slug']: entry for entry in data['templates']} + + +def detect_kind(entry: dict) -> str: + tags = entry.get('tags') or [] + if entry.get('domain') == 'Architecture' or 'architecture-diagram' in tags: + return 'architecture' + return 'workflow' + + +def compute_use_cases(entry: dict) -> list[str]: + haystack = normalize_text( + ' '.join( + str(part) + for part in [entry.get('slug', ''), entry.get('domain', ''), entry.get('sourcePath', ''), *(entry.get('tags') or [])] + if part + ) + ) + matches: list[str] = [] + for use_case in USE_CASES: + if any(normalize_text(keyword) in haystack for keyword in use_case['keywords']): + matches.append(use_case['id']) + return matches + + +def make_readme(entry: dict, primary_use_case: str, secondary_use_cases: list[str], relative_dir: str) -> str: + title = entry['title'] + description = entry.get('description') or '' + source_domain = entry.get('domain') or 'unknown' + tags = entry.get('tags') or [] + lines = [ + f'# {title}', + '', + description, + '', + f'**Template ID:** `{entry["slug"]}` ', + f'**Kind:** {detect_kind(entry)} ', + f'**Source domain:** {source_domain} ', + f'**Primary use case:** {primary_use_case} ', + f'**Secondary use cases:** {", ".join(secondary_use_cases) if secondary_use_cases else "None"} ', + f'**Complexity:** {entry.get("complexity", "n/a")}/5 ', + f'**Nodes:** {entry.get("numNodes", "n/a")} ', + f'**Lanes:** {entry.get("numLanes", "n/a")} ', + f'**Tags:** [{", ".join(tags)}] ', + f'**Source path:** `{entry.get("sourcePath", "")}` ', + f'**Repo path:** `{relative_dir}`', + '', + '## Files', + '- `workflow.fz` — FlowZap Code source', + '- `metadata.json` — Structured metadata', + ] + return '\n'.join(lines).strip() + '\n' + + +def clean_repo_root() -> None: + for name in LEGACY_TOP_LEVEL_DIRS: + path = REPO_ROOT / name + if path.is_dir(): + shutil.rmtree(path) + for name in ('metadata.csv', 'templates.index.json', 'use-cases.index.json', 'README.md', 'CONTRIBUTING.md'): + path = REPO_ROOT / name + if path.exists(): + path.unlink() + + +def write_root_docs(total_templates: int, counts: Counter) -> None: + readme_lines = [ + '# sequence-workflows', + '', + f'A synchronized FlowZap template corpus with **{total_templates} canonical templates** sourced from `https://flowzap.xyz/sitemap-templates.xml` and organized by **primary Use Case**.', + '', + '## Organization Model', + '', + '- Top-level folders are primary Use Cases from the FlowZap Templates dropdown.', + '- Second-level folders preserve the original source domain from the FlowZap app index.', + '- Each template keeps all matched Use Cases in `metadata.json` and the generated JSON/CSV indexes.', + '- Templates that do not match any current dropdown Use Case are placed under `uncategorized/`.', + '', + '## Top-Level Folders', + '', + ] + for use_case in USE_CASES: + readme_lines.append(f'- `{use_case["id"]}/` — {use_case["labels"]["en"]} ({counts.get(use_case["id"], 0)})') + readme_lines.append(f'- `uncategorized/` — Unmatched canonical templates ({counts.get("uncategorized", 0)})') + readme_lines.extend([ + '', + '## Generated Indexes', + '', + '- `templates.index.json` — Full machine-readable template index', + '- `use-cases.index.json` — Use Case summary with counts and template paths', + '- `metadata.csv` — Flat CSV export of core template metadata', + '', + '## Sync Source', + '', + '- Canonical URL source: `https://flowzap.xyz/sitemap-templates.xml`', + '- Template metadata source: `FlowZap-App-v5/src/templateLibrary/templatesIndex.json`', + '- Template file source: `FlowZap-App-v5/public/template-files/*.fz`', + ]) + (REPO_ROOT / 'README.md').write_text('\n'.join(readme_lines).strip() + '\n', encoding='utf-8') + + contributing_lines = [ + '# Contributing', + '', + 'This repository is synchronized from the FlowZap application template library.', + '', + '## Structure', + '', + '- `primary-use-case/source-domain/template-slug/`', + '- `workflow.fz` contains the FlowZap Code source', + '- `metadata.json` stores machine-readable metadata including primary and secondary Use Cases', + '- `templates.index.json`, `use-cases.index.json`, and `metadata.csv` are generated artifacts', + '', + '## Sync Expectations', + '', + '- Keep the sitemap-driven template set aligned with `https://flowzap.xyz/sitemap-templates.xml`.', + '- Preserve one canonical template copy per slug.', + '- Use `primary_use_case` for folder placement and `use_cases` for the full taxonomy membership.', + '- Preserve `source_domain` from the app index for traceability.', + ] + (REPO_ROOT / 'CONTRIBUTING.md').write_text('\n'.join(contributing_lines).strip() + '\n', encoding='utf-8') + + +def main() -> None: + if not FLOWZAP_APP_ROOT.exists(): + raise SystemExit(f'FlowZap app not found at {FLOWZAP_APP_ROOT}') + canonical_slugs = load_canonical_slugs() + app_index = load_app_index() + clean_repo_root() + + templates_index: list[dict] = [] + use_case_index = {use_case['id']: {'label': use_case['labels']['en'], 'count': 0, 'templates': []} for use_case in USE_CASES} + use_case_index['uncategorized'] = {'label': 'Uncategorized', 'count': 0, 'templates': []} + counts: Counter = Counter() + skipped_slugs: list[str] = [] + + for slug in canonical_slugs: + entry = app_index.get(slug) + if entry is None: + skipped_slugs.append(slug) + continue + template_file = TEMPLATE_FILES_DIR / f'{slug}.fz' + if not template_file.exists(): + raise SystemExit(f'Missing template file: {template_file}') + + source_domain = entry.get('domain') or 'unknown' + source_domain_slug = slugify(source_domain) + use_cases = compute_use_cases(entry) + primary_use_case = use_cases[0] if use_cases else 'uncategorized' + secondary_use_cases = use_cases[1:] + kind = detect_kind(entry) + workflow_id = slug[:-9] if slug.endswith('-workflow') else slug + + relative_dir = f'{primary_use_case}/{source_domain_slug}/{slug}' + target_dir = REPO_ROOT / relative_dir + target_dir.mkdir(parents=True, exist_ok=True) + + shutil.copyfile(template_file, target_dir / 'workflow.fz') + + metadata = { + 'template_id': slug, + 'workflow_id': workflow_id, + 'title': entry['title'], + 'kind': kind, + 'source_domain': source_domain, + 'primary_use_case': primary_use_case, + 'secondary_use_cases': secondary_use_cases, + 'use_cases': use_cases, + 'complexity': entry.get('complexity'), + 'num_nodes': entry.get('numNodes'), + 'num_lanes': entry.get('numLanes'), + 'tags': entry.get('tags') or [], + 'description': entry.get('description') or '', + 'source_path': entry.get('sourcePath') or '', + 'repo_path': relative_dir, + } + (target_dir / 'metadata.json').write_text(json.dumps(metadata, indent=2, ensure_ascii=False) + '\n', encoding='utf-8') + (target_dir / 'README.md').write_text(make_readme(entry, primary_use_case, secondary_use_cases, relative_dir), encoding='utf-8') + + record = { + 'slug': slug, + 'title': entry['title'], + 'description': entry.get('description') or '', + 'kind': kind, + 'sourceDomain': source_domain, + 'primaryUseCase': primary_use_case, + 'secondaryUseCases': secondary_use_cases, + 'useCases': use_cases, + 'complexity': entry.get('complexity'), + 'numNodes': entry.get('numNodes'), + 'numLanes': entry.get('numLanes'), + 'tags': entry.get('tags') or [], + 'sourcePath': entry.get('sourcePath') or '', + 'repoPath': relative_dir, + } + templates_index.append(record) + use_case_index[primary_use_case]['count'] += 1 + use_case_index[primary_use_case]['templates'].append({'slug': slug, 'title': entry['title'], 'repoPath': relative_dir}) + counts[primary_use_case] += 1 + + (REPO_ROOT / 'templates.index.json').write_text(json.dumps({'templates': templates_index}, indent=2, ensure_ascii=False) + '\n', encoding='utf-8') + (REPO_ROOT / 'use-cases.index.json').write_text(json.dumps({'useCases': use_case_index}, indent=2, ensure_ascii=False) + '\n', encoding='utf-8') + + with (REPO_ROOT / 'metadata.csv').open('w', encoding='utf-8', newline='') as handle: + writer = csv.DictWriter(handle, fieldnames=['template_id', 'workflow_id', 'title', 'kind', 'source_domain', 'primary_use_case', 'secondary_use_cases', 'use_cases', 'complexity', 'num_nodes', 'num_lanes', 'tags', 'description', 'source_path', 'repo_path']) + writer.writeheader() + for item in templates_index: + writer.writerow({ + 'template_id': item['slug'], + 'workflow_id': item['slug'][:-9] if item['slug'].endswith('-workflow') else item['slug'], + 'title': item['title'], + 'kind': item['kind'], + 'source_domain': item['sourceDomain'], + 'primary_use_case': item['primaryUseCase'], + 'secondary_use_cases': ';'.join(item['secondaryUseCases']), + 'use_cases': ';'.join(item['useCases']), + 'complexity': item['complexity'], + 'num_nodes': item['numNodes'], + 'num_lanes': item['numLanes'], + 'tags': ';'.join(item['tags']), + 'description': item['description'], + 'source_path': item['sourcePath'], + 'repo_path': item['repoPath'], + }) + + write_root_docs(len(templates_index), counts) + if skipped_slugs: + print('Skipped sitemap entries without template metadata:', ', '.join(skipped_slugs)) + print(f'Synchronized {len(templates_index)} templates into {REPO_ROOT}') + + +if __name__ == '__main__': + main() diff --git a/security/architecture/event-driven-domain-events-architecture/README.md b/security/architecture/event-driven-domain-events-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..bbd5ed114a4407d04688360640be89b07a934765 --- /dev/null +++ b/security/architecture/event-driven-domain-events-architecture/README.md @@ -0,0 +1,19 @@ +# Event-Driven Domain Events Architecture + +A domain events architecture diagram showing how aggregate roots raise domain events that are dispatched both in-process to local handlers and cross-boundary to integration event consumers in other bounded contexts. This template models the DDD event pattern where domain logic triggers side effects through a clean event dispatcher, maintaining separation between domain and infrastructure concerns. Key for teams implementing Domain-Driven Design with event-based integration. + +**Template ID:** `event-driven-domain-events-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** security +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 17 +**Lanes:** 4 +**Tags:** [domain-events, ddd, aggregate-root, bounded-context, event-dispatcher, integration-events, domain-driven-design, architecture-diagram] +**Source path:** `` +**Repo path:** `security/architecture/event-driven-domain-events-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/security/architecture/event-driven-domain-events-architecture/metadata.json b/security/architecture/event-driven-domain-events-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..77a2eb6cbce828970e4702f2261eb117c2675a72 --- /dev/null +++ b/security/architecture/event-driven-domain-events-architecture/metadata.json @@ -0,0 +1,28 @@ +{ + "template_id": "event-driven-domain-events-architecture", + "workflow_id": "event-driven-domain-events-architecture", + "title": "Event-Driven Domain Events Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "security", + "secondary_use_cases": [], + "use_cases": [ + "security" + ], + "complexity": 4, + "num_nodes": 17, + "num_lanes": 4, + "tags": [ + "domain-events", + "ddd", + "aggregate-root", + "bounded-context", + "event-dispatcher", + "integration-events", + "domain-driven-design", + "architecture-diagram" + ], + "description": "A domain events architecture diagram showing how aggregate roots raise domain events that are dispatched both in-process to local handlers and cross-boundary to integration event consumers in other bounded contexts. This template models the DDD event pattern where domain logic triggers side effects through a clean event dispatcher, maintaining separation between domain and infrastructure concerns. Key for teams implementing Domain-Driven Design with event-based integration.", + "source_path": "", + "repo_path": "security/architecture/event-driven-domain-events-architecture" +} diff --git a/security/architecture/event-driven-domain-events-architecture/workflow.fz b/security/architecture/event-driven-domain-events-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..e75a2d11edea7d7ba08e37702beafb2c19978dd6 --- /dev/null +++ b/security/architecture/event-driven-domain-events-architecture/workflow.fz @@ -0,0 +1,42 @@ +Domain { # Domain Layer +n1: circle label:"Business Operation" +n2: rectangle label:"Aggregate Root" +n3: rectangle label:"Apply Domain Logic" +n4: rectangle label:"Raise Domain Event" +n5: rectangle label:"Commit Unit of Work" +n1.handle(right) -> n2.handle(left) +n2.handle(right) -> n3.handle(left) [label="State Transition"] +n3.handle(right) -> n4.handle(left) [label="OrderShipped"] +n4.handle(right) -> n5.handle(left) [label="Transactional"] +n5.handle(bottom) -> Dispatcher.n6.handle(top) [label="After Commit"] +} +Dispatcher { # Event Dispatcher +n6: rectangle label:"Collect Pending Events" +n7: rectangle label:"Resolve Event Handlers" +n8: rectangle label:"Dispatch In-Process" +n9: rectangle label:"Dispatch Cross-Boundary" +n6.handle(right) -> n7.handle(left) [label="Event Queue"] +n7.handle(right) -> n8.handle(left) [label="Same Bounded Context"] +n7.handle(bottom) -> n9.handle(top) [label="External Context"] +n8.handle(bottom) -> Handlers.n10.handle(top) [label="Sync"] +n9.handle(bottom) -> Integration.n14.handle(top) [label="Async"] +} +Handlers { # In-Process Handlers +n10: rectangle label:"Update Read Cache" +n11: rectangle label:"Send Notification" +n12: rectangle label:"Trigger Side Effect" +n13: rectangle label:"Log Audit Entry" +n10.handle(right) -> n11.handle(left) +n11.handle(right) -> n12.handle(left) +n12.handle(right) -> n13.handle(left) +} +Integration { # Integration Events +n14: rectangle label:"Publish to Message Bus" +n15: rectangle label:"Billing Context Subscribes" +n16: rectangle label:"Shipping Context Subscribes" +n17: rectangle label:"Analytics Context Subscribes" +n14.handle(right) -> n15.handle(left) [label="BillingEvent"] +n14.handle(bottom) -> n16.handle(top) [label="ShippingEvent"] +n15.handle(right) -> n17.handle(left) +n16.handle(right) -> n17.handle(left) +} diff --git a/security/architecture/microservices-api-gateway-architecture/README.md b/security/architecture/microservices-api-gateway-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..d50e129f5c05472507f0fb77c29c50ec5f93c002 --- /dev/null +++ b/security/architecture/microservices-api-gateway-architecture/README.md @@ -0,0 +1,19 @@ +# Microservices API Gateway Architecture + +A microservices API gateway architecture diagram showing request routing, JWT authentication, rate limiting, service discovery, and response aggregation across distributed backend services. This template models the entry point for all client traffic in a microservices ecosystem, enforcing security policies before requests reach internal services. Ideal for platform engineers designing scalable API infrastructure with centralized cross-cutting concerns. + +**Template ID:** `microservices-api-gateway-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** security +**Secondary use cases:** mcp +**Complexity:** 4/5 +**Nodes:** 17 +**Lanes:** 3 +**Tags:** [microservices, api-gateway, jwt-authentication, rate-limiting, service-discovery, load-balancing, architecture-diagram, distributed-systems] +**Source path:** `` +**Repo path:** `security/architecture/microservices-api-gateway-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/security/architecture/microservices-api-gateway-architecture/metadata.json b/security/architecture/microservices-api-gateway-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..ece42a1fdc1dbe59b41a134d09210536b36bdd94 --- /dev/null +++ b/security/architecture/microservices-api-gateway-architecture/metadata.json @@ -0,0 +1,31 @@ +{ + "template_id": "microservices-api-gateway-architecture", + "workflow_id": "microservices-api-gateway-architecture", + "title": "Microservices API Gateway Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "security", + "secondary_use_cases": [ + "mcp" + ], + "use_cases": [ + "security", + "mcp" + ], + "complexity": 4, + "num_nodes": 17, + "num_lanes": 3, + "tags": [ + "microservices", + "api-gateway", + "jwt-authentication", + "rate-limiting", + "service-discovery", + "load-balancing", + "architecture-diagram", + "distributed-systems" + ], + "description": "A microservices API gateway architecture diagram showing request routing, JWT authentication, rate limiting, service discovery, and response aggregation across distributed backend services. This template models the entry point for all client traffic in a microservices ecosystem, enforcing security policies before requests reach internal services. Ideal for platform engineers designing scalable API infrastructure with centralized cross-cutting concerns.", + "source_path": "", + "repo_path": "security/architecture/microservices-api-gateway-architecture" +} diff --git a/security/architecture/microservices-api-gateway-architecture/workflow.fz b/security/architecture/microservices-api-gateway-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..72680228519bdd93af5c899ea50596cd50da04c0 --- /dev/null +++ b/security/architecture/microservices-api-gateway-architecture/workflow.fz @@ -0,0 +1,52 @@ +Client { # Client Application +n1: circle label:"Incoming Request" +n2: rectangle label:"Load Balancer" +n21: rectangle label:"Receive API Response" +n22: circle label:"End" +n1.handle(right) -> n2.handle(left) +n2.handle(bottom) -> Gateway.n3.handle(top) [label="Route Request"] +n21.handle(right) -> n22.handle(left) +} +Gateway { # API Gateway +n3: rectangle label:"Authenticate JWT Token" +n4: diamond label:"Token Valid?" +n5: rectangle label:"Apply Rate Limiting" +n6: rectangle label:"Return 401 Unauthorized" +n7: diamond label:"Rate Limit OK?" +n8: rectangle label:"Route to Microservice" +n9: rectangle label:"Return 429 Throttled" +n18: rectangle label:"Aggregate Responses" +n19: rectangle label:"Format Response" +n20: rectangle label:"Send to Client" +n3.handle(right) -> n4.handle(left) +n4.handle(right) -> n5.handle(left) [label="Yes"] +n4.handle(bottom) -> n6.handle(top) [label="No"] +n5.handle(right) -> n7.handle(left) +n6.handle(top) -> Client.n21.handle(bottom) [label="401"] +n7.handle(right) -> n8.handle(left) [label="Yes"] +n7.handle(bottom) -> n9.handle(top) [label="No"] +n8.handle(bottom) -> Services.n10.handle(top) [label="Forward"] +n9.handle(top) -> Client.n21.handle(bottom) [label="429"] +n18.handle(right) -> n19.handle(left) +n19.handle(right) -> n20.handle(left) +n20.handle(top) -> Client.n21.handle(bottom) [label="Response"] +} +Services { # Microservices Cluster +n10: rectangle label:"Service Discovery Lookup" +n11: rectangle label:"User Service" +n12: rectangle label:"Order Service" +n13: rectangle label:"Inventory Service" +n14: rectangle label:"Compose Response" +n15: rectangle label:"Prepare Aggregated Data" +n16: rectangle label:"Forward Aggregated Data" +n17: rectangle label:"Send to Gateway" +n10.handle(right) -> n11.handle(left) [label="Users"] +n10.handle(bottom) -> n12.handle(top) [label="Orders"] +n11.handle(right) -> n14.handle(left) +n12.handle(right) -> n13.handle(left) [label="Check Stock"] +n13.handle(right) -> n14.handle(left) +n14.handle(right) -> n15.handle(left) +n15.handle(right) -> n16.handle(left) +n16.handle(right) -> n17.handle(left) +n17.handle(top) -> Gateway.n18.handle(bottom) [label="Aggregated"] +} diff --git a/security/architecture/multi-tenant-saas-architecture/README.md b/security/architecture/multi-tenant-saas-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..b4a4020d1d4d7b549382546d488ad61786ec8921 --- /dev/null +++ b/security/architecture/multi-tenant-saas-architecture/README.md @@ -0,0 +1,19 @@ +# Multi-Tenant SaaS Architecture + +A multi-tenant SaaS architecture diagram with tenant identification, tier-based routing (shared vs dedicated pools), row-level security, per-tenant encryption keys, and isolated backup strategies for standard and enterprise isolation models. This template models the architecture decisions for building SaaS platforms that serve multiple customers from shared infrastructure while maintaining strict data isolation. Critical for SaaS architects balancing cost efficiency with enterprise security requirements. + +**Template ID:** `multi-tenant-saas-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** security +**Secondary use cases:** delivery +**Complexity:** 4/5 +**Nodes:** 17 +**Lanes:** 4 +**Tags:** [multi-tenant, saas-architecture, tenant-isolation, row-level-security, shared-infrastructure, enterprise-tier, data-isolation, architecture-diagram] +**Source path:** `` +**Repo path:** `security/architecture/multi-tenant-saas-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/security/architecture/multi-tenant-saas-architecture/metadata.json b/security/architecture/multi-tenant-saas-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..38c722c44ad208ab86ab01b9954c1002653e9dad --- /dev/null +++ b/security/architecture/multi-tenant-saas-architecture/metadata.json @@ -0,0 +1,31 @@ +{ + "template_id": "multi-tenant-saas-architecture", + "workflow_id": "multi-tenant-saas-architecture", + "title": "Multi-Tenant SaaS Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "security", + "secondary_use_cases": [ + "delivery" + ], + "use_cases": [ + "security", + "delivery" + ], + "complexity": 4, + "num_nodes": 17, + "num_lanes": 4, + "tags": [ + "multi-tenant", + "saas-architecture", + "tenant-isolation", + "row-level-security", + "shared-infrastructure", + "enterprise-tier", + "data-isolation", + "architecture-diagram" + ], + "description": "A multi-tenant SaaS architecture diagram with tenant identification, tier-based routing (shared vs dedicated pools), row-level security, per-tenant encryption keys, and isolated backup strategies for standard and enterprise isolation models. This template models the architecture decisions for building SaaS platforms that serve multiple customers from shared infrastructure while maintaining strict data isolation. Critical for SaaS architects balancing cost efficiency with enterprise security requirements.", + "source_path": "", + "repo_path": "security/architecture/multi-tenant-saas-architecture" +} diff --git a/security/architecture/multi-tenant-saas-architecture/workflow.fz b/security/architecture/multi-tenant-saas-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..d9d92a7365fe0f7a2777aef262aec5e697201820 --- /dev/null +++ b/security/architecture/multi-tenant-saas-architecture/workflow.fz @@ -0,0 +1,50 @@ +Tenant { # Tenant Request +n1: circle label:"Tenant API Call" +n2: rectangle label:"Tenant Identification" +n20: rectangle label:"Receive Response" +n21: circle label:"End" +n1.handle(right) -> n2.handle(left) [label="X-Tenant-ID"] +n2.handle(bottom) -> Routing.n3.handle(top) [label="Resolve Tenant"] +n20.handle(right) -> n21.handle(left) +} +Routing { # Tenant Routing Layer +n3: rectangle label:"Tenant Config Lookup" +n4: diamond label:"Isolation Model?" +n5: rectangle label:"Route to Shared Pool" +n6: rectangle label:"Route to Dedicated Pool" +n7: rectangle label:"Apply Tenant Rate Limits" +n18: rectangle label:"Receive App Response" +n19: rectangle label:"Forward to Tenant" +n3.handle(right) -> n4.handle(left) [label="Tier"] +n4.handle(right) -> n5.handle(left) [label="Standard Tier"] +n4.handle(bottom) -> n6.handle(top) [label="Enterprise Tier"] +n5.handle(right) -> n7.handle(left) +n6.handle(right) -> n7.handle(left) +n7.handle(bottom) -> Application.n8.handle(top) [label="Tenant Context"] +n18.handle(right) -> n19.handle(left) +n19.handle(top) -> Tenant.n20.handle(bottom) [label="Response"] +} +Application { # Application Layer +n8: rectangle label:"Inject Tenant Context" +n9: rectangle label:"Execute Business Logic" +n10: rectangle label:"Apply Row-Level Security" +n15: rectangle label:"Receive Query Results" +n16: rectangle label:"Return Tenant-Scoped Data" +n17: rectangle label:"Forward to Routing" +n8.handle(right) -> n9.handle(left) [label="Middleware"] +n9.handle(right) -> n10.handle(left) [label="Query"] +n10.handle(bottom) -> DataLayer.n11.handle(top) [label="Tenant Filter"] +n15.handle(right) -> n16.handle(left) [label="Filtered"] +n16.handle(right) -> n17.handle(left) +n17.handle(top) -> Routing.n18.handle(bottom) [label="App Response"] +} +DataLayer { # Data Isolation +n11: rectangle label:"Shared Database (Schema per Tenant)" +n12: rectangle label:"Dedicated Database (Enterprise)" +n13: rectangle label:"Tenant Encryption Keys" +n14: rectangle label:"Return Query Results" +n11.handle(right) -> n13.handle(left) [label="Encrypt at Rest"] +n12.handle(right) -> n13.handle(left) [label="Dedicated Key"] +n13.handle(right) -> n14.handle(left) +n14.handle(top) -> Application.n15.handle(bottom) [label="Data Results"] +} diff --git a/security/architecture/zero-trust-security-architecture/README.md b/security/architecture/zero-trust-security-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..cab45100e40a1fbde9ec50aab4214e4f90737922 --- /dev/null +++ b/security/architecture/zero-trust-security-architecture/README.md @@ -0,0 +1,19 @@ +# Zero Trust Security Architecture + +A zero trust security architecture diagram with device posture checks, MFA identity verification, risk-based policy decisions, short-lived JWT tokens, micro-segmentation, mTLS encryption, least-privilege access enforcement, and continuous monitoring. This template models the 'never trust, always verify' security paradigm where every request is authenticated and authorized regardless of network location. Essential for security architects implementing modern zero-trust frameworks in cloud-native environments. + +**Template ID:** `zero-trust-security-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** security +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 19 +**Lanes:** 4 +**Tags:** [zero-trust, security-architecture, mfa, micro-segmentation, mtls, least-privilege, continuous-verification, architecture-diagram] +**Source path:** `` +**Repo path:** `security/architecture/zero-trust-security-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/security/architecture/zero-trust-security-architecture/metadata.json b/security/architecture/zero-trust-security-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..0ae235a4941a3bf0239c19f8d33d8a6668fa7544 --- /dev/null +++ b/security/architecture/zero-trust-security-architecture/metadata.json @@ -0,0 +1,28 @@ +{ + "template_id": "zero-trust-security-architecture", + "workflow_id": "zero-trust-security-architecture", + "title": "Zero Trust Security Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "security", + "secondary_use_cases": [], + "use_cases": [ + "security" + ], + "complexity": 4, + "num_nodes": 19, + "num_lanes": 4, + "tags": [ + "zero-trust", + "security-architecture", + "mfa", + "micro-segmentation", + "mtls", + "least-privilege", + "continuous-verification", + "architecture-diagram" + ], + "description": "A zero trust security architecture diagram with device posture checks, MFA identity verification, risk-based policy decisions, short-lived JWT tokens, micro-segmentation, mTLS encryption, least-privilege access enforcement, and continuous monitoring. This template models the 'never trust, always verify' security paradigm where every request is authenticated and authorized regardless of network location. Essential for security architects implementing modern zero-trust frameworks in cloud-native environments.", + "source_path": "", + "repo_path": "security/architecture/zero-trust-security-architecture" +} diff --git a/security/architecture/zero-trust-security-architecture/workflow.fz b/security/architecture/zero-trust-security-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..c7bab98776668293a31b868c04ed442033d53e15 --- /dev/null +++ b/security/architecture/zero-trust-security-architecture/workflow.fz @@ -0,0 +1,65 @@ +User { # User / Device +n1: circle label:"Access Request" +n2: rectangle label:"Device Posture Check" +n3: rectangle label:"Identity Verification (MFA)" +n28: rectangle label:"Receive Access Decision" +n29: circle label:"Access Granted or Denied" +n1.handle(right) -> n2.handle(left) +n2.handle(right) -> n3.handle(left) [label="Device Compliant"] +n3.handle(bottom) -> PolicyEngine.n4.handle(top) [label="Authenticate"] +n28.handle(right) -> n29.handle(left) +} +PolicyEngine { # Policy Decision Point +n4: rectangle label:"Evaluate Identity Context" +n5: rectangle label:"Check Risk Score" +n6: diamond label:"Trust Level Sufficient?" +n7: rectangle label:"Issue Short-Lived Token" +n8: rectangle label:"Deny and Log" +n9: rectangle label:"Step-Up Authentication" +n24: rectangle label:"Receive Enforcement Result" +n25: rectangle label:"Forward to User" +n4.handle(right) -> n5.handle(left) [label="Context"] +n5.handle(right) -> n6.handle(left) +n6.handle(right) -> n7.handle(left) [label="Trusted"] +n6.handle(bottom) -> n8.handle(top) [label="Denied"] +n6.handle(left) -> n9.handle(right) [label="Elevated"] +n7.handle(bottom) -> Enforcement.n10.handle(top) [label="JWT (5 min TTL)"] +n8.handle(top) -> User.n28.handle(bottom) [label="403"] +n24.handle(right) -> n25.handle(left) +n25.handle(top) -> User.n28.handle(bottom) [label="Access Result"] +} +Enforcement { # Policy Enforcement Points +n10: rectangle label:"Micro-Segmentation Gateway" +n11: rectangle label:"Encrypt All Traffic (mTLS)" +n12: rectangle label:"Least-Privilege Access" +n22: rectangle label:"Receive Resource Response" +n23: rectangle label:"Forward to PolicyEngine" +n26: rectangle label:"Monitoring Dashboard" +n27: rectangle label:"Threat Detection" +n10.handle(right) -> n11.handle(left) [label="Segment"] +n11.handle(right) -> n12.handle(left) [label="Encrypted"] +n12.handle(bottom) -> Resources.n13.handle(top) [label="Scoped Access"] +n22.handle(right) -> n23.handle(left) +n23.handle(top) -> PolicyEngine.n24.handle(bottom) [label="Enforcement Result"] +n26.handle(right) -> n27.handle(left) [label="Detect"] +} +Resources { # Protected Resources +n13: rectangle label:"Application Service" +n14: rectangle label:"Database" +n15: rectangle label:"API Endpoint" +n16: rectangle label:"Audit Log" +n17: rectangle label:"Prepare Response" +n18: rectangle label:"Package Response" +n19: rectangle label:"Forward Response" +n20: rectangle label:"Continuous Monitoring" +n21: rectangle label:"Send to Enforcement" +n13.handle(right) -> n14.handle(left) [label="Query"] +n14.handle(right) -> n15.handle(left) [label="Call"] +n15.handle(right) -> n16.handle(left) [label="Log Access"] +n16.handle(right) -> n17.handle(left) +n17.handle(right) -> n18.handle(left) +n18.handle(right) -> n19.handle(left) +n19.handle(right) -> n20.handle(left) +n20.handle(right) -> n21.handle(left) +n21.handle(top) -> Enforcement.n22.handle(bottom) [label="Resource Response"] +} diff --git a/security/business-operations/api-key-rotation-workflow/README.md b/security/business-operations/api-key-rotation-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..652d299e31b1ecf68531d1ef89f85c6c44e9dfeb --- /dev/null +++ b/security/business-operations/api-key-rotation-workflow/README.md @@ -0,0 +1,19 @@ +# Api Key Rotation Workflow + +API key rotation workflow with new key generation, dual-key transition period, client notification, old key deprecation, and audit logging. + +**Template ID:** `api-key-rotation-workflow` +**Kind:** workflow +**Source domain:** business-operations +**Primary use case:** security +**Secondary use cases:** compliance +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [api-key-rotation, security, credential-management, zero-downtime, secrets-manager, compliance] +**Source path:** `business-operations/api-key-rotation` +**Repo path:** `security/business-operations/api-key-rotation-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/security/business-operations/api-key-rotation-workflow/metadata.json b/security/business-operations/api-key-rotation-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..8e4e93aed2a379533fb6c57e90fc7b64a085c429 --- /dev/null +++ b/security/business-operations/api-key-rotation-workflow/metadata.json @@ -0,0 +1,29 @@ +{ + "template_id": "api-key-rotation-workflow", + "workflow_id": "api-key-rotation", + "title": "Api Key Rotation Workflow", + "kind": "workflow", + "source_domain": "business-operations", + "primary_use_case": "security", + "secondary_use_cases": [ + "compliance" + ], + "use_cases": [ + "security", + "compliance" + ], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "api-key-rotation", + "security", + "credential-management", + "zero-downtime", + "secrets-manager", + "compliance" + ], + "description": "API key rotation workflow with new key generation, dual-key transition period, client notification, old key deprecation, and audit logging.", + "source_path": "business-operations/api-key-rotation", + "repo_path": "security/business-operations/api-key-rotation-workflow" +} diff --git a/business-operations/api-key-rotation/workflow.fz b/security/business-operations/api-key-rotation-workflow/workflow.fz similarity index 100% rename from business-operations/api-key-rotation/workflow.fz rename to security/business-operations/api-key-rotation-workflow/workflow.fz diff --git a/security/business-operations/sms-verification-workflow/README.md b/security/business-operations/sms-verification-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..7c70c9329c92cc934fe7ca064ac4e8cbe1cb46a9 --- /dev/null +++ b/security/business-operations/sms-verification-workflow/README.md @@ -0,0 +1,19 @@ +# Sms Verification Workflow + +SMS phone verification workflow with OTP generation, rate limiting, code validation, retry handling, and verification status tracking. + +**Template ID:** `sms-verification-workflow` +**Kind:** workflow +**Source domain:** business-operations +**Primary use case:** security +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 13 +**Lanes:** 4 +**Tags:** [sms-verification, otp, twilio, phone-verification, 2fa, fraud-prevention] +**Source path:** `business-operations/sms-verification` +**Repo path:** `security/business-operations/sms-verification-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/security/business-operations/sms-verification-workflow/metadata.json b/security/business-operations/sms-verification-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..3daadab8a38841c98911fe93c81903ec67ff3cf5 --- /dev/null +++ b/security/business-operations/sms-verification-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "sms-verification-workflow", + "workflow_id": "sms-verification", + "title": "Sms Verification Workflow", + "kind": "workflow", + "source_domain": "business-operations", + "primary_use_case": "security", + "secondary_use_cases": [], + "use_cases": [ + "security" + ], + "complexity": 3, + "num_nodes": 13, + "num_lanes": 4, + "tags": [ + "sms-verification", + "otp", + "twilio", + "phone-verification", + "2fa", + "fraud-prevention" + ], + "description": "SMS phone verification workflow with OTP generation, rate limiting, code validation, retry handling, and verification status tracking.", + "source_path": "business-operations/sms-verification", + "repo_path": "security/business-operations/sms-verification-workflow" +} diff --git a/business-operations/sms-verification/workflow.fz b/security/business-operations/sms-verification-workflow/workflow.fz similarity index 100% rename from business-operations/sms-verification/workflow.fz rename to security/business-operations/sms-verification-workflow/workflow.fz diff --git a/security/devops/certificate-renewal-workflow/README.md b/security/devops/certificate-renewal-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..0e5907706a75f9273fc03f72c06a47468edf558f --- /dev/null +++ b/security/devops/certificate-renewal-workflow/README.md @@ -0,0 +1,19 @@ +# Certificate Renewal Workflow + +SSL/TLS certificate renewal workflow with expiration monitoring, certificate request by type (DV/OV/EV), domain validation, deployment to load balancers, and health check verification with rollback. + +**Template ID:** `certificate-renewal-workflow` +**Kind:** workflow +**Source domain:** devops +**Primary use case:** security +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 19 +**Lanes:** 3 +**Tags:** [ssl-certificate, tls-renewal, lets-encrypt, certificate-authority, domain-validation, load-balancer, health-check] +**Source path:** `devops/certificate-renewal` +**Repo path:** `security/devops/certificate-renewal-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/devops/certificate-renewal/metadata.json b/security/devops/certificate-renewal-workflow/metadata.json similarity index 54% rename from devops/certificate-renewal/metadata.json rename to security/devops/certificate-renewal-workflow/metadata.json index 0ecaafdbdd9f35d396b4778b1a5eefbb762d924c..25f2cab38e9874bbf0570dae3f975e8b7e7c0db3 100644 --- a/devops/certificate-renewal/metadata.json +++ b/security/devops/certificate-renewal-workflow/metadata.json @@ -1,6 +1,14 @@ { + "template_id": "certificate-renewal-workflow", "workflow_id": "certificate-renewal", - "domain": "devops", + "title": "Certificate Renewal Workflow", + "kind": "workflow", + "source_domain": "devops", + "primary_use_case": "security", + "secondary_use_cases": [], + "use_cases": [ + "security" + ], "complexity": 4, "num_nodes": 19, "num_lanes": 3, @@ -13,5 +21,7 @@ "load-balancer", "health-check" ], - "description": "SSL/TLS certificate renewal workflow with expiration monitoring, certificate request by type (DV/OV/EV), domain validation, deployment to load balancers, and health check verification with rollback." -} \ No newline at end of file + "description": "SSL/TLS certificate renewal workflow with expiration monitoring, certificate request by type (DV/OV/EV), domain validation, deployment to load balancers, and health check verification with rollback.", + "source_path": "devops/certificate-renewal", + "repo_path": "security/devops/certificate-renewal-workflow" +} diff --git a/devops/certificate-renewal/workflow.fz b/security/devops/certificate-renewal-workflow/workflow.fz similarity index 100% rename from devops/certificate-renewal/workflow.fz rename to security/devops/certificate-renewal-workflow/workflow.fz diff --git a/security/devops/mcp-gateway-proxy/README.md b/security/devops/mcp-gateway-proxy/README.md new file mode 100644 index 0000000000000000000000000000000000000000..f44b8d0d081e3d697018998eafc9d4270c9021c0 --- /dev/null +++ b/security/devops/mcp-gateway-proxy/README.md @@ -0,0 +1,19 @@ +# MCP Gateway Proxy Architecture + +An API gateway pattern that sits between agents and MCP servers to handle authentication, rate limits, and auditing. The gateway enforces OAuth 2.0, SAML, SSO, tool-level rate limiting, and team-based quotas. Essential for multi-team or multi-tenant MCP deployments. + +**Template ID:** `mcp-gateway-proxy` +**Kind:** architecture +**Source domain:** DevOps +**Primary use case:** security +**Secondary use cases:** compliance, mcp +**Complexity:** 3/5 +**Nodes:** 7 +**Lanes:** 3 +**Tags:** [mcp, gateway, proxy, oauth, rate-limiting, audit, architecture-diagram, production-grade] +**Source path:** `` +**Repo path:** `security/devops/mcp-gateway-proxy` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/security/devops/mcp-gateway-proxy/metadata.json b/security/devops/mcp-gateway-proxy/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..a4c023f22cedd7096f6c2ac2d7c674c6dc3a9b9a --- /dev/null +++ b/security/devops/mcp-gateway-proxy/metadata.json @@ -0,0 +1,33 @@ +{ + "template_id": "mcp-gateway-proxy", + "workflow_id": "mcp-gateway-proxy", + "title": "MCP Gateway Proxy Architecture", + "kind": "architecture", + "source_domain": "DevOps", + "primary_use_case": "security", + "secondary_use_cases": [ + "compliance", + "mcp" + ], + "use_cases": [ + "security", + "compliance", + "mcp" + ], + "complexity": 3, + "num_nodes": 7, + "num_lanes": 3, + "tags": [ + "mcp", + "gateway", + "proxy", + "oauth", + "rate-limiting", + "audit", + "architecture-diagram", + "production-grade" + ], + "description": "An API gateway pattern that sits between agents and MCP servers to handle authentication, rate limits, and auditing. The gateway enforces OAuth 2.0, SAML, SSO, tool-level rate limiting, and team-based quotas. Essential for multi-team or multi-tenant MCP deployments.", + "source_path": "", + "repo_path": "security/devops/mcp-gateway-proxy" +} diff --git a/security/devops/mcp-gateway-proxy/workflow.fz b/security/devops/mcp-gateway-proxy/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..31408cabf98e30f6a1e076dbec2f49bec6024a3e --- /dev/null +++ b/security/devops/mcp-gateway-proxy/workflow.fz @@ -0,0 +1,32 @@ +Host { # Host Application + n1: circle label="User sends prompt" + n2: rectangle label="Agent builds tool call" + n3: rectangle label="Send request to gateway" + n4: rectangle label="Receive gateway response" + n5: rectangle label="Agent responds to user" + n1.handle(right) -> n2.handle(left) + n2.handle(right) -> n3.handle(left) + n3.handle(bottom) -> Gateway.n6.handle(top) [label="Tool request"] + n4.handle(right) -> n5.handle(left) +} + +Gateway { # MCP Gateway + n6: rectangle label="Receive and log request" + n7: diamond label="Authorized?" + n8: rectangle label="Forward to MCP server" + n9: rectangle label="Receive MCP response" + n10: rectangle label="Log response and return" + n6.handle(right) -> n7.handle(left) + n7.handle(right) -> n8.handle(left) [label="Yes"] + n7.handle(top) -> Host.n4.handle(left) [label="401 Unauthorized"] + n8.handle(bottom) -> MCPServer.n11.handle(top) [label="Forwarded request"] + n9.handle(right) -> n10.handle(left) + n10.handle(top) -> Host.n4.handle(bottom) [label="Authorized response"] +} + +MCPServer { # MCP Server + n11: rectangle label="Execute tool" + n12: rectangle label="Return result" + n11.handle(right) -> n12.handle(left) + n12.handle(top) -> Gateway.n9.handle(bottom) [label="Tool result"] +} diff --git a/security/devops/secret-rotation-workflow/README.md b/security/devops/secret-rotation-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..078e949fbb88d70e45cc242db90d3b1dc6ce98f1 --- /dev/null +++ b/security/devops/secret-rotation-workflow/README.md @@ -0,0 +1,19 @@ +# Secret Rotation Workflow + +Automated secret rotation workflow with HashiCorp Vault for API keys, database passwords, and certificates including Kubernetes secret updates and rolling service restarts. + +**Template ID:** `secret-rotation-workflow` +**Kind:** workflow +**Source domain:** devops +**Primary use case:** security +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 18 +**Lanes:** 3 +**Tags:** [secret-rotation, vault, kubernetes-secrets, api-keys, database-passwords, certificates, security] +**Source path:** `devops/secret-rotation` +**Repo path:** `security/devops/secret-rotation-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/security/devops/secret-rotation-workflow/metadata.json b/security/devops/secret-rotation-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..34410c81fd84266f4e4cfbe32bca04fb3d17a539 --- /dev/null +++ b/security/devops/secret-rotation-workflow/metadata.json @@ -0,0 +1,27 @@ +{ + "template_id": "secret-rotation-workflow", + "workflow_id": "secret-rotation", + "title": "Secret Rotation Workflow", + "kind": "workflow", + "source_domain": "devops", + "primary_use_case": "security", + "secondary_use_cases": [], + "use_cases": [ + "security" + ], + "complexity": 4, + "num_nodes": 18, + "num_lanes": 3, + "tags": [ + "secret-rotation", + "vault", + "kubernetes-secrets", + "api-keys", + "database-passwords", + "certificates", + "security" + ], + "description": "Automated secret rotation workflow with HashiCorp Vault for API keys, database passwords, and certificates including Kubernetes secret updates and rolling service restarts.", + "source_path": "devops/secret-rotation", + "repo_path": "security/devops/secret-rotation-workflow" +} diff --git a/devops/secret-rotation/workflow.fz b/security/devops/secret-rotation-workflow/workflow.fz similarity index 100% rename from devops/secret-rotation/workflow.fz rename to security/devops/secret-rotation-workflow/workflow.fz diff --git a/security/devops/security-scan-workflow/README.md b/security/devops/security-scan-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..c3fbc1a8fbd3fb5329f6608ce169d42658a49d53 --- /dev/null +++ b/security/devops/security-scan-workflow/README.md @@ -0,0 +1,19 @@ +# Security Scan Workflow + +Security scanning workflow with SAST, DAST, dependency vulnerability scanning, finding triage, and remediation tracking in CI/CD pipeline. + +**Template ID:** `security-scan-workflow` +**Kind:** workflow +**Source domain:** devops +**Primary use case:** security +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [security-scanning, sast, dast, dependency-check, snyk, devsecops] +**Source path:** `devops/security-scan` +**Repo path:** `security/devops/security-scan-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/security/devops/security-scan-workflow/metadata.json b/security/devops/security-scan-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..d558dfe0bc94f3dd1e73a697fbb8ada64163afc2 --- /dev/null +++ b/security/devops/security-scan-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "security-scan-workflow", + "workflow_id": "security-scan", + "title": "Security Scan Workflow", + "kind": "workflow", + "source_domain": "devops", + "primary_use_case": "security", + "secondary_use_cases": [], + "use_cases": [ + "security" + ], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "security-scanning", + "sast", + "dast", + "dependency-check", + "snyk", + "devsecops" + ], + "description": "Security scanning workflow with SAST, DAST, dependency vulnerability scanning, finding triage, and remediation tracking in CI/CD pipeline.", + "source_path": "devops/security-scan", + "repo_path": "security/devops/security-scan-workflow" +} diff --git a/devops/security-scan/workflow.fz b/security/devops/security-scan-workflow/workflow.fz similarity index 100% rename from devops/security-scan/workflow.fz rename to security/devops/security-scan-workflow/workflow.fz diff --git a/security/devops/vulnerability-patch-workflow/README.md b/security/devops/vulnerability-patch-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..e552f01950fe3ebb317391dc5b8159885644369c --- /dev/null +++ b/security/devops/vulnerability-patch-workflow/README.md @@ -0,0 +1,19 @@ +# Vulnerability Patch Workflow + +Security vulnerability patching workflow with CVE scanning, severity-based triage (critical/high/medium), patch testing, staging deployment, and production rollout with rollback capability. + +**Template ID:** `vulnerability-patch-workflow` +**Kind:** workflow +**Source domain:** devops +**Primary use case:** security +**Secondary use cases:** compliance, delivery +**Complexity:** 4/5 +**Nodes:** 19 +**Lanes:** 3 +**Tags:** [vulnerability-management, security-patching, cve-triage, cvss-scoring, patch-testing, rollback, compliance] +**Source path:** `devops/vulnerability-patch` +**Repo path:** `security/devops/vulnerability-patch-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/devops/vulnerability-patch/metadata.json b/security/devops/vulnerability-patch-workflow/metadata.json similarity index 50% rename from devops/vulnerability-patch/metadata.json rename to security/devops/vulnerability-patch-workflow/metadata.json index 9839f8847cbf1cff9a9886dfd004ffcdc77e5855..6faf23480fbf13a1d6eeaafd414b6fa15a6b22e5 100644 --- a/devops/vulnerability-patch/metadata.json +++ b/security/devops/vulnerability-patch-workflow/metadata.json @@ -1,6 +1,19 @@ { + "template_id": "vulnerability-patch-workflow", "workflow_id": "vulnerability-patch", - "domain": "devops", + "title": "Vulnerability Patch Workflow", + "kind": "workflow", + "source_domain": "devops", + "primary_use_case": "security", + "secondary_use_cases": [ + "compliance", + "delivery" + ], + "use_cases": [ + "security", + "compliance", + "delivery" + ], "complexity": 4, "num_nodes": 19, "num_lanes": 3, @@ -13,5 +26,7 @@ "rollback", "compliance" ], - "description": "Security vulnerability patching workflow with CVE scanning, severity-based triage (critical/high/medium), patch testing, staging deployment, and production rollout with rollback capability." -} \ No newline at end of file + "description": "Security vulnerability patching workflow with CVE scanning, severity-based triage (critical/high/medium), patch testing, staging deployment, and production rollout with rollback capability.", + "source_path": "devops/vulnerability-patch", + "repo_path": "security/devops/vulnerability-patch-workflow" +} diff --git a/devops/vulnerability-patch/workflow.fz b/security/devops/vulnerability-patch-workflow/workflow.fz similarity index 100% rename from devops/vulnerability-patch/workflow.fz rename to security/devops/vulnerability-patch-workflow/workflow.fz diff --git a/security/logistics/shipping-process-workflow/README.md b/security/logistics/shipping-process-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..609c7692c6c3616e07a7d27a2ef0eb8ad1bd2fca --- /dev/null +++ b/security/logistics/shipping-process-workflow/README.md @@ -0,0 +1,19 @@ +# Shipping Process Workflow + +Order shipping workflow with carrier selection, rate shopping, label generation, tracking number assignment, and dispatch confirmation. + +**Template ID:** `shipping-process-workflow` +**Kind:** workflow +**Source domain:** logistics +**Primary use case:** security +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [shipping-process, order-fulfillment, carrier-selection, label-generation, tracking-number, dispatch] +**Source path:** `logistics/shipping-process` +**Repo path:** `security/logistics/shipping-process-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/security/logistics/shipping-process-workflow/metadata.json b/security/logistics/shipping-process-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..859d4e7a7c9a7f5a144b32f85801fd273a6106d0 --- /dev/null +++ b/security/logistics/shipping-process-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "shipping-process-workflow", + "workflow_id": "shipping-process", + "title": "Shipping Process Workflow", + "kind": "workflow", + "source_domain": "logistics", + "primary_use_case": "security", + "secondary_use_cases": [], + "use_cases": [ + "security" + ], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "shipping-process", + "order-fulfillment", + "carrier-selection", + "label-generation", + "tracking-number", + "dispatch" + ], + "description": "Order shipping workflow with carrier selection, rate shopping, label generation, tracking number assignment, and dispatch confirmation.", + "source_path": "logistics/shipping-process", + "repo_path": "security/logistics/shipping-process-workflow" +} diff --git a/logistics/shipping-process/workflow.fz b/security/logistics/shipping-process-workflow/workflow.fz similarity index 100% rename from logistics/shipping-process/workflow.fz rename to security/logistics/shipping-process-workflow/workflow.fz diff --git a/security/patterns/authentication-flow-workflow/README.md b/security/patterns/authentication-flow-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..4835b28deef715b750229f5c7072b2d1d32f7c58 --- /dev/null +++ b/security/patterns/authentication-flow-workflow/README.md @@ -0,0 +1,19 @@ +# Authentication Flow Workflow + +User authentication workflow with credential validation, MFA challenge, JWT token generation, session creation, and failed attempt tracking. + +**Template ID:** `authentication-flow-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** security +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [authentication, login, jwt, oauth, mfa, session-management] +**Source path:** `patterns/authentication-flow` +**Repo path:** `security/patterns/authentication-flow-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/security/patterns/authentication-flow-workflow/metadata.json b/security/patterns/authentication-flow-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..06902030adec5acb289bf6997d7333aff1d5d2d5 --- /dev/null +++ b/security/patterns/authentication-flow-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "authentication-flow-workflow", + "workflow_id": "authentication-flow", + "title": "Authentication Flow Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "security", + "secondary_use_cases": [], + "use_cases": [ + "security" + ], + "complexity": 3, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "authentication", + "login", + "jwt", + "oauth", + "mfa", + "session-management" + ], + "description": "User authentication workflow with credential validation, MFA challenge, JWT token generation, session creation, and failed attempt tracking.", + "source_path": "patterns/authentication-flow", + "repo_path": "security/patterns/authentication-flow-workflow" +} diff --git a/patterns/authentication-flow/workflow.fz b/security/patterns/authentication-flow-workflow/workflow.fz similarity index 100% rename from patterns/authentication-flow/workflow.fz rename to security/patterns/authentication-flow-workflow/workflow.fz diff --git a/support/business-operations/knowledge-base-workflow/README.md b/support/business-operations/knowledge-base-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..fef9d2637716f3a7a1233f33f541a3cab9c91984 --- /dev/null +++ b/support/business-operations/knowledge-base-workflow/README.md @@ -0,0 +1,19 @@ +# Knowledge Base Workflow + +Knowledge base management workflow with article creation, review approval, SEO optimization, version control, and search analytics tracking. + +**Template ID:** `knowledge-base-workflow` +**Kind:** workflow +**Source domain:** business-operations +**Primary use case:** support +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 13 +**Lanes:** 4 +**Tags:** [knowledge-base, help-center, documentation, self-service, article-management, zendesk] +**Source path:** `business-operations/knowledge-base` +**Repo path:** `support/business-operations/knowledge-base-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/support/business-operations/knowledge-base-workflow/metadata.json b/support/business-operations/knowledge-base-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..5c0b0b30a891c273da53d1b3e77054cabe9e9f6c --- /dev/null +++ b/support/business-operations/knowledge-base-workflow/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "knowledge-base-workflow", + "workflow_id": "knowledge-base", + "title": "Knowledge Base Workflow", + "kind": "workflow", + "source_domain": "business-operations", + "primary_use_case": "support", + "secondary_use_cases": [], + "use_cases": [ + "support" + ], + "complexity": 3, + "num_nodes": 13, + "num_lanes": 4, + "tags": [ + "knowledge-base", + "help-center", + "documentation", + "self-service", + "article-management", + "zendesk" + ], + "description": "Knowledge base management workflow with article creation, review approval, SEO optimization, version control, and search analytics tracking.", + "source_path": "business-operations/knowledge-base", + "repo_path": "support/business-operations/knowledge-base-workflow" +} diff --git a/business-operations/knowledge-base/workflow.fz b/support/business-operations/knowledge-base-workflow/workflow.fz similarity index 100% rename from business-operations/knowledge-base/workflow.fz rename to support/business-operations/knowledge-base-workflow/workflow.fz diff --git a/syntax-primitives/01-basic-lane/README.md b/syntax-primitives/01-basic-lane/README.md deleted file mode 100644 index a22fa3a0bba9341ade91b6c012183f59d01d5710..0000000000000000000000000000000000000000 --- a/syntax-primitives/01-basic-lane/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# 01 Basic Lane - -This workflow models two connected nodes in a single lane showing basic flow. - -**Domain:** syntax-primitives -**Complexity:** 1/5 -**Tags:** [01, basic, lane] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/syntax-primitives/01-basic-lane/metadata.json b/syntax-primitives/01-basic-lane/metadata.json deleted file mode 100644 index 94c07e5dafe3afc12fe78800d18ff277d5c53df1..0000000000000000000000000000000000000000 --- a/syntax-primitives/01-basic-lane/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "01-basic-lane", - "domain": "syntax-primitives", - "complexity": 1, - "num_nodes": 5, - "num_lanes": 1, - "tags": [ - "01", - "basic", - "lane" - ], - "description": "This workflow models two connected nodes in a single lane showing basic flow." -} \ No newline at end of file diff --git a/syntax-primitives/01-basic-lane/workflow.fz b/syntax-primitives/01-basic-lane/workflow.fz deleted file mode 100644 index 9241e9e0774209687bdfd3d6329c6d2b0aec8905..0000000000000000000000000000000000000000 --- a/syntax-primitives/01-basic-lane/workflow.fz +++ /dev/null @@ -1,12 +0,0 @@ -laneA { # Lanea - n1: circle label:"Start 01 Basic Lane" - n2: rectangle label:"01 Basic Lane step 2" - n3: rectangle label:"01 Basic Lane step 3" - n4: rectangle label:"01 Basic Lane step 4" - n5: circle label:"End 01 Basic Lane" - - n1.handle(right) -> n2.handle(left) - n2.handle(right) -> n3.handle(left) - n3.handle(right) -> n4.handle(left) - n4.handle(right) -> n5.handle(left) -} \ No newline at end of file diff --git a/syntax-primitives/02-handle-positions/README.md b/syntax-primitives/02-handle-positions/README.md deleted file mode 100644 index c1a143d299415e028d84ababe905c5bb11efcf03..0000000000000000000000000000000000000000 --- a/syntax-primitives/02-handle-positions/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# 02 Handle Positions - -This workflow models nodes with explicit top, bottom, left, and right handle connections. - -**Domain:** syntax-primitives -**Complexity:** 1/5 -**Tags:** [02, handle, positions] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/syntax-primitives/02-handle-positions/metadata.json b/syntax-primitives/02-handle-positions/metadata.json deleted file mode 100644 index 93ddcdd13af71182c57d90a3dd81768470c3ebfd..0000000000000000000000000000000000000000 --- a/syntax-primitives/02-handle-positions/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "02-handle-positions", - "domain": "syntax-primitives", - "complexity": 1, - "num_nodes": 5, - "num_lanes": 1, - "tags": [ - "02", - "handle", - "positions" - ], - "description": "This workflow models nodes with explicit top, bottom, left, and right handle connections." -} \ No newline at end of file diff --git a/syntax-primitives/02-handle-positions/workflow.fz b/syntax-primitives/02-handle-positions/workflow.fz deleted file mode 100644 index b0798ce511f948dc7d7986a36732ebec9fdd534a..0000000000000000000000000000000000000000 --- a/syntax-primitives/02-handle-positions/workflow.fz +++ /dev/null @@ -1,11 +0,0 @@ -laneA { # Lane A - n1: circle label:"Start 02 Handle Positions" - n2: rectangle label:"02 Handle Positions step 2" - n3: rectangle label:"02 Handle Positions step 3" - n4: rectangle label:"02 Handle Positions step 4" - n5: circle label:"End 02 Handle Positions" - - n1.handle(bottom) -> n2.handle(top) [label="Bottom to Top"] - n2.handle(right) -> n3.handle(left) [label="Right to Left"] - n3.handle(top) -> n4.handle(bottom) [label="Top to Bottom"] -} \ No newline at end of file diff --git a/syntax-primitives/03-all-shapes/README.md b/syntax-primitives/03-all-shapes/README.md deleted file mode 100644 index 28537ec527ef1763f12388575716a4d26c719e3d..0000000000000000000000000000000000000000 --- a/syntax-primitives/03-all-shapes/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# 03 All Shapes - -This workflow models a workflow that demonstrates circle, rectangle, diamond, and taskbox shapes. - -**Domain:** syntax-primitives -**Complexity:** 1/5 -**Tags:** [03, all, shapes] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/syntax-primitives/03-all-shapes/metadata.json b/syntax-primitives/03-all-shapes/metadata.json deleted file mode 100644 index 0f6d2fa263463f4d8f303924b7297b513d29e004..0000000000000000000000000000000000000000 --- a/syntax-primitives/03-all-shapes/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "03-all-shapes", - "domain": "syntax-primitives", - "complexity": 1, - "num_nodes": 5, - "num_lanes": 1, - "tags": [ - "03", - "all", - "shapes" - ], - "description": "This workflow models a workflow that demonstrates circle, rectangle, diamond, and taskbox shapes." -} \ No newline at end of file diff --git a/syntax-primitives/03-all-shapes/workflow.fz b/syntax-primitives/03-all-shapes/workflow.fz deleted file mode 100644 index 17b384a1c86c37148d6e1ec941ce7b8a042dd9fa..0000000000000000000000000000000000000000 --- a/syntax-primitives/03-all-shapes/workflow.fz +++ /dev/null @@ -1,12 +0,0 @@ -laneA { # Lane A - n1: circle label:"Start 03 All Shapes" - n2: circle label:"03 All Shapes step 2" - n3: rectangle label:"03 All Shapes step 3" - n4: diamond label:"03 All Shapes step 4" - n5: circle label:"End 03 All Shapes" - - n1.handle(right) -> n2.handle(left) - n2.handle(right) -> n3.handle(left) - n3.handle(right) -> n4.handle(left) - n4.handle(right) -> n5.handle(left) -} \ No newline at end of file diff --git a/syntax-primitives/04-labeled-arrows/README.md b/syntax-primitives/04-labeled-arrows/README.md deleted file mode 100644 index c49cc64b46ac637024f401b64f784cee7f3d8afb..0000000000000000000000000000000000000000 --- a/syntax-primitives/04-labeled-arrows/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# 04 Labeled Arrows - -This workflow models connections with descriptive labels between nodes. - -**Domain:** syntax-primitives -**Complexity:** 1/5 -**Tags:** [04, labeled, arrows] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/syntax-primitives/04-labeled-arrows/metadata.json b/syntax-primitives/04-labeled-arrows/metadata.json deleted file mode 100644 index 9c15e56a29e66471163ffb20e91d8a7c433d5732..0000000000000000000000000000000000000000 --- a/syntax-primitives/04-labeled-arrows/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "04-labeled-arrows", - "domain": "syntax-primitives", - "complexity": 1, - "num_nodes": 5, - "num_lanes": 1, - "tags": [ - "04", - "labeled", - "arrows" - ], - "description": "This workflow models connections with descriptive labels between nodes." -} \ No newline at end of file diff --git a/syntax-primitives/04-labeled-arrows/workflow.fz b/syntax-primitives/04-labeled-arrows/workflow.fz deleted file mode 100644 index f9fb8fdc4f2c22f0eb0a5eb331a96d87140981c3..0000000000000000000000000000000000000000 --- a/syntax-primitives/04-labeled-arrows/workflow.fz +++ /dev/null @@ -1,12 +0,0 @@ -laneA { # Lane A - n1: circle label:"Start 04 Labeled Arrows" - n2: rectangle label:"04 Labeled Arrows step 2" - n3: rectangle label:"04 Labeled Arrows step 3" - n4: rectangle label:"04 Labeled Arrows step 4" - n5: circle label:"End 04 Labeled Arrows" - - n1.handle(right) -> n2.handle(left) - n2.handle(right) -> n3.handle(left) - n3.handle(right) -> n4.handle(left) - n4.handle(right) -> n5.handle(left) -} \ No newline at end of file diff --git a/syntax-primitives/05-multiple-lanes/README.md b/syntax-primitives/05-multiple-lanes/README.md deleted file mode 100644 index 19b1cebd7f404c6d75244f247b2ba3fcb45cf88e..0000000000000000000000000000000000000000 --- a/syntax-primitives/05-multiple-lanes/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# 05 Multiple Lanes - -This workflow models three lanes with cross-lane communication. - -**Domain:** syntax-primitives -**Complexity:** 1/5 -**Tags:** [05, multiple, lanes] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/syntax-primitives/05-multiple-lanes/metadata.json b/syntax-primitives/05-multiple-lanes/metadata.json deleted file mode 100644 index 12407d99e75fede0a6affb90ddfa544b67a25e72..0000000000000000000000000000000000000000 --- a/syntax-primitives/05-multiple-lanes/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "05-multiple-lanes", - "domain": "syntax-primitives", - "complexity": 1, - "num_nodes": 5, - "num_lanes": 3, - "tags": [ - "05", - "multiple", - "lanes" - ], - "description": "This workflow models three lanes with cross-lane communication." -} \ No newline at end of file diff --git a/syntax-primitives/05-multiple-lanes/workflow.fz b/syntax-primitives/05-multiple-lanes/workflow.fz deleted file mode 100644 index 99cca37abd4236e7276b1118e15c88fb062fd45c..0000000000000000000000000000000000000000 --- a/syntax-primitives/05-multiple-lanes/workflow.fz +++ /dev/null @@ -1,18 +0,0 @@ -laneA { # Lane A - n1: circle label:"Start 05 Multiple Lanes" - n4: rectangle label:"05 Multiple Lanes step 4" - - n1.handle(bottom) -> laneB.n2.handle(top) - n4.handle(bottom) -> laneB.n5.handle(top) -} -laneB { # Lane B - n2: rectangle label:"05 Multiple Lanes step 2" - n5: circle label:"End 05 Multiple Lanes" - - n2.handle(bottom) -> laneC.n3.handle(top) -} -laneC { # Lane C - n3: rectangle label:"05 Multiple Lanes step 3" - - n3.handle(bottom) -> laneA.n4.handle(top) -} \ No newline at end of file diff --git a/syntax-primitives/06-nested-lanes/README.md b/syntax-primitives/06-nested-lanes/README.md deleted file mode 100644 index 1158451c5c0f396c92cce3bef7ba15c4296feef3..0000000000000000000000000000000000000000 --- a/syntax-primitives/06-nested-lanes/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# 06 Nested Lanes - -This workflow models lanes that conceptually contain other lanes. - -**Domain:** syntax-primitives -**Complexity:** 1/5 -**Tags:** [06, nested, lanes] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/syntax-primitives/06-nested-lanes/metadata.json b/syntax-primitives/06-nested-lanes/metadata.json deleted file mode 100644 index 6d55a98217c9f25f118333376afd20869d1ec407..0000000000000000000000000000000000000000 --- a/syntax-primitives/06-nested-lanes/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "06-nested-lanes", - "domain": "syntax-primitives", - "complexity": 1, - "num_nodes": 5, - "num_lanes": 3, - "tags": [ - "06", - "nested", - "lanes" - ], - "description": "This workflow models lanes that conceptually contain other lanes." -} \ No newline at end of file diff --git a/syntax-primitives/06-nested-lanes/workflow.fz b/syntax-primitives/06-nested-lanes/workflow.fz deleted file mode 100644 index af9d935745772231eeab198415c886964845254e..0000000000000000000000000000000000000000 --- a/syntax-primitives/06-nested-lanes/workflow.fz +++ /dev/null @@ -1,18 +0,0 @@ -laneA { # Lane A - n1: circle label:"Start 06 Nested Lanes" - n4: rectangle label:"06 Nested Lanes step 4" - - n1.handle(bottom) -> laneB.n2.handle(top) - n4.handle(bottom) -> laneB.n5.handle(top) -} -laneB { # Lane B - n2: rectangle label:"06 Nested Lanes step 2" - n5: circle label:"End 06 Nested Lanes" - - n2.handle(bottom) -> laneC.n3.handle(top) -} -laneC { # Lane C - n3: rectangle label:"06 Nested Lanes step 3" - - n3.handle(bottom) -> laneA.n4.handle(top) -} \ No newline at end of file diff --git a/syntax-primitives/07-unicode-labels/README.md b/syntax-primitives/07-unicode-labels/README.md deleted file mode 100644 index 593aa917a8ed740739be6ff66f83643b46cb10d2..0000000000000000000000000000000000000000 --- a/syntax-primitives/07-unicode-labels/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# 07 Unicode Labels - -This workflow models a workflow with emoji and international characters in labels. - -**Domain:** syntax-primitives -**Complexity:** 1/5 -**Tags:** [07, unicode, labels] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/syntax-primitives/07-unicode-labels/metadata.json b/syntax-primitives/07-unicode-labels/metadata.json deleted file mode 100644 index f08f5d37131f8be322060c263df105aef98b5b35..0000000000000000000000000000000000000000 --- a/syntax-primitives/07-unicode-labels/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "07-unicode-labels", - "domain": "syntax-primitives", - "complexity": 1, - "num_nodes": 5, - "num_lanes": 1, - "tags": [ - "07", - "unicode", - "labels" - ], - "description": "This workflow models a workflow with emoji and international characters in labels." -} \ No newline at end of file diff --git a/syntax-primitives/07-unicode-labels/workflow.fz b/syntax-primitives/07-unicode-labels/workflow.fz deleted file mode 100644 index e96789f9684816a867cb1db32143c94d0f2d0625..0000000000000000000000000000000000000000 --- a/syntax-primitives/07-unicode-labels/workflow.fz +++ /dev/null @@ -1,12 +0,0 @@ -laneA { # Lane A - n1: circle label:"Start 07 Unicode Labels" - n2: rectangle label:"Unicode label 🚀" - n3: rectangle label:"多言語ラベル" - n4: rectangle label:"07 Unicode Labels step 4" - n5: circle label:"End 07 Unicode Labels" - - n1.handle(right) -> n2.handle(left) - n2.handle(right) -> n3.handle(left) - n3.handle(right) -> n4.handle(left) - n4.handle(right) -> n5.handle(left) -} \ No newline at end of file diff --git a/syntax-primitives/08-empty-lane/README.md b/syntax-primitives/08-empty-lane/README.md deleted file mode 100644 index fc0b0cad064149a21367efbd45f1683cc0ac899f..0000000000000000000000000000000000000000 --- a/syntax-primitives/08-empty-lane/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# 08 Empty Lane - -This workflow models a lane with no nodes to test empty-lane handling. - -**Domain:** syntax-primitives -**Complexity:** 1/5 -**Tags:** [08, empty, lane] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/syntax-primitives/08-empty-lane/metadata.json b/syntax-primitives/08-empty-lane/metadata.json deleted file mode 100644 index 9ce6a0ec46e9de9f027e36f37b976cb8d517e80c..0000000000000000000000000000000000000000 --- a/syntax-primitives/08-empty-lane/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "08-empty-lane", - "domain": "syntax-primitives", - "complexity": 1, - "num_nodes": 5, - "num_lanes": 1, - "tags": [ - "08", - "empty", - "lane" - ], - "description": "This workflow models a lane with no nodes to test empty-lane handling." -} \ No newline at end of file diff --git a/syntax-primitives/08-empty-lane/workflow.fz b/syntax-primitives/08-empty-lane/workflow.fz deleted file mode 100644 index 891cfbabcf6fd8a850866b8420af7ef93efc4ecd..0000000000000000000000000000000000000000 --- a/syntax-primitives/08-empty-lane/workflow.fz +++ /dev/null @@ -1,12 +0,0 @@ -laneA { # Lane A - n1: circle label:"Start 08 Empty Lane" - n2: rectangle label:"08 Empty Lane step 2" - n3: rectangle label:"08 Empty Lane step 3" - n4: rectangle label:"08 Empty Lane step 4" - n5: circle label:"End 08 Empty Lane" - - n1.handle(right) -> n2.handle(left) - n2.handle(right) -> n3.handle(left) - n3.handle(right) -> n4.handle(left) - n4.handle(right) -> n5.handle(left) -} \ No newline at end of file diff --git a/syntax-primitives/09-cross-lane-circular/README.md b/syntax-primitives/09-cross-lane-circular/README.md deleted file mode 100644 index 0dbc85baa5cb60e9b1c4e640690c844eb2d5852c..0000000000000000000000000000000000000000 --- a/syntax-primitives/09-cross-lane-circular/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# 09 Cross Lane Circular - -This workflow models an arrow that loops back across lanes in a circular fashion. - -**Domain:** syntax-primitives -**Complexity:** 1/5 -**Tags:** [09, cross, lane, circular] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/syntax-primitives/09-cross-lane-circular/metadata.json b/syntax-primitives/09-cross-lane-circular/metadata.json deleted file mode 100644 index aa74bd42ee58270745ef911c0fb5fad7b0070c8d..0000000000000000000000000000000000000000 --- a/syntax-primitives/09-cross-lane-circular/metadata.json +++ /dev/null @@ -1,14 +0,0 @@ -{ - "workflow_id": "09-cross-lane-circular", - "domain": "syntax-primitives", - "complexity": 1, - "num_nodes": 5, - "num_lanes": 1, - "tags": [ - "09", - "cross", - "lane", - "circular" - ], - "description": "This workflow models an arrow that loops back across lanes in a circular fashion." -} \ No newline at end of file diff --git a/syntax-primitives/09-cross-lane-circular/workflow.fz b/syntax-primitives/09-cross-lane-circular/workflow.fz deleted file mode 100644 index a3ab67343aee0b3ebe4851a0b71f94036d714884..0000000000000000000000000000000000000000 --- a/syntax-primitives/09-cross-lane-circular/workflow.fz +++ /dev/null @@ -1,12 +0,0 @@ -laneA { # Lane A - n1: circle label:"Start 09 Cross Lane Circular" - n2: rectangle label:"09 Cross Lane Circular step 2" - n3: rectangle label:"09 Cross Lane Circular step 3" - n4: rectangle label:"09 Cross Lane Circular step 4" - n5: circle label:"End 09 Cross Lane Circular" - - n1.handle(right) -> n2.handle(left) - n2.handle(right) -> n3.handle(left) - n3.handle(right) -> n4.handle(left) - n4.handle(right) -> n5.handle(left) -} \ No newline at end of file diff --git a/syntax-primitives/10-long-labels/README.md b/syntax-primitives/10-long-labels/README.md deleted file mode 100644 index 3b97a01fe72dd2796e1de278d9acc98a893fa070..0000000000000000000000000000000000000000 --- a/syntax-primitives/10-long-labels/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# 10 Long Labels - -This workflow models labels with extra-long descriptive text. - -**Domain:** syntax-primitives -**Complexity:** 1/5 -**Tags:** [10, long, labels] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/syntax-primitives/10-long-labels/metadata.json b/syntax-primitives/10-long-labels/metadata.json deleted file mode 100644 index e19dd7e26999a7f8164a01ba4a3cf8e3e0e620de..0000000000000000000000000000000000000000 --- a/syntax-primitives/10-long-labels/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "10-long-labels", - "domain": "syntax-primitives", - "complexity": 1, - "num_nodes": 5, - "num_lanes": 1, - "tags": [ - "10", - "long", - "labels" - ], - "description": "This workflow models labels with extra-long descriptive text." -} \ No newline at end of file diff --git a/syntax-primitives/10-long-labels/workflow.fz b/syntax-primitives/10-long-labels/workflow.fz deleted file mode 100644 index 385ac5c4ec59ec8126a6f3bcb4a84a3d3f0a441a..0000000000000000000000000000000000000000 --- a/syntax-primitives/10-long-labels/workflow.fz +++ /dev/null @@ -1,12 +0,0 @@ -laneA { # Lane A - n1: circle label:"Start 10 Long Labels" - n2: rectangle label:"10 Long Labels step 2" - n3: rectangle label:"10 Long Labels step 3" - n4: rectangle label:"10 Long Labels step 4" - n5: circle label:"End 10 Long Labels" - - n1.handle(right) -> n2.handle(left) - n2.handle(right) -> n3.handle(left) - n3.handle(right) -> n4.handle(left) - n4.handle(right) -> n5.handle(left) -} \ No newline at end of file diff --git a/syntax-primitives/11-taskbox-complete/README.md b/syntax-primitives/11-taskbox-complete/README.md deleted file mode 100644 index c5d42c6983697519a44a54fce8ed9b73d24f414f..0000000000000000000000000000000000000000 --- a/syntax-primitives/11-taskbox-complete/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# 11 Taskbox Complete - -This workflow models a taskbox with owner, description, and system parameters. - -**Domain:** syntax-primitives -**Complexity:** 2/5 -**Tags:** [11, taskbox, complete] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/syntax-primitives/11-taskbox-complete/metadata.json b/syntax-primitives/11-taskbox-complete/metadata.json deleted file mode 100644 index 8a9d2b721cfd648da52bc13291526311f3f73c16..0000000000000000000000000000000000000000 --- a/syntax-primitives/11-taskbox-complete/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "11-taskbox-complete", - "domain": "syntax-primitives", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "11", - "taskbox", - "complete" - ], - "description": "This workflow models a taskbox with owner, description, and system parameters." -} \ No newline at end of file diff --git a/syntax-primitives/11-taskbox-complete/workflow.fz b/syntax-primitives/11-taskbox-complete/workflow.fz deleted file mode 100644 index 53a50017dd6a4364ff9b5dba6fba1b7ced437dfc..0000000000000000000000000000000000000000 --- a/syntax-primitives/11-taskbox-complete/workflow.fz +++ /dev/null @@ -1,18 +0,0 @@ -laneA { # Lane A - n1: circle label:"Start 11 Taskbox Complete" - n3: taskbox owner:"" description:"" system:"" - n5: rectangle label:"11 Taskbox Complete step 5" - n7: circle label:"End 11 Taskbox Complete" - n1.handle(bottom) -> laneB.n2.handle(top) - n3.handle(bottom) -> laneB.n4.handle(top) - n5.handle(bottom) -> laneB.n6.handle(top) -} - -laneB { # Lane B - n2: rectangle label:"11 Taskbox Complete step 2" - n4: taskbox owner:"" description:"" system:"" - n6: rectangle label:"11 Taskbox Complete step 6" - n6.handle(right) -> laneA.n7.handle(left) - n4.handle(right) -> laneA.n5.handle(left) - n2.handle(right) -> laneA.n3.handle(left) -} diff --git a/syntax-primitives/12-bidirectional-arrows/README.md b/syntax-primitives/12-bidirectional-arrows/README.md deleted file mode 100644 index c56d22fb2e07e46cfdfc2b86ca5fcb1f94b9ff3f..0000000000000000000000000000000000000000 --- a/syntax-primitives/12-bidirectional-arrows/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# 12 Bidirectional Arrows - -This workflow models two-way connections between the same pair of nodes. - -**Domain:** syntax-primitives -**Complexity:** 2/5 -**Tags:** [12, bidirectional, arrows] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/syntax-primitives/12-bidirectional-arrows/metadata.json b/syntax-primitives/12-bidirectional-arrows/metadata.json deleted file mode 100644 index e6bc3aa350a5084ae93ec43d5c25c2ae7bc5ce43..0000000000000000000000000000000000000000 --- a/syntax-primitives/12-bidirectional-arrows/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "12-bidirectional-arrows", - "domain": "syntax-primitives", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "12", - "bidirectional", - "arrows" - ], - "description": "This workflow models two-way connections between the same pair of nodes." -} \ No newline at end of file diff --git a/syntax-primitives/12-bidirectional-arrows/workflow.fz b/syntax-primitives/12-bidirectional-arrows/workflow.fz deleted file mode 100644 index f2b278d0507e4cc0fce03dacaaa9b46d4b454705..0000000000000000000000000000000000000000 --- a/syntax-primitives/12-bidirectional-arrows/workflow.fz +++ /dev/null @@ -1,18 +0,0 @@ -laneA { # Lane A - n1: circle label:"Start 12 Bidirectional Arrows" - n3: rectangle label:"12 Bidirectional Arrows step 3" - n5: rectangle label:"12 Bidirectional Arrows step 5" - n7: circle label:"End 12 Bidirectional Arrows" - n1.handle(bottom) -> laneB.n2.handle(top) - n3.handle(bottom) -> laneB.n4.handle(top) - n5.handle(bottom) -> laneB.n6.handle(top) -} - -laneB { # Lane B - n2: rectangle label:"12 Bidirectional Arrows step 2" - n4: rectangle label:"12 Bidirectional Arrows step 4" - n6: rectangle label:"12 Bidirectional Arrows step 6" - n2.handle(right) -> laneA.n3.handle(left) - n4.handle(right) -> laneA.n5.handle(left) - n6.handle(right) -> laneA.n7.handle(left) -} diff --git a/syntax-primitives/13-parallel-flows/README.md b/syntax-primitives/13-parallel-flows/README.md deleted file mode 100644 index 519b7f79d2799414caacc82c6cf76915b6118b97..0000000000000000000000000000000000000000 --- a/syntax-primitives/13-parallel-flows/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# 13 Parallel Flows - -This workflow models one node splitting into three parallel tasks. - -**Domain:** syntax-primitives -**Complexity:** 2/5 -**Tags:** [13, parallel, flows] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/syntax-primitives/13-parallel-flows/metadata.json b/syntax-primitives/13-parallel-flows/metadata.json deleted file mode 100644 index f64e71d85149515e99ff289f8d20459d0b3ac8d2..0000000000000000000000000000000000000000 --- a/syntax-primitives/13-parallel-flows/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "13-parallel-flows", - "domain": "syntax-primitives", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "13", - "parallel", - "flows" - ], - "description": "This workflow models one node splitting into three parallel tasks." -} \ No newline at end of file diff --git a/syntax-primitives/13-parallel-flows/workflow.fz b/syntax-primitives/13-parallel-flows/workflow.fz deleted file mode 100644 index e318c02c606c65b9378590ba43767e39b9d0166a..0000000000000000000000000000000000000000 --- a/syntax-primitives/13-parallel-flows/workflow.fz +++ /dev/null @@ -1,22 +0,0 @@ -laneA { # Lane A - n1: circle label:"Start 13 Parallel Flows" - n3: rectangle label:"13 Parallel Flows step 3" - n5: rectangle label:"13 Parallel Flows step 5" - n7: circle label:"End 13 Parallel Flows" - n1.handle(right) -> n3.handle(left) - n3.handle(right) -> n7.handle(left) - n1.handle(right) -> laneB.n4.handle(left) - n1.handle(right) -> n5.handle(left) - n5.handle(right) -> n7.handle(left) - n1.handle(right) -> laneB.n6.handle(left) - n1.handle(bottom) -> laneB.n2.handle(top) -} - -laneB { # Lane B - n2: rectangle label:"13 Parallel Flows step 2" - n4: rectangle label:"13 Parallel Flows step 4" - n6: rectangle label:"13 Parallel Flows step 6" - n2.handle(right) -> laneA.n7.handle(left) - n6.handle(right) -> laneA.n7.handle(bottom) - n4.handle(right) -> laneA.n7.handle(bottom) -} diff --git a/syntax-primitives/14-error-handling/README.md b/syntax-primitives/14-error-handling/README.md deleted file mode 100644 index e9fefcc6530972321b419d1fb75f13aebbd22a69..0000000000000000000000000000000000000000 --- a/syntax-primitives/14-error-handling/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# 14 Error Handling - -This workflow models a try and retry style pattern for handling errors. - -**Domain:** syntax-primitives -**Complexity:** 2/5 -**Tags:** [14, error, handling] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/syntax-primitives/14-error-handling/metadata.json b/syntax-primitives/14-error-handling/metadata.json deleted file mode 100644 index 14027082027a1c05b9ce658fdd337d0b7ad5c966..0000000000000000000000000000000000000000 --- a/syntax-primitives/14-error-handling/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "14-error-handling", - "domain": "syntax-primitives", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "14", - "error", - "handling" - ], - "description": "This workflow models a try and retry style pattern for handling errors." -} \ No newline at end of file diff --git a/syntax-primitives/14-error-handling/workflow.fz b/syntax-primitives/14-error-handling/workflow.fz deleted file mode 100644 index b826eeec5fd66908893f0b577d4ff9e4492bfa91..0000000000000000000000000000000000000000 --- a/syntax-primitives/14-error-handling/workflow.fz +++ /dev/null @@ -1,20 +0,0 @@ -laneA { # Lane A - n1: circle label:"Start 14 Error Handling" - n3: rectangle label:"14 Error Handling step 3" - n5: rectangle label:"14 Error Handling step 5" - n7: circle label:"End 14 Error Handling" - n1.handle(bottom) -> laneB.n2.handle(top) - n3.handle(bottom) -> laneB.n4.handle(top) - n5.handle(bottom) -> laneB.n6.handle(top) -} - -laneB { # Lane B - n2: rectangle label:"14 Error Handling step 2" - n4: rectangle label:"14 Error Handling step 4" - n6: rectangle label:"14 Error Handling step 6" - n2.handle(right) -> laneA.n3.handle(left) - n4.handle(right) -> laneA.n5.handle(left) - n6.handle(right) -> laneA.n7.handle(left) -} - -} \ No newline at end of file diff --git a/syntax-primitives/15-optional-parameters/README.md b/syntax-primitives/15-optional-parameters/README.md deleted file mode 100644 index d78258690d24d6290d9bd98da53684ec0883f690..0000000000000000000000000000000000000000 --- a/syntax-primitives/15-optional-parameters/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# 15 Optional Parameters - -This workflow models a taskbox with some optional fields left out. - -**Domain:** syntax-primitives -**Complexity:** 2/5 -**Tags:** [15, optional, parameters] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/syntax-primitives/15-optional-parameters/metadata.json b/syntax-primitives/15-optional-parameters/metadata.json deleted file mode 100644 index 84f8aa7b8b75a6f33d2a1f555e1aae5d5366f6e4..0000000000000000000000000000000000000000 --- a/syntax-primitives/15-optional-parameters/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "15-optional-parameters", - "domain": "syntax-primitives", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "15", - "optional", - "parameters" - ], - "description": "This workflow models a taskbox with some optional fields left out." -} \ No newline at end of file diff --git a/syntax-primitives/15-optional-parameters/workflow.fz b/syntax-primitives/15-optional-parameters/workflow.fz deleted file mode 100644 index d166a03e5773fd8315c52cf35eee37c1089d2861..0000000000000000000000000000000000000000 --- a/syntax-primitives/15-optional-parameters/workflow.fz +++ /dev/null @@ -1,18 +0,0 @@ -laneA { # Lane A - n1: circle label:"Start 15 Optional Parameters" - n3: rectangle label:"15 Optional Parameters step 3" - n5: rectangle label:"15 Optional Parameters step 5" - n7: circle label:"End 15 Optional Parameters" - n1.handle(bottom) -> laneB.n2.handle(top) - n3.handle(bottom) -> laneB.n4.handle(top) - n5.handle(bottom) -> laneB.n6.handle(top) -} - -laneB { # Lane B - n2: rectangle label:"15 Optional Parameters step 2" - n4: rectangle label:"15 Optional Parameters step 4" - n6: rectangle label:"15 Optional Parameters step 6" - n2.handle(right) -> laneA.n3.handle(left) - n4.handle(right) -> laneA.n5.handle(left) - n6.handle(right) -> laneA.n7.handle(left) -} diff --git a/syntax-primitives/16-max-nodes/README.md b/syntax-primitives/16-max-nodes/README.md deleted file mode 100644 index 0246bcbec5d6d3e898e571822803bd5ae6fb89bb..0000000000000000000000000000000000000000 --- a/syntax-primitives/16-max-nodes/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# 16 Max Nodes - -This workflow models 50 nodes in one lane as a stress test. - -**Domain:** syntax-primitives -**Complexity:** 2/5 -**Tags:** [16, max, nodes] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/syntax-primitives/16-max-nodes/metadata.json b/syntax-primitives/16-max-nodes/metadata.json deleted file mode 100644 index e1fe54d6c39a48105669595c93beee2aa91a8a71..0000000000000000000000000000000000000000 --- a/syntax-primitives/16-max-nodes/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "16-max-nodes", - "domain": "syntax-primitives", - "complexity": 2, - "num_nodes": 50, - "num_lanes": 2, - "tags": [ - "16", - "max", - "nodes" - ], - "description": "This workflow models 50 nodes in one lane as a stress test." -} \ No newline at end of file diff --git a/syntax-primitives/16-max-nodes/workflow.fz b/syntax-primitives/16-max-nodes/workflow.fz deleted file mode 100644 index 23770289943742ec87d84982ebd68131c9a43868..0000000000000000000000000000000000000000 --- a/syntax-primitives/16-max-nodes/workflow.fz +++ /dev/null @@ -1,104 +0,0 @@ -laneA { # Lane A - n1: circle label:"Start 16 Max Nodes" - n3: rectangle label:"16 Max Nodes step 3" - n5: rectangle label:"16 Max Nodes step 5" - n7: rectangle label:"16 Max Nodes step 7" - n9: rectangle label:"16 Max Nodes step 9" - n11: rectangle label:"16 Max Nodes step 11" - n13: rectangle label:"16 Max Nodes step 13" - n15: rectangle label:"16 Max Nodes step 15" - n17: rectangle label:"16 Max Nodes step 17" - n19: rectangle label:"16 Max Nodes step 19" - n21: rectangle label:"16 Max Nodes step 21" - n23: rectangle label:"16 Max Nodes step 23" - n25: rectangle label:"16 Max Nodes step 25" - n27: rectangle label:"16 Max Nodes step 27" - n29: rectangle label:"16 Max Nodes step 29" - n31: rectangle label:"16 Max Nodes step 31" - n33: rectangle label:"16 Max Nodes step 33" - n35: rectangle label:"16 Max Nodes step 35" - n37: rectangle label:"16 Max Nodes step 37" - n39: rectangle label:"16 Max Nodes step 39" - n41: rectangle label:"16 Max Nodes step 41" - n43: rectangle label:"16 Max Nodes step 43" - n45: rectangle label:"16 Max Nodes step 45" - n47: rectangle label:"16 Max Nodes step 47" - n49: rectangle label:"16 Max Nodes step 49" - n1.handle(bottom) -> laneB.n2.handle(top) - n3.handle(bottom) -> laneB.n4.handle(top) - n5.handle(bottom) -> laneB.n6.handle(top) - n7.handle(bottom) -> laneB.n8.handle(top) - n9.handle(bottom) -> laneB.n10.handle(top) - n11.handle(bottom) -> laneB.n12.handle(top) - n13.handle(bottom) -> laneB.n14.handle(top) - n15.handle(bottom) -> laneB.n16.handle(top) - n17.handle(bottom) -> laneB.n18.handle(top) - n19.handle(bottom) -> laneB.n20.handle(top) - n21.handle(bottom) -> laneB.n22.handle(top) - n23.handle(bottom) -> laneB.n24.handle(top) - n25.handle(bottom) -> laneB.n26.handle(top) - n27.handle(bottom) -> laneB.n28.handle(top) - n29.handle(bottom) -> laneB.n30.handle(top) - n31.handle(bottom) -> laneB.n32.handle(top) - n33.handle(bottom) -> laneB.n34.handle(top) - n35.handle(bottom) -> laneB.n36.handle(top) - n37.handle(bottom) -> laneB.n38.handle(top) - n39.handle(bottom) -> laneB.n40.handle(top) - n41.handle(bottom) -> laneB.n42.handle(top) - n43.handle(bottom) -> laneB.n44.handle(top) - n45.handle(bottom) -> laneB.n46.handle(top) - n47.handle(bottom) -> laneB.n48.handle(top) - n49.handle(bottom) -> laneB.n50.handle(top) -} - -laneB { # Lane B - n2: rectangle label:"16 Max Nodes step 2" - n4: rectangle label:"16 Max Nodes step 4" - n6: rectangle label:"16 Max Nodes step 6" - n8: rectangle label:"16 Max Nodes step 8" - n10: rectangle label:"16 Max Nodes step 10" - n12: rectangle label:"16 Max Nodes step 12" - n14: rectangle label:"16 Max Nodes step 14" - n16: rectangle label:"16 Max Nodes step 16" - n18: rectangle label:"16 Max Nodes step 18" - n20: rectangle label:"16 Max Nodes step 20" - n22: rectangle label:"16 Max Nodes step 22" - n24: rectangle label:"16 Max Nodes step 24" - n26: rectangle label:"16 Max Nodes step 26" - n28: rectangle label:"16 Max Nodes step 28" - n30: rectangle label:"16 Max Nodes step 30" - n32: rectangle label:"16 Max Nodes step 32" - n34: rectangle label:"16 Max Nodes step 34" - n36: rectangle label:"16 Max Nodes step 36" - n38: rectangle label:"16 Max Nodes step 38" - n40: rectangle label:"16 Max Nodes step 40" - n42: rectangle label:"16 Max Nodes step 42" - n44: rectangle label:"16 Max Nodes step 44" - n46: rectangle label:"16 Max Nodes step 46" - n48: rectangle label:"16 Max Nodes step 48" - n50: circle label:"End 16 Max Nodes" - n2.handle(right) -> laneA.n3.handle(left) - n4.handle(right) -> laneA.n5.handle(left) - n6.handle(right) -> laneA.n7.handle(left) - n8.handle(right) -> laneA.n9.handle(left) - n10.handle(right) -> laneA.n11.handle(left) - n12.handle(right) -> laneA.n13.handle(left) - n14.handle(right) -> laneA.n15.handle(left) - n16.handle(right) -> laneA.n17.handle(left) - n18.handle(right) -> laneA.n19.handle(left) - n20.handle(right) -> laneA.n21.handle(left) - n22.handle(right) -> laneA.n23.handle(left) - n24.handle(right) -> laneA.n25.handle(left) - n26.handle(right) -> laneA.n27.handle(left) - n28.handle(right) -> laneA.n29.handle(left) - n30.handle(right) -> laneA.n31.handle(left) - n32.handle(right) -> laneA.n33.handle(left) - n34.handle(right) -> laneA.n35.handle(left) - n36.handle(right) -> laneA.n37.handle(left) - n38.handle(right) -> laneA.n39.handle(left) - n40.handle(right) -> laneA.n41.handle(left) - n42.handle(right) -> laneA.n43.handle(left) - n44.handle(right) -> laneA.n45.handle(left) - n46.handle(right) -> laneA.n47.handle(left) - n48.handle(right) -> laneA.n49.handle(left) -} diff --git a/syntax-primitives/17-minimal-nodes/README.md b/syntax-primitives/17-minimal-nodes/README.md deleted file mode 100644 index fc10f605997389413416015aaa7dddbf408b6214..0000000000000000000000000000000000000000 --- a/syntax-primitives/17-minimal-nodes/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# 17 Minimal Nodes - -This workflow models a workflow with a single start node only. - -**Domain:** syntax-primitives -**Complexity:** 2/5 -**Tags:** [17, minimal, nodes] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/syntax-primitives/17-minimal-nodes/metadata.json b/syntax-primitives/17-minimal-nodes/metadata.json deleted file mode 100644 index c610824bfd5460ec2ca3946602453342b2f973e1..0000000000000000000000000000000000000000 --- a/syntax-primitives/17-minimal-nodes/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "17-minimal-nodes", - "domain": "syntax-primitives", - "complexity": 2, - "num_nodes": 1, - "num_lanes": 1, - "tags": [ - "17", - "minimal", - "nodes" - ], - "description": "This workflow models a workflow with a single start node only." -} \ No newline at end of file diff --git a/syntax-primitives/17-minimal-nodes/workflow.fz b/syntax-primitives/17-minimal-nodes/workflow.fz deleted file mode 100644 index 22925c4f062ab2396fd72160e48f22a54d31c16c..0000000000000000000000000000000000000000 --- a/syntax-primitives/17-minimal-nodes/workflow.fz +++ /dev/null @@ -1,3 +0,0 @@ -laneA { # Lane A - n1: circle label:"Start 17 Minimal Nodes" -} \ No newline at end of file diff --git a/syntax-primitives/18-complex-handles/README.md b/syntax-primitives/18-complex-handles/README.md deleted file mode 100644 index 48fc5c9f95f11898d064ae1c91b8f364beec35b5..0000000000000000000000000000000000000000 --- a/syntax-primitives/18-complex-handles/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# 18 Complex Handles - -This workflow models a workflow that uses every handle position in one diagram. - -**Domain:** syntax-primitives -**Complexity:** 2/5 -**Tags:** [18, complex, handles] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/syntax-primitives/18-complex-handles/metadata.json b/syntax-primitives/18-complex-handles/metadata.json deleted file mode 100644 index cf05309cc597b1c4aed4f14d0846530b5824c3ff..0000000000000000000000000000000000000000 --- a/syntax-primitives/18-complex-handles/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "18-complex-handles", - "domain": "syntax-primitives", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "18", - "complex", - "handles" - ], - "description": "This workflow models a workflow that uses every handle position in one diagram." -} \ No newline at end of file diff --git a/syntax-primitives/18-complex-handles/workflow.fz b/syntax-primitives/18-complex-handles/workflow.fz deleted file mode 100644 index 0184b2fa5dc8bb3759a3ac479dc01fad9dde6db7..0000000000000000000000000000000000000000 --- a/syntax-primitives/18-complex-handles/workflow.fz +++ /dev/null @@ -1,18 +0,0 @@ -laneA { # Lane A - n1: circle label:"Start 18 Complex Handles" - n3: rectangle label:"18 Complex Handles step 3" - n5: rectangle label:"18 Complex Handles step 5" - n7: circle label:"End 18 Complex Handles" - n1.handle(bottom) -> laneB.n2.handle(top) - n3.handle(bottom) -> laneB.n4.handle(top) - n5.handle(bottom) -> laneB.n6.handle(top) -} - -laneB { # Lane B - n2: rectangle label:"18 Complex Handles step 2" - n4: rectangle label:"18 Complex Handles step 4" - n6: rectangle label:"18 Complex Handles step 6" - n2.handle(right) -> laneA.n3.handle(left) - n4.handle(right) -> laneA.n5.handle(left) - n6.handle(right) -> laneA.n7.handle(left) -} diff --git a/syntax-primitives/19-label-escaping/README.md b/syntax-primitives/19-label-escaping/README.md deleted file mode 100644 index ef3f2cfc338dc785e71edae26ce6c21e0655ea50..0000000000000000000000000000000000000000 --- a/syntax-primitives/19-label-escaping/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# 19 Label Escaping - -This workflow models labels that include quotes and special characters. - -**Domain:** syntax-primitives -**Complexity:** 2/5 -**Tags:** [19, label, escaping] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/syntax-primitives/19-label-escaping/metadata.json b/syntax-primitives/19-label-escaping/metadata.json deleted file mode 100644 index bbf8b41fccda4c24ed5bb5ac50c3af9cc92fc4fc..0000000000000000000000000000000000000000 --- a/syntax-primitives/19-label-escaping/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "19-label-escaping", - "domain": "syntax-primitives", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 2, - "tags": [ - "19", - "label", - "escaping" - ], - "description": "This workflow models labels that include quotes and special characters." -} \ No newline at end of file diff --git a/syntax-primitives/19-label-escaping/workflow.fz b/syntax-primitives/19-label-escaping/workflow.fz deleted file mode 100644 index c8dae4819435c96d723a7ef4b73757b4204e45c8..0000000000000000000000000000000000000000 --- a/syntax-primitives/19-label-escaping/workflow.fz +++ /dev/null @@ -1,18 +0,0 @@ -laneA { # Lane A - n1: circle label:"Start 19 Label Escaping" - n3: rectangle label:"19 Label Escaping step 3" - n5: rectangle label:"19 Label Escaping step 5" - n7: circle label:"End 19 Label Escaping" - n1.handle(bottom) -> laneB.n2.handle(top) - n3.handle(bottom) -> laneB.n4.handle(top) - n5.handle(bottom) -> laneB.n6.handle(top) -} - -laneB { # Lane B - n2: rectangle label:"19 Label Escaping step 2" - n4: rectangle label:"19 Label Escaping step 4" - n6: rectangle label:"19 Label Escaping step 6" - n2.handle(right) -> laneA.n3.handle(left) - n4.handle(right) -> laneA.n5.handle(left) - n6.handle(right) -> laneA.n7.handle(left) -} diff --git a/syntax-primitives/20-syntax-complete/README.md b/syntax-primitives/20-syntax-complete/README.md deleted file mode 100644 index 57248ab02c6a30ac5de2ceaf2c52e47bcc13d673..0000000000000000000000000000000000000000 --- a/syntax-primitives/20-syntax-complete/README.md +++ /dev/null @@ -1,12 +0,0 @@ -# 20 Syntax Complete - -This workflow models one workflow using most available language features. - -**Domain:** syntax-primitives -**Complexity:** 2/5 -**Tags:** [20, syntax, complete] - -## Process Flow -1. Start the process -2. Perform the key steps -3. Complete and record the outcome diff --git a/syntax-primitives/20-syntax-complete/metadata.json b/syntax-primitives/20-syntax-complete/metadata.json deleted file mode 100644 index 725ac19486b3c1cbe41b5c507b69ba50161cfb3f..0000000000000000000000000000000000000000 --- a/syntax-primitives/20-syntax-complete/metadata.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "workflow_id": "20-syntax-complete", - "domain": "syntax-primitives", - "complexity": 2, - "num_nodes": 7, - "num_lanes": 3, - "tags": [ - "20", - "syntax", - "complete" - ], - "description": "This workflow models one workflow using most available language features." -} \ No newline at end of file diff --git a/syntax-primitives/20-syntax-complete/workflow.fz b/syntax-primitives/20-syntax-complete/workflow.fz deleted file mode 100644 index 610fb36445ee0577b4c727fafc7dc34521f16dda..0000000000000000000000000000000000000000 --- a/syntax-primitives/20-syntax-complete/workflow.fz +++ /dev/null @@ -1,21 +0,0 @@ -laneA { # Lane A - n1: circle label:"Start 20 Syntax Complete" - n4: rectangle label:"20 Syntax Complete step 4" - n7: circle label:"End 20 Syntax Complete" - n1.handle(bottom) -> laneB.n2.handle(top) - n4.handle(bottom) -> laneB.n5.handle(top) -} - -laneB { # Lane B - n2: rectangle label:"20 Syntax Complete step 2" - n5: rectangle label:"20 Syntax Complete step 5" - n2.handle(bottom) -> laneC.n3.handle(top) - n5.handle(bottom) -> laneC.n6.handle(top) -} - -laneC { # Lane C - n3: rectangle label:"20 Syntax Complete step 3" - n6: rectangle label:"20 Syntax Complete step 6" - n3.handle(right) -> laneA.n4.handle(left) - n6.handle(right) -> laneA.n7.handle(left) -} diff --git a/templates.index.json b/templates.index.json new file mode 100644 index 0000000000000000000000000000000000000000..5bdc85fd01f68d19397175e6e076e389834ec1e9 --- /dev/null +++ b/templates.index.json @@ -0,0 +1,6050 @@ +{ + "templates": [ + { + "slug": "a-b-testing-workflow", + "title": "A B Testing Workflow", + "description": "This workflow models comparing two versions to see which performs better.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "a", + "b", + "testing", + "patterns" + ], + "sourcePath": "patterns/a-b-testing", + "repoPath": "uncategorized/patterns/a-b-testing-workflow" + }, + { + "slug": "ab-test-setup-workflow", + "title": "Ab Test Setup Workflow", + "description": "A/B test setup workflow with hypothesis definition, variant creation, traffic allocation, statistical analysis, and winner deployment.", + "kind": "workflow", + "sourceDomain": "business-operations", + "primaryUseCase": "onboarding", + "secondaryUseCases": [], + "useCases": [ + "onboarding" + ], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "ab-testing", + "experimentation", + "split-testing", + "statistical-significance", + "conversion-optimization", + "optimizely" + ], + "sourcePath": "business-operations/ab-test-setup", + "repoPath": "onboarding/business-operations/ab-test-setup-workflow" + }, + { + "slug": "access-review-workflow", + "title": "Access Review Workflow", + "description": "Quarterly user access review workflow with manager certification, separation of duties validation, remediation tracking, and compliance reporting for audit purposes.", + "kind": "workflow", + "sourceDomain": "devops", + "primaryUseCase": "approval", + "secondaryUseCases": [ + "compliance" + ], + "useCases": [ + "approval", + "compliance" + ], + "complexity": 4, + "numNodes": 18, + "numLanes": 3, + "tags": [ + "access-review", + "user-access-certification", + "quarterly-review", + "manager-approval", + "compliance", + "sod-violations", + "audit" + ], + "sourcePath": "devops/access-review", + "repoPath": "approval/devops/access-review-workflow" + }, + { + "slug": "account-deletion-workflow", + "title": "Account Deletion Workflow", + "description": "Account deletion workflow with cancellation reason capture, retention offer, subscription termination, data cleanup, and confirmation email.", + "kind": "workflow", + "sourceDomain": "business-operations", + "primaryUseCase": "offboarding", + "secondaryUseCases": [ + "billing" + ], + "useCases": [ + "offboarding", + "billing" + ], + "complexity": 3, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "account-deletion", + "user-offboarding", + "data-cleanup", + "subscription-cancel", + "retention-offer", + "exit-survey" + ], + "sourcePath": "business-operations/account-deletion", + "repoPath": "offboarding/business-operations/account-deletion-workflow" + }, + { + "slug": "api-gateway-workflow", + "title": "Api Gateway Workflow", + "description": "API Gateway pattern with request authentication, rate limiting, request routing to backend services, response aggregation, and error handling.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "handoff", + "secondaryUseCases": [ + "security", + "mcp" + ], + "useCases": [ + "handoff", + "security", + "mcp" + ], + "complexity": 3, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "api-gateway", + "microservices", + "rate-limiting", + "request-routing", + "authentication", + "load-balancing" + ], + "sourcePath": "patterns/api-gateway", + "repoPath": "handoff/patterns/api-gateway-workflow" + }, + { + "slug": "api-key-rotation-workflow", + "title": "Api Key Rotation Workflow", + "description": "API key rotation workflow with new key generation, dual-key transition period, client notification, old key deprecation, and audit logging.", + "kind": "workflow", + "sourceDomain": "business-operations", + "primaryUseCase": "security", + "secondaryUseCases": [ + "compliance" + ], + "useCases": [ + "security", + "compliance" + ], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "api-key-rotation", + "security", + "credential-management", + "zero-downtime", + "secrets-manager", + "compliance" + ], + "sourcePath": "business-operations/api-key-rotation", + "repoPath": "security/business-operations/api-key-rotation-workflow" + }, + { + "slug": "audit-trail-workflow", + "title": "Audit Trail Workflow", + "description": "This workflow models logging all important actions for compliance.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "compliance", + "secondaryUseCases": [], + "useCases": [ + "compliance" + ], + "complexity": 4, + "numNodes": 13, + "numLanes": 4, + "tags": [ + "audit", + "trail", + "patterns", + "decision", + "loop" + ], + "sourcePath": "patterns/audit-trail", + "repoPath": "compliance/patterns/audit-trail-workflow" + }, + { + "slug": "authentication-flow-workflow", + "title": "Authentication Flow Workflow", + "description": "User authentication workflow with credential validation, MFA challenge, JWT token generation, session creation, and failed attempt tracking.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "security", + "secondaryUseCases": [], + "useCases": [ + "security" + ], + "complexity": 3, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "authentication", + "login", + "jwt", + "oauth", + "mfa", + "session-management" + ], + "sourcePath": "patterns/authentication-flow", + "repoPath": "security/patterns/authentication-flow-workflow" + }, + { + "slug": "authorization-flow-workflow", + "title": "Authorization Flow Workflow", + "description": "This workflow models checking user permissions before actions run.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "approval", + "secondaryUseCases": [ + "security" + ], + "useCases": [ + "approval", + "security" + ], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "authorization", + "flow", + "patterns" + ], + "sourcePath": "patterns/authorization-flow", + "repoPath": "approval/patterns/authorization-flow-workflow" + }, + { + "slug": "background-check-workflow", + "title": "Background Check Workflow", + "description": "Pre-employment background check workflow with criminal history search, employment verification, education verification, and drug screening coordination.", + "kind": "workflow", + "sourceDomain": "hr", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "background-check", + "pre-employment", + "criminal-history", + "employment-verification", + "education-verification", + "drug-screening" + ], + "sourcePath": "hr/background-check", + "repoPath": "uncategorized/hr/background-check-workflow" + }, + { + "slug": "backup-restore-workflow", + "title": "Backup Restore Workflow", + "description": "Backup and restore workflow with scheduled backups, offsite replication, retention policy enforcement, restore testing, and RTO/RPO validation.", + "kind": "workflow", + "sourceDomain": "devops", + "primaryUseCase": "delivery", + "secondaryUseCases": [], + "useCases": [ + "delivery" + ], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "backup-restore", + "disaster-recovery", + "rpo-rto", + "snapshot", + "data-protection", + "recovery-testing" + ], + "sourcePath": "devops/backup-restore", + "repoPath": "delivery/devops/backup-restore-workflow" + }, + { + "slug": "bank-reconciliation-workflow", + "title": "Bank Reconciliation Workflow", + "description": "Bank reconciliation workflow with automated transaction matching, variance reporting, discrepancy research, and journal entry creation for timing differences and bank errors.", + "kind": "workflow", + "sourceDomain": "finance", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 18, + "numLanes": 3, + "tags": [ + "bank-reconciliation", + "gl-matching", + "variance-analysis", + "journal-entries", + "auto-matching", + "discrepancy-resolution" + ], + "sourcePath": "finance/bank-reconciliation", + "repoPath": "uncategorized/finance/bank-reconciliation-workflow" + }, + { + "slug": "batch-processing-workflow", + "title": "Batch Processing Workflow", + "description": "Batch processing pattern with job scheduling, chunk-based processing, checkpoint/restart capability, error handling, and completion reporting.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "batch-processing", + "scheduled-jobs", + "bulk-operations", + "etl", + "chunk-processing", + "job-scheduler" + ], + "sourcePath": "patterns/batch-processing", + "repoPath": "uncategorized/patterns/batch-processing-workflow" + }, + { + "slug": "billing-dispute-workflow", + "title": "Billing Dispute Workflow", + "description": "Billing dispute workflow with dispute intake, transaction review, fraud analysis, resolution decision, and chargeback response handling.", + "kind": "workflow", + "sourceDomain": "business-operations", + "primaryUseCase": "approval", + "secondaryUseCases": [ + "billing" + ], + "useCases": [ + "approval", + "billing" + ], + "complexity": 4, + "numNodes": 13, + "numLanes": 4, + "tags": [ + "billing-dispute", + "chargeback", + "refund-request", + "dispute-resolution", + "fraud-review", + "stripe" + ], + "sourcePath": "business-operations/billing-dispute", + "repoPath": "approval/business-operations/billing-dispute-workflow" + }, + { + "slug": "blue-green-deploy-workflow", + "title": "Blue Green Deploy Workflow", + "description": "Blue-green deployment pattern with parallel environment setup, smoke testing, load balancer traffic switch, and instant rollback capability.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "delivery", + "secondaryUseCases": [], + "useCases": [ + "delivery" + ], + "complexity": 4, + "numNodes": 13, + "numLanes": 4, + "tags": [ + "blue-green-deployment", + "zero-downtime", + "traffic-switching", + "rollback", + "load-balancer", + "release-management" + ], + "sourcePath": "patterns/blue-green-deploy", + "repoPath": "delivery/patterns/blue-green-deploy-workflow" + }, + { + "slug": "bonus-allocation-workflow", + "title": "Bonus Allocation Workflow", + "description": "Annual bonus allocation workflow with budget pool distribution, performance-based calculation, manager calibration, executive approval, and payroll processing.", + "kind": "workflow", + "sourceDomain": "hr", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "bonus-allocation", + "annual-bonus", + "performance-bonus", + "budget-pool", + "calibration", + "payout" + ], + "sourcePath": "hr/bonus-allocation", + "repoPath": "uncategorized/hr/bonus-allocation-workflow" + }, + { + "slug": "budget-approval-workflow", + "title": "Budget Approval Workflow", + "description": "Corporate budget approval workflow with tiered approval routing based on amount thresholds (CFO < $100K, CEO $100K-$1M, Board > $1M), prior year comparison, and fund allocation.", + "kind": "workflow", + "sourceDomain": "finance", + "primaryUseCase": "approval", + "secondaryUseCases": [], + "useCases": [ + "approval" + ], + "complexity": 4, + "numNodes": 19, + "numLanes": 3, + "tags": [ + "budget-approval", + "financial-planning", + "tiered-approval", + "cfo-approval", + "ceo-approval", + "board-approval", + "fund-allocation" + ], + "sourcePath": "finance/budget-approval", + "repoPath": "approval/finance/budget-approval-workflow" + }, + { + "slug": "cache-aside-workflow", + "title": "Cache Aside Workflow", + "description": "Cache-aside pattern with cache lookup, database fallback on miss, cache population, TTL-based expiration, and write-through invalidation.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "cache-aside", + "lazy-loading", + "cache-miss", + "cache-invalidation", + "redis", + "performance" + ], + "sourcePath": "patterns/cache-aside", + "repoPath": "uncategorized/patterns/cache-aside-workflow" + }, + { + "slug": "callback-pattern-workflow", + "title": "Callback Pattern Workflow", + "description": "This workflow models an async operation that notifies a callback when done.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "callback", + "pattern", + "patterns", + "decision", + "loop" + ], + "sourcePath": "patterns/callback-pattern", + "repoPath": "uncategorized/patterns/callback-pattern-workflow" + }, + { + "slug": "canary-deploy-workflow", + "title": "Canary Deploy Workflow", + "description": "Canary deployment pattern with gradual traffic shifting, real-time metrics monitoring, automatic rollback triggers, and progressive rollout to full production.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "incident", + "secondaryUseCases": [ + "delivery" + ], + "useCases": [ + "incident", + "delivery" + ], + "complexity": 3, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "canary-deployment", + "progressive-rollout", + "traffic-splitting", + "metrics-monitoring", + "gradual-release", + "feature-flags" + ], + "sourcePath": "patterns/canary-deploy", + "repoPath": "incident/patterns/canary-deploy-workflow" + }, + { + "slug": "candidate-rejection-workflow", + "title": "Candidate Rejection Workflow", + "description": "Candidate rejection workflow with stage-appropriate messaging, personalized rejection letters, talent pool consideration, ATS status update, and candidate experience feedback.", + "kind": "workflow", + "sourceDomain": "hr", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "candidate-rejection", + "hiring-decision", + "rejection-letter", + "talent-pool", + "candidate-experience", + "ats-update" + ], + "sourcePath": "hr/candidate-rejection", + "repoPath": "uncategorized/hr/candidate-rejection-workflow" + }, + { + "slug": "carrier-selection-workflow", + "title": "Carrier Selection Workflow", + "description": "Carrier selection workflow with rate shopping, transit time comparison, service level matching, carrier performance scoring, and optimal carrier assignment.", + "kind": "workflow", + "sourceDomain": "logistics", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "carrier-selection", + "rate-shopping", + "transit-time", + "service-level", + "tms", + "freight-optimization" + ], + "sourcePath": "logistics/carrier-selection", + "repoPath": "uncategorized/logistics/carrier-selection-workflow" + }, + { + "slug": "cash-flow-forecast-workflow", + "title": "Cash Flow Forecast Workflow", + "description": "Cash flow forecasting workflow with AR/AP projections, working capital analysis, liquidity gap identification, and short-term financing recommendations.", + "kind": "workflow", + "sourceDomain": "finance", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "cash-flow-forecast", + "liquidity-planning", + "working-capital", + "ar-collections", + "ap-disbursements", + "treasury" + ], + "sourcePath": "finance/cash-flow-forecast", + "repoPath": "uncategorized/finance/cash-flow-forecast-workflow" + }, + { + "slug": "certificate-renewal-workflow", + "title": "Certificate Renewal Workflow", + "description": "SSL/TLS certificate renewal workflow with expiration monitoring, certificate request by type (DV/OV/EV), domain validation, deployment to load balancers, and health check verification with rollback.", + "kind": "workflow", + "sourceDomain": "devops", + "primaryUseCase": "security", + "secondaryUseCases": [], + "useCases": [ + "security" + ], + "complexity": 4, + "numNodes": 19, + "numLanes": 3, + "tags": [ + "ssl-certificate", + "tls-renewal", + "lets-encrypt", + "certificate-authority", + "domain-validation", + "load-balancer", + "health-check" + ], + "sourcePath": "devops/certificate-renewal", + "repoPath": "security/devops/certificate-renewal-workflow" + }, + { + "slug": "chaos-engineering-workflow", + "title": "Chaos Engineering Workflow", + "description": "Chaos engineering workflow with hypothesis definition, steady-state monitoring, controlled fault injection, blast radius limitation, and resilience validation.", + "kind": "workflow", + "sourceDomain": "devops", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 13, + "numLanes": 4, + "tags": [ + "chaos-engineering", + "fault-injection", + "resilience-testing", + "game-day", + "blast-radius", + "steady-state" + ], + "sourcePath": "devops/chaos-engineering", + "repoPath": "uncategorized/devops/chaos-engineering-workflow" + }, + { + "slug": "ci-cd-pipeline-workflow", + "title": "Ci Cd Pipeline Workflow", + "description": "Full CI/CD pipeline with code checkout, linting, unit tests, artifact building, staging deployment, smoke tests, production deployment, and automatic rollback on failure.", + "kind": "workflow", + "sourceDomain": "devops", + "primaryUseCase": "delivery", + "secondaryUseCases": [], + "useCases": [ + "delivery" + ], + "complexity": 4, + "numNodes": 22, + "numLanes": 3, + "tags": [ + "ci-cd", + "continuous-integration", + "continuous-deployment", + "github-actions", + "artifact-registry", + "staging", + "production", + "rollback" + ], + "sourcePath": "devops/ci-cd-pipeline", + "repoPath": "delivery/devops/ci-cd-pipeline-workflow" + }, + { + "slug": "circuit-breaker-workflow", + "title": "Circuit Breaker Workflow", + "description": "Circuit breaker resilience pattern with closed, open, and half-open states for protecting services from cascading failures with automatic recovery testing.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "mcp", + "secondaryUseCases": [], + "useCases": [ + "mcp" + ], + "complexity": 4, + "numNodes": 19, + "numLanes": 3, + "tags": [ + "circuit-breaker", + "resilience", + "fault-tolerance", + "microservices", + "hystrix", + "half-open", + "fallback" + ], + "sourcePath": "patterns/circuit-breaker", + "repoPath": "mcp/patterns/circuit-breaker-workflow" + }, + { + "slug": "claim-check-workflow", + "title": "Claim Check Workflow", + "description": "This workflow models keeping large payloads external and only passing references.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 2, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "claim", + "check", + "patterns" + ], + "sourcePath": "patterns/claim-check", + "repoPath": "uncategorized/patterns/claim-check-workflow" + }, + { + "slug": "cohort-analysis-workflow", + "title": "Cohort Analysis Workflow", + "description": "Cohort analysis workflow with user segmentation by signup date, retention curve calculation, LTV projection, and behavioral pattern identification.", + "kind": "workflow", + "sourceDomain": "business-operations", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 13, + "numLanes": 4, + "tags": [ + "cohort-analysis", + "retention-analysis", + "user-behavior", + "ltv", + "churn-prediction", + "analytics" + ], + "sourcePath": "business-operations/cohort-analysis", + "repoPath": "uncategorized/business-operations/cohort-analysis-workflow" + }, + { + "slug": "cold-chain-monitoring-workflow", + "title": "Cold Chain Monitoring Workflow", + "description": "Cold chain monitoring workflow with IoT temperature sensors, real-time alerts, excursion documentation, corrective action triggers, and compliance reporting.", + "kind": "workflow", + "sourceDomain": "logistics", + "primaryUseCase": "incident", + "secondaryUseCases": [], + "useCases": [ + "incident" + ], + "complexity": 3, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "cold-chain", + "temperature-monitoring", + "iot-sensors", + "excursion-alert", + "pharmaceutical", + "perishables" + ], + "sourcePath": "logistics/cold-chain-monitoring", + "repoPath": "incident/logistics/cold-chain-monitoring-workflow" + }, + { + "slug": "community-moderation-workflow", + "title": "Community Moderation Workflow", + "description": "Community content moderation workflow with AI auto-flagging, user reports, human review queue, action enforcement, and appeals handling.", + "kind": "workflow", + "sourceDomain": "business-operations", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "community-moderation", + "content-moderation", + "user-reports", + "trust-safety", + "ai-moderation", + "appeals" + ], + "sourcePath": "business-operations/community-moderation", + "repoPath": "uncategorized/business-operations/community-moderation-workflow" + }, + { + "slug": "compensation-transaction-workflow", + "title": "Compensation Transaction Workflow", + "description": "This workflow models rolling back work when a later step fails.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 2, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "compensation", + "transaction", + "patterns", + "decision", + "loop" + ], + "sourcePath": "patterns/compensation-transaction", + "repoPath": "uncategorized/patterns/compensation-transaction-workflow" + }, + { + "slug": "conflict-resolution-workflow", + "title": "Conflict Resolution Workflow", + "description": "Workplace conflict resolution workflow with complaint intake, HR investigation, mediation sessions, resolution documentation, and follow-up monitoring.", + "kind": "workflow", + "sourceDomain": "hr", + "primaryUseCase": "billing", + "secondaryUseCases": [], + "useCases": [ + "billing" + ], + "complexity": 4, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "conflict-resolution", + "workplace-dispute", + "mediation", + "hr-investigation", + "employee-relations", + "grievance" + ], + "sourcePath": "hr/conflict-resolution", + "repoPath": "billing/hr/conflict-resolution-workflow" + }, + { + "slug": "consent-management-workflow", + "title": "Consent Management Workflow", + "description": "User consent management workflow with cookie banner, preference center, consent recording, downstream system sync, and audit trail.", + "kind": "workflow", + "sourceDomain": "business-operations", + "primaryUseCase": "compliance", + "secondaryUseCases": [], + "useCases": [ + "compliance" + ], + "complexity": 3, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "consent-management", + "gdpr", + "cookie-consent", + "privacy-preferences", + "opt-in-opt-out", + "compliance" + ], + "sourcePath": "business-operations/consent-management", + "repoPath": "compliance/business-operations/consent-management-workflow" + }, + { + "slug": "container-loading-workflow", + "title": "Container Loading Workflow", + "description": "Container loading workflow with load plan optimization, weight distribution, cube utilization maximization, seal application, and bill of lading generation.", + "kind": "workflow", + "sourceDomain": "logistics", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "container-loading", + "load-planning", + "weight-distribution", + "cube-utilization", + "seal-verification", + "ocean-freight" + ], + "sourcePath": "logistics/container-loading", + "repoPath": "uncategorized/logistics/container-loading-workflow" + }, + { + "slug": "content-enricher-workflow", + "title": "Content Enricher Workflow", + "description": "This workflow models adding extra data from other sources.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "content", + "enricher", + "patterns", + "decision" + ], + "sourcePath": "patterns/content-enricher", + "repoPath": "uncategorized/patterns/content-enricher-workflow" + }, + { + "slug": "cost-center-workflow", + "title": "Cost Center Workflow", + "description": "This workflow models managing cost center budgets.", + "kind": "workflow", + "sourceDomain": "finance", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 2, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "cost", + "center", + "finance", + "decision" + ], + "sourcePath": "finance/cost-center", + "repoPath": "uncategorized/finance/cost-center-workflow" + }, + { + "slug": "cqrs-workflow", + "title": "Cqrs Workflow", + "description": "CQRS (Command Query Responsibility Segregation) pattern with separate command and query paths, domain event publishing, read model synchronization, and DTO transformation.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 19, + "numLanes": 4, + "tags": [ + "cqrs", + "command-query-separation", + "event-sourcing", + "read-model", + "write-model", + "domain-events", + "eventual-consistency" + ], + "sourcePath": "patterns/cqrs", + "repoPath": "uncategorized/patterns/cqrs-workflow" + }, + { + "slug": "credit-control-workflow", + "title": "Credit Control Workflow", + "description": "Customer credit control workflow with credit limit assessment, credit scoring, order hold management, collections escalation, and payment plan negotiation.", + "kind": "workflow", + "sourceDomain": "finance", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "credit-control", + "credit-limit", + "customer-credit", + "credit-scoring", + "collections", + "accounts-receivable" + ], + "sourcePath": "finance/credit-control", + "repoPath": "uncategorized/finance/credit-control-workflow" + }, + { + "slug": "cross-docking-workflow", + "title": "Cross Docking Workflow", + "description": "Cross-docking workflow with inbound scheduling, sortation by destination, outbound consolidation, and direct transfer without storage for just-in-time delivery.", + "kind": "workflow", + "sourceDomain": "logistics", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "cross-docking", + "flow-through", + "dock-scheduling", + "sortation", + "consolidation", + "just-in-time" + ], + "sourcePath": "logistics/cross-docking", + "repoPath": "uncategorized/logistics/cross-docking-workflow" + }, + { + "slug": "crud-user-browser-server-workflow", + "title": "Crud User Browser Server Workflow", + "description": "This workflow models user creates, reads, updates, and deletes data through a browser and server.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 2, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "crud", + "user", + "browser", + "server", + "patterns" + ], + "sourcePath": "patterns/crud-user-browser-server", + "repoPath": "uncategorized/patterns/crud-user-browser-server-workflow" + }, + { + "slug": "customs-clearance-workflow", + "title": "Customs Clearance Workflow", + "description": "International customs clearance workflow with importer documentation, customs broker HS code classification, duty calculation, customs authority inspection, and clearance certificate issuance.", + "kind": "workflow", + "sourceDomain": "logistics", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 19, + "numLanes": 3, + "tags": [ + "customs-clearance", + "international-trade", + "customs-broker", + "hs-codes", + "import-export", + "duties-taxes", + "inspection" + ], + "sourcePath": "logistics/customs-clearance", + "repoPath": "uncategorized/logistics/customs-clearance-workflow" + }, + { + "slug": "cycle-counting-workflow", + "title": "Cycle Counting Workflow", + "description": "Inventory cycle counting workflow with ABC classification, count scheduling, variance investigation, adjustment approval, and inventory accuracy tracking.", + "kind": "workflow", + "sourceDomain": "logistics", + "primaryUseCase": "compliance", + "secondaryUseCases": [], + "useCases": [ + "compliance" + ], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "cycle-counting", + "inventory-accuracy", + "abc-analysis", + "variance-investigation", + "perpetual-inventory", + "audit" + ], + "sourcePath": "logistics/cycle-counting", + "repoPath": "compliance/logistics/cycle-counting-workflow" + }, + { + "slug": "damaged-goods-workflow", + "title": "Damaged Goods Workflow", + "description": "Damaged goods processing workflow with damage documentation, carrier claim filing, disposition decision (salvage/dispose), inventory adjustment, and loss tracking.", + "kind": "workflow", + "sourceDomain": "logistics", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "damaged-goods", + "damage-claim", + "inventory-write-off", + "carrier-claim", + "disposition", + "loss-prevention" + ], + "sourcePath": "logistics/damaged-goods", + "repoPath": "uncategorized/logistics/damaged-goods-workflow" + }, + { + "slug": "data-export-workflow", + "title": "Data Export Workflow", + "description": "User data export workflow with export request, async job processing, data aggregation, secure file generation, and download link delivery.", + "kind": "workflow", + "sourceDomain": "business-operations", + "primaryUseCase": "compliance", + "secondaryUseCases": [], + "useCases": [ + "compliance" + ], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "data-export", + "data-portability", + "gdpr", + "bulk-export", + "async-job", + "download-link" + ], + "sourcePath": "business-operations/data-export", + "repoPath": "compliance/business-operations/data-export-workflow" + }, + { + "slug": "database-migration-workflow", + "title": "Database Migration Workflow", + "description": "Database schema migration workflow with CI testing, DBA review and approval, maintenance window scheduling, backup snapshots, migration execution, data integrity verification, and automatic rollback.", + "kind": "workflow", + "sourceDomain": "devops", + "primaryUseCase": "approval", + "secondaryUseCases": [ + "delivery" + ], + "useCases": [ + "approval", + "delivery" + ], + "complexity": 4, + "numNodes": 20, + "numLanes": 4, + "tags": [ + "database-migration", + "schema-changes", + "flyway", + "liquibase", + "rollback", + "dba-approval", + "maintenance-window" + ], + "sourcePath": "devops/database-migration", + "repoPath": "approval/devops/database-migration-workflow" + }, + { + "slug": "dead-letter-queue-workflow", + "title": "Dead Letter Queue Workflow", + "description": "Dead letter queue pattern for handling failed messages with retry exhaustion detection, DLQ routing, manual inspection, and reprocessing capability.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "dead-letter-queue", + "dlq", + "message-retry", + "poison-message", + "error-handling", + "message-queue" + ], + "sourcePath": "patterns/dead-letter-queue", + "repoPath": "uncategorized/patterns/dead-letter-queue-workflow" + }, + { + "slug": "decision-diamond-workflow", + "title": "Decision Diamond Workflow", + "description": "This workflow models an if or then style branch for approval or rejection.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "decision", + "diamond", + "patterns" + ], + "sourcePath": "patterns/decision-diamond", + "repoPath": "uncategorized/patterns/decision-diamond-workflow" + }, + { + "slug": "delivery-confirmation-workflow", + "title": "Delivery Confirmation Workflow", + "description": "Delivery confirmation workflow with proof of delivery capture, signature collection, photo documentation, order status update, and customer notification.", + "kind": "workflow", + "sourceDomain": "logistics", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 2, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "delivery-confirmation", + "pod", + "signature-capture", + "order-completion", + "customer-notification", + "tracking-update" + ], + "sourcePath": "logistics/delivery-confirmation", + "repoPath": "uncategorized/logistics/delivery-confirmation-workflow" + }, + { + "slug": "deployment-rollback-workflow", + "title": "Deployment Rollback Workflow", + "description": "Deployment rollback workflow with issue detection, rollback decision, previous version restoration, health verification, and post-mortem documentation.", + "kind": "workflow", + "sourceDomain": "devops", + "primaryUseCase": "incident", + "secondaryUseCases": [ + "delivery" + ], + "useCases": [ + "incident", + "delivery" + ], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "deployment-rollback", + "version-revert", + "incident-response", + "kubernetes", + "helm-rollback", + "service-recovery" + ], + "sourcePath": "devops/deployment-rollback", + "repoPath": "incident/devops/deployment-rollback-workflow" + }, + { + "slug": "diversity-initiative-workflow", + "title": "Diversity Initiative Workflow", + "description": "This workflow models promoting workplace diversity.", + "kind": "workflow", + "sourceDomain": "hr", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "diversity", + "initiative", + "hr" + ], + "sourcePath": "hr/diversity-initiative", + "repoPath": "uncategorized/hr/diversity-initiative-workflow" + }, + { + "slug": "dunning-flow-workflow", + "title": "Dunning Flow Workflow", + "description": "Dunning collection workflow with escalating reminder emails, grace period management, account suspension, and payment recovery tracking.", + "kind": "workflow", + "sourceDomain": "business-operations", + "primaryUseCase": "billing", + "secondaryUseCases": [], + "useCases": [ + "billing" + ], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "dunning-flow", + "collections", + "overdue-payment", + "payment-reminder", + "account-suspension", + "revenue-recovery" + ], + "sourcePath": "business-operations/dunning-flow", + "repoPath": "billing/business-operations/dunning-flow-workflow" + }, + { + "slug": "email-campaign-workflow", + "title": "Email Campaign Workflow", + "description": "Email marketing campaign workflow with audience segmentation, A/B testing, send scheduling, deliverability monitoring, and engagement analytics.", + "kind": "workflow", + "sourceDomain": "business-operations", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 13, + "numLanes": 4, + "tags": [ + "email-campaign", + "marketing-automation", + "mailchimp", + "segmentation", + "a-b-testing", + "deliverability" + ], + "sourcePath": "business-operations/email-campaign", + "repoPath": "uncategorized/business-operations/email-campaign-workflow" + }, + { + "slug": "employee-engagement-workflow", + "title": "Employee Engagement Workflow", + "description": "This workflow models measuring and improving engagement.", + "kind": "workflow", + "sourceDomain": "hr", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 2, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "employee", + "engagement", + "hr", + "parallel" + ], + "sourcePath": "hr/employee-engagement", + "repoPath": "uncategorized/hr/employee-engagement-workflow" + }, + { + "slug": "enricher-workflow", + "title": "Enricher Workflow", + "description": "This workflow models adding metadata to messages before passing them on.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "enricher", + "patterns" + ], + "sourcePath": "patterns/enricher", + "repoPath": "uncategorized/patterns/enricher-workflow" + }, + { + "slug": "error-retry-loop-workflow", + "title": "Error Retry Loop Workflow", + "description": "This workflow models a failed operation that retries with backoff.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 2, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "error", + "retry", + "loop", + "patterns" + ], + "sourcePath": "patterns/error-retry-loop", + "repoPath": "uncategorized/patterns/error-retry-loop-workflow" + }, + { + "slug": "escalation-pattern-workflow", + "title": "Escalation Pattern Workflow", + "description": "This workflow models escalating issues to higher authority when needed.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "handoff", + "secondaryUseCases": [], + "useCases": [ + "handoff" + ], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "escalation", + "pattern", + "patterns" + ], + "sourcePath": "patterns/escalation-pattern", + "repoPath": "handoff/patterns/escalation-pattern-workflow" + }, + { + "slug": "event-driven-workflow", + "title": "Event Driven Workflow", + "description": "This workflow models reacting to incoming business events.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "event", + "driven", + "patterns" + ], + "sourcePath": "patterns/event-driven", + "repoPath": "uncategorized/patterns/event-driven-workflow" + }, + { + "slug": "event-sourcing-workflow", + "title": "Event Sourcing Workflow", + "description": "Event sourcing pattern with event capture, event store persistence, aggregate reconstruction, snapshot optimization, and temporal state queries.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "compliance", + "secondaryUseCases": [], + "useCases": [ + "compliance" + ], + "complexity": 4, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "event-sourcing", + "event-store", + "aggregate", + "replay", + "audit-log", + "temporal-query" + ], + "sourcePath": "patterns/event-sourcing", + "repoPath": "compliance/patterns/event-sourcing-workflow" + }, + { + "slug": "expense-allocation-workflow", + "title": "Expense Allocation Workflow", + "description": "This workflow models allocating costs to departments.", + "kind": "workflow", + "sourceDomain": "finance", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "expense", + "allocation", + "finance" + ], + "sourcePath": "finance/expense-allocation", + "repoPath": "uncategorized/finance/expense-allocation-workflow" + }, + { + "slug": "expense-approval-workflow", + "title": "Expense Approval Workflow", + "description": "Employee expense approval workflow with receipt validation, policy compliance check, tiered approval based on amount, and reimbursement processing.", + "kind": "workflow", + "sourceDomain": "hr", + "primaryUseCase": "approval", + "secondaryUseCases": [ + "compliance" + ], + "useCases": [ + "approval", + "compliance" + ], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "expense-approval", + "travel-expenses", + "receipt-validation", + "policy-compliance", + "tiered-approval", + "reimbursement" + ], + "sourcePath": "hr/expense-approval", + "repoPath": "approval/hr/expense-approval-workflow" + }, + { + "slug": "expense-claim-workflow", + "title": "Expense Claim Workflow", + "description": "Employee expense reimbursement workflow with receipt submission, manager approval, finance review, policy compliance check, and direct deposit payment.", + "kind": "workflow", + "sourceDomain": "finance", + "primaryUseCase": "approval", + "secondaryUseCases": [], + "useCases": [ + "approval" + ], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "expense-reimbursement", + "employee-expenses", + "receipt-upload", + "manager-approval", + "finance-review", + "direct-deposit" + ], + "sourcePath": "finance/expense-claim", + "repoPath": "approval/finance/expense-claim-workflow" + }, + { + "slug": "fan-out-fan-in-workflow", + "title": "Fan Out Fan In Workflow", + "description": "Fan-out/fan-in pattern with work distribution to parallel workers, concurrent execution, result aggregation, and error handling for partial failures.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "ai-orchestration", + "secondaryUseCases": [], + "useCases": [ + "ai-orchestration" + ], + "complexity": 4, + "numNodes": 13, + "numLanes": 4, + "tags": [ + "fan-out-fan-in", + "scatter-gather", + "parallel-processing", + "aggregation", + "map-reduce", + "concurrency" + ], + "sourcePath": "patterns/fan-out-fan-in", + "repoPath": "ai-orchestration/patterns/fan-out-fan-in-workflow" + }, + { + "slug": "feature-toggle-workflow", + "title": "Feature Toggle Workflow", + "description": "Feature toggle pattern with flag configuration, user targeting rules, percentage rollouts, and instant kill-switch capability for production features.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "feature-toggle", + "feature-flags", + "dark-launch", + "a-b-testing", + "gradual-rollout", + "kill-switch" + ], + "sourcePath": "patterns/feature-toggle", + "repoPath": "uncategorized/patterns/feature-toggle-workflow" + }, + { + "slug": "filter-workflow", + "title": "Filter Workflow", + "description": "This workflow models removing items that do not meet criteria.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 13, + "numLanes": 4, + "tags": [ + "filter", + "patterns", + "decision", + "loop" + ], + "sourcePath": "patterns/filter", + "repoPath": "uncategorized/patterns/filter-workflow" + }, + { + "slug": "financial-reporting-workflow", + "title": "Financial Reporting Workflow", + "description": "Financial reporting workflow with GAAP-compliant statement preparation, management review, audit committee approval, and SEC filing for public companies.", + "kind": "workflow", + "sourceDomain": "finance", + "primaryUseCase": "compliance", + "secondaryUseCases": [], + "useCases": [ + "compliance" + ], + "complexity": 4, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "financial-reporting", + "gaap-compliance", + "income-statement", + "balance-sheet", + "cash-flow-statement", + "sec-filing" + ], + "sourcePath": "finance/financial-reporting", + "repoPath": "compliance/finance/financial-reporting-workflow" + }, + { + "slug": "fixed-assets-workflow", + "title": "Fixed Assets Workflow", + "description": "Fixed asset management workflow with asset capitalization, depreciation scheduling, physical inventory verification, and asset disposal/retirement processing.", + "kind": "workflow", + "sourceDomain": "finance", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "fixed-assets", + "asset-tracking", + "depreciation", + "capitalization", + "asset-disposal", + "physical-inventory" + ], + "sourcePath": "finance/fixed-assets", + "repoPath": "uncategorized/finance/fixed-assets-workflow" + }, + { + "slug": "fleet-maintenance-workflow", + "title": "Fleet Maintenance Workflow", + "description": "Fleet maintenance workflow with preventive maintenance scheduling, vehicle inspection, work order creation, parts ordering, and DOT compliance tracking.", + "kind": "workflow", + "sourceDomain": "logistics", + "primaryUseCase": "compliance", + "secondaryUseCases": [], + "useCases": [ + "compliance" + ], + "complexity": 3, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "fleet-maintenance", + "preventive-maintenance", + "vehicle-inspection", + "work-order", + "dot-compliance", + "telematics" + ], + "sourcePath": "logistics/fleet-maintenance", + "repoPath": "compliance/logistics/fleet-maintenance-workflow" + }, + { + "slug": "gdpr-deletion-workflow", + "title": "Gdpr Deletion Workflow", + "description": "GDPR data deletion workflow with identity verification, data inventory scan, PII removal across systems, backup purging, and deletion confirmation.", + "kind": "workflow", + "sourceDomain": "business-operations", + "primaryUseCase": "compliance", + "secondaryUseCases": [], + "useCases": [ + "compliance" + ], + "complexity": 4, + "numNodes": 13, + "numLanes": 4, + "tags": [ + "gdpr-deletion", + "right-to-be-forgotten", + "data-privacy", + "pii-removal", + "compliance", + "dsar" + ], + "sourcePath": "business-operations/gdpr-deletion", + "repoPath": "compliance/business-operations/gdpr-deletion-workflow" + }, + { + "slug": "hazmat-handling-workflow", + "title": "Hazmat Handling Workflow", + "description": "Hazardous materials handling workflow with UN classification, SDS documentation, proper labeling, certified handler assignment, and emergency response procedures.", + "kind": "workflow", + "sourceDomain": "logistics", + "primaryUseCase": "incident", + "secondaryUseCases": [ + "compliance" + ], + "useCases": [ + "incident", + "compliance" + ], + "complexity": 4, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "hazmat-handling", + "dangerous-goods", + "un-classification", + "sds-documentation", + "dot-compliance", + "emergency-response" + ], + "sourcePath": "logistics/hazmat-handling", + "repoPath": "incident/logistics/hazmat-handling-workflow" + }, + { + "slug": "idempotent-consumer-workflow", + "title": "Idempotent Consumer Workflow", + "description": "This workflow models processing each message safely only once.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "idempotent", + "consumer", + "patterns" + ], + "sourcePath": "patterns/idempotent-consumer", + "repoPath": "uncategorized/patterns/idempotent-consumer-workflow" + }, + { + "slug": "in-app-message-workflow", + "title": "In App Message Workflow", + "description": "In-app messaging workflow with trigger conditions, audience targeting, message display, user interaction tracking, and conversion measurement.", + "kind": "workflow", + "sourceDomain": "business-operations", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 2, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "in-app-message", + "product-tours", + "tooltips", + "announcements", + "user-engagement", + "intercom" + ], + "sourcePath": "business-operations/in-app-message", + "repoPath": "uncategorized/business-operations/in-app-message-workflow" + }, + { + "slug": "incident-response-workflow", + "title": "Incident Response Workflow", + "description": "Production incident response workflow with severity-based routing, war room coordination, incident commander assignment, customer communication, root cause analysis, and postmortem scheduling.", + "kind": "workflow", + "sourceDomain": "devops", + "primaryUseCase": "incident", + "secondaryUseCases": [], + "useCases": [ + "incident" + ], + "complexity": 5, + "numNodes": 23, + "numLanes": 4, + "tags": [ + "incident-management", + "on-call", + "pagerduty", + "war-room", + "severity-levels", + "postmortem", + "sre" + ], + "sourcePath": "devops/incident-response", + "repoPath": "incident/devops/incident-response-workflow" + }, + { + "slug": "infrastructure-provisioning-workflow", + "title": "Infrastructure Provisioning Workflow", + "description": "Infrastructure as Code provisioning workflow with Terraform plan, approval gates, state management, resource creation, and drift detection.", + "kind": "workflow", + "sourceDomain": "devops", + "primaryUseCase": "delivery", + "secondaryUseCases": [], + "useCases": [ + "delivery" + ], + "complexity": 4, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "infrastructure-provisioning", + "terraform", + "iac", + "cloud-resources", + "gitops", + "state-management" + ], + "sourcePath": "devops/infrastructure-provisioning", + "repoPath": "delivery/devops/infrastructure-provisioning-workflow" + }, + { + "slug": "insurance-claim-workflow", + "title": "Insurance Claim Workflow", + "description": "Insurance claim processing workflow with incident documentation, claim filing, adjuster assignment, damage assessment, and settlement negotiation.", + "kind": "workflow", + "sourceDomain": "finance", + "primaryUseCase": "approval", + "secondaryUseCases": [], + "useCases": [ + "approval" + ], + "complexity": 3, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "insurance-claim", + "claim-filing", + "adjuster-review", + "settlement", + "property-damage", + "liability" + ], + "sourcePath": "finance/insurance-claim", + "repoPath": "approval/finance/insurance-claim-workflow" + }, + { + "slug": "internal-controls-workflow", + "title": "Internal Controls Workflow", + "description": "Internal controls testing workflow with risk assessment, control design evaluation, operating effectiveness testing, deficiency identification, and remediation tracking.", + "kind": "workflow", + "sourceDomain": "finance", + "primaryUseCase": "compliance", + "secondaryUseCases": [], + "useCases": [ + "compliance" + ], + "complexity": 4, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "internal-controls", + "sox-compliance", + "control-testing", + "segregation-of-duties", + "risk-assessment", + "remediation" + ], + "sourcePath": "finance/internal-controls", + "repoPath": "compliance/finance/internal-controls-workflow" + }, + { + "slug": "internship-program-workflow", + "title": "Internship Program Workflow", + "description": "This workflow models managing an internship program.", + "kind": "workflow", + "sourceDomain": "hr", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 2, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "internship", + "program", + "hr" + ], + "sourcePath": "hr/internship-program", + "repoPath": "uncategorized/hr/internship-program-workflow" + }, + { + "slug": "interview-process-workflow", + "title": "Interview Process Workflow", + "description": "Multi-stage interview process with resume screening, phone screen, technical interview, onsite panel, team consensus decision, and offer/rejection handling.", + "kind": "workflow", + "sourceDomain": "hr", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 22, + "numLanes": 3, + "tags": [ + "interview-process", + "hiring", + "phone-screen", + "technical-interview", + "onsite-panel", + "talent-acquisition", + "offer-management" + ], + "sourcePath": "hr/interview-process", + "repoPath": "uncategorized/hr/interview-process-workflow" + }, + { + "slug": "inventory-receipt-workflow", + "title": "Inventory Receipt Workflow", + "description": "Inventory receiving workflow with ASN verification, PO matching, quantity count, damage inspection, and WMS inventory update.", + "kind": "workflow", + "sourceDomain": "logistics", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "inventory-receipt", + "goods-receiving", + "po-matching", + "asn-verification", + "dock-scheduling", + "wms" + ], + "sourcePath": "logistics/inventory-receipt", + "repoPath": "uncategorized/logistics/inventory-receipt-workflow" + }, + { + "slug": "invoice-processing-workflow", + "title": "Invoice Processing Workflow", + "description": "Accounts payable invoice automation with OCR data extraction, three-way PO matching, tiered approval workflow, and automated payment processing with GL updates.", + "kind": "workflow", + "sourceDomain": "finance", + "primaryUseCase": "approval", + "secondaryUseCases": [ + "billing" + ], + "useCases": [ + "approval", + "billing" + ], + "complexity": 4, + "numNodes": 19, + "numLanes": 4, + "tags": [ + "accounts-payable", + "invoice-automation", + "ocr", + "po-matching", + "approval-workflow", + "payment-processing", + "three-way-match" + ], + "sourcePath": "finance/invoice-processing", + "repoPath": "approval/finance/invoice-processing-workflow" + }, + { + "slug": "job-posting-workflow", + "title": "Job Posting Workflow", + "description": "Job posting workflow with requisition approval, job description drafting, multi-channel posting (LinkedIn, Indeed, career sites), AI resume screening, and ATS candidate tracking.", + "kind": "workflow", + "sourceDomain": "hr", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 19, + "numLanes": 3, + "tags": [ + "job-posting", + "job-requisition", + "ats", + "linkedin", + "indeed", + "ai-screening", + "talent-acquisition" + ], + "sourcePath": "hr/job-posting", + "repoPath": "uncategorized/hr/job-posting-workflow" + }, + { + "slug": "kitting-process-workflow", + "title": "Kitting Process Workflow", + "description": "Kit assembly workflow with BOM explosion, component picking, assembly verification, kit labeling, and inventory conversion from components to finished kit.", + "kind": "workflow", + "sourceDomain": "logistics", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 2, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "kitting-process", + "kit-assembly", + "bom", + "component-picking", + "value-added-services", + "bundling" + ], + "sourcePath": "logistics/kitting-process", + "repoPath": "uncategorized/logistics/kitting-process-workflow" + }, + { + "slug": "knowledge-base-workflow", + "title": "Knowledge Base Workflow", + "description": "Knowledge base management workflow with article creation, review approval, SEO optimization, version control, and search analytics tracking.", + "kind": "workflow", + "sourceDomain": "business-operations", + "primaryUseCase": "support", + "secondaryUseCases": [], + "useCases": [ + "support" + ], + "complexity": 3, + "numNodes": 13, + "numLanes": 4, + "tags": [ + "knowledge-base", + "help-center", + "documentation", + "self-service", + "article-management", + "zendesk" + ], + "sourcePath": "business-operations/knowledge-base", + "repoPath": "support/business-operations/knowledge-base-workflow" + }, + { + "slug": "last-mile-delivery-workflow", + "title": "Last Mile Delivery Workflow", + "description": "Last mile delivery workflow with route optimization, real-time GPS tracking, delivery attempt handling, proof of delivery capture, and customer notification.", + "kind": "workflow", + "sourceDomain": "logistics", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "last-mile-delivery", + "route-optimization", + "proof-of-delivery", + "delivery-exception", + "customer-notification", + "gps-tracking" + ], + "sourcePath": "logistics/last-mile-delivery", + "repoPath": "uncategorized/logistics/last-mile-delivery-workflow" + }, + { + "slug": "load-testing-workflow", + "title": "Load Testing Workflow", + "description": "Load testing workflow with test scenario design, gradual ramp-up, performance metrics collection, bottleneck identification, and capacity recommendations.", + "kind": "workflow", + "sourceDomain": "devops", + "primaryUseCase": "delivery", + "secondaryUseCases": [], + "useCases": [ + "delivery" + ], + "complexity": 4, + "numNodes": 13, + "numLanes": 4, + "tags": [ + "load-testing", + "performance-testing", + "stress-testing", + "k6", + "jmeter", + "capacity-planning" + ], + "sourcePath": "devops/load-testing", + "repoPath": "delivery/devops/load-testing-workflow" + }, + { + "slug": "materialized-view-workflow", + "title": "Materialized View Workflow", + "description": "This workflow models serving queries from a precomputed view.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 13, + "numLanes": 4, + "tags": [ + "materialized", + "view", + "patterns", + "decision", + "loop" + ], + "sourcePath": "patterns/materialized-view", + "repoPath": "uncategorized/patterns/materialized-view-workflow" + }, + { + "slug": "message-queue-workflow", + "title": "Message Queue Workflow", + "description": "This workflow models asynchronous processing of work via a queue.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "message", + "queue", + "patterns", + "decision" + ], + "sourcePath": "patterns/message-queue", + "repoPath": "uncategorized/patterns/message-queue-workflow" + }, + { + "slug": "monitoring-alert-workflow", + "title": "Monitoring Alert Workflow", + "description": "Monitoring and alerting workflow with metric collection, threshold evaluation, alert routing, escalation policies, and incident creation.", + "kind": "workflow", + "sourceDomain": "devops", + "primaryUseCase": "incident", + "secondaryUseCases": [], + "useCases": [ + "incident" + ], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "monitoring-alerting", + "prometheus", + "pagerduty", + "threshold-alerts", + "anomaly-detection", + "on-call" + ], + "sourcePath": "devops/monitoring-alert", + "repoPath": "incident/devops/monitoring-alert-workflow" + }, + { + "slug": "monthly-close-workflow", + "title": "Monthly Close Workflow", + "description": "Corporate month-end financial close process including transaction posting, bank reconciliation, accruals, depreciation, trial balance validation, and financial statement generation.", + "kind": "workflow", + "sourceDomain": "finance", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 22, + "numLanes": 4, + "tags": [ + "monthly-close", + "financial-reporting", + "accounting", + "reconciliation", + "trial-balance", + "period-close" + ], + "sourcePath": "finance/monthly-close", + "repoPath": "uncategorized/finance/monthly-close-workflow" + }, + { + "slug": "nested-decisions-workflow", + "title": "Nested Decisions Workflow", + "description": "This workflow models multiple layers of decisions before completion.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "nested", + "decisions", + "patterns", + "decision", + "loop" + ], + "sourcePath": "patterns/nested-decisions", + "repoPath": "uncategorized/patterns/nested-decisions-workflow" + }, + { + "slug": "normalizer-workflow", + "title": "Normalizer Workflow", + "description": "This workflow models converting varied inputs to a standard format.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 13, + "numLanes": 4, + "tags": [ + "normalizer", + "patterns" + ], + "sourcePath": "patterns/normalizer", + "repoPath": "uncategorized/patterns/normalizer-workflow" + }, + { + "slug": "notification-pattern-workflow", + "title": "Notification Pattern Workflow", + "description": "This workflow models sending alerts via multiple channels.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 2, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "notification", + "pattern", + "patterns" + ], + "sourcePath": "patterns/notification-pattern", + "repoPath": "uncategorized/patterns/notification-pattern-workflow" + }, + { + "slug": "oauth-flow-workflow", + "title": "Oauth Flow Workflow", + "description": "OAuth 2.0 authorization code flow with redirect handling, code exchange, token storage, refresh token rotation, and scope management.", + "kind": "workflow", + "sourceDomain": "business-operations", + "primaryUseCase": "approval", + "secondaryUseCases": [ + "security" + ], + "useCases": [ + "approval", + "security" + ], + "complexity": 4, + "numNodes": 13, + "numLanes": 4, + "tags": [ + "oauth-flow", + "oauth2", + "authorization-code", + "token-exchange", + "sso", + "third-party-auth" + ], + "sourcePath": "business-operations/oauth-flow", + "repoPath": "approval/business-operations/oauth-flow-workflow" + }, + { + "slug": "offboarding-workflow", + "title": "Offboarding Workflow", + "description": "Employee offboarding workflow with exit interview, knowledge transfer, asset collection, access revocation, final pay processing, and benefits continuation.", + "kind": "workflow", + "sourceDomain": "hr", + "primaryUseCase": "handoff", + "secondaryUseCases": [ + "offboarding" + ], + "useCases": [ + "handoff", + "offboarding" + ], + "complexity": 4, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "employee-offboarding", + "exit-interview", + "access-revocation", + "asset-return", + "knowledge-transfer", + "final-paycheck" + ], + "sourcePath": "hr/offboarding", + "repoPath": "handoff/hr/offboarding-workflow" + }, + { + "slug": "on-call-rotation-workflow", + "title": "On Call Rotation Workflow", + "description": "On-call rotation workflow with schedule creation, shift handoffs, override management, escalation policies, and fair rotation distribution.", + "kind": "workflow", + "sourceDomain": "devops", + "primaryUseCase": "handoff", + "secondaryUseCases": [ + "incident", + "security" + ], + "useCases": [ + "handoff", + "incident", + "security" + ], + "complexity": 3, + "numNodes": 13, + "numLanes": 4, + "tags": [ + "on-call-rotation", + "incident-management", + "pagerduty", + "escalation", + "schedule-management", + "handoff" + ], + "sourcePath": "devops/on-call-rotation", + "repoPath": "handoff/devops/on-call-rotation-workflow" + }, + { + "slug": "onboarding-workflow", + "title": "Onboarding Workflow", + "description": "Complete employee onboarding workflow covering offer acceptance, HR record creation, benefits enrollment, background check verification, IT account provisioning, equipment setup, and first day orientation.", + "kind": "workflow", + "sourceDomain": "hr", + "primaryUseCase": "onboarding", + "secondaryUseCases": [ + "delivery" + ], + "useCases": [ + "onboarding", + "delivery" + ], + "complexity": 4, + "numNodes": 20, + "numLanes": 3, + "tags": [ + "employee-onboarding", + "new-hire", + "hr-workflow", + "background-check", + "it-provisioning", + "benefits-enrollment" + ], + "sourcePath": "hr/onboarding", + "repoPath": "onboarding/hr/onboarding-workflow" + }, + { + "slug": "packing-process-workflow", + "title": "Packing Process Workflow", + "description": "Order packing workflow with carton selection, item verification, packing slip insertion, weight check, and package sealing for shipment.", + "kind": "workflow", + "sourceDomain": "logistics", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 2, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "order-packing", + "box-selection", + "packing-slip", + "weight-verification", + "cartonization", + "fulfillment" + ], + "sourcePath": "logistics/packing-process", + "repoPath": "uncategorized/logistics/packing-process-workflow" + }, + { + "slug": "parallel-execution-workflow", + "title": "Parallel Execution Workflow", + "description": "This workflow models multiple tasks that run at the same time.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 13, + "numLanes": 4, + "tags": [ + "parallel", + "execution", + "patterns", + "loop" + ], + "sourcePath": "patterns/parallel-execution", + "repoPath": "uncategorized/patterns/parallel-execution-workflow" + }, + { + "slug": "payment-failure-workflow", + "title": "Payment Failure Workflow", + "description": "Failed payment recovery workflow with smart retry scheduling, dunning email sequence, payment method update prompts, and involuntary churn prevention.", + "kind": "workflow", + "sourceDomain": "business-operations", + "primaryUseCase": "billing", + "secondaryUseCases": [], + "useCases": [ + "billing" + ], + "complexity": 3, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "payment-failure", + "dunning", + "retry-logic", + "card-decline", + "revenue-recovery", + "stripe" + ], + "sourcePath": "business-operations/payment-failure", + "repoPath": "billing/business-operations/payment-failure-workflow" + }, + { + "slug": "payment-run-workflow", + "title": "Payment Run Workflow", + "description": "Accounts payable payment run workflow with batch creation, tiered approval (single/dual based on amount), ACH file generation, check printing, and vendor record updates.", + "kind": "workflow", + "sourceDomain": "finance", + "primaryUseCase": "handoff", + "secondaryUseCases": [ + "approval", + "billing" + ], + "useCases": [ + "handoff", + "approval", + "billing" + ], + "complexity": 4, + "numNodes": 18, + "numLanes": 3, + "tags": [ + "payment-run", + "accounts-payable", + "ach-payments", + "check-run", + "dual-approval", + "bank-transfer", + "vendor-payments" + ], + "sourcePath": "finance/payment-run", + "repoPath": "handoff/finance/payment-run-workflow" + }, + { + "slug": "payroll-processing-workflow", + "title": "Payroll Processing Workflow", + "description": "Complete payroll processing workflow with timesheet collection, gross pay calculation, overtime, tax withholding (federal, state, FICA), benefits deductions, compliance validation, and ACH direct deposit.", + "kind": "workflow", + "sourceDomain": "finance", + "primaryUseCase": "compliance", + "secondaryUseCases": [], + "useCases": [ + "compliance" + ], + "complexity": 5, + "numNodes": 24, + "numLanes": 4, + "tags": [ + "payroll-processing", + "salary-calculation", + "tax-withholding", + "fica", + "ach-direct-deposit", + "benefits-deductions", + "compliance" + ], + "sourcePath": "finance/payroll-processing", + "repoPath": "compliance/finance/payroll-processing-workflow" + }, + { + "slug": "performance-review-workflow", + "title": "Performance Review Workflow", + "description": "Annual performance review workflow with self-assessment, manager evaluation, 360 feedback collection, calibration sessions, and merit increase recommendations.", + "kind": "workflow", + "sourceDomain": "hr", + "primaryUseCase": "approval", + "secondaryUseCases": [], + "useCases": [ + "approval" + ], + "complexity": 4, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "performance-review", + "annual-evaluation", + "goal-setting", + "360-feedback", + "calibration", + "merit-increase" + ], + "sourcePath": "hr/performance-review", + "repoPath": "approval/hr/performance-review-workflow" + }, + { + "slug": "personalization-engine-workflow", + "title": "Personalization Engine Workflow", + "description": "Make.com automation scenario for real-time personalization using Segment events, ML recommendation API, and Braze campaign delivery across email and push channels.", + "kind": "workflow", + "sourceDomain": "business-operations", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 20, + "numLanes": 3, + "tags": [ + "make-com", + "personalization", + "segment", + "braze", + "ml-recommendations", + "content-delivery", + "marketing-automation" + ], + "sourcePath": "business-operations/personalization-engine", + "repoPath": "uncategorized/business-operations/personalization-engine-workflow" + }, + { + "slug": "picking-process-workflow", + "title": "Picking Process Workflow", + "description": "Warehouse order picking workflow with pick list generation, zone routing, batch picking optimization, barcode scanning verification, and pick completion confirmation.", + "kind": "workflow", + "sourceDomain": "logistics", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "order-picking", + "warehouse-management", + "pick-list", + "batch-picking", + "wave-picking", + "wms" + ], + "sourcePath": "logistics/picking-process", + "repoPath": "uncategorized/logistics/picking-process-workflow" + }, + { + "slug": "plan-downgrade-workflow", + "title": "Plan Downgrade Workflow", + "description": "Subscription plan downgrade workflow with retention offer, feature restriction warning, data migration handling, and end-of-period scheduling.", + "kind": "workflow", + "sourceDomain": "business-operations", + "primaryUseCase": "billing", + "secondaryUseCases": [ + "delivery" + ], + "useCases": [ + "billing", + "delivery" + ], + "complexity": 3, + "numNodes": 13, + "numLanes": 4, + "tags": [ + "plan-downgrade", + "retention", + "feature-restriction", + "data-migration", + "churn-prevention", + "billing" + ], + "sourcePath": "business-operations/plan-downgrade", + "repoPath": "billing/business-operations/plan-downgrade-workflow" + }, + { + "slug": "plan-upgrade-workflow", + "title": "Plan Upgrade Workflow", + "description": "Subscription plan upgrade workflow with feature comparison, proration calculation, immediate feature unlock, and billing adjustment.", + "kind": "workflow", + "sourceDomain": "business-operations", + "primaryUseCase": "billing", + "secondaryUseCases": [], + "useCases": [ + "billing" + ], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "plan-upgrade", + "upsell", + "proration", + "feature-unlock", + "expansion-revenue", + "billing" + ], + "sourcePath": "business-operations/plan-upgrade", + "repoPath": "billing/business-operations/plan-upgrade-workflow" + }, + { + "slug": "polling-pattern-workflow", + "title": "Polling Pattern Workflow", + "description": "This workflow models periodically checking status until work is done.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 13, + "numLanes": 4, + "tags": [ + "polling", + "pattern", + "patterns", + "loop" + ], + "sourcePath": "patterns/polling-pattern", + "repoPath": "uncategorized/patterns/polling-pattern-workflow" + }, + { + "slug": "process-manager-workflow", + "title": "Process Manager Workflow", + "description": "This workflow models orchestrating multiple services to complete a process.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "process", + "manager", + "patterns" + ], + "sourcePath": "patterns/process-manager", + "repoPath": "uncategorized/patterns/process-manager-workflow" + }, + { + "slug": "procurement-card-workflow", + "title": "Procurement Card Workflow", + "description": "This workflow models managing company credit cards.", + "kind": "workflow", + "sourceDomain": "finance", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "procurement", + "card", + "finance" + ], + "sourcePath": "finance/procurement-card", + "repoPath": "uncategorized/finance/procurement-card-workflow" + }, + { + "slug": "promotion-process-workflow", + "title": "Promotion Process Workflow", + "description": "Employee promotion workflow with performance validation, job level assessment, compensation adjustment, title change, and announcement coordination.", + "kind": "workflow", + "sourceDomain": "hr", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "promotion-process", + "career-advancement", + "job-leveling", + "title-change", + "compensation-adjustment", + "succession-planning" + ], + "sourcePath": "hr/promotion-process", + "repoPath": "uncategorized/hr/promotion-process-workflow" + }, + { + "slug": "pto-request-workflow", + "title": "Pto Request Workflow", + "description": "PTO request workflow with balance verification, manager approval, calendar blocking, and team coverage check before approval.", + "kind": "workflow", + "sourceDomain": "hr", + "primaryUseCase": "approval", + "secondaryUseCases": [], + "useCases": [ + "approval" + ], + "complexity": 2, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "pto-request", + "time-off", + "vacation", + "leave-management", + "manager-approval", + "accrual-balance" + ], + "sourcePath": "hr/pto-request", + "repoPath": "approval/hr/pto-request-workflow" + }, + { + "slug": "pub-sub-workflow", + "title": "Pub Sub Workflow", + "description": "This workflow models one publisher notifying many subscribers of events.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 13, + "numLanes": 4, + "tags": [ + "pub", + "sub", + "patterns" + ], + "sourcePath": "patterns/pub-sub", + "repoPath": "uncategorized/patterns/pub-sub-workflow" + }, + { + "slug": "purchase-order-workflow", + "title": "Purchase Order Workflow", + "description": "Procurement purchase order workflow with requisition creation, budget validation, vendor sourcing, competitive bidding, and tiered approval routing based on amount thresholds.", + "kind": "workflow", + "sourceDomain": "finance", + "primaryUseCase": "approval", + "secondaryUseCases": [ + "ai-orchestration" + ], + "useCases": [ + "approval", + "ai-orchestration" + ], + "complexity": 4, + "numNodes": 22, + "numLanes": 3, + "tags": [ + "purchase-order", + "procurement", + "requisition", + "vendor-sourcing", + "competitive-bidding", + "tiered-approval", + "budget-validation" + ], + "sourcePath": "finance/purchase-order", + "repoPath": "approval/finance/purchase-order-workflow" + }, + { + "slug": "push-notification-workflow", + "title": "Push Notification Workflow", + "description": "Mobile push notification workflow with audience targeting, platform routing (iOS/Android), delivery tracking, and engagement analytics.", + "kind": "workflow", + "sourceDomain": "business-operations", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "push-notification", + "mobile-engagement", + "firebase-fcm", + "apns", + "segmentation", + "deep-linking" + ], + "sourcePath": "business-operations/push-notification", + "repoPath": "uncategorized/business-operations/push-notification-workflow" + }, + { + "slug": "put-away-process-workflow", + "title": "Put Away Process Workflow", + "description": "Warehouse put-away workflow with location assignment, slotting optimization, forklift routing, barcode confirmation, and WMS location update.", + "kind": "workflow", + "sourceDomain": "logistics", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 2, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "put-away", + "warehouse-storage", + "location-assignment", + "slotting", + "wms", + "inventory-placement" + ], + "sourcePath": "logistics/put-away-process", + "repoPath": "uncategorized/logistics/put-away-process-workflow" + }, + { + "slug": "quality-inspection-workflow", + "title": "Quality Inspection Workflow", + "description": "Incoming quality inspection workflow with AQL sampling, defect classification, hold/release decision, supplier notification, and quality metrics tracking.", + "kind": "workflow", + "sourceDomain": "logistics", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "quality-inspection", + "incoming-inspection", + "aql-sampling", + "defect-tracking", + "supplier-quality", + "hold-release" + ], + "sourcePath": "logistics/quality-inspection", + "repoPath": "uncategorized/logistics/quality-inspection-workflow" + }, + { + "slug": "rate-limiter-workflow", + "title": "Rate Limiter Workflow", + "description": "This workflow models preventing too many requests from being processed.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 13, + "numLanes": 4, + "tags": [ + "rate", + "limiter", + "patterns" + ], + "sourcePath": "patterns/rate-limiter", + "repoPath": "uncategorized/patterns/rate-limiter-workflow" + }, + { + "slug": "reference-check-workflow", + "title": "Reference Check Workflow", + "description": "Professional reference check workflow with reference collection, outreach scheduling, structured interview questions, feedback documentation, and hiring recommendation.", + "kind": "workflow", + "sourceDomain": "hr", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "reference-check", + "employment-verification", + "professional-references", + "hiring-decision", + "candidate-vetting", + "feedback-collection" + ], + "sourcePath": "hr/reference-check", + "repoPath": "uncategorized/hr/reference-check-workflow" + }, + { + "slug": "referral-program-workflow", + "title": "Referral Program Workflow", + "description": "Customer referral program workflow with unique link generation, referral tracking, conversion validation, and dual-sided reward fulfillment.", + "kind": "workflow", + "sourceDomain": "business-operations", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 13, + "numLanes": 4, + "tags": [ + "referral-program", + "viral-growth", + "referral-tracking", + "reward-fulfillment", + "affiliate", + "word-of-mouth" + ], + "sourcePath": "business-operations/referral-program", + "repoPath": "uncategorized/business-operations/referral-program-workflow" + }, + { + "slug": "relocation-assistance-workflow", + "title": "Relocation Assistance Workflow", + "description": "This workflow models helping employees relocate.", + "kind": "workflow", + "sourceDomain": "hr", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "relocation", + "assistance", + "hr", + "decision" + ], + "sourcePath": "hr/relocation-assistance", + "repoPath": "uncategorized/hr/relocation-assistance-workflow" + }, + { + "slug": "reorder-process-workflow", + "title": "Reorder Process Workflow", + "description": "Inventory reorder workflow with reorder point monitoring, economic order quantity calculation, safety stock consideration, and automatic purchase requisition generation.", + "kind": "workflow", + "sourceDomain": "logistics", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "reorder-process", + "reorder-point", + "safety-stock", + "eoq", + "demand-planning", + "auto-replenishment" + ], + "sourcePath": "logistics/reorder-process", + "repoPath": "uncategorized/logistics/reorder-process-workflow" + }, + { + "slug": "request-reply-workflow", + "title": "Request Reply Workflow", + "description": "This workflow models a synchronous request that waits for a reply.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 2, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "request", + "reply", + "patterns" + ], + "sourcePath": "patterns/request-reply", + "repoPath": "uncategorized/patterns/request-reply-workflow" + }, + { + "slug": "retry-with-backoff-workflow", + "title": "Retry With Backoff Workflow", + "description": "Exponential backoff retry pattern for API calls with configurable retry limits, delay calculation, retryable error detection, and graceful degradation on permanent failures.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 20, + "numLanes": 3, + "tags": [ + "retry-pattern", + "exponential-backoff", + "fault-tolerance", + "api-resilience", + "transient-errors", + "http-retry", + "jitter" + ], + "sourcePath": "patterns/retry-with-backoff", + "repoPath": "uncategorized/patterns/retry-with-backoff-workflow" + }, + { + "slug": "returns-processing-workflow", + "title": "Returns Processing Workflow", + "description": "Customer returns processing workflow with RMA generation, return receipt, quality inspection, disposition decision, and refund or exchange processing.", + "kind": "workflow", + "sourceDomain": "logistics", + "primaryUseCase": "billing", + "secondaryUseCases": [], + "useCases": [ + "billing" + ], + "complexity": 3, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "returns-processing", + "rma", + "refund", + "restocking", + "quality-inspection", + "reverse-logistics" + ], + "sourcePath": "logistics/returns-processing", + "repoPath": "billing/logistics/returns-processing-workflow" + }, + { + "slug": "reverse-logistics-workflow", + "title": "Reverse Logistics Workflow", + "description": "Reverse logistics workflow with return authorization, product grading, refurbishment decision, recycling coordination, and secondary market disposition.", + "kind": "workflow", + "sourceDomain": "logistics", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "reverse-logistics", + "product-returns", + "refurbishment", + "recycling", + "disposition", + "sustainability" + ], + "sourcePath": "logistics/reverse-logistics", + "repoPath": "uncategorized/logistics/reverse-logistics-workflow" + }, + { + "slug": "review-collection-workflow", + "title": "Review Collection Workflow", + "description": "Customer review collection workflow with post-purchase trigger, review request email, rating submission, moderation, and public display.", + "kind": "workflow", + "sourceDomain": "business-operations", + "primaryUseCase": "approval", + "secondaryUseCases": [], + "useCases": [ + "approval" + ], + "complexity": 2, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "review-collection", + "customer-feedback", + "nps", + "ratings", + "social-proof", + "testimonials" + ], + "sourcePath": "business-operations/review-collection", + "repoPath": "approval/business-operations/review-collection-workflow" + }, + { + "slug": "router-workflow", + "title": "Router Workflow", + "description": "This workflow models routing messages based on their content.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "router", + "patterns", + "decision" + ], + "sourcePath": "patterns/router", + "repoPath": "uncategorized/patterns/router-workflow" + }, + { + "slug": "routing-slip-workflow", + "title": "Routing Slip Workflow", + "description": "This workflow models having messages carry their own routing instructions.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "handoff", + "secondaryUseCases": [], + "useCases": [ + "handoff" + ], + "complexity": 4, + "numNodes": 13, + "numLanes": 4, + "tags": [ + "routing", + "slip", + "patterns" + ], + "sourcePath": "patterns/routing-slip", + "repoPath": "handoff/patterns/routing-slip-workflow" + }, + { + "slug": "saga-pattern-workflow", + "title": "Saga Pattern Workflow", + "description": "Saga orchestration pattern for distributed transactions across Order, Payment, and Shipping services with automatic compensation rollback on failures.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "delivery", + "secondaryUseCases": [ + "ai-orchestration" + ], + "useCases": [ + "delivery", + "ai-orchestration" + ], + "complexity": 5, + "numNodes": 20, + "numLanes": 4, + "tags": [ + "saga-pattern", + "distributed-transactions", + "microservices", + "compensation", + "orchestration", + "eventual-consistency", + "rollback" + ], + "sourcePath": "patterns/saga-pattern", + "repoPath": "delivery/patterns/saga-pattern-workflow" + }, + { + "slug": "salary-increase-workflow", + "title": "Salary Increase Workflow", + "description": "Salary increase workflow with market analysis, comp ratio review, budget validation, tiered approval based on increase percentage, and payroll system update.", + "kind": "workflow", + "sourceDomain": "hr", + "primaryUseCase": "approval", + "secondaryUseCases": [], + "useCases": [ + "approval" + ], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "salary-increase", + "compensation", + "merit-raise", + "market-adjustment", + "budget-approval", + "comp-ratio" + ], + "sourcePath": "hr/salary-increase", + "repoPath": "approval/hr/salary-increase-workflow" + }, + { + "slug": "search-optimization-workflow", + "title": "Search Optimization Workflow", + "description": "Search optimization workflow with query analysis, relevance tuning, synonym management, click-through tracking, and A/B testing of ranking algorithms.", + "kind": "workflow", + "sourceDomain": "business-operations", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 13, + "numLanes": 4, + "tags": [ + "search-optimization", + "elasticsearch", + "relevance-tuning", + "query-analysis", + "algolia", + "search-analytics" + ], + "sourcePath": "business-operations/search-optimization", + "repoPath": "uncategorized/business-operations/search-optimization-workflow" + }, + { + "slug": "secret-rotation-workflow", + "title": "Secret Rotation Workflow", + "description": "Automated secret rotation workflow with HashiCorp Vault for API keys, database passwords, and certificates including Kubernetes secret updates and rolling service restarts.", + "kind": "workflow", + "sourceDomain": "devops", + "primaryUseCase": "security", + "secondaryUseCases": [], + "useCases": [ + "security" + ], + "complexity": 4, + "numNodes": 18, + "numLanes": 3, + "tags": [ + "secret-rotation", + "vault", + "kubernetes-secrets", + "api-keys", + "database-passwords", + "certificates", + "security" + ], + "sourcePath": "devops/secret-rotation", + "repoPath": "security/devops/secret-rotation-workflow" + }, + { + "slug": "security-scan-workflow", + "title": "Security Scan Workflow", + "description": "Security scanning workflow with SAST, DAST, dependency vulnerability scanning, finding triage, and remediation tracking in CI/CD pipeline.", + "kind": "workflow", + "sourceDomain": "devops", + "primaryUseCase": "security", + "secondaryUseCases": [], + "useCases": [ + "security" + ], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "security-scanning", + "sast", + "dast", + "dependency-check", + "snyk", + "devsecops" + ], + "sourcePath": "devops/security-scan", + "repoPath": "security/devops/security-scan-workflow" + }, + { + "slug": "shipping-process-workflow", + "title": "Shipping Process Workflow", + "description": "Order shipping workflow with carrier selection, rate shopping, label generation, tracking number assignment, and dispatch confirmation.", + "kind": "workflow", + "sourceDomain": "logistics", + "primaryUseCase": "security", + "secondaryUseCases": [], + "useCases": [ + "security" + ], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "shipping-process", + "order-fulfillment", + "carrier-selection", + "label-generation", + "tracking-number", + "dispatch" + ], + "sourcePath": "logistics/shipping-process", + "repoPath": "security/logistics/shipping-process-workflow" + }, + { + "slug": "sms-verification-workflow", + "title": "Sms Verification Workflow", + "description": "SMS phone verification workflow with OTP generation, rate limiting, code validation, retry handling, and verification status tracking.", + "kind": "workflow", + "sourceDomain": "business-operations", + "primaryUseCase": "security", + "secondaryUseCases": [], + "useCases": [ + "security" + ], + "complexity": 3, + "numNodes": 13, + "numLanes": 4, + "tags": [ + "sms-verification", + "otp", + "twilio", + "phone-verification", + "2fa", + "fraud-prevention" + ], + "sourcePath": "business-operations/sms-verification", + "repoPath": "security/business-operations/sms-verification-workflow" + }, + { + "slug": "snapshot-pattern-workflow", + "title": "Snapshot Pattern Workflow", + "description": "This workflow models taking periodic snapshots of important state.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 2, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "snapshot", + "pattern", + "patterns", + "decision", + "loop" + ], + "sourcePath": "patterns/snapshot-pattern", + "repoPath": "uncategorized/patterns/snapshot-pattern-workflow" + }, + { + "slug": "state-machine-workflow", + "title": "State Machine Workflow", + "description": "This workflow models tracking object state changes over time.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 13, + "numLanes": 4, + "tags": [ + "state", + "machine", + "patterns", + "parallel" + ], + "sourcePath": "patterns/state-machine", + "repoPath": "uncategorized/patterns/state-machine-workflow" + }, + { + "slug": "stock-transfer-workflow", + "title": "Stock Transfer Workflow", + "description": "Internal stock transfer workflow with transfer request, source location pick, destination put-away, and inventory record updates across locations.", + "kind": "workflow", + "sourceDomain": "logistics", + "primaryUseCase": "handoff", + "secondaryUseCases": [], + "useCases": [ + "handoff" + ], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "stock-transfer", + "inventory-movement", + "location-transfer", + "bin-to-bin", + "wms", + "inventory-rebalancing" + ], + "sourcePath": "logistics/stock-transfer", + "repoPath": "handoff/logistics/stock-transfer-workflow" + }, + { + "slug": "strangler-fig-workflow", + "title": "Strangler Fig Workflow", + "description": "This workflow models gradually replacing an old system with a new one.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 2, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "strangler", + "fig", + "patterns", + "decision" + ], + "sourcePath": "patterns/strangler-fig", + "repoPath": "uncategorized/patterns/strangler-fig-workflow" + }, + { + "slug": "subscription-lifecycle-workflow", + "title": "Subscription Lifecycle Workflow", + "description": "SaaS subscription lifecycle workflow with trial signup, conversion nurturing, payment processing, renewal management, and churn prevention campaigns.", + "kind": "workflow", + "sourceDomain": "business-operations", + "primaryUseCase": "billing", + "secondaryUseCases": [], + "useCases": [ + "billing" + ], + "complexity": 4, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "subscription-lifecycle", + "saas", + "trial-conversion", + "renewal", + "churn-prevention", + "stripe" + ], + "sourcePath": "business-operations/subscription-lifecycle", + "repoPath": "billing/business-operations/subscription-lifecycle-workflow" + }, + { + "slug": "support-ticket-workflow", + "title": "Support Ticket Workflow", + "description": "Customer support ticket workflow with auto-categorization, SLA tracking, agent assignment, escalation rules, and satisfaction survey.", + "kind": "workflow", + "sourceDomain": "business-operations", + "primaryUseCase": "handoff", + "secondaryUseCases": [ + "support" + ], + "useCases": [ + "handoff", + "support" + ], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "support-ticket", + "helpdesk", + "zendesk", + "sla", + "ticket-routing", + "customer-service" + ], + "sourcePath": "business-operations/support-ticket", + "repoPath": "handoff/business-operations/support-ticket-workflow" + }, + { + "slug": "tax-filing-workflow", + "title": "Tax Filing Workflow", + "description": "Corporate tax filing workflow with taxable income calculation, deductions, tax credits, variance review, and electronic or paper filing to IRS with receipt confirmation.", + "kind": "workflow", + "sourceDomain": "finance", + "primaryUseCase": "compliance", + "secondaryUseCases": [], + "useCases": [ + "compliance" + ], + "complexity": 4, + "numNodes": 19, + "numLanes": 3, + "tags": [ + "tax-filing", + "corporate-tax", + "tax-calculation", + "irs-efile", + "tax-credits", + "deductions", + "compliance" + ], + "sourcePath": "finance/tax-filing", + "repoPath": "compliance/finance/tax-filing-workflow" + }, + { + "slug": "termination-process-workflow", + "title": "Termination Process Workflow", + "description": "Employee termination workflow handling voluntary and involuntary separations with legal review, separation agreements, final pay calculation, COBRA notices, and severance processing.", + "kind": "workflow", + "sourceDomain": "hr", + "primaryUseCase": "approval", + "secondaryUseCases": [ + "offboarding" + ], + "useCases": [ + "approval", + "offboarding" + ], + "complexity": 4, + "numNodes": 20, + "numLanes": 3, + "tags": [ + "employee-termination", + "offboarding", + "separation-agreement", + "final-pay", + "cobra", + "severance", + "legal-review" + ], + "sourcePath": "hr/termination-process", + "repoPath": "approval/hr/termination-process-workflow" + }, + { + "slug": "timeout-pattern-workflow", + "title": "Timeout Pattern Workflow", + "description": "This workflow models an operation that times out after a delay.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 13, + "numLanes": 4, + "tags": [ + "timeout", + "pattern", + "patterns" + ], + "sourcePath": "patterns/timeout-pattern", + "repoPath": "uncategorized/patterns/timeout-pattern-workflow" + }, + { + "slug": "training-enrollment-workflow", + "title": "Training Enrollment Workflow", + "description": "Training enrollment workflow with course catalog browsing, manager approval, LMS registration, completion tracking, and certification management.", + "kind": "workflow", + "sourceDomain": "hr", + "primaryUseCase": "compliance", + "secondaryUseCases": [], + "useCases": [ + "compliance" + ], + "complexity": 2, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "training-enrollment", + "learning-management", + "lms", + "professional-development", + "compliance-training", + "certification" + ], + "sourcePath": "hr/training-enrollment", + "repoPath": "compliance/hr/training-enrollment-workflow" + }, + { + "slug": "transactional-outbox-workflow", + "title": "Transactional Outbox Workflow", + "description": "This workflow models writing data and publishing messages in one transaction.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 13, + "numLanes": 4, + "tags": [ + "transactional", + "outbox", + "patterns", + "parallel" + ], + "sourcePath": "patterns/transactional-outbox", + "repoPath": "uncategorized/patterns/transactional-outbox-workflow" + }, + { + "slug": "transform-workflow", + "title": "Transform Workflow", + "description": "This workflow models converting messages into a new shape.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 2, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "transform", + "patterns" + ], + "sourcePath": "patterns/transform", + "repoPath": "uncategorized/patterns/transform-workflow" + }, + { + "slug": "treasury-management-workflow", + "title": "Treasury Management Workflow", + "description": "Corporate treasury management workflow with cash pooling, FX exposure hedging, short-term investment decisions, and bank relationship management.", + "kind": "workflow", + "sourceDomain": "finance", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "treasury-management", + "cash-pooling", + "fx-hedging", + "investment-portfolio", + "bank-relationships", + "liquidity" + ], + "sourcePath": "finance/treasury-management", + "repoPath": "uncategorized/finance/treasury-management-workflow" + }, + { + "slug": "two-factor-setup-workflow", + "title": "Two Factor Setup Workflow", + "description": "Two-factor authentication setup workflow with method selection (TOTP/SMS), QR code generation, backup codes, and verification confirmation.", + "kind": "workflow", + "sourceDomain": "business-operations", + "primaryUseCase": "onboarding", + "secondaryUseCases": [ + "security" + ], + "useCases": [ + "onboarding", + "security" + ], + "complexity": 2, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "two-factor-auth", + "mfa", + "totp", + "authenticator-app", + "security", + "account-protection" + ], + "sourcePath": "business-operations/two-factor-setup", + "repoPath": "onboarding/business-operations/two-factor-setup-workflow" + }, + { + "slug": "user-onboarding-workflow", + "title": "User Onboarding Workflow", + "description": "New user onboarding workflow with welcome email, profile setup, product tour, first action prompt, and activation milestone tracking.", + "kind": "workflow", + "sourceDomain": "business-operations", + "primaryUseCase": "onboarding", + "secondaryUseCases": [], + "useCases": [ + "onboarding" + ], + "complexity": 2, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "user-onboarding", + "activation", + "product-tour", + "welcome-email", + "first-time-user", + "time-to-value" + ], + "sourcePath": "business-operations/user-onboarding", + "repoPath": "onboarding/business-operations/user-onboarding-workflow" + }, + { + "slug": "user-segmentation-workflow", + "title": "User Segmentation Workflow", + "description": "User segmentation workflow with attribute collection, behavioral event tracking, segment rule definition, dynamic membership, and downstream sync.", + "kind": "workflow", + "sourceDomain": "business-operations", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 2, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "user-segmentation", + "audience-targeting", + "behavioral-cohorts", + "customer-segments", + "segment", + "marketing-automation" + ], + "sourcePath": "business-operations/user-segmentation", + "repoPath": "uncategorized/business-operations/user-segmentation-workflow" + }, + { + "slug": "validator-workflow", + "title": "Validator Workflow", + "description": "This workflow models checking that incoming data is valid.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 2, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "validator", + "patterns", + "parallel" + ], + "sourcePath": "patterns/validator", + "repoPath": "uncategorized/patterns/validator-workflow" + }, + { + "slug": "vendor-onboarding-workflow", + "title": "Vendor Onboarding Workflow", + "description": "Vendor onboarding workflow with application review, W-9/W-8BEN verification, insurance certificate validation, background checks, and compliance approval before vendor activation.", + "kind": "workflow", + "sourceDomain": "finance", + "primaryUseCase": "onboarding", + "secondaryUseCases": [ + "billing", + "compliance" + ], + "useCases": [ + "onboarding", + "billing", + "compliance" + ], + "complexity": 4, + "numNodes": 19, + "numLanes": 3, + "tags": [ + "vendor-onboarding", + "supplier-management", + "w9-verification", + "insurance-compliance", + "background-check", + "payment-terms", + "procurement" + ], + "sourcePath": "finance/vendor-onboarding", + "repoPath": "onboarding/finance/vendor-onboarding-workflow" + }, + { + "slug": "vulnerability-patch-workflow", + "title": "Vulnerability Patch Workflow", + "description": "Security vulnerability patching workflow with CVE scanning, severity-based triage (critical/high/medium), patch testing, staging deployment, and production rollout with rollback capability.", + "kind": "workflow", + "sourceDomain": "devops", + "primaryUseCase": "security", + "secondaryUseCases": [ + "compliance", + "delivery" + ], + "useCases": [ + "security", + "compliance", + "delivery" + ], + "complexity": 4, + "numNodes": 19, + "numLanes": 3, + "tags": [ + "vulnerability-management", + "security-patching", + "cve-triage", + "cvss-scoring", + "patch-testing", + "rollback", + "compliance" + ], + "sourcePath": "devops/vulnerability-patch", + "repoPath": "security/devops/vulnerability-patch-workflow" + }, + { + "slug": "warehouse-transfer-workflow", + "title": "Warehouse Transfer Workflow", + "description": "Inter-warehouse transfer workflow with transfer order creation, shipping from source DC, in-transit tracking, and receiving at destination warehouse.", + "kind": "workflow", + "sourceDomain": "logistics", + "primaryUseCase": "handoff", + "secondaryUseCases": [], + "useCases": [ + "handoff" + ], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "warehouse-transfer", + "inter-facility", + "transfer-order", + "in-transit-inventory", + "network-optimization", + "distribution" + ], + "sourcePath": "logistics/warehouse-transfer", + "repoPath": "handoff/logistics/warehouse-transfer-workflow" + }, + { + "slug": "webhook-integration-workflow", + "title": "Webhook Integration Workflow", + "description": "Webhook integration workflow with endpoint registration, payload signing, delivery attempt, retry with backoff, and delivery status tracking.", + "kind": "workflow", + "sourceDomain": "business-operations", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 2, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "webhook", + "event-driven", + "http-callback", + "integration", + "retry-logic", + "payload-signing" + ], + "sourcePath": "business-operations/webhook-integration", + "repoPath": "uncategorized/business-operations/webhook-integration-workflow" + }, + { + "slug": "webhook-pattern-workflow", + "title": "Webhook Pattern Workflow", + "description": "This workflow models an HTTP callback when an event occurs.", + "kind": "workflow", + "sourceDomain": "patterns", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 2, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "webhook", + "pattern", + "patterns", + "decision", + "loop" + ], + "sourcePath": "patterns/webhook-pattern", + "repoPath": "uncategorized/patterns/webhook-pattern-workflow" + }, + { + "slug": "webinar-registration-workflow", + "title": "Webinar Registration Workflow", + "description": "Webinar registration workflow with signup form, calendar invite, reminder email sequence, attendance tracking, and post-event follow-up.", + "kind": "workflow", + "sourceDomain": "business-operations", + "primaryUseCase": "onboarding", + "secondaryUseCases": [], + "useCases": [ + "onboarding" + ], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "webinar", + "event-registration", + "zoom", + "calendar-invite", + "reminder-sequence", + "lead-capture" + ], + "sourcePath": "business-operations/webinar-registration", + "repoPath": "onboarding/business-operations/webinar-registration-workflow" + }, + { + "slug": "yearly-audit-workflow", + "title": "Yearly Audit Workflow", + "description": "Annual financial audit workflow with external auditor engagement, document preparation, fieldwork coordination, findings remediation, and management letter response.", + "kind": "workflow", + "sourceDomain": "finance", + "primaryUseCase": "compliance", + "secondaryUseCases": [], + "useCases": [ + "compliance" + ], + "complexity": 4, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "annual-audit", + "external-auditors", + "sox-compliance", + "financial-statements", + "audit-findings", + "management-letter" + ], + "sourcePath": "finance/yearly-audit", + "repoPath": "compliance/finance/yearly-audit-workflow" + }, + { + "slug": "shopify-universal-commerce-protocol", + "title": "Shopify Universal Commerce Protocol", + "description": "End-to-end agentic commerce workflow showing how an AI assistant (ChatGPT) orchestrates product search, checkout, and payment through Shopify's Universal Commerce Protocol (UCP) gateway, enabling conversational shopping experiences.", + "kind": "workflow", + "sourceDomain": "business-operations", + "primaryUseCase": "billing", + "secondaryUseCases": [ + "agentic" + ], + "useCases": [ + "billing", + "agentic" + ], + "complexity": 4, + "numNodes": 47, + "numLanes": 5, + "tags": [ + "shopify", + "ucp", + "universal-commerce-protocol", + "agentic-commerce", + "ai-shopping", + "chatgpt", + "e-commerce", + "checkout", + "payment" + ], + "sourcePath": "business-operations/shopify-universal-commerce-protocol", + "repoPath": "billing/business-operations/shopify-universal-commerce-protocol" + }, + { + "slug": "microservices-api-gateway-architecture", + "title": "Microservices API Gateway Architecture", + "description": "A microservices API gateway architecture diagram showing request routing, JWT authentication, rate limiting, service discovery, and response aggregation across distributed backend services. This template models the entry point for all client traffic in a microservices ecosystem, enforcing security policies before requests reach internal services. Ideal for platform engineers designing scalable API infrastructure with centralized cross-cutting concerns.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "security", + "secondaryUseCases": [ + "mcp" + ], + "useCases": [ + "security", + "mcp" + ], + "complexity": 4, + "numNodes": 17, + "numLanes": 3, + "tags": [ + "microservices", + "api-gateway", + "jwt-authentication", + "rate-limiting", + "service-discovery", + "load-balancing", + "architecture-diagram", + "distributed-systems" + ], + "sourcePath": "", + "repoPath": "security/architecture/microservices-api-gateway-architecture" + }, + { + "slug": "microservices-service-mesh-architecture", + "title": "Microservices Service Mesh Architecture", + "description": "A service mesh architecture diagram with Istio or Linkerd sidecar proxies handling mTLS encryption, traffic policies, circuit breaking, and distributed tracing across microservices. This template visualizes how a service mesh abstracts networking concerns away from application code, enabling zero-trust communication between services. Essential for teams adopting service mesh infrastructure to improve observability and security.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "mcp", + "secondaryUseCases": [], + "useCases": [ + "mcp" + ], + "complexity": 4, + "numNodes": 18, + "numLanes": 3, + "tags": [ + "service-mesh", + "istio", + "linkerd", + "mtls", + "sidecar-proxy", + "distributed-tracing", + "traffic-management", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "mcp/architecture/microservices-service-mesh-architecture" + }, + { + "slug": "microservices-database-per-service-architecture", + "title": "Microservices Database-Per-Service Architecture", + "description": "A database-per-service architecture diagram where each microservice owns its dedicated data store, with event-driven synchronization via Kafka for cross-service data consistency. This template demonstrates the core microservices data isolation principle, showing how PostgreSQL and MongoDB coexist in a polyglot persistence strategy. Critical for architects enforcing service autonomy while maintaining eventual consistency.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 16, + "numLanes": 4, + "tags": [ + "database-per-service", + "polyglot-persistence", + "microservices", + "kafka", + "event-driven", + "data-isolation", + "eventual-consistency", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "uncategorized/architecture/microservices-database-per-service-architecture" + }, + { + "slug": "microservices-decomposition-by-business-capability", + "title": "Microservices Decomposition by Business Capability", + "description": "A microservices decomposition architecture diagram organized by business capabilities: Identity, Product Catalog, Pricing, and Order Fulfillment, each with independent data stores and APIs. This template shows how to break a monolith into services aligned with business domains, using a Backend-for-Frontend (BFF) pattern for client-specific aggregation. Useful for architects planning domain-driven microservice boundaries.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 17, + "numLanes": 5, + "tags": [ + "microservices-decomposition", + "business-capability", + "bff", + "domain-driven-design", + "service-boundaries", + "monolith-to-microservices", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "uncategorized/architecture/microservices-decomposition-by-business-capability" + }, + { + "slug": "microservices-strangler-fig-migration", + "title": "Microservices Strangler Fig Migration Architecture", + "description": "A strangler fig migration architecture diagram showing the incremental replacement of a legacy monolith with new microservices, using a routing layer to split traffic between old and new systems. This template models the proven migration strategy where new features are built as microservices while legacy endpoints are gradually retired. Essential for teams modernizing legacy systems without risky big-bang rewrites.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "delivery", + "secondaryUseCases": [], + "useCases": [ + "delivery" + ], + "complexity": 4, + "numNodes": 16, + "numLanes": 4, + "tags": [ + "strangler-fig", + "legacy-migration", + "monolith-decomposition", + "anti-corruption-layer", + "incremental-migration", + "modernization", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "delivery/architecture/microservices-strangler-fig-migration" + }, + { + "slug": "microservices-service-discovery-architecture", + "title": "Microservices Service Discovery Architecture", + "description": "A service discovery architecture diagram with Consul or Eureka registry, client-side load balancing, health check heartbeats, and automatic instance registration and deregistration. This template visualizes how microservices dynamically locate each other without hardcoded endpoints, enabling elastic scaling and self-healing infrastructure. Key for platform teams building resilient service-to-service communication.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "handoff", + "secondaryUseCases": [], + "useCases": [ + "handoff" + ], + "complexity": 3, + "numNodes": 16, + "numLanes": 3, + "tags": [ + "service-discovery", + "consul", + "eureka", + "health-check", + "client-side-load-balancing", + "service-registry", + "dynamic-routing", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "handoff/architecture/microservices-service-discovery-architecture" + }, + { + "slug": "microservices-sidecar-pattern-architecture", + "title": "Microservices Sidecar Pattern Architecture", + "description": "A sidecar pattern architecture diagram showing Envoy proxy, log collector, and config watcher sidecars running alongside application containers in a Kubernetes pod, with a control plane managing configuration. This template demonstrates how auxiliary concerns like logging, monitoring, and configuration are deployed as co-located containers. Foundational for teams adopting cloud-native container orchestration patterns.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "mcp", + "secondaryUseCases": [], + "useCases": [ + "mcp" + ], + "complexity": 4, + "numNodes": 13, + "numLanes": 3, + "tags": [ + "sidecar-pattern", + "envoy-proxy", + "kubernetes", + "container-pattern", + "observability", + "control-plane", + "cloud-native", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "mcp/architecture/microservices-sidecar-pattern-architecture" + }, + { + "slug": "microservices-backend-for-frontend-architecture", + "title": "Microservices Backend-for-Frontend (BFF) Architecture", + "description": "A Backend-for-Frontend architecture diagram with separate BFF layers for web and mobile clients, each optimizing API responses for their specific platform while sharing common backend microservices. This template shows how to avoid one-size-fits-all APIs by tailoring data aggregation and payload optimization per client type. Recommended for teams serving multiple frontend platforms from a shared microservices backend.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 12, + "numLanes": 3, + "tags": [ + "backend-for-frontend", + "bff-pattern", + "mobile-api", + "web-api", + "api-aggregation", + "payload-optimization", + "microservices", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "uncategorized/architecture/microservices-backend-for-frontend-architecture" + }, + { + "slug": "event-driven-publish-subscribe-architecture", + "title": "Event-Driven Publish-Subscribe Architecture", + "description": "An event-driven publish-subscribe architecture diagram with Kafka or RabbitMQ message broker, event serialization, topic partitioning, fan-out delivery to multiple consumers, and dead letter queue error handling. This template models the foundational async messaging pattern where producers and consumers are fully decoupled through a message broker. Essential for architects building loosely coupled, scalable event-driven systems.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 17, + "numLanes": 3, + "tags": [ + "publish-subscribe", + "event-driven", + "kafka", + "rabbitmq", + "message-broker", + "fan-out", + "dead-letter-queue", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "uncategorized/architecture/event-driven-publish-subscribe-architecture" + }, + { + "slug": "event-driven-event-sourcing-architecture", + "title": "Event-Driven Event Sourcing Architecture", + "description": "An event sourcing architecture diagram where all state changes are stored as an immutable sequence of domain events, with read projections built from the event stream and snapshot optimization for fast aggregate loading. This template shows how event sourcing eliminates data loss by preserving the complete history of every state transition. Critical for systems requiring full audit trails, temporal queries, and event replay capabilities.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 18, + "numLanes": 4, + "tags": [ + "event-sourcing", + "immutable-events", + "event-store", + "projections", + "snapshot", + "aggregate", + "temporal-query", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "uncategorized/architecture/event-driven-event-sourcing-architecture" + }, + { + "slug": "event-driven-cqrs-with-event-store-architecture", + "title": "Event-Driven CQRS with Event Store Architecture", + "description": "A CQRS architecture diagram combining separate command and query APIs with an event bus for asynchronous read model synchronization, including projectors that build denormalized views from domain events. This template demonstrates the full CQRS+ES stack where writes go through domain validation and reads are served from optimized materialized views. Ideal for high-throughput systems where read and write workloads have fundamentally different scaling requirements.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 18, + "numLanes": 4, + "tags": [ + "cqrs", + "event-store", + "command-query-separation", + "read-model", + "write-model", + "projector", + "eventual-consistency", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "uncategorized/architecture/event-driven-cqrs-with-event-store-architecture" + }, + { + "slug": "event-driven-choreography-architecture", + "title": "Event-Driven Choreography Architecture", + "description": "An event-driven choreography architecture diagram where microservices coordinate through events without a central orchestrator, with Order, Payment, Inventory, and Shipping services reacting to each other's domain events. This template models the decentralized coordination pattern where each service knows only its own responsibilities and publishes events for others to consume. Best for teams favoring autonomous services over centralized workflow control.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 19, + "numLanes": 5, + "tags": [ + "choreography", + "event-driven", + "decentralized-coordination", + "domain-events", + "microservices", + "autonomous-services", + "pub-sub", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "uncategorized/architecture/event-driven-choreography-architecture" + }, + { + "slug": "event-driven-event-streaming-pipeline-architecture", + "title": "Event-Driven Streaming Pipeline Architecture", + "description": "A real-time event streaming pipeline architecture diagram with IoT sensors, application logs, and clickstream data flowing through Kafka into Apache Flink for window aggregation, anomaly detection, and multi-sink output to data lakes and dashboards. This template visualizes end-to-end stream processing from ingestion through transformation to storage and alerting. Essential for data engineers building real-time analytics and monitoring platforms.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "delivery", + "secondaryUseCases": [], + "useCases": [ + "delivery" + ], + "complexity": 4, + "numNodes": 18, + "numLanes": 4, + "tags": [ + "event-streaming", + "kafka", + "apache-flink", + "stream-processing", + "real-time-analytics", + "iot", + "data-pipeline", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "delivery/architecture/event-driven-event-streaming-pipeline-architecture" + }, + { + "slug": "event-driven-domain-events-architecture", + "title": "Event-Driven Domain Events Architecture", + "description": "A domain events architecture diagram showing how aggregate roots raise domain events that are dispatched both in-process to local handlers and cross-boundary to integration event consumers in other bounded contexts. This template models the DDD event pattern where domain logic triggers side effects through a clean event dispatcher, maintaining separation between domain and infrastructure concerns. Key for teams implementing Domain-Driven Design with event-based integration.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "security", + "secondaryUseCases": [], + "useCases": [ + "security" + ], + "complexity": 4, + "numNodes": 17, + "numLanes": 4, + "tags": [ + "domain-events", + "ddd", + "aggregate-root", + "bounded-context", + "event-dispatcher", + "integration-events", + "domain-driven-design", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "security/architecture/event-driven-domain-events-architecture" + }, + { + "slug": "event-driven-cdc-change-data-capture-architecture", + "title": "Event-Driven CDC (Change Data Capture) Architecture", + "description": "A Change Data Capture architecture diagram using Debezium to tail database transaction logs and publish change events to Kafka, feeding downstream consumers that update search indexes, invalidate caches, load data warehouses, and write audit logs. This template shows how CDC eliminates dual-write problems by capturing changes at the database level without modifying application code. Critical for data synchronization across heterogeneous systems.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 17, + "numLanes": 4, + "tags": [ + "change-data-capture", + "cdc", + "debezium", + "transaction-log", + "kafka-connect", + "data-synchronization", + "dual-write", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "uncategorized/architecture/event-driven-cdc-change-data-capture-architecture" + }, + { + "slug": "event-driven-dead-letter-queue-architecture", + "title": "Event-Driven Dead Letter Queue Architecture", + "description": "A dead letter queue architecture diagram with retry policies, exponential backoff, max retry thresholds, DLQ routing for failed messages, operations alerting, and manual reprocessing workflows. This template models the critical error handling pattern for asynchronous messaging systems, ensuring no message is silently lost when processing fails. Essential for building reliable event-driven systems with proper failure recovery mechanisms.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "incident", + "secondaryUseCases": [ + "compliance" + ], + "useCases": [ + "incident", + "compliance" + ], + "complexity": 3, + "numNodes": 16, + "numLanes": 3, + "tags": [ + "dead-letter-queue", + "dlq", + "retry-policy", + "message-processing", + "error-handling", + "operations-alerting", + "message-reliability", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "incident/architecture/event-driven-dead-letter-queue-architecture" + }, + { + "slug": "cqrs-read-write-separation-architecture", + "title": "CQRS Read-Write Separation Architecture", + "description": "A CQRS read-write separation architecture diagram with dedicated command and query paths, PostgreSQL for writes, Redis or Elasticsearch for optimized reads, and an event-driven synchronization layer with lag monitoring. This template demonstrates the core CQRS principle of separating read and write models to independently scale and optimize each path. Ideal for applications with asymmetric read/write ratios where query performance is critical.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 18, + "numLanes": 4, + "tags": [ + "cqrs", + "read-write-separation", + "command-query", + "postgresql", + "redis", + "elasticsearch", + "read-model-sync", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "uncategorized/architecture/cqrs-read-write-separation-architecture" + }, + { + "slug": "cqrs-materialized-view-architecture", + "title": "CQRS Materialized View Architecture", + "description": "A CQRS materialized view architecture diagram with multiple projectors building purpose-specific read models: order summaries, customer dashboards, analytics cubes, and search indexes, all fed from a single event stream. This template shows how to create multiple optimized query views from the same write events, each tailored to a specific use case with sub-millisecond read latency. Perfect for systems requiring diverse query patterns from a single data source.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 18, + "numLanes": 4, + "tags": [ + "materialized-view", + "cqrs", + "projectors", + "read-model", + "denormalization", + "query-optimization", + "event-stream", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "uncategorized/architecture/cqrs-materialized-view-architecture" + }, + { + "slug": "cqrs-task-based-ui-architecture", + "title": "CQRS Task-Based UI Architecture", + "description": "A CQRS task-based UI architecture diagram where the frontend captures user intent as explicit commands, submits them asynchronously with optimistic updates, and receives real-time confirmations via WebSocket when the read model is synchronized. This template models the modern UI pattern that replaces CRUD forms with intent-driven commands, enabling responsive user experiences with eventual consistency. Recommended for teams building reactive frontends on CQRS backends.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 19, + "numLanes": 4, + "tags": [ + "task-based-ui", + "cqrs", + "optimistic-update", + "websocket", + "command-pattern", + "idempotency", + "reactive-ui", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "uncategorized/architecture/cqrs-task-based-ui-architecture" + }, + { + "slug": "serverless-api-backend-architecture", + "title": "Serverless API Backend Architecture", + "description": "A serverless API backend architecture diagram with API Gateway, Lambda authorizer functions, business logic functions, and managed cloud services including DynamoDB, S3, SQS, and SNS for a fully managed, auto-scaling backend. This template models the serverless-first approach where infrastructure management is eliminated entirely, with pay-per-invocation pricing and automatic scaling to zero. Essential for startups and teams building cost-efficient, event-driven API backends.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "mcp", + "secondaryUseCases": [], + "useCases": [ + "mcp" + ], + "complexity": 3, + "numNodes": 15, + "numLanes": 3, + "tags": [ + "serverless", + "aws-lambda", + "api-gateway", + "dynamodb", + "cloud-architecture", + "auto-scaling", + "pay-per-use", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "mcp/architecture/serverless-api-backend-architecture" + }, + { + "slug": "serverless-event-processing-architecture", + "title": "Serverless Event Processing Architecture", + "description": "A serverless event processing architecture diagram with S3, DynamoDB Streams, API Gateway, and CloudWatch triggers invoking Lambda functions, orchestrated by Step Functions with fan-out via SQS and dead letter queue error handling. This template shows how to build complex event processing pipelines entirely from managed serverless components, with no servers to provision or manage. Ideal for data processing workflows that need elastic scaling and built-in fault tolerance.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 17, + "numLanes": 4, + "tags": [ + "serverless", + "event-processing", + "step-functions", + "lambda-triggers", + "sqs", + "s3-events", + "dynamodb-streams", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "uncategorized/architecture/serverless-event-processing-architecture" + }, + { + "slug": "serverless-step-functions-orchestration-architecture", + "title": "Serverless Step Functions Orchestration Architecture", + "description": "An AWS Step Functions orchestration architecture diagram with state machine workflows including choice states, parallel processing, wait-for-callback patterns, and compensation rollback for failed steps. This template models serverless workflow orchestration where complex multi-step processes are defined as state machines with built-in error handling and retry logic. Critical for teams building reliable serverless workflows that require human approval or long-running processes.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "incident", + "secondaryUseCases": [ + "ai-orchestration" + ], + "useCases": [ + "incident", + "ai-orchestration" + ], + "complexity": 4, + "numNodes": 17, + "numLanes": 3, + "tags": [ + "step-functions", + "serverless-orchestration", + "state-machine", + "workflow-automation", + "callback-pattern", + "compensation", + "aws", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "incident/architecture/serverless-step-functions-orchestration-architecture" + }, + { + "slug": "serverless-edge-computing-architecture", + "title": "Serverless Edge Computing Architecture", + "description": "A serverless edge computing architecture diagram with CloudFront or Cloudflare edge locations, Lambda@Edge functions for A/B testing and geo-personalization, origin shield request collapsing, and cache-first response strategies. This template visualizes how computation moves to the network edge for ultra-low latency responses, with edge functions modifying requests and responses before they reach the origin. Essential for performance-critical applications serving global audiences.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "handoff", + "secondaryUseCases": [], + "useCases": [ + "handoff" + ], + "complexity": 3, + "numNodes": 15, + "numLanes": 3, + "tags": [ + "edge-computing", + "lambda-at-edge", + "cloudfront", + "cloudflare", + "cdn", + "geo-routing", + "cache-strategy", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "handoff/architecture/serverless-edge-computing-architecture" + }, + { + "slug": "serverless-data-pipeline-architecture", + "title": "Serverless Data Pipeline Architecture", + "description": "A serverless data pipeline architecture diagram with Kinesis ingestion, Lambda transformation functions, S3 data lake storage zones (raw and curated), Glue catalog registration, and Athena query engine feeding QuickSight dashboards and SageMaker ML models. This template models a complete serverless ETL pipeline from data ingestion through transformation, cataloging, and analytics without managing any infrastructure. Ideal for data teams building cost-effective analytics platforms.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "delivery", + "secondaryUseCases": [], + "useCases": [ + "delivery" + ], + "complexity": 4, + "numNodes": 17, + "numLanes": 4, + "tags": [ + "serverless-data-pipeline", + "kinesis", + "glue", + "athena", + "s3-data-lake", + "etl", + "sagemaker", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "delivery/architecture/serverless-data-pipeline-architecture" + }, + { + "slug": "serverless-multi-cloud-architecture", + "title": "Serverless Multi-Cloud Architecture", + "description": "A multi-cloud serverless architecture diagram with DNS-based traffic routing between AWS and Azure regions, automatic failover on health check failures, and bi-directional data replication with conflict resolution across cloud providers. This template models the multi-cloud strategy for maximum availability and vendor independence, using serverless services from both AWS (Lambda, DynamoDB) and Azure (Functions, Cosmos DB). Critical for enterprises requiring cloud provider redundancy.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "handoff", + "secondaryUseCases": [], + "useCases": [ + "handoff" + ], + "complexity": 4, + "numNodes": 18, + "numLanes": 4, + "tags": [ + "multi-cloud", + "aws", + "azure", + "cloud-failover", + "dns-routing", + "data-replication", + "vendor-independence", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "handoff/architecture/serverless-multi-cloud-architecture" + }, + { + "slug": "saga-orchestration-pattern-architecture", + "title": "Saga Orchestration Pattern Architecture", + "description": "A saga orchestration architecture diagram with a central orchestrator coordinating multi-step distributed transactions across Order, Inventory, and Payment services, with a dedicated compensation chain for rollback on failure. This template models the orchestration-based saga pattern where a single coordinator manages the transaction lifecycle and triggers compensating actions when any step fails. Essential for architects implementing reliable distributed transactions without two-phase commit.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "delivery", + "secondaryUseCases": [ + "ai-orchestration" + ], + "useCases": [ + "delivery", + "ai-orchestration" + ], + "complexity": 4, + "numNodes": 19, + "numLanes": 5, + "tags": [ + "saga-pattern", + "orchestration", + "distributed-transaction", + "compensation", + "microservices", + "rollback", + "consistency", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "delivery/architecture/saga-orchestration-pattern-architecture" + }, + { + "slug": "saga-choreography-pattern-architecture", + "title": "Saga Choreography Pattern Architecture", + "description": "A saga choreography architecture diagram where Order, Payment, and Inventory services coordinate through domain events without a central orchestrator, with each service publishing and subscribing to events that drive the transaction forward or trigger compensation. This template models the decentralized saga approach where services autonomously react to events, reducing single points of failure at the cost of increased complexity in tracking saga state. Best for teams preferring service autonomy over centralized control.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 18, + "numLanes": 5, + "tags": [ + "saga-choreography", + "event-driven-saga", + "decentralized", + "domain-events", + "compensation", + "autonomous-services", + "distributed-transaction", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "uncategorized/architecture/saga-choreography-pattern-architecture" + }, + { + "slug": "saga-distributed-transaction-architecture", + "title": "Saga Distributed Transaction Architecture", + "description": "A distributed transaction architecture diagram implementing the two-phase commit protocol with a transaction coordinator sending prepare and commit messages to participating services, with global abort on any vote failure. This template visualizes the classic 2PC protocol used when strong consistency is required across multiple services, showing the prepare, vote, and commit/abort phases. Important for understanding distributed consensus trade-offs in microservices architectures.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "ai-orchestration", + "secondaryUseCases": [], + "useCases": [ + "ai-orchestration" + ], + "complexity": 4, + "numNodes": 17, + "numLanes": 4, + "tags": [ + "distributed-transaction", + "two-phase-commit", + "2pc", + "transaction-coordinator", + "consensus", + "strong-consistency", + "prepare-commit", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "ai-orchestration/architecture/saga-distributed-transaction-architecture" + }, + { + "slug": "saga-travel-booking-architecture", + "title": "Saga Travel Booking Architecture", + "description": "A travel booking saga architecture diagram orchestrating flight, hotel, and car rental reservations as a single distributed transaction, with automatic compensation to cancel all bookings if any reservation step fails. This template models the classic saga use case where multiple independent services must either all succeed or all roll back, ensuring travelers never end up with partial bookings. Perfect for demonstrating saga patterns with a real-world business scenario.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "ai-orchestration", + "secondaryUseCases": [], + "useCases": [ + "ai-orchestration" + ], + "complexity": 4, + "numNodes": 17, + "numLanes": 5, + "tags": [ + "saga-pattern", + "travel-booking", + "flight-reservation", + "hotel-booking", + "compensation", + "distributed-transaction", + "orchestration", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "ai-orchestration/architecture/saga-travel-booking-architecture" + }, + { + "slug": "saga-order-fulfillment-architecture", + "title": "Saga Order Fulfillment Architecture", + "description": "An order fulfillment saga architecture diagram with four sequential steps: customer verification, inventory reservation, payment authorization, and shipment creation, with a compensation chain that reverses completed steps on failure. This template models the end-to-end order lifecycle as a saga, showing how each service participates in the transaction and how compensating actions maintain data consistency. Ideal for e-commerce architects designing reliable order processing pipelines.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "approval", + "secondaryUseCases": [ + "billing", + "security" + ], + "useCases": [ + "approval", + "billing", + "security" + ], + "complexity": 4, + "numNodes": 18, + "numLanes": 3, + "tags": [ + "order-fulfillment", + "saga-pattern", + "e-commerce", + "payment-authorization", + "inventory-reservation", + "compensation-chain", + "distributed-transaction", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "approval/architecture/saga-order-fulfillment-architecture" + }, + { + "slug": "circuit-breaker-resilience-architecture", + "title": "Circuit Breaker Resilience Architecture", + "description": "A circuit breaker resilience architecture diagram showing the complete state machine with closed, open, and half-open states, failure threshold tracking, recovery timer, and fallback response strategies for protecting services from cascading failures. This template visualizes the circuit breaker pattern in detail, including how the breaker transitions between states based on success and failure counts. Essential for building fault-tolerant microservices that degrade gracefully under load.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "mcp", + "secondaryUseCases": [], + "useCases": [ + "mcp" + ], + "complexity": 4, + "numNodes": 18, + "numLanes": 3, + "tags": [ + "circuit-breaker", + "resilience", + "fault-tolerance", + "cascading-failure", + "half-open-state", + "fallback", + "state-machine", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "mcp/architecture/circuit-breaker-resilience-architecture" + }, + { + "slug": "bulkhead-isolation-architecture", + "title": "Bulkhead Isolation Architecture", + "description": "A bulkhead isolation architecture diagram with separate thread pools for critical, standard, and batch workloads, each with independent connection pools, exhaustion detection, and backpressure strategies to prevent one workload from starving others. This template models the bulkhead pattern inspired by ship hull compartments, where resource isolation ensures that a failure or overload in one component cannot cascade to others. Critical for systems requiring guaranteed availability for high-priority operations.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "handoff", + "secondaryUseCases": [], + "useCases": [ + "handoff" + ], + "complexity": 4, + "numNodes": 18, + "numLanes": 4, + "tags": [ + "bulkhead-pattern", + "resource-isolation", + "thread-pool", + "backpressure", + "fault-isolation", + "resilience", + "priority-routing", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "handoff/architecture/bulkhead-isolation-architecture" + }, + { + "slug": "retry-with-exponential-backoff-architecture", + "title": "Retry with Exponential Backoff Architecture", + "description": "A retry with exponential backoff architecture diagram showing the complete retry policy engine with retryable vs non-retryable error classification, exponential delay calculation with jitter, max retry thresholds, and graceful exhaustion handling. This template models the essential resilience pattern for handling transient failures in distributed systems, preventing thundering herd problems through randomized backoff delays. Foundational for any service-to-service communication in cloud architectures.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 17, + "numLanes": 3, + "tags": [ + "retry-pattern", + "exponential-backoff", + "jitter", + "transient-failure", + "resilience", + "error-handling", + "thundering-herd", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "uncategorized/architecture/retry-with-exponential-backoff-architecture" + }, + { + "slug": "rate-limiter-architecture", + "title": "Rate Limiter Architecture", + "description": "A rate limiter architecture diagram implementing the token bucket algorithm with Redis-backed distributed counters, sliding window logs, API key identification, rate limit headers, and multi-node synchronization for consistent enforcement. This template shows how to protect APIs from abuse and ensure fair usage across clients, with proper HTTP 429 responses and Retry-After headers. Essential for API platform teams building production-grade rate limiting infrastructure.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 17, + "numLanes": 4, + "tags": [ + "rate-limiter", + "token-bucket", + "sliding-window", + "redis", + "api-protection", + "throttling", + "distributed-rate-limiting", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "uncategorized/architecture/rate-limiter-architecture" + }, + { + "slug": "health-check-pattern-architecture", + "title": "Health Check Pattern Architecture", + "description": "A health check pattern architecture diagram with load balancer probes, deep health checks verifying database, cache, disk, and dependency status, automatic instance rotation, and alerting integration with PagerDuty for consecutive failures. This template models the health monitoring infrastructure that enables self-healing systems, where unhealthy instances are automatically removed from rotation and operations teams are alerted. Key for building production-ready services with proper observability.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "incident", + "secondaryUseCases": [ + "security" + ], + "useCases": [ + "incident", + "security" + ], + "complexity": 3, + "numNodes": 19, + "numLanes": 4, + "tags": [ + "health-check", + "load-balancer", + "self-healing", + "monitoring", + "pagerduty", + "instance-rotation", + "deep-health-check", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "incident/architecture/health-check-pattern-architecture" + }, + { + "slug": "hexagonal-ports-adapters-architecture", + "title": "Hexagonal (Ports and Adapters) Architecture", + "description": "A hexagonal architecture diagram showing the clean separation between domain core, inbound adapters (REST, GraphQL, CLI, message consumers), outbound adapters (PostgreSQL, Stripe, email, Redis), and the port interfaces that connect them. This template visualizes the ports and adapters pattern where the domain core has zero dependencies on infrastructure, making it fully testable and technology-agnostic. Foundational for teams adopting clean architecture principles in their codebase.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 16, + "numLanes": 4, + "tags": [ + "hexagonal-architecture", + "ports-and-adapters", + "clean-architecture", + "dependency-inversion", + "domain-core", + "testability", + "technology-agnostic", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "uncategorized/architecture/hexagonal-ports-adapters-architecture" + }, + { + "slug": "clean-architecture-layers", + "title": "Clean Architecture Layers", + "description": "A clean architecture layers diagram showing the four concentric layers: Entities (domain), Use Cases (application), Interface Adapters (controllers, presenters, repositories), and Frameworks & Drivers (web server, database, cloud SDK). This template models Uncle Bob's Clean Architecture with the dependency rule where inner layers never depend on outer layers, ensuring the domain model remains pure and framework-independent. Essential reference for software architects enforcing architectural boundaries.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 3, + "numNodes": 16, + "numLanes": 4, + "tags": [ + "clean-architecture", + "uncle-bob", + "dependency-rule", + "layered-architecture", + "use-cases", + "entities", + "interface-adapters", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "uncategorized/architecture/clean-architecture-layers" + }, + { + "slug": "domain-driven-design-bounded-contexts-architecture", + "title": "Domain-Driven Design Bounded Contexts Architecture", + "description": "A DDD bounded contexts architecture diagram with Order, Customer, Shipping, and Billing contexts connected through an anti-corruption layer, shared kernel, and context map defining integration relationships. This template visualizes the strategic DDD patterns for decomposing complex domains into autonomous bounded contexts that communicate through well-defined integration events. Critical for architects applying Domain-Driven Design to large-scale enterprise systems.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 18, + "numLanes": 5, + "tags": [ + "domain-driven-design", + "bounded-context", + "anti-corruption-layer", + "context-map", + "shared-kernel", + "strategic-ddd", + "aggregate", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "uncategorized/architecture/domain-driven-design-bounded-contexts-architecture" + }, + { + "slug": "api-composition-pattern-architecture", + "title": "API Composition Pattern Architecture", + "description": "An API composition architecture diagram with a composer service that fans out parallel requests to multiple microservices, collects responses with timeout handling, and merges results into a single unified response with partial fallback support. This template models the API composition pattern used when a single client query requires data from multiple services, avoiding the need for direct service-to-service calls. Useful for teams building aggregation layers in microservices architectures.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "incident", + "secondaryUseCases": [], + "useCases": [ + "incident" + ], + "complexity": 3, + "numNodes": 16, + "numLanes": 3, + "tags": [ + "api-composition", + "response-aggregation", + "fan-out", + "parallel-requests", + "timeout-handling", + "partial-response", + "microservices", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "incident/architecture/api-composition-pattern-architecture" + }, + { + "slug": "outbox-pattern-reliable-messaging-architecture", + "title": "Outbox Pattern for Reliable Messaging Architecture", + "description": "A transactional outbox architecture diagram where domain writes and event publishing happen in the same database transaction, with a relay process polling the outbox table and publishing events to a message broker with guaranteed delivery. This template solves the dual-write problem where updating a database and publishing an event are not atomic, ensuring exactly-once event delivery without distributed transactions. Critical for event-driven architectures requiring reliable message publishing.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 18, + "numLanes": 4, + "tags": [ + "outbox-pattern", + "transactional-outbox", + "reliable-messaging", + "dual-write", + "exactly-once", + "debezium", + "event-publishing", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "uncategorized/architecture/outbox-pattern-reliable-messaging-architecture" + }, + { + "slug": "ambassador-pattern-architecture", + "title": "Ambassador Pattern Architecture", + "description": "An ambassador pattern architecture diagram with a local proxy sidecar handling authentication header injection, circuit breaking, retry logic, and metrics collection for outbound requests to external third-party APIs. This template models the ambassador pattern where a helper service running alongside the application offloads cross-cutting concerns for external communication. Useful for teams integrating with unreliable third-party services that need resilience wrappers.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "mcp", + "secondaryUseCases": [], + "useCases": [ + "mcp" + ], + "complexity": 3, + "numNodes": 15, + "numLanes": 3, + "tags": [ + "ambassador-pattern", + "sidecar-proxy", + "external-api", + "retry-logic", + "circuit-breaker", + "metrics-collection", + "cross-cutting-concerns", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "mcp/architecture/ambassador-pattern-architecture" + }, + { + "slug": "graphql-federation-architecture", + "title": "GraphQL Federation Architecture", + "description": "A GraphQL federation architecture diagram with an Apollo Gateway building query plans and fanning out to User, Product, and Review subgraphs, each owning its schema and database, with response stitching into a unified GraphQL result. This template models the federated GraphQL approach where multiple teams independently develop and deploy their subgraphs while clients see a single unified API. Ideal for organizations scaling GraphQL across multiple teams and services.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "mcp", + "secondaryUseCases": [], + "useCases": [ + "mcp" + ], + "complexity": 3, + "numNodes": 15, + "numLanes": 3, + "tags": [ + "graphql-federation", + "apollo-gateway", + "subgraph", + "schema-stitching", + "query-plan", + "federated-api", + "graphql", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "mcp/architecture/graphql-federation-architecture" + }, + { + "slug": "zero-trust-security-architecture", + "title": "Zero Trust Security Architecture", + "description": "A zero trust security architecture diagram with device posture checks, MFA identity verification, risk-based policy decisions, short-lived JWT tokens, micro-segmentation, mTLS encryption, least-privilege access enforcement, and continuous monitoring. This template models the 'never trust, always verify' security paradigm where every request is authenticated and authorized regardless of network location. Essential for security architects implementing modern zero-trust frameworks in cloud-native environments.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "security", + "secondaryUseCases": [], + "useCases": [ + "security" + ], + "complexity": 4, + "numNodes": 19, + "numLanes": 4, + "tags": [ + "zero-trust", + "security-architecture", + "mfa", + "micro-segmentation", + "mtls", + "least-privilege", + "continuous-verification", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "security/architecture/zero-trust-security-architecture" + }, + { + "slug": "multi-tenant-saas-architecture", + "title": "Multi-Tenant SaaS Architecture", + "description": "A multi-tenant SaaS architecture diagram with tenant identification, tier-based routing (shared vs dedicated pools), row-level security, per-tenant encryption keys, and isolated backup strategies for standard and enterprise isolation models. This template models the architecture decisions for building SaaS platforms that serve multiple customers from shared infrastructure while maintaining strict data isolation. Critical for SaaS architects balancing cost efficiency with enterprise security requirements.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "security", + "secondaryUseCases": [ + "delivery" + ], + "useCases": [ + "security", + "delivery" + ], + "complexity": 4, + "numNodes": 17, + "numLanes": 4, + "tags": [ + "multi-tenant", + "saas-architecture", + "tenant-isolation", + "row-level-security", + "shared-infrastructure", + "enterprise-tier", + "data-isolation", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "security/architecture/multi-tenant-saas-architecture" + }, + { + "slug": "kubernetes-container-orchestration-architecture", + "title": "Kubernetes Container Orchestration Architecture", + "description": "A Kubernetes container orchestration architecture diagram showing the control plane (API Server, etcd, Scheduler, Controller Manager), worker nodes (Kubelet, container runtime, kube-proxy, pods), networking layer (Ingress, Network Policy, Service Mesh), and persistent storage with CSI drivers. This template provides a comprehensive view of the Kubernetes architecture stack from control plane to storage layer. Foundational reference for DevOps engineers and platform teams managing Kubernetes clusters.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "ai-orchestration", + "secondaryUseCases": [], + "useCases": [ + "ai-orchestration" + ], + "complexity": 4, + "numNodes": 18, + "numLanes": 4, + "tags": [ + "kubernetes", + "container-orchestration", + "k8s", + "control-plane", + "worker-node", + "ingress", + "persistent-storage", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "ai-orchestration/architecture/kubernetes-container-orchestration-architecture" + }, + { + "slug": "data-mesh-architecture", + "title": "Data Mesh Architecture", + "description": "A data mesh architecture diagram with domain-oriented data ownership across Sales, Marketing, and Finance domains, each exposing self-serve data products through APIs with quality SLAs, governed by a federated data platform with a shared catalog and cross-domain query engine. This template models the paradigm shift from centralized data teams to domain-owned data products, applying microservices principles to data architecture. Essential for organizations scaling data operations beyond centralized data warehouse bottlenecks.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 17, + "numLanes": 4, + "tags": [ + "data-mesh", + "domain-ownership", + "data-product", + "self-serve-data", + "federated-governance", + "data-platform", + "data-architecture", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "uncategorized/architecture/data-mesh-architecture" + }, + { + "slug": "cell-based-architecture", + "title": "Cell-Based Architecture", + "description": "A cell-based architecture diagram with geographic routing to independent, self-contained cells (US-East, EU-West), each with its own gateway, compute, database, cache, and message queue, plus shared services for cross-cell replication and global configuration. This template models the cell architecture pattern used by hyperscale systems to achieve blast radius isolation, where failures in one cell cannot affect users in another. Key for architects designing systems that require extreme availability and fault isolation.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "handoff", + "secondaryUseCases": [], + "useCases": [ + "handoff" + ], + "complexity": 4, + "numNodes": 20, + "numLanes": 4, + "tags": [ + "cell-based-architecture", + "blast-radius", + "geographic-routing", + "fault-isolation", + "independent-cells", + "cross-cell-replication", + "hyperscale", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "handoff/architecture/cell-based-architecture" + }, + { + "slug": "observability-three-pillars-architecture", + "title": "Observability Three Pillars Architecture", + "description": "An observability architecture diagram implementing the three pillars (metrics, traces, logs) with OpenTelemetry SDK instrumentation, OTLP collector pipeline, Prometheus, Jaeger, and Loki backends, Grafana dashboards, SLO/SLI tracking, and PagerDuty alerting integration. This template provides a complete observability stack reference showing how telemetry data flows from application instrumentation through collection, storage, visualization, and incident response. Essential for SRE teams building production monitoring infrastructure.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 17, + "numLanes": 4, + "tags": [ + "observability", + "three-pillars", + "opentelemetry", + "prometheus", + "jaeger", + "loki", + "grafana", + "slo-sli", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "uncategorized/architecture/observability-three-pillars-architecture" + }, + { + "slug": "gitops-deployment-architecture", + "title": "GitOps Deployment Architecture", + "description": "A GitOps deployment architecture diagram with developer Git workflow, CI/CD pipeline building and pushing container images, ArgoCD or Flux detecting Git manifest changes, drift detection, automatic cluster synchronization, and rolling update deployment to Kubernetes. This template models the GitOps paradigm where Git is the single source of truth for both application code and infrastructure state, enabling declarative, auditable, and reproducible deployments. Critical for teams adopting GitOps practices for Kubernetes deployments.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "delivery", + "secondaryUseCases": [], + "useCases": [ + "delivery" + ], + "complexity": 4, + "numNodes": 19, + "numLanes": 4, + "tags": [ + "gitops", + "argocd", + "flux", + "kubernetes-deployment", + "declarative-infrastructure", + "drift-detection", + "rolling-update", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "delivery/architecture/gitops-deployment-architecture" + }, + { + "slug": "ai-native-single-agent-architecture", + "title": "AI-Native Single Agent Architecture", + "description": "A single-agent AI architecture where one agent handles everything: parsing requests, reasoning, calling tools via MCP, and generating responses. This is the default architecture for prototypes and simple automations—easy to debug but hits context-window limits quickly and is hard to parallelize. Ideal for MVPs and solo builders shipping fast.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "agentic", + "secondaryUseCases": [ + "ai-orchestration", + "mcp" + ], + "useCases": [ + "agentic", + "ai-orchestration", + "mcp" + ], + "complexity": 2, + "numNodes": 11, + "numLanes": 3, + "tags": [ + "ai-native", + "single-agent", + "agentic-ai", + "mcp", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "agentic/architecture/ai-native-single-agent-architecture" + }, + { + "slug": "ai-native-sequential-pipeline-architecture", + "title": "AI-Native Sequential Pipeline Architecture", + "description": "A sequential pipeline architecture chaining multiple agents in a fixed order (parse → enrich → analyze → format), which is a common 'LLM microservices' setup when each step can be isolated. This structure is often used in document processing and ETL-like workflows because each step is testable and predictable.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "delivery", + "secondaryUseCases": [ + "agentic", + "ai-orchestration" + ], + "useCases": [ + "delivery", + "agentic", + "ai-orchestration" + ], + "complexity": 2, + "numNodes": 7, + "numLanes": 2, + "tags": [ + "ai-native", + "sequential-pipeline", + "agentic-ai", + "llm-microservices", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "delivery/architecture/ai-native-sequential-pipeline-architecture" + }, + { + "slug": "ai-native-orchestrator-worker-architecture", + "title": "AI-Native Orchestrator-Worker Architecture", + "description": "An orchestrator-worker architecture where an orchestrator agent breaks a goal into subtasks, dispatches to specialized workers, then synthesizes a final response. This is the most common 'agent orchestration' architecture—powerful but the orchestrator can become a bottleneck as the number of workers grows. Frameworks like LangGraph focus on explicit routing/state to manage this.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "agentic", + "secondaryUseCases": [ + "ai-orchestration" + ], + "useCases": [ + "agentic", + "ai-orchestration" + ], + "complexity": 3, + "numNodes": 14, + "numLanes": 4, + "tags": [ + "ai-native", + "orchestrator-worker", + "agentic-ai", + "langgraph", + "multi-agent", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "agentic/architecture/ai-native-orchestrator-worker-architecture" + }, + { + "slug": "ai-native-hierarchical-architecture", + "title": "AI-Native Hierarchical Architecture", + "description": "A hierarchical multi-agent architecture that scales orchestration by stacking supervisors and team leads (a tree structure), which mirrors enterprise org structures and helps partition context. This is the 'enterprise-grade agentic AI architecture' when a single orchestrator cannot manage all workers directly. Ideal for large enterprises and multi-domain workflows.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "agentic", + "secondaryUseCases": [ + "ai-orchestration" + ], + "useCases": [ + "agentic", + "ai-orchestration" + ], + "complexity": 4, + "numNodes": 16, + "numLanes": 4, + "tags": [ + "ai-native", + "hierarchical", + "agentic-ai", + "enterprise", + "multi-agent", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "agentic/architecture/ai-native-hierarchical-architecture" + }, + { + "slug": "ai-native-parallel-fan-out-architecture", + "title": "AI-Native Parallel Fan-Out Architecture", + "description": "A parallel fan-out architecture that runs multiple agents simultaneously on independent checks (style, security, performance) and then merges results. This is a standard multi-agent design approach for throughput, mapping cleanly to CI/CD, incident response, and research. Fan-in reconciliation becomes the subtle part.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "delivery", + "secondaryUseCases": [ + "agentic", + "ai-orchestration" + ], + "useCases": [ + "delivery", + "agentic", + "ai-orchestration" + ], + "complexity": 3, + "numNodes": 11, + "numLanes": 2, + "tags": [ + "ai-native", + "parallel-fan-out", + "agentic-ai", + "map-reduce", + "ci-cd", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "delivery/architecture/ai-native-parallel-fan-out-architecture" + }, + { + "slug": "ai-native-event-driven-kafka-architecture", + "title": "AI-Native Event-Driven Kafka Architecture", + "description": "An event-driven agentic AI architecture that replaces the central orchestrator with Kafka/PubSub topics: agents subscribe, react, and publish new events. This aligns multi-agent systems with proven microservices choreography and is ideal for real-time, high-throughput systems and 'agent mesh' setups.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "agentic", + "secondaryUseCases": [ + "ai-orchestration", + "mcp" + ], + "useCases": [ + "agentic", + "ai-orchestration", + "mcp" + ], + "complexity": 3, + "numNodes": 12, + "numLanes": 5, + "tags": [ + "ai-native", + "event-driven", + "agentic-ai", + "kafka", + "pub-sub", + "agent-mesh", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "agentic/architecture/ai-native-event-driven-kafka-architecture" + }, + { + "slug": "ai-native-generator-critic-architecture", + "title": "AI-Native Generator-Critic Architecture", + "description": "A competitive / generator-critic architecture where multiple generators produce independent answers, then an evaluator agent scores and selects the best output. This approach improves quality and reduces single-model brittleness. It's costlier (multiple LLM calls) but pays off when correctness or creativity matters more than latency.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "agentic", + "secondaryUseCases": [ + "ai-orchestration" + ], + "useCases": [ + "agentic", + "ai-orchestration" + ], + "complexity": 3, + "numNodes": 9, + "numLanes": 3, + "tags": [ + "ai-native", + "generator-critic", + "agentic-ai", + "tournament-mode", + "multi-agent", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "agentic/architecture/ai-native-generator-critic-architecture" + }, + { + "slug": "event-driven-notification-hub-architecture", + "title": "Event-Driven Notification Hub Architecture", + "description": "An event-driven notification hub architecture diagram with multi-source event ingestion, template-based message rendering, user preference routing across email (SendGrid/SES), push (FCM), SMS (Twilio), and Slack channels, with delivery tracking and retry mechanisms. This template models a centralized notification system that decouples business services from delivery infrastructure, supporting multi-channel communication with user-controlled preferences. Ideal for platform teams building scalable notification infrastructure.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "uncategorized", + "secondaryUseCases": [], + "useCases": [], + "complexity": 4, + "numNodes": 20, + "numLanes": 3, + "tags": [ + "notification-hub", + "multi-channel", + "event-driven", + "sendgrid", + "firebase-cloud-messaging", + "twilio", + "delivery-tracking", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "uncategorized/architecture/event-driven-notification-hub-architecture" + }, + { + "slug": "agentic-supervisor-worker", + "title": "Agentic Supervisor-Worker Architecture", + "description": "A supervisor-worker multi-agent architecture where an orchestrator agent receives a high-level goal, breaks it into subtasks, delegates each to specialist worker agents (researcher, writer, QA), monitors execution, handles failures, and synthesizes results. The orchestrator manages but does not execute tasks itself.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "agentic", + "secondaryUseCases": [], + "useCases": [ + "agentic" + ], + "complexity": 3, + "numNodes": 10, + "numLanes": 4, + "tags": [ + "agentic", + "supervisor-worker", + "multi-agent", + "orchestrator", + "architecture-diagram", + "ai-team" + ], + "sourcePath": "", + "repoPath": "agentic/architecture/agentic-supervisor-worker" + }, + { + "slug": "agentic-sequential-pipeline", + "title": "Agentic Sequential Pipeline Architecture", + "description": "A sequential pipeline multi-agent architecture where agents are arranged in a strict sequence. Each agent transforms or enriches the output of the previous one, then passes it forward. No central orchestrator — the flow is deterministic like an assembly line.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "delivery", + "secondaryUseCases": [ + "agentic", + "ai-orchestration" + ], + "useCases": [ + "delivery", + "agentic", + "ai-orchestration" + ], + "complexity": 2, + "numNodes": 5, + "numLanes": 5, + "tags": [ + "agentic", + "sequential-pipeline", + "multi-agent", + "assembly-line", + "architecture-diagram", + "ai-team" + ], + "sourcePath": "", + "repoPath": "delivery/architecture/agentic-sequential-pipeline" + }, + { + "slug": "agentic-swarm", + "title": "Agentic Swarm Architecture", + "description": "A swarm multi-agent architecture where multiple agents work on the same or related tasks simultaneously, with no central coordinator. Their outputs are then aggregated, voted on, or merged by a dedicated aggregator node. Agents may compete — the best output wins.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "agentic", + "secondaryUseCases": [], + "useCases": [ + "agentic" + ], + "complexity": 3, + "numNodes": 6, + "numLanes": 5, + "tags": [ + "agentic", + "swarm", + "multi-agent", + "parallel", + "aggregator", + "architecture-diagram", + "ai-team" + ], + "sourcePath": "", + "repoPath": "agentic/architecture/agentic-swarm" + }, + { + "slug": "agentic-hierarchical", + "title": "Agentic Hierarchical Architecture", + "description": "A hierarchical multi-agent architecture with multi-level organizational structure. A top-level executive agent manages mid-level team lead agents, who each manage their own pool of specialist workers. Teams within teams — the hierarchy maps to domain separation.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "agentic", + "secondaryUseCases": [], + "useCases": [ + "agentic" + ], + "complexity": 4, + "numNodes": 8, + "numLanes": 7, + "tags": [ + "agentic", + "hierarchical", + "multi-agent", + "enterprise", + "architecture-diagram", + "ai-team" + ], + "sourcePath": "", + "repoPath": "agentic/architecture/agentic-hierarchical" + }, + { + "slug": "agentic-team-of-rivals", + "title": "Agentic Team of Rivals Architecture", + "description": "The most architecturally sophisticated multi-agent pattern. Agents are assigned not just roles but opposing incentives. A Planner is optimistic about goal completion. A Critic is constitutionally skeptical and holds veto authority. Errors get caught through adversarial pressure rather than trusting a single model's self-assessment.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "agentic", + "secondaryUseCases": [], + "useCases": [ + "agentic" + ], + "complexity": 3, + "numNodes": 5, + "numLanes": 3, + "tags": [ + "agentic", + "team-of-rivals", + "multi-agent", + "critic", + "veto", + "architecture-diagram", + "ai-team" + ], + "sourcePath": "", + "repoPath": "agentic/architecture/agentic-team-of-rivals" + }, + { + "slug": "ai-orchestration-single-agent", + "title": "AI Orchestration - Single Agent (Monolith)", + "description": "The simplest AI-native architecture — a single agent that receives user input, reasons, plans, decides on tool calls, processes results, and generates responses. Direct MCP connection over stdio or HTTP. Best for MVPs and when low latency matters.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "ai-orchestration", + "secondaryUseCases": [ + "mcp" + ], + "useCases": [ + "ai-orchestration", + "mcp" + ], + "complexity": 2, + "numNodes": 12, + "numLanes": 3, + "tags": [ + "ai-native", + "single-agent", + "monolith", + "mcp", + "architecture-diagram", + "orchestration" + ], + "sourcePath": "", + "repoPath": "ai-orchestration/architecture/ai-orchestration-single-agent" + }, + { + "slug": "ai-orchestration-sequential-pipeline", + "title": "AI Orchestration - Sequential Pipeline", + "description": "An assembly-line architecture where agents are arranged in a strict sequence. Each agent transforms or enriches the output of the previous one, then passes it forward. Best for tasks with clear sequential dependencies — document processing, content production pipelines, compliance workflows.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "delivery", + "secondaryUseCases": [ + "ai-orchestration" + ], + "useCases": [ + "delivery", + "ai-orchestration" + ], + "complexity": 2, + "numNodes": 5, + "numLanes": 2, + "tags": [ + "ai-native", + "sequential-pipeline", + "assembly-line", + "architecture-diagram", + "orchestration" + ], + "sourcePath": "", + "repoPath": "delivery/architecture/ai-orchestration-sequential-pipeline" + }, + { + "slug": "ai-orchestration-orchestrator-worker", + "title": "AI Orchestration - Orchestrator-Worker", + "description": "A conductor-style architecture where one orchestrator agent receives a complex task, breaks it into subtasks, dispatches each to specialist worker agents (research, code, review), collects results, and synthesizes the final answer. Best for complex multi-step tasks with dynamic decomposition.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "agentic", + "secondaryUseCases": [ + "ai-orchestration" + ], + "useCases": [ + "agentic", + "ai-orchestration" + ], + "complexity": 3, + "numNodes": 15, + "numLanes": 5, + "tags": [ + "ai-native", + "orchestrator-worker", + "conductor", + "multi-agent", + "architecture-diagram", + "orchestration" + ], + "sourcePath": "", + "repoPath": "agentic/architecture/ai-orchestration-orchestrator-worker" + }, + { + "slug": "ai-orchestration-hierarchical", + "title": "AI Orchestration - Hierarchical (Org Chart)", + "description": "An org-chart architecture with multi-level structure. A top-level supervisor manages team leads, who each manage their own pool of specialist workers. Teams within teams. Best for enterprise-scale automation with 10+ specialized agents spanning multiple domains.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "agentic", + "secondaryUseCases": [ + "ai-orchestration" + ], + "useCases": [ + "agentic", + "ai-orchestration" + ], + "complexity": 4, + "numNodes": 17, + "numLanes": 5, + "tags": [ + "ai-native", + "hierarchical", + "org-chart", + "enterprise", + "multi-agent", + "architecture-diagram", + "orchestration" + ], + "sourcePath": "", + "repoPath": "agentic/architecture/ai-orchestration-hierarchical" + }, + { + "slug": "ai-orchestration-parallel-fan-out", + "title": "AI Orchestration - Parallel Fan-Out (Map-Reduce)", + "description": "A map-reduce style architecture where a coordinator fans out tasks to multiple parallel worker agents (style check, security audit, performance analysis), gathers all results, and makes an aggregate decision. Best for PR reviews, code reviews, and multi-dimensional analysis.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "agentic", + "secondaryUseCases": [ + "ai-orchestration" + ], + "useCases": [ + "agentic", + "ai-orchestration" + ], + "complexity": 3, + "numNodes": 9, + "numLanes": 3, + "tags": [ + "ai-native", + "parallel-fan-out", + "map-reduce", + "coordinator", + "multi-agent", + "architecture-diagram", + "orchestration" + ], + "sourcePath": "", + "repoPath": "agentic/architecture/ai-orchestration-parallel-fan-out" + }, + { + "slug": "ai-orchestration-event-driven-mesh", + "title": "AI Orchestration - Event-Driven Mesh (Kafka-First)", + "description": "An event-driven agent mesh architecture using a Kafka-style event broker. Multiple agents subscribe to topics (orders, alerts, analytics), process events independently, and publish results back to the bus. Best for real-time event processing and decoupled service architectures.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "ai-orchestration", + "secondaryUseCases": [ + "mcp" + ], + "useCases": [ + "ai-orchestration", + "mcp" + ], + "complexity": 3, + "numNodes": 13, + "numLanes": 5, + "tags": [ + "ai-native", + "event-driven", + "kafka", + "agent-mesh", + "pub-sub", + "architecture-diagram", + "orchestration" + ], + "sourcePath": "", + "repoPath": "ai-orchestration/architecture/ai-orchestration-event-driven-mesh" + }, + { + "slug": "ai-orchestration-competitive-generator-critic", + "title": "AI Orchestration - Competitive Generator-Critic", + "description": "A tournament-mode architecture where multiple generator agents produce independent outputs in parallel, then an evaluator agent scores and selects the best. Quality threshold checking with refinement loops. Best when correctness or creativity matters more than latency.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "agentic", + "secondaryUseCases": [ + "ai-orchestration" + ], + "useCases": [ + "agentic", + "ai-orchestration" + ], + "complexity": 3, + "numNodes": 10, + "numLanes": 3, + "tags": [ + "ai-native", + "competitive", + "generator-critic", + "tournament", + "multi-agent", + "architecture-diagram", + "orchestration" + ], + "sourcePath": "", + "repoPath": "agentic/architecture/ai-orchestration-competitive-generator-critic" + }, + { + "slug": "mcp-direct-connect", + "title": "MCP Direct Connect Architecture", + "description": "The simplest MCP pattern — direct connection between host application and MCP server over stdio or HTTP. No extra hops, lowest latency, easiest debugging. Perfect for MVPs, hackathons, and single-team setups where security governance is not yet a concern.", + "kind": "architecture", + "sourceDomain": "DevOps", + "primaryUseCase": "mcp", + "secondaryUseCases": [], + "useCases": [ + "mcp" + ], + "complexity": 1, + "numNodes": 6, + "numLanes": 2, + "tags": [ + "mcp", + "direct-connect", + "stdio", + "http", + "architecture-diagram", + "production-grade" + ], + "sourcePath": "", + "repoPath": "mcp/devops/mcp-direct-connect" + }, + { + "slug": "mcp-gateway-proxy", + "title": "MCP Gateway Proxy Architecture", + "description": "An API gateway pattern that sits between agents and MCP servers to handle authentication, rate limits, and auditing. The gateway enforces OAuth 2.0, SAML, SSO, tool-level rate limiting, and team-based quotas. Essential for multi-team or multi-tenant MCP deployments.", + "kind": "architecture", + "sourceDomain": "DevOps", + "primaryUseCase": "security", + "secondaryUseCases": [ + "compliance", + "mcp" + ], + "useCases": [ + "security", + "compliance", + "mcp" + ], + "complexity": 3, + "numNodes": 7, + "numLanes": 3, + "tags": [ + "mcp", + "gateway", + "proxy", + "oauth", + "rate-limiting", + "audit", + "architecture-diagram", + "production-grade" + ], + "sourcePath": "", + "repoPath": "security/devops/mcp-gateway-proxy" + }, + { + "slug": "mcp-tool-router", + "title": "MCP Tool Router Architecture", + "description": "A routing pattern that puts a semantic router in front of MCP tools so the LLM only sees the subset it needs. Uses vector embeddings and cosine similarity to match user intent to tools dynamically. Achieves up to 96% reduction in input tokens when dealing with large tool catalogs.", + "kind": "architecture", + "sourceDomain": "DevOps", + "primaryUseCase": "handoff", + "secondaryUseCases": [ + "mcp" + ], + "useCases": [ + "handoff", + "mcp" + ], + "complexity": 3, + "numNodes": 8, + "numLanes": 4, + "tags": [ + "mcp", + "tool-router", + "semantic-routing", + "embeddings", + "token-optimization", + "architecture-diagram", + "production-grade" + ], + "sourcePath": "", + "repoPath": "handoff/devops/mcp-tool-router" + }, + { + "slug": "mcp-agent-mesh", + "title": "MCP Agent Mesh Architecture", + "description": "A multi-agent mesh pattern where agents communicate through a shared context broker backed by MCP. Enables coordinated tool access and state synchronization across multiple specialized agents (planner, coder, reviewer, operator). Supports both orchestrated and choreographed interaction patterns.", + "kind": "architecture", + "sourceDomain": "DevOps", + "primaryUseCase": "agentic", + "secondaryUseCases": [ + "mcp" + ], + "useCases": [ + "agentic", + "mcp" + ], + "complexity": 4, + "numNodes": 10, + "numLanes": 4, + "tags": [ + "mcp", + "agent-mesh", + "shared-context", + "multi-agent", + "broker", + "architecture-diagram", + "production-grade" + ], + "sourcePath": "", + "repoPath": "agentic/devops/mcp-agent-mesh" + }, + { + "slug": "mcp-circuit-breaker", + "title": "MCP Circuit Breaker Architecture", + "description": "A resilience pattern that wraps MCP calls with health-aware gates using three states: Closed (normal), Open (failures detected, fast-fail), and Half-Open (testing recovery). Prevents cascading failures when tools become unresponsive. Essential for production-grade reliability.", + "kind": "architecture", + "sourceDomain": "DevOps", + "primaryUseCase": "mcp", + "secondaryUseCases": [], + "useCases": [ + "mcp" + ], + "complexity": 3, + "numNodes": 9, + "numLanes": 3, + "tags": [ + "mcp", + "circuit-breaker", + "resilience", + "fault-tolerance", + "health-check", + "architecture-diagram", + "production-grade" + ], + "sourcePath": "", + "repoPath": "mcp/devops/mcp-circuit-breaker" + }, + { + "slug": "mcp-context-proxy", + "title": "MCP Context Proxy Architecture", + "description": "A caching and compression layer that sits between agents and MCP servers, intercepting redundant context requests before they hit the wire. Uses TTL-based cache invalidation, Brotli compression, and semantic caching. Can achieve up to 95%+ token reduction and significantly lower LLM bills.", + "kind": "architecture", + "sourceDomain": "DevOps", + "primaryUseCase": "mcp", + "secondaryUseCases": [], + "useCases": [ + "mcp" + ], + "complexity": 3, + "numNodes": 7, + "numLanes": 3, + "tags": [ + "mcp", + "context-proxy", + "caching", + "compression", + "token-optimization", + "architecture-diagram", + "production-grade" + ], + "sourcePath": "", + "repoPath": "mcp/devops/mcp-context-proxy" + }, + { + "slug": "context-session-memory", + "title": "Context Management - Session Memory", + "description": "Short-term context pattern where the channel sends new messages plus recent history. The agent runtime merges that with local session state, assembles the prompt, and persists the response back into history. Simple but cost and latency grow with history length.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "context-management", + "secondaryUseCases": [], + "useCases": [ + "context-management" + ], + "complexity": 2, + "numNodes": 9, + "numLanes": 3, + "tags": [ + "context-management", + "session-memory", + "short-term", + "memory", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "context-management/architecture/context-session-memory" + }, + { + "slug": "context-rolling-summary-memory", + "title": "Context Management - Rolling Summary Memory", + "description": "Compressed history pattern that keeps full history for a while, then when a threshold is hit, summarizes the last chunk and replaces detailed turns with a shorter summary message. Dramatically reduces prompt size on long-running chats while maintaining gist continuity.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "context-management", + "secondaryUseCases": [], + "useCases": [ + "context-management" + ], + "complexity": 3, + "numNodes": 8, + "numLanes": 4, + "tags": [ + "context-management", + "rolling-summary", + "compression", + "memory", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "context-management/architecture/context-rolling-summary-memory" + }, + { + "slug": "context-profile-memory", + "title": "Context Management - Profile Memory", + "description": "Identity-style memory pattern where profile data is loaded at session start. Each prompt combines system persona, user profile, and current message. New facts can be written back to profile memory. Small predictable overhead with big UX lift — the agent remembers your name, stack, tone, and constraints.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "context-management", + "secondaryUseCases": [], + "useCases": [ + "context-management" + ], + "complexity": 2, + "numNodes": 7, + "numLanes": 3, + "tags": [ + "context-management", + "profile-memory", + "identity", + "user-profile", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "context-management/architecture/context-profile-memory" + }, + { + "slug": "context-semantic-memory", + "title": "Context Management - Semantic Memory", + "description": "Vector-based memory pattern where text is chunked, embedded, and stored in a vector database. On query, the question is embedded, a vector search is run, candidates are reranked, and top results are injected into the prompt. Where the agent feels like it remembers everything without hallucinating.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "context-management", + "secondaryUseCases": [], + "useCases": [ + "context-management" + ], + "complexity": 3, + "numNodes": 9, + "numLanes": 4, + "tags": [ + "context-management", + "semantic-memory", + "vector-db", + "embeddings", + "rag", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "context-management/architecture/context-semantic-memory" + }, + { + "slug": "context-episodic-memory", + "title": "Context Management - Episodic Memory", + "description": "Learning-from-experience pattern where every task run becomes an episode with input, actions, and outcome. Before tackling a new task, the agent fetches similar episodes and uses them as hints. Over time, the agent feels like it's learning instead of repeating the same failed plans.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "context-management", + "secondaryUseCases": [], + "useCases": [ + "context-management" + ], + "complexity": 3, + "numNodes": 11, + "numLanes": 4, + "tags": [ + "context-management", + "episodic-memory", + "learning", + "experience", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "context-management/architecture/context-episodic-memory" + }, + { + "slug": "context-hybrid-retrieval-memory", + "title": "Context Management - Hybrid Retrieval Memory", + "description": "Multi-modal retrieval pattern combining semantic search, exact/keyword search, and recency search in parallel. Results are merged and reranked into a single context set. Much higher recall because the agent can find both fuzzy references and exact entities. Essential for comprehensive knowledge retrieval.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "context-management", + "secondaryUseCases": [], + "useCases": [ + "context-management" + ], + "complexity": 4, + "numNodes": 11, + "numLanes": 5, + "tags": [ + "context-management", + "hybrid-retrieval", + "semantic", + "keyword", + "recency", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "context-management/architecture/context-hybrid-retrieval-memory" + }, + { + "slug": "context-shared-memory", + "title": "Context Management - Shared Memory", + "description": "Multi-agent coordination pattern where an orchestrator breaks work into subtasks, specialist agents pull from and push to a shared state store, and the orchestrator composes the final answer from that shared state. Multi-agent setups feel coherent instead of each assistant having its own inconsistent memory.", + "kind": "architecture", + "sourceDomain": "Architecture", + "primaryUseCase": "agentic", + "secondaryUseCases": [ + "context-management" + ], + "useCases": [ + "agentic", + "context-management" + ], + "complexity": 3, + "numNodes": 9, + "numLanes": 4, + "tags": [ + "context-management", + "shared-memory", + "multi-agent", + "orchestrator", + "architecture-diagram" + ], + "sourcePath": "", + "repoPath": "agentic/architecture/context-shared-memory" + } + ] +} diff --git a/uncategorized/architecture/clean-architecture-layers/README.md b/uncategorized/architecture/clean-architecture-layers/README.md new file mode 100644 index 0000000000000000000000000000000000000000..0093f27d419d7ee4508024d4910cbfae76ba9f54 --- /dev/null +++ b/uncategorized/architecture/clean-architecture-layers/README.md @@ -0,0 +1,19 @@ +# Clean Architecture Layers + +A clean architecture layers diagram showing the four concentric layers: Entities (domain), Use Cases (application), Interface Adapters (controllers, presenters, repositories), and Frameworks & Drivers (web server, database, cloud SDK). This template models Uncle Bob's Clean Architecture with the dependency rule where inner layers never depend on outer layers, ensuring the domain model remains pure and framework-independent. Essential reference for software architects enforcing architectural boundaries. + +**Template ID:** `clean-architecture-layers` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 16 +**Lanes:** 4 +**Tags:** [clean-architecture, uncle-bob, dependency-rule, layered-architecture, use-cases, entities, interface-adapters, architecture-diagram] +**Source path:** `` +**Repo path:** `uncategorized/architecture/clean-architecture-layers` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/architecture/clean-architecture-layers/metadata.json b/uncategorized/architecture/clean-architecture-layers/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..2f4e013b207f63de4f19cba06fe9a23a9d30773f --- /dev/null +++ b/uncategorized/architecture/clean-architecture-layers/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "clean-architecture-layers", + "workflow_id": "clean-architecture-layers", + "title": "Clean Architecture Layers", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 16, + "num_lanes": 4, + "tags": [ + "clean-architecture", + "uncle-bob", + "dependency-rule", + "layered-architecture", + "use-cases", + "entities", + "interface-adapters", + "architecture-diagram" + ], + "description": "A clean architecture layers diagram showing the four concentric layers: Entities (domain), Use Cases (application), Interface Adapters (controllers, presenters, repositories), and Frameworks & Drivers (web server, database, cloud SDK). This template models Uncle Bob's Clean Architecture with the dependency rule where inner layers never depend on outer layers, ensuring the domain model remains pure and framework-independent. Essential reference for software architects enforcing architectural boundaries.", + "source_path": "", + "repo_path": "uncategorized/architecture/clean-architecture-layers" +} diff --git a/uncategorized/architecture/clean-architecture-layers/workflow.fz b/uncategorized/architecture/clean-architecture-layers/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..90d0bd0198b3b7b58cb0fcc9babbf9beb95cb616 --- /dev/null +++ b/uncategorized/architecture/clean-architecture-layers/workflow.fz @@ -0,0 +1,41 @@ +External { # External Layer (Frameworks & Drivers) +n1: rectangle label:"Express/Fastify Web Server" +n2: rectangle label:"PostgreSQL Driver" +n3: rectangle label:"Redis Client" +n4: rectangle label:"AWS SDK" +n17: rectangle label:"Return View Model" +n1.handle(bottom) -> Interface.n5.handle(top) [label="HTTP Request"] +n2.handle(bottom) -> Interface.n7.handle(top) [label="DB Connection"] +n3.handle(bottom) -> Interface.n7.handle(top) [label="Cache"] +n4.handle(bottom) -> Interface.n7.handle(top) [label="Cloud Storage"] +} +Interface { # Interface Adapters Layer +n5: rectangle label:"Controller" +n6: rectangle label:"DTO Mapper" +n7: rectangle label:"Repository Implementation" +n16: rectangle label:"Presenter" +n5.handle(right) -> n6.handle(left) [label="Map Input"] +n6.handle(bottom) -> UseCase.n8.handle(top) [label="Request Model"] +n7.handle(bottom) -> UseCase.n11.handle(top) [label="Implements"] +n16.handle(top) -> External.n17.handle(bottom) [label="View Model"] +} +UseCase { # Use Cases Layer (Application) +n8: rectangle label:"Create Order Use Case" +n9: rectangle label:"Get Order Use Case" +n10: rectangle label:"Cancel Order Use Case" +n11: rectangle label:"Order Repository Interface" +n8.handle(bottom) -> Entity.n12.handle(top) [label="Call Domain"] +n9.handle(bottom) -> Entity.n12.handle(top) [label="Query"] +n10.handle(bottom) -> Entity.n13.handle(top) [label="Cancel"] +n8.handle(right) -> n11.handle(left) [label="Persist"] +n9.handle(top) -> Interface.n16.handle(bottom) [label="Output"] +} +Entity { # Entities Layer (Domain) +n12: rectangle label:"Order Aggregate Root" +n13: rectangle label:"Order Item Entity" +n14: rectangle label:"Money Value Object" +n15: rectangle label:"Order Status Enum" +n12.handle(right) -> n13.handle(left) [label="Contains"] +n13.handle(right) -> n14.handle(left) [label="Uses"] +n12.handle(bottom) -> n15.handle(top) [label="State"] +} diff --git a/uncategorized/architecture/cqrs-materialized-view-architecture/README.md b/uncategorized/architecture/cqrs-materialized-view-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..d6f8937f33119fa5a41b366f7dcd1af16dd6bf35 --- /dev/null +++ b/uncategorized/architecture/cqrs-materialized-view-architecture/README.md @@ -0,0 +1,19 @@ +# CQRS Materialized View Architecture + +A CQRS materialized view architecture diagram with multiple projectors building purpose-specific read models: order summaries, customer dashboards, analytics cubes, and search indexes, all fed from a single event stream. This template shows how to create multiple optimized query views from the same write events, each tailored to a specific use case with sub-millisecond read latency. Perfect for systems requiring diverse query patterns from a single data source. + +**Template ID:** `cqrs-materialized-view-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 18 +**Lanes:** 4 +**Tags:** [materialized-view, cqrs, projectors, read-model, denormalization, query-optimization, event-stream, architecture-diagram] +**Source path:** `` +**Repo path:** `uncategorized/architecture/cqrs-materialized-view-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/architecture/cqrs-materialized-view-architecture/metadata.json b/uncategorized/architecture/cqrs-materialized-view-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..5bbbd5d926506f7d0f9ed7066e83bc2e125ac8bb --- /dev/null +++ b/uncategorized/architecture/cqrs-materialized-view-architecture/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "cqrs-materialized-view-architecture", + "workflow_id": "cqrs-materialized-view-architecture", + "title": "CQRS Materialized View Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 18, + "num_lanes": 4, + "tags": [ + "materialized-view", + "cqrs", + "projectors", + "read-model", + "denormalization", + "query-optimization", + "event-stream", + "architecture-diagram" + ], + "description": "A CQRS materialized view architecture diagram with multiple projectors building purpose-specific read models: order summaries, customer dashboards, analytics cubes, and search indexes, all fed from a single event stream. This template shows how to create multiple optimized query views from the same write events, each tailored to a specific use case with sub-millisecond read latency. Perfect for systems requiring diverse query patterns from a single data source.", + "source_path": "", + "repo_path": "uncategorized/architecture/cqrs-materialized-view-architecture" +} diff --git a/uncategorized/architecture/cqrs-materialized-view-architecture/workflow.fz b/uncategorized/architecture/cqrs-materialized-view-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..e4ed310b10241abd1a8b203fd36760a09aa183c8 --- /dev/null +++ b/uncategorized/architecture/cqrs-materialized-view-architecture/workflow.fz @@ -0,0 +1,43 @@ +WriteModel { # Write Model +n1: circle label:"Incoming Command" +n2: rectangle label:"Command Handler" +n3: rectangle label:"Validate Against Aggregate" +n4: rectangle label:"Persist to Write Store" +n5: rectangle label:"Emit Domain Event" +n1.handle(right) -> n2.handle(left) +n2.handle(right) -> n3.handle(left) +n3.handle(right) -> n4.handle(left) [label="Normalized"] +n4.handle(right) -> n5.handle(left) [label="After Commit"] +n5.handle(bottom) -> EventBus.n6.handle(top) [label="Publish"] +} +EventBus { # Event Bus +n6: rectangle label:"Route Event" +n7: rectangle label:"Guarantee Ordering" +n8: rectangle label:"Deliver to Projectors" +n6.handle(right) -> n7.handle(left) [label="Partition Key"] +n7.handle(right) -> n8.handle(left) +n8.handle(bottom) -> Projectors.n9.handle(top) [label="Fan-Out"] +} +Projectors { # View Projectors +n9: rectangle label:"Order Summary Projector" +n10: rectangle label:"Customer Dashboard Projector" +n11: rectangle label:"Analytics Projector" +n12: rectangle label:"Search Index Projector" +n9.handle(bottom) -> Views.n13.handle(top) [label="Build View"] +n10.handle(bottom) -> Views.n14.handle(top) [label="Build View"] +n11.handle(bottom) -> Views.n15.handle(top) [label="Build View"] +n12.handle(bottom) -> Views.n16.handle(top) [label="Build View"] +} +Views { # Materialized Views +n13: rectangle label:"Order Summary Table" +n14: rectangle label:"Customer Dashboard Cache" +n15: rectangle label:"Analytics Cube" +n16: rectangle label:"Elasticsearch Index" +n17: rectangle label:"Query API" +n18: circle label:"Fast Read Response" +n13.handle(right) -> n17.handle(left) +n14.handle(right) -> n17.handle(left) +n15.handle(right) -> n17.handle(left) +n16.handle(right) -> n17.handle(left) +n17.handle(right) -> n18.handle(left) [label="Sub-ms Latency"] +} diff --git a/uncategorized/architecture/cqrs-read-write-separation-architecture/README.md b/uncategorized/architecture/cqrs-read-write-separation-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..c1f2a2ff7d16d83bcb191b20fd8ea8d38d359bfd --- /dev/null +++ b/uncategorized/architecture/cqrs-read-write-separation-architecture/README.md @@ -0,0 +1,19 @@ +# CQRS Read-Write Separation Architecture + +A CQRS read-write separation architecture diagram with dedicated command and query paths, PostgreSQL for writes, Redis or Elasticsearch for optimized reads, and an event-driven synchronization layer with lag monitoring. This template demonstrates the core CQRS principle of separating read and write models to independently scale and optimize each path. Ideal for applications with asymmetric read/write ratios where query performance is critical. + +**Template ID:** `cqrs-read-write-separation-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 18 +**Lanes:** 4 +**Tags:** [cqrs, read-write-separation, command-query, postgresql, redis, elasticsearch, read-model-sync, architecture-diagram] +**Source path:** `` +**Repo path:** `uncategorized/architecture/cqrs-read-write-separation-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/architecture/cqrs-read-write-separation-architecture/metadata.json b/uncategorized/architecture/cqrs-read-write-separation-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..767ef047391fd61a3818d89d50fd2ddc8afe115b --- /dev/null +++ b/uncategorized/architecture/cqrs-read-write-separation-architecture/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "cqrs-read-write-separation-architecture", + "workflow_id": "cqrs-read-write-separation-architecture", + "title": "CQRS Read-Write Separation Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 18, + "num_lanes": 4, + "tags": [ + "cqrs", + "read-write-separation", + "command-query", + "postgresql", + "redis", + "elasticsearch", + "read-model-sync", + "architecture-diagram" + ], + "description": "A CQRS read-write separation architecture diagram with dedicated command and query paths, PostgreSQL for writes, Redis or Elasticsearch for optimized reads, and an event-driven synchronization layer with lag monitoring. This template demonstrates the core CQRS principle of separating read and write models to independently scale and optimize each path. Ideal for applications with asymmetric read/write ratios where query performance is critical.", + "source_path": "", + "repo_path": "uncategorized/architecture/cqrs-read-write-separation-architecture" +} diff --git a/uncategorized/architecture/cqrs-read-write-separation-architecture/workflow.fz b/uncategorized/architecture/cqrs-read-write-separation-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..6408f4d2fc653e9b30e35158740d6588e0336bf4 --- /dev/null +++ b/uncategorized/architecture/cqrs-read-write-separation-architecture/workflow.fz @@ -0,0 +1,50 @@ +Client { # Client Application +n1: circle label:"User Action" +n2: diamond label:"Read or Write?" +n19: rectangle label:"Display Query Result" +n20: rectangle label:"Confirm Write Success" +n21: circle label:"End" +n1.handle(right) -> n2.handle(left) +n2.handle(bottom) -> WritePath.n3.handle(top) [label="Command"] +n2.handle(right) -> ReadPath.n9.handle(left) [label="Query"] +n19.handle(right) -> n21.handle(left) +n20.handle(right) -> n21.handle(left) +} +WritePath { # Write Path (Command) +n3: rectangle label:"Command Validator" +n4: rectangle label:"Domain Aggregate" +n5: rectangle label:"Write Database (PostgreSQL)" +n6: rectangle label:"Publish Change Event" +n7: rectangle label:"Send Write Confirmation" +n8: rectangle label:"Forward ACK" +n3.handle(right) -> n4.handle(left) [label="Validated"] +n4.handle(right) -> n5.handle(left) [label="Persist"] +n5.handle(right) -> n6.handle(left) [label="Committed"] +n6.handle(bottom) -> Sync.n15.handle(top) [label="DomainEvent"] +n5.handle(bottom) -> n7.handle(top) [label="ACK"] +n7.handle(right) -> n8.handle(left) +n8.handle(top) -> Client.n20.handle(bottom) [label="Write OK"] +} +ReadPath { # Read Path (Query) +n9: rectangle label:"Query Router" +n10: rectangle label:"Read Database (Redis/Elastic)" +n11: rectangle label:"Transform to DTO" +n12: rectangle label:"Return Response" +n13: rectangle label:"Send Query Result" +n14: rectangle label:"Forward Result" +n9.handle(right) -> n10.handle(left) [label="Optimized Query"] +n10.handle(right) -> n11.handle(left) [label="Denormalized"] +n11.handle(right) -> n12.handle(left) +n12.handle(right) -> n13.handle(left) +n13.handle(right) -> n14.handle(left) +n14.handle(top) -> Client.n19.handle(bottom) [label="JSON"] +} +Sync { # Synchronization Layer +n15: rectangle label:"Event Consumer" +n16: rectangle label:"Transform for Read Model" +n17: rectangle label:"Update Read Database" +n18: rectangle label:"Sync Complete" +n15.handle(right) -> n16.handle(left) [label="Consume"] +n16.handle(right) -> n17.handle(left) [label="Upsert"] +n17.handle(right) -> n18.handle(left) [label="Updated"] +} diff --git a/uncategorized/architecture/cqrs-task-based-ui-architecture/README.md b/uncategorized/architecture/cqrs-task-based-ui-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..a5205c0456888e9e7a46ca7720b5a2a1dfd1821a --- /dev/null +++ b/uncategorized/architecture/cqrs-task-based-ui-architecture/README.md @@ -0,0 +1,19 @@ +# CQRS Task-Based UI Architecture + +A CQRS task-based UI architecture diagram where the frontend captures user intent as explicit commands, submits them asynchronously with optimistic updates, and receives real-time confirmations via WebSocket when the read model is synchronized. This template models the modern UI pattern that replaces CRUD forms with intent-driven commands, enabling responsive user experiences with eventual consistency. Recommended for teams building reactive frontends on CQRS backends. + +**Template ID:** `cqrs-task-based-ui-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 19 +**Lanes:** 4 +**Tags:** [task-based-ui, cqrs, optimistic-update, websocket, command-pattern, idempotency, reactive-ui, architecture-diagram] +**Source path:** `` +**Repo path:** `uncategorized/architecture/cqrs-task-based-ui-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/architecture/cqrs-task-based-ui-architecture/metadata.json b/uncategorized/architecture/cqrs-task-based-ui-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..2c8447ea70ce9cb3914623a1f03ed0cbd7f3aba3 --- /dev/null +++ b/uncategorized/architecture/cqrs-task-based-ui-architecture/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "cqrs-task-based-ui-architecture", + "workflow_id": "cqrs-task-based-ui-architecture", + "title": "CQRS Task-Based UI Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 19, + "num_lanes": 4, + "tags": [ + "task-based-ui", + "cqrs", + "optimistic-update", + "websocket", + "command-pattern", + "idempotency", + "reactive-ui", + "architecture-diagram" + ], + "description": "A CQRS task-based UI architecture diagram where the frontend captures user intent as explicit commands, submits them asynchronously with optimistic updates, and receives real-time confirmations via WebSocket when the read model is synchronized. This template models the modern UI pattern that replaces CRUD forms with intent-driven commands, enabling responsive user experiences with eventual consistency. Recommended for teams building reactive frontends on CQRS backends.", + "source_path": "", + "repo_path": "uncategorized/architecture/cqrs-task-based-ui-architecture" +} diff --git a/uncategorized/architecture/cqrs-task-based-ui-architecture/workflow.fz b/uncategorized/architecture/cqrs-task-based-ui-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..e18798c1d603965e3d61d517c130a698e08a0371 --- /dev/null +++ b/uncategorized/architecture/cqrs-task-based-ui-architecture/workflow.fz @@ -0,0 +1,48 @@ +UI { # Task-Based UI +n1: circle label:"User Intent" +n2: rectangle label:"Render Task Form" +n3: rectangle label:"Capture User Intent as Command" +n4: rectangle label:"Submit Command" +n23: rectangle label:"Show Optimistic Update" +n24: circle label:"UI Confirmed" +n1.handle(right) -> n2.handle(left) +n2.handle(right) -> n3.handle(left) [label="PlaceOrder"] +n3.handle(right) -> n4.handle(left) [label="Command DTO"] +n4.handle(bottom) -> CommandAPI.n5.handle(top) [label="POST /commands"] +n23.handle(right) -> n24.handle(left) +} +CommandAPI { # Command API +n5: rectangle label:"Deserialize Command" +n6: rectangle label:"Authorize User" +n7: diamond label:"Idempotency Check" +n8: rectangle label:"Dispatch to Handler" +n9: rectangle label:"Return 202 Accepted" +n10: rectangle label:"Return 409 Duplicate" +n5.handle(right) -> n6.handle(left) +n6.handle(right) -> n7.handle(left) +n7.handle(right) -> n8.handle(left) [label="New"] +n7.handle(bottom) -> n10.handle(top) [label="Duplicate"] +n8.handle(right) -> n9.handle(left) [label="Queued"] +n8.handle(bottom) -> Domain.n11.handle(top) [label="Process"] +n9.handle(top) -> UI.n23.handle(bottom) [label="202 Accepted"] +} +Domain { # Domain Model +n11: rectangle label:"Load Aggregate" +n12: rectangle label:"Execute Business Logic" +n13: rectangle label:"Persist State Change" +n14: rectangle label:"Emit Events" +n11.handle(right) -> n12.handle(left) [label="Current State"] +n12.handle(right) -> n13.handle(left) [label="New State"] +n13.handle(right) -> n14.handle(left) [label="Committed"] +n14.handle(bottom) -> QuerySync.n15.handle(top) [label="Async"] +} +QuerySync { # Query Synchronization +n15: rectangle label:"Update Read Model" +n16: rectangle label:"Invalidate Cache" +n17: rectangle label:"Push via WebSocket" +n18: rectangle label:"Send Confirmed Update" +n15.handle(right) -> n16.handle(left) +n16.handle(right) -> n17.handle(left) [label="Real-Time"] +n17.handle(right) -> n18.handle(left) +n18.handle(top) -> UI.n23.handle(bottom) [label="Confirmed"] +} diff --git a/uncategorized/architecture/data-mesh-architecture/README.md b/uncategorized/architecture/data-mesh-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..1c7c5c568bec15604dc9d3df2f83c84818d38070 --- /dev/null +++ b/uncategorized/architecture/data-mesh-architecture/README.md @@ -0,0 +1,19 @@ +# Data Mesh Architecture + +A data mesh architecture diagram with domain-oriented data ownership across Sales, Marketing, and Finance domains, each exposing self-serve data products through APIs with quality SLAs, governed by a federated data platform with a shared catalog and cross-domain query engine. This template models the paradigm shift from centralized data teams to domain-owned data products, applying microservices principles to data architecture. Essential for organizations scaling data operations beyond centralized data warehouse bottlenecks. + +**Template ID:** `data-mesh-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 17 +**Lanes:** 4 +**Tags:** [data-mesh, domain-ownership, data-product, self-serve-data, federated-governance, data-platform, data-architecture, architecture-diagram] +**Source path:** `` +**Repo path:** `uncategorized/architecture/data-mesh-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/architecture/data-mesh-architecture/metadata.json b/uncategorized/architecture/data-mesh-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..743ca0b11ece2ac84ce7e4804a4ee8bd2915556e --- /dev/null +++ b/uncategorized/architecture/data-mesh-architecture/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "data-mesh-architecture", + "workflow_id": "data-mesh-architecture", + "title": "Data Mesh Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 17, + "num_lanes": 4, + "tags": [ + "data-mesh", + "domain-ownership", + "data-product", + "self-serve-data", + "federated-governance", + "data-platform", + "data-architecture", + "architecture-diagram" + ], + "description": "A data mesh architecture diagram with domain-oriented data ownership across Sales, Marketing, and Finance domains, each exposing self-serve data products through APIs with quality SLAs, governed by a federated data platform with a shared catalog and cross-domain query engine. This template models the paradigm shift from centralized data teams to domain-owned data products, applying microservices principles to data architecture. Essential for organizations scaling data operations beyond centralized data warehouse bottlenecks.", + "source_path": "", + "repo_path": "uncategorized/architecture/data-mesh-architecture" +} diff --git a/uncategorized/architecture/data-mesh-architecture/workflow.fz b/uncategorized/architecture/data-mesh-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..1c5aaaf23f2b792e7ebb297a5c5c3815e80347fe --- /dev/null +++ b/uncategorized/architecture/data-mesh-architecture/workflow.fz @@ -0,0 +1,41 @@ +SalesDomain { # Sales Data Domain +n1: rectangle label:"Sales Data Product Owner" +n2: rectangle label:"Sales Pipeline Dataset" +n3: rectangle label:"Self-Serve Data API" +n4: rectangle label:"Data Quality SLA" +n1.handle(right) -> n2.handle(left) [label="Owns"] +n2.handle(right) -> n3.handle(left) [label="Expose"] +n3.handle(right) -> n4.handle(left) [label="Monitor"] +n3.handle(bottom) -> Platform.n13.handle(top) [label="Register"] +} +MarketingDomain { # Marketing Data Domain +n5: rectangle label:"Marketing Data Product Owner" +n6: rectangle label:"Campaign Analytics Dataset" +n7: rectangle label:"Self-Serve Data API" +n8: rectangle label:"Data Quality SLA" +n5.handle(right) -> n6.handle(left) [label="Owns"] +n6.handle(right) -> n7.handle(left) [label="Expose"] +n7.handle(right) -> n8.handle(left) [label="Monitor"] +n7.handle(bottom) -> Platform.n13.handle(top) [label="Register"] +} +FinanceDomain { # Finance Data Domain +n9: rectangle label:"Finance Data Product Owner" +n10: rectangle label:"Revenue Reporting Dataset" +n11: rectangle label:"Self-Serve Data API" +n12: rectangle label:"Data Quality SLA" +n9.handle(right) -> n10.handle(left) [label="Owns"] +n10.handle(right) -> n11.handle(left) [label="Expose"] +n11.handle(right) -> n12.handle(left) [label="Monitor"] +n11.handle(bottom) -> Platform.n13.handle(top) [label="Register"] +} +Platform { # Self-Serve Data Platform +n13: rectangle label:"Data Product Catalog" +n14: rectangle label:"Federated Governance" +n15: rectangle label:"Shared Infrastructure" +n16: rectangle label:"Data Mesh Gateway" +n17: rectangle label:"Cross-Domain Query Engine" +n13.handle(right) -> n14.handle(left) [label="Policies"] +n14.handle(right) -> n15.handle(left) [label="Standards"] +n15.handle(right) -> n16.handle(left) [label="Access"] +n16.handle(right) -> n17.handle(left) [label="Federated Query"] +} diff --git a/uncategorized/architecture/domain-driven-design-bounded-contexts-architecture/README.md b/uncategorized/architecture/domain-driven-design-bounded-contexts-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..fd3b489d1e31bf9af873812153cb3285ce781a31 --- /dev/null +++ b/uncategorized/architecture/domain-driven-design-bounded-contexts-architecture/README.md @@ -0,0 +1,19 @@ +# Domain-Driven Design Bounded Contexts Architecture + +A DDD bounded contexts architecture diagram with Order, Customer, Shipping, and Billing contexts connected through an anti-corruption layer, shared kernel, and context map defining integration relationships. This template visualizes the strategic DDD patterns for decomposing complex domains into autonomous bounded contexts that communicate through well-defined integration events. Critical for architects applying Domain-Driven Design to large-scale enterprise systems. + +**Template ID:** `domain-driven-design-bounded-contexts-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 18 +**Lanes:** 5 +**Tags:** [domain-driven-design, bounded-context, anti-corruption-layer, context-map, shared-kernel, strategic-ddd, aggregate, architecture-diagram] +**Source path:** `` +**Repo path:** `uncategorized/architecture/domain-driven-design-bounded-contexts-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/architecture/domain-driven-design-bounded-contexts-architecture/metadata.json b/uncategorized/architecture/domain-driven-design-bounded-contexts-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..a524c2988238965cf74299a474ba8ef23138982f --- /dev/null +++ b/uncategorized/architecture/domain-driven-design-bounded-contexts-architecture/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "domain-driven-design-bounded-contexts-architecture", + "workflow_id": "domain-driven-design-bounded-contexts-architecture", + "title": "Domain-Driven Design Bounded Contexts Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 18, + "num_lanes": 5, + "tags": [ + "domain-driven-design", + "bounded-context", + "anti-corruption-layer", + "context-map", + "shared-kernel", + "strategic-ddd", + "aggregate", + "architecture-diagram" + ], + "description": "A DDD bounded contexts architecture diagram with Order, Customer, Shipping, and Billing contexts connected through an anti-corruption layer, shared kernel, and context map defining integration relationships. This template visualizes the strategic DDD patterns for decomposing complex domains into autonomous bounded contexts that communicate through well-defined integration events. Critical for architects applying Domain-Driven Design to large-scale enterprise systems.", + "source_path": "", + "repo_path": "uncategorized/architecture/domain-driven-design-bounded-contexts-architecture" +} diff --git a/uncategorized/architecture/domain-driven-design-bounded-contexts-architecture/workflow.fz b/uncategorized/architecture/domain-driven-design-bounded-contexts-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..62a23e9065d008f022e42c1e86756cdbc1624496 --- /dev/null +++ b/uncategorized/architecture/domain-driven-design-bounded-contexts-architecture/workflow.fz @@ -0,0 +1,67 @@ +OrderContext { # Order Bounded Context +n1: rectangle label:"Order Service" +n2: rectangle label:"Order Aggregate" +n3: rectangle label:"Order Line Item" +n4: rectangle label:"Order Repository" +n27: rectangle label:"Receive Shipping Ack" +n28: rectangle label:"Order Shipping Confirmed" +n1.handle(right) -> n2.handle(left) [label="Manages"] +n2.handle(right) -> n3.handle(left) [label="Contains"] +n3.handle(right) -> n4.handle(left) [label="Persists"] +n1.handle(bottom) -> ACL.n9.handle(top) [label="Integration Event"] +n27.handle(right) -> n28.handle(left) +} +CustomerContext { # Customer Bounded Context +n5: rectangle label:"Customer Service" +n6: rectangle label:"Customer Aggregate" +n7: rectangle label:"Address Value Object" +n8: rectangle label:"Customer Repository" +n29: rectangle label:"Receive Billing Ack" +n30: rectangle label:"Invoice Confirmed" +n5.handle(right) -> n6.handle(left) [label="Manages"] +n6.handle(right) -> n7.handle(left) [label="Has"] +n7.handle(right) -> n8.handle(left) [label="Persists"] +n5.handle(bottom) -> ACL.n10.handle(top) [label="Integration Event"] +n29.handle(right) -> n30.handle(left) +} +ACL { # Anti-Corruption Layer +n9: rectangle label:"Order-to-Shipping Translator" +n10: rectangle label:"Customer-to-Billing Translator" +n11: rectangle label:"Shared Kernel (Common Types)" +n12: rectangle label:"Context Map" +n23: rectangle label:"Receive Shipping Result" +n24: rectangle label:"Forward to OrderContext" +n25: rectangle label:"Receive Billing Result" +n26: rectangle label:"Forward to CustomerContext" +n9.handle(bottom) -> ShippingContext.n13.handle(top) [label="ShipmentRequested"] +n10.handle(bottom) -> BillingContext.n19.handle(top) [label="InvoiceRequested"] +n11.handle(right) -> n12.handle(left) [label="Defines"] +n23.handle(right) -> n24.handle(left) +n24.handle(top) -> OrderContext.n27.handle(bottom) [label="Shipping Ack"] +n25.handle(right) -> n26.handle(left) +n26.handle(top) -> CustomerContext.n29.handle(bottom) [label="Billing Ack"] +} +ShippingContext { # Shipping Bounded Context +n13: rectangle label:"Shipping Service" +n14: rectangle label:"Shipment Aggregate" +n15: rectangle label:"Tracking Number VO" +n16: rectangle label:"Confirm Shipment" +n17: rectangle label:"Return Shipping Result" +n18: rectangle label:"Send to ACL" +n13.handle(right) -> n14.handle(left) [label="Manages"] +n14.handle(right) -> n15.handle(left) [label="Assigned"] +n15.handle(right) -> n16.handle(left) +n16.handle(right) -> n17.handle(left) +n17.handle(right) -> n18.handle(left) +n18.handle(top) -> ACL.n23.handle(bottom) [label="ShipmentConfirmed"] +} +BillingContext { # Billing Bounded Context +n19: rectangle label:"Billing Service" +n20: rectangle label:"Invoice Aggregate" +n21: rectangle label:"Payment Entity" +n22: rectangle label:"Return Billing Result" +n19.handle(right) -> n20.handle(left) [label="Manages"] +n20.handle(right) -> n21.handle(left) [label="Contains"] +n21.handle(right) -> n22.handle(left) +n22.handle(top) -> ACL.n25.handle(bottom) [label="InvoiceConfirmed"] +} diff --git a/uncategorized/architecture/event-driven-cdc-change-data-capture-architecture/README.md b/uncategorized/architecture/event-driven-cdc-change-data-capture-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..d553da619a87ec96aad6890bc82fa6595eec0ee3 --- /dev/null +++ b/uncategorized/architecture/event-driven-cdc-change-data-capture-architecture/README.md @@ -0,0 +1,19 @@ +# Event-Driven CDC (Change Data Capture) Architecture + +A Change Data Capture architecture diagram using Debezium to tail database transaction logs and publish change events to Kafka, feeding downstream consumers that update search indexes, invalidate caches, load data warehouses, and write audit logs. This template shows how CDC eliminates dual-write problems by capturing changes at the database level without modifying application code. Critical for data synchronization across heterogeneous systems. + +**Template ID:** `event-driven-cdc-change-data-capture-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 17 +**Lanes:** 4 +**Tags:** [change-data-capture, cdc, debezium, transaction-log, kafka-connect, data-synchronization, dual-write, architecture-diagram] +**Source path:** `` +**Repo path:** `uncategorized/architecture/event-driven-cdc-change-data-capture-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/architecture/event-driven-cdc-change-data-capture-architecture/metadata.json b/uncategorized/architecture/event-driven-cdc-change-data-capture-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..9aa05503e12dab185035da8d9a12a408a534a8f8 --- /dev/null +++ b/uncategorized/architecture/event-driven-cdc-change-data-capture-architecture/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "event-driven-cdc-change-data-capture-architecture", + "workflow_id": "event-driven-cdc-change-data-capture-architecture", + "title": "Event-Driven CDC (Change Data Capture) Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 17, + "num_lanes": 4, + "tags": [ + "change-data-capture", + "cdc", + "debezium", + "transaction-log", + "kafka-connect", + "data-synchronization", + "dual-write", + "architecture-diagram" + ], + "description": "A Change Data Capture architecture diagram using Debezium to tail database transaction logs and publish change events to Kafka, feeding downstream consumers that update search indexes, invalidate caches, load data warehouses, and write audit logs. This template shows how CDC eliminates dual-write problems by capturing changes at the database level without modifying application code. Critical for data synchronization across heterogeneous systems.", + "source_path": "", + "repo_path": "uncategorized/architecture/event-driven-cdc-change-data-capture-architecture" +} diff --git a/uncategorized/architecture/event-driven-cdc-change-data-capture-architecture/workflow.fz b/uncategorized/architecture/event-driven-cdc-change-data-capture-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..91a9757e401c444de4115726599d11d3723db071 --- /dev/null +++ b/uncategorized/architecture/event-driven-cdc-change-data-capture-architecture/workflow.fz @@ -0,0 +1,41 @@ +SourceDB { # Source Database +n1: circle label:"Data Write Operation" +n2: rectangle label:"Transaction Log (WAL)" +n3: rectangle label:"Commit to Database" +n1.handle(right) -> n2.handle(left) +n2.handle(right) -> n3.handle(left) [label="Persist"] +n2.handle(bottom) -> CDC.n4.handle(top) [label="Log Tail"] +} +CDC { # CDC Engine (Debezium) +n4: rectangle label:"Read Transaction Log" +n5: rectangle label:"Detect Change Event" +n6: rectangle label:"Serialize to Avro/JSON" +n7: diamond label:"Schema Changed?" +n8: rectangle label:"Update Schema Registry" +n9: rectangle label:"Publish Change Event" +n4.handle(right) -> n5.handle(left) [label="INSERT/UPDATE/DELETE"] +n5.handle(right) -> n6.handle(left) [label="Before + After"] +n6.handle(right) -> n7.handle(left) +n7.handle(right) -> n9.handle(left) [label="No"] +n7.handle(bottom) -> n8.handle(top) [label="Yes"] +n8.handle(right) -> n9.handle(left) [label="Registered"] +n9.handle(bottom) -> Consumers.n10.handle(top) [label="Kafka Topic"] +} +Consumers { # Downstream Consumers +n10: rectangle label:"Search Index Updater" +n11: rectangle label:"Cache Invalidator" +n12: rectangle label:"Data Warehouse Loader" +n13: rectangle label:"Audit Log Writer" +n10.handle(right) -> n11.handle(left) [label="Elasticsearch"] +n12.handle(right) -> n13.handle(left) [label="Snowflake"] +} +TargetDB { # Target Systems +n14: rectangle label:"Elasticsearch Index" +n15: rectangle label:"Redis Cache" +n16: rectangle label:"Data Warehouse" +n17: rectangle label:"Audit Database" +n10.handle(bottom) -> TargetDB.n14.handle(top) [label="Upsert Doc"] +n11.handle(bottom) -> TargetDB.n15.handle(top) [label="Invalidate"] +n12.handle(bottom) -> TargetDB.n16.handle(top) [label="Load"] +n13.handle(bottom) -> TargetDB.n17.handle(top) [label="Append"] +} diff --git a/uncategorized/architecture/event-driven-choreography-architecture/README.md b/uncategorized/architecture/event-driven-choreography-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..ce850c998001f4efe85c83b759199f27186a8968 --- /dev/null +++ b/uncategorized/architecture/event-driven-choreography-architecture/README.md @@ -0,0 +1,19 @@ +# Event-Driven Choreography Architecture + +An event-driven choreography architecture diagram where microservices coordinate through events without a central orchestrator, with Order, Payment, Inventory, and Shipping services reacting to each other's domain events. This template models the decentralized coordination pattern where each service knows only its own responsibilities and publishes events for others to consume. Best for teams favoring autonomous services over centralized workflow control. + +**Template ID:** `event-driven-choreography-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 19 +**Lanes:** 5 +**Tags:** [choreography, event-driven, decentralized-coordination, domain-events, microservices, autonomous-services, pub-sub, architecture-diagram] +**Source path:** `` +**Repo path:** `uncategorized/architecture/event-driven-choreography-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/architecture/event-driven-choreography-architecture/metadata.json b/uncategorized/architecture/event-driven-choreography-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..e466216b3b06c92ee766d92d8cf6b316e14023eb --- /dev/null +++ b/uncategorized/architecture/event-driven-choreography-architecture/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "event-driven-choreography-architecture", + "workflow_id": "event-driven-choreography-architecture", + "title": "Event-Driven Choreography Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 19, + "num_lanes": 5, + "tags": [ + "choreography", + "event-driven", + "decentralized-coordination", + "domain-events", + "microservices", + "autonomous-services", + "pub-sub", + "architecture-diagram" + ], + "description": "An event-driven choreography architecture diagram where microservices coordinate through events without a central orchestrator, with Order, Payment, Inventory, and Shipping services reacting to each other's domain events. This template models the decentralized coordination pattern where each service knows only its own responsibilities and publishes events for others to consume. Best for teams favoring autonomous services over centralized workflow control.", + "source_path": "", + "repo_path": "uncategorized/architecture/event-driven-choreography-architecture" +} diff --git a/uncategorized/architecture/event-driven-choreography-architecture/workflow.fz b/uncategorized/architecture/event-driven-choreography-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..22b83bbb651fde670e588d5a2d09b16588636f57 --- /dev/null +++ b/uncategorized/architecture/event-driven-choreography-architecture/workflow.fz @@ -0,0 +1,47 @@ +OrderService { # Order Service +n1: circle label:"New Order Received" +n2: rectangle label:"Validate Order" +n3: rectangle label:"Emit OrderCreated Event" +n17: rectangle label:"Receive Payment Confirmation" +n18: rectangle label:"Update Order Status" +n19: circle label:"Order Complete" +n1.handle(right) -> n2.handle(left) +n2.handle(right) -> n3.handle(left) [label="Valid"] +n3.handle(bottom) -> EventBus.n4.handle(top) [label="Publish"] +n17.handle(right) -> n18.handle(left) [label="Confirmed"] +n18.handle(right) -> n19.handle(left) +} +EventBus { # Event Bus +n4: rectangle label:"OrderCreated Topic" +n8: rectangle label:"PaymentConfirmed Topic" +n12: rectangle label:"InventoryReserved Topic" +n16: rectangle label:"ShipmentScheduled Topic" +n4.handle(bottom) -> PaymentService.n5.handle(top) [label="Subscribe"] +n8.handle(top) -> OrderService.n17.handle(bottom) [label="Notify"] +n8.handle(bottom) -> InventoryService.n9.handle(top) [label="Subscribe"] +n12.handle(bottom) -> ShippingService.n13.handle(top) [label="Subscribe"] +} +PaymentService { # Payment Service +n5: rectangle label:"Receive OrderCreated" +n6: rectangle label:"Process Payment" +n7: rectangle label:"Emit PaymentConfirmed" +n5.handle(right) -> n6.handle(left) [label="Charge"] +n6.handle(right) -> n7.handle(left) [label="Success"] +n7.handle(top) -> EventBus.n8.handle(bottom) [label="Publish"] +} +InventoryService { # Inventory Service +n9: rectangle label:"Receive PaymentConfirmed" +n10: rectangle label:"Reserve Stock" +n11: rectangle label:"Emit InventoryReserved" +n9.handle(right) -> n10.handle(left) [label="Allocate"] +n10.handle(right) -> n11.handle(left) [label="Reserved"] +n11.handle(top) -> EventBus.n12.handle(bottom) [label="Publish"] +} +ShippingService { # Shipping Service +n13: rectangle label:"Receive InventoryReserved" +n14: rectangle label:"Schedule Shipment" +n15: rectangle label:"Emit ShipmentScheduled" +n13.handle(right) -> n14.handle(left) [label="Plan Route"] +n14.handle(right) -> n15.handle(left) [label="Scheduled"] +n15.handle(top) -> EventBus.n16.handle(bottom) [label="Publish"] +} diff --git a/uncategorized/architecture/event-driven-cqrs-with-event-store-architecture/README.md b/uncategorized/architecture/event-driven-cqrs-with-event-store-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..a1014b41a38e2cc4c26b31636d2eebbe05df7668 --- /dev/null +++ b/uncategorized/architecture/event-driven-cqrs-with-event-store-architecture/README.md @@ -0,0 +1,19 @@ +# Event-Driven CQRS with Event Store Architecture + +A CQRS architecture diagram combining separate command and query APIs with an event bus for asynchronous read model synchronization, including projectors that build denormalized views from domain events. This template demonstrates the full CQRS+ES stack where writes go through domain validation and reads are served from optimized materialized views. Ideal for high-throughput systems where read and write workloads have fundamentally different scaling requirements. + +**Template ID:** `event-driven-cqrs-with-event-store-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 18 +**Lanes:** 4 +**Tags:** [cqrs, event-store, command-query-separation, read-model, write-model, projector, eventual-consistency, architecture-diagram] +**Source path:** `` +**Repo path:** `uncategorized/architecture/event-driven-cqrs-with-event-store-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/architecture/event-driven-cqrs-with-event-store-architecture/metadata.json b/uncategorized/architecture/event-driven-cqrs-with-event-store-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..d3d3cc81d1b46b45363ec70c7976a206f074cd56 --- /dev/null +++ b/uncategorized/architecture/event-driven-cqrs-with-event-store-architecture/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "event-driven-cqrs-with-event-store-architecture", + "workflow_id": "event-driven-cqrs-with-event-store-architecture", + "title": "Event-Driven CQRS with Event Store Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 18, + "num_lanes": 4, + "tags": [ + "cqrs", + "event-store", + "command-query-separation", + "read-model", + "write-model", + "projector", + "eventual-consistency", + "architecture-diagram" + ], + "description": "A CQRS architecture diagram combining separate command and query APIs with an event bus for asynchronous read model synchronization, including projectors that build denormalized views from domain events. This template demonstrates the full CQRS+ES stack where writes go through domain validation and reads are served from optimized materialized views. Ideal for high-throughput systems where read and write workloads have fundamentally different scaling requirements.", + "source_path": "", + "repo_path": "uncategorized/architecture/event-driven-cqrs-with-event-store-architecture" +} diff --git a/uncategorized/architecture/event-driven-cqrs-with-event-store-architecture/workflow.fz b/uncategorized/architecture/event-driven-cqrs-with-event-store-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..9b2434199210a71fe1b39c7100e143330fa3f838 --- /dev/null +++ b/uncategorized/architecture/event-driven-cqrs-with-event-store-architecture/workflow.fz @@ -0,0 +1,43 @@ +WriteAPI { # Write API (Command) +n1: circle label:"POST/PUT Request" +n2: rectangle label:"Command Handler" +n3: rectangle label:"Validate Business Rules" +n4: rectangle label:"Persist to Write DB" +n5: rectangle label:"Publish Domain Event" +n1.handle(right) -> n2.handle(left) +n2.handle(right) -> n3.handle(left) +n3.handle(right) -> n4.handle(left) [label="Valid"] +n4.handle(right) -> n5.handle(left) [label="Committed"] +n5.handle(bottom) -> EventBus.n6.handle(top) [label="OrderPlaced"] +} +EventBus { # Event Bus (Kafka) +n6: rectangle label:"Receive Domain Event" +n7: rectangle label:"Route to Topic" +n8: rectangle label:"Guarantee Delivery" +n9: rectangle label:"Fan-Out to Consumers" +n6.handle(right) -> n7.handle(left) +n7.handle(right) -> n8.handle(left) [label="At-Least-Once"] +n8.handle(right) -> n9.handle(left) +n9.handle(bottom) -> Projector.n10.handle(top) [label="Consume"] +} +Projector { # Read Model Projector +n10: rectangle label:"Event Handler" +n11: rectangle label:"Update Read Model" +n12: rectangle label:"Rebuild Materialized View" +n13: diamond label:"Consistency Check" +n14: rectangle label:"Mark Projection Current" +n10.handle(right) -> n11.handle(left) [label="Transform"] +n11.handle(right) -> n12.handle(left) [label="Upsert"] +n12.handle(right) -> n13.handle(left) +n13.handle(right) -> n14.handle(left) [label="Consistent"] +n14.handle(bottom) -> ReadSide.n15.handle(top) [label="Updated"] +} +ReadSide { # Read API (Query) +n15: rectangle label:"Query Handler" +n16: rectangle label:"Read from Read DB" +n17: rectangle label:"Transform to DTO" +n18: circle label:"GET Response" +n15.handle(right) -> n16.handle(left) +n16.handle(right) -> n17.handle(left) [label="Denormalized"] +n17.handle(right) -> n18.handle(left) +} diff --git a/uncategorized/architecture/event-driven-event-sourcing-architecture/README.md b/uncategorized/architecture/event-driven-event-sourcing-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..8864c0a19674b5dd51f09b5ed15dc52cd503139d --- /dev/null +++ b/uncategorized/architecture/event-driven-event-sourcing-architecture/README.md @@ -0,0 +1,19 @@ +# Event-Driven Event Sourcing Architecture + +An event sourcing architecture diagram where all state changes are stored as an immutable sequence of domain events, with read projections built from the event stream and snapshot optimization for fast aggregate loading. This template shows how event sourcing eliminates data loss by preserving the complete history of every state transition. Critical for systems requiring full audit trails, temporal queries, and event replay capabilities. + +**Template ID:** `event-driven-event-sourcing-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 18 +**Lanes:** 4 +**Tags:** [event-sourcing, immutable-events, event-store, projections, snapshot, aggregate, temporal-query, architecture-diagram] +**Source path:** `` +**Repo path:** `uncategorized/architecture/event-driven-event-sourcing-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/architecture/event-driven-event-sourcing-architecture/metadata.json b/uncategorized/architecture/event-driven-event-sourcing-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..d245047c70aecb8e8958ebcde8c355ea088c2082 --- /dev/null +++ b/uncategorized/architecture/event-driven-event-sourcing-architecture/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "event-driven-event-sourcing-architecture", + "workflow_id": "event-driven-event-sourcing-architecture", + "title": "Event-Driven Event Sourcing Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 18, + "num_lanes": 4, + "tags": [ + "event-sourcing", + "immutable-events", + "event-store", + "projections", + "snapshot", + "aggregate", + "temporal-query", + "architecture-diagram" + ], + "description": "An event sourcing architecture diagram where all state changes are stored as an immutable sequence of domain events, with read projections built from the event stream and snapshot optimization for fast aggregate loading. This template shows how event sourcing eliminates data loss by preserving the complete history of every state transition. Critical for systems requiring full audit trails, temporal queries, and event replay capabilities.", + "source_path": "", + "repo_path": "uncategorized/architecture/event-driven-event-sourcing-architecture" +} diff --git a/uncategorized/architecture/event-driven-event-sourcing-architecture/workflow.fz b/uncategorized/architecture/event-driven-event-sourcing-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..de56cc32ba136959f6f3b10beab527000b3ce2ea --- /dev/null +++ b/uncategorized/architecture/event-driven-event-sourcing-architecture/workflow.fz @@ -0,0 +1,44 @@ +Command { # Command Side +n1: circle label:"User Command" +n2: rectangle label:"Validate Command" +n3: rectangle label:"Load Aggregate" +n4: rectangle label:"Apply Business Rules" +n5: rectangle label:"Emit Domain Events" +n1.handle(right) -> n2.handle(left) +n2.handle(right) -> n3.handle(left) [label="Valid"] +n3.handle(right) -> n4.handle(left) [label="Current State"] +n4.handle(right) -> n5.handle(left) [label="State Change"] +n5.handle(bottom) -> EventStore.n6.handle(top) [label="Append"] +} +EventStore { # Event Store +n6: rectangle label:"Append Event to Stream" +n7: rectangle label:"Assign Sequence Number" +n8: rectangle label:"Persist Immutable Event" +n9: rectangle label:"Publish to Projections" +n10: rectangle label:"Snapshot Manager" +n6.handle(right) -> n7.handle(left) +n7.handle(right) -> n8.handle(left) [label="Write-Ahead Log"] +n8.handle(right) -> n9.handle(left) [label="Notify"] +n8.handle(bottom) -> n10.handle(top) [label="Checkpoint"] +n9.handle(bottom) -> Projections.n11.handle(top) [label="Event Stream"] +} +Projections { # Read Projections +n11: rectangle label:"Event Handler" +n12: rectangle label:"Build Read Model" +n13: rectangle label:"Update Materialized View" +n14: rectangle label:"Serve Query" +n15: circle label:"Query Response" +n11.handle(right) -> n12.handle(left) [label="Transform"] +n12.handle(right) -> n13.handle(left) [label="Upsert"] +n13.handle(right) -> n14.handle(left) [label="Ready"] +n14.handle(right) -> n15.handle(left) +} +Replay { # Event Replay +n16: rectangle label:"Replay from Offset" +n17: rectangle label:"Rebuild Projection" +n18: rectangle label:"Verify Consistency" +n19: rectangle label:"Projection Rebuilt" +n16.handle(right) -> n17.handle(left) [label="Historical Events"] +n17.handle(right) -> n18.handle(left) [label="Rebuilt"] +n18.handle(right) -> n19.handle(left) [label="Consistent"] +} diff --git a/uncategorized/architecture/event-driven-notification-hub-architecture/README.md b/uncategorized/architecture/event-driven-notification-hub-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..3568d93d65e0ab05ca7c596343720527376cf765 --- /dev/null +++ b/uncategorized/architecture/event-driven-notification-hub-architecture/README.md @@ -0,0 +1,19 @@ +# Event-Driven Notification Hub Architecture + +An event-driven notification hub architecture diagram with multi-source event ingestion, template-based message rendering, user preference routing across email (SendGrid/SES), push (FCM), SMS (Twilio), and Slack channels, with delivery tracking and retry mechanisms. This template models a centralized notification system that decouples business services from delivery infrastructure, supporting multi-channel communication with user-controlled preferences. Ideal for platform teams building scalable notification infrastructure. + +**Template ID:** `event-driven-notification-hub-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 20 +**Lanes:** 3 +**Tags:** [notification-hub, multi-channel, event-driven, sendgrid, firebase-cloud-messaging, twilio, delivery-tracking, architecture-diagram] +**Source path:** `` +**Repo path:** `uncategorized/architecture/event-driven-notification-hub-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/architecture/event-driven-notification-hub-architecture/metadata.json b/uncategorized/architecture/event-driven-notification-hub-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..f0cacd6fc663f5d3fa70b41e629fc5e05798ad09 --- /dev/null +++ b/uncategorized/architecture/event-driven-notification-hub-architecture/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "event-driven-notification-hub-architecture", + "workflow_id": "event-driven-notification-hub-architecture", + "title": "Event-Driven Notification Hub Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 20, + "num_lanes": 3, + "tags": [ + "notification-hub", + "multi-channel", + "event-driven", + "sendgrid", + "firebase-cloud-messaging", + "twilio", + "delivery-tracking", + "architecture-diagram" + ], + "description": "An event-driven notification hub architecture diagram with multi-source event ingestion, template-based message rendering, user preference routing across email (SendGrid/SES), push (FCM), SMS (Twilio), and Slack channels, with delivery tracking and retry mechanisms. This template models a centralized notification system that decouples business services from delivery infrastructure, supporting multi-channel communication with user-controlled preferences. Ideal for platform teams building scalable notification infrastructure.", + "source_path": "", + "repo_path": "uncategorized/architecture/event-driven-notification-hub-architecture" +} diff --git a/uncategorized/architecture/event-driven-notification-hub-architecture/workflow.fz b/uncategorized/architecture/event-driven-notification-hub-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..9fc956fc89eabc04df063c2138f46f40ae73075a --- /dev/null +++ b/uncategorized/architecture/event-driven-notification-hub-architecture/workflow.fz @@ -0,0 +1,48 @@ +Sources { # Event Sources +n1: rectangle label:"Order Service Event" +n2: rectangle label:"User Service Event" +n3: rectangle label:"Payment Service Event" +n4: rectangle label:"System Alert Event" +n1.handle(bottom) -> Hub.n5.handle(top) [label="OrderShipped"] +n2.handle(bottom) -> Hub.n5.handle(top) [label="AccountCreated"] +n3.handle(bottom) -> Hub.n5.handle(top) [label="PaymentFailed"] +n4.handle(bottom) -> Hub.n5.handle(top) [label="SystemDown"] +} +Hub { # Notification Hub +n5: rectangle label:"Receive Event" +n6: rectangle label:"Resolve Notification Template" +n7: rectangle label:"Check User Preferences" +n8: diamond label:"Channel Preference?" +n9: rectangle label:"Route to Email Channel" +n10: rectangle label:"Route to Push Channel" +n11: rectangle label:"Route to SMS Channel" +n12: rectangle label:"Route to Slack Channel" +n5.handle(right) -> n6.handle(left) [label="Match Template"] +n6.handle(right) -> n7.handle(left) [label="Render"] +n7.handle(right) -> n8.handle(left) +n8.handle(right) -> n9.handle(left) [label="Email"] +n8.handle(bottom) -> n10.handle(top) [label="Push"] +n8.handle(left) -> n11.handle(right) [label="SMS"] +n8.handle(bottom) -> n12.handle(top) [label="Slack"] +n9.handle(bottom) -> Delivery.n13.handle(top) [label="Send"] +n10.handle(bottom) -> Delivery.n14.handle(top) [label="Send"] +n11.handle(bottom) -> Delivery.n15.handle(top) [label="Send"] +n12.handle(bottom) -> Delivery.n16.handle(top) [label="Send"] +} +Delivery { # Delivery Providers +n13: rectangle label:"SendGrid / SES" +n14: rectangle label:"Firebase Cloud Messaging" +n15: rectangle label:"Twilio SMS" +n16: rectangle label:"Slack Webhook" +n17: rectangle label:"Delivery Status Tracker" +n18: diamond label:"Delivered?" +n19: rectangle label:"Log Success" +n20: rectangle label:"Retry or DLQ" +n13.handle(right) -> n17.handle(left) [label="Callback"] +n14.handle(right) -> n17.handle(left) [label="Callback"] +n15.handle(right) -> n17.handle(left) [label="Callback"] +n16.handle(right) -> n17.handle(left) [label="Callback"] +n17.handle(right) -> n18.handle(left) +n18.handle(right) -> n19.handle(left) [label="Yes"] +n18.handle(bottom) -> n20.handle(top) [label="No"] +} diff --git a/uncategorized/architecture/event-driven-publish-subscribe-architecture/README.md b/uncategorized/architecture/event-driven-publish-subscribe-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..2774b65129cea6775e7db86ef3afd045ced98c46 --- /dev/null +++ b/uncategorized/architecture/event-driven-publish-subscribe-architecture/README.md @@ -0,0 +1,19 @@ +# Event-Driven Publish-Subscribe Architecture + +An event-driven publish-subscribe architecture diagram with Kafka or RabbitMQ message broker, event serialization, topic partitioning, fan-out delivery to multiple consumers, and dead letter queue error handling. This template models the foundational async messaging pattern where producers and consumers are fully decoupled through a message broker. Essential for architects building loosely coupled, scalable event-driven systems. + +**Template ID:** `event-driven-publish-subscribe-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 17 +**Lanes:** 3 +**Tags:** [publish-subscribe, event-driven, kafka, rabbitmq, message-broker, fan-out, dead-letter-queue, architecture-diagram] +**Source path:** `` +**Repo path:** `uncategorized/architecture/event-driven-publish-subscribe-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/architecture/event-driven-publish-subscribe-architecture/metadata.json b/uncategorized/architecture/event-driven-publish-subscribe-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..3c4174082c1ee39c571fe040d154c1361180848d --- /dev/null +++ b/uncategorized/architecture/event-driven-publish-subscribe-architecture/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "event-driven-publish-subscribe-architecture", + "workflow_id": "event-driven-publish-subscribe-architecture", + "title": "Event-Driven Publish-Subscribe Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 17, + "num_lanes": 3, + "tags": [ + "publish-subscribe", + "event-driven", + "kafka", + "rabbitmq", + "message-broker", + "fan-out", + "dead-letter-queue", + "architecture-diagram" + ], + "description": "An event-driven publish-subscribe architecture diagram with Kafka or RabbitMQ message broker, event serialization, topic partitioning, fan-out delivery to multiple consumers, and dead letter queue error handling. This template models the foundational async messaging pattern where producers and consumers are fully decoupled through a message broker. Essential for architects building loosely coupled, scalable event-driven systems.", + "source_path": "", + "repo_path": "uncategorized/architecture/event-driven-publish-subscribe-architecture" +} diff --git a/uncategorized/architecture/event-driven-publish-subscribe-architecture/workflow.fz b/uncategorized/architecture/event-driven-publish-subscribe-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..0f90b8a18a794d8a347569255c4b14a2bdfaa12f --- /dev/null +++ b/uncategorized/architecture/event-driven-publish-subscribe-architecture/workflow.fz @@ -0,0 +1,37 @@ +Producer { # Event Producer +n1: circle label:"Business Action" +n2: rectangle label:"Create Domain Event" +n3: rectangle label:"Serialize Event" +n4: rectangle label:"Publish to Topic" +n1.handle(right) -> n2.handle(left) +n2.handle(right) -> n3.handle(left) [label="OrderCreated"] +n3.handle(right) -> n4.handle(left) [label="Avro/JSON"] +n4.handle(bottom) -> Broker.n5.handle(top) [label="Produce"] +} +Broker { # Message Broker (Kafka/RabbitMQ) +n5: rectangle label:"Receive Event" +n6: rectangle label:"Partition by Key" +n7: rectangle label:"Persist to Log" +n8: rectangle label:"Fan-Out to Subscribers" +n5.handle(right) -> n6.handle(left) +n6.handle(right) -> n7.handle(left) [label="Append"] +n7.handle(right) -> n8.handle(left) [label="Notify"] +n8.handle(bottom) -> Consumers.n9.handle(top) [label="Deliver"] +} +Consumers { # Event Consumers +n9: rectangle label:"Inventory Consumer" +n10: diamond label:"Processing OK?" +n11: rectangle label:"Update Stock Level" +n12: rectangle label:"Send to Dead Letter Queue" +n13: rectangle label:"Notification Consumer" +n14: rectangle label:"Send Order Email" +n15: rectangle label:"Analytics Consumer" +n16: rectangle label:"Update Dashboard" +n9.handle(right) -> n10.handle(left) +n10.handle(right) -> n11.handle(left) [label="Yes"] +n10.handle(bottom) -> n12.handle(top) [label="No"] +n11.handle(right) -> n13.handle(left) +n13.handle(right) -> n14.handle(left) [label="Email"] +n14.handle(right) -> n15.handle(left) +n15.handle(right) -> n16.handle(left) [label="Aggregate"] +} diff --git a/uncategorized/architecture/hexagonal-ports-adapters-architecture/README.md b/uncategorized/architecture/hexagonal-ports-adapters-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..b77de7fd416967370772ae4a105db0b2ae17cdc9 --- /dev/null +++ b/uncategorized/architecture/hexagonal-ports-adapters-architecture/README.md @@ -0,0 +1,19 @@ +# Hexagonal (Ports and Adapters) Architecture + +A hexagonal architecture diagram showing the clean separation between domain core, inbound adapters (REST, GraphQL, CLI, message consumers), outbound adapters (PostgreSQL, Stripe, email, Redis), and the port interfaces that connect them. This template visualizes the ports and adapters pattern where the domain core has zero dependencies on infrastructure, making it fully testable and technology-agnostic. Foundational for teams adopting clean architecture principles in their codebase. + +**Template ID:** `hexagonal-ports-adapters-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 16 +**Lanes:** 4 +**Tags:** [hexagonal-architecture, ports-and-adapters, clean-architecture, dependency-inversion, domain-core, testability, technology-agnostic, architecture-diagram] +**Source path:** `` +**Repo path:** `uncategorized/architecture/hexagonal-ports-adapters-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/architecture/hexagonal-ports-adapters-architecture/metadata.json b/uncategorized/architecture/hexagonal-ports-adapters-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..42ff95c1dfb1391813ae716c87883a2387a188ae --- /dev/null +++ b/uncategorized/architecture/hexagonal-ports-adapters-architecture/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "hexagonal-ports-adapters-architecture", + "workflow_id": "hexagonal-ports-adapters-architecture", + "title": "Hexagonal (Ports and Adapters) Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 16, + "num_lanes": 4, + "tags": [ + "hexagonal-architecture", + "ports-and-adapters", + "clean-architecture", + "dependency-inversion", + "domain-core", + "testability", + "technology-agnostic", + "architecture-diagram" + ], + "description": "A hexagonal architecture diagram showing the clean separation between domain core, inbound adapters (REST, GraphQL, CLI, message consumers), outbound adapters (PostgreSQL, Stripe, email, Redis), and the port interfaces that connect them. This template visualizes the ports and adapters pattern where the domain core has zero dependencies on infrastructure, making it fully testable and technology-agnostic. Foundational for teams adopting clean architecture principles in their codebase.", + "source_path": "", + "repo_path": "uncategorized/architecture/hexagonal-ports-adapters-architecture" +} diff --git a/uncategorized/architecture/hexagonal-ports-adapters-architecture/workflow.fz b/uncategorized/architecture/hexagonal-ports-adapters-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..34fe75d7c7cb67e6a8803ffb12f38ffa4075cdd7 --- /dev/null +++ b/uncategorized/architecture/hexagonal-ports-adapters-architecture/workflow.fz @@ -0,0 +1,41 @@ +InboundAdapters { # Inbound Adapters (Driving) +n1: rectangle label:"REST Controller" +n2: rectangle label:"GraphQL Resolver" +n3: rectangle label:"CLI Command Handler" +n4: rectangle label:"Message Consumer" +n1.handle(bottom) -> Ports.n5.handle(top) [label="Port: CreateOrder"] +n2.handle(bottom) -> Ports.n5.handle(top) [label="Port: CreateOrder"] +n3.handle(bottom) -> Ports.n6.handle(top) [label="Port: RunReport"] +n4.handle(bottom) -> Ports.n6.handle(top) [label="Port: ProcessEvent"] +} +Ports { # Ports (Interfaces) +n5: rectangle label:"Inbound Port: OrderUseCase" +n6: rectangle label:"Inbound Port: ReportUseCase" +n5.handle(bottom) -> Core.n7.handle(top) [label="Implement"] +n6.handle(bottom) -> Core.n8.handle(top) [label="Implement"] +} +Core { # Domain Core (Hexagon) +n7: rectangle label:"Order Service" +n8: rectangle label:"Report Service" +n9: rectangle label:"Domain Model (Entities)" +n10: rectangle label:"Business Rules (Value Objects)" +n7.handle(right) -> n9.handle(left) [label="Use"] +n8.handle(right) -> n9.handle(left) [label="Use"] +n9.handle(right) -> n10.handle(left) [label="Enforce"] +n7.handle(bottom) -> OutboundPorts.n11.handle(top) [label="Call Port"] +n8.handle(bottom) -> OutboundPorts.n12.handle(top) [label="Call Port"] +} +OutboundPorts { # Outbound Ports +n11: rectangle label:"Outbound Port: OrderRepository" +n12: rectangle label:"Outbound Port: PaymentGateway" +n11.handle(bottom) -> OutboundAdapters.n13.handle(top) [label="Implements"] +n12.handle(bottom) -> OutboundAdapters.n14.handle(top) [label="Implements"] +} +OutboundAdapters { # Outbound Adapters (Driven) +n13: rectangle label:"PostgreSQL Repository" +n14: rectangle label:"Stripe Payment Adapter" +n15: rectangle label:"Email Notification Adapter" +n16: rectangle label:"Redis Cache Adapter" +n13.handle(right) -> n15.handle(left) +n14.handle(right) -> n16.handle(left) +} diff --git a/uncategorized/architecture/microservices-backend-for-frontend-architecture/README.md b/uncategorized/architecture/microservices-backend-for-frontend-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..2a4b0894a21af0ccb30392bdce12d1f3179a0f32 --- /dev/null +++ b/uncategorized/architecture/microservices-backend-for-frontend-architecture/README.md @@ -0,0 +1,19 @@ +# Microservices Backend-for-Frontend (BFF) Architecture + +A Backend-for-Frontend architecture diagram with separate BFF layers for web and mobile clients, each optimizing API responses for their specific platform while sharing common backend microservices. This template shows how to avoid one-size-fits-all APIs by tailoring data aggregation and payload optimization per client type. Recommended for teams serving multiple frontend platforms from a shared microservices backend. + +**Template ID:** `microservices-backend-for-frontend-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 12 +**Lanes:** 3 +**Tags:** [backend-for-frontend, bff-pattern, mobile-api, web-api, api-aggregation, payload-optimization, microservices, architecture-diagram] +**Source path:** `` +**Repo path:** `uncategorized/architecture/microservices-backend-for-frontend-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/architecture/microservices-backend-for-frontend-architecture/metadata.json b/uncategorized/architecture/microservices-backend-for-frontend-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..0d3676d7c6ad194dc62095f8da1299dfa18599fb --- /dev/null +++ b/uncategorized/architecture/microservices-backend-for-frontend-architecture/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "microservices-backend-for-frontend-architecture", + "workflow_id": "microservices-backend-for-frontend-architecture", + "title": "Microservices Backend-for-Frontend (BFF) Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 12, + "num_lanes": 3, + "tags": [ + "backend-for-frontend", + "bff-pattern", + "mobile-api", + "web-api", + "api-aggregation", + "payload-optimization", + "microservices", + "architecture-diagram" + ], + "description": "A Backend-for-Frontend architecture diagram with separate BFF layers for web and mobile clients, each optimizing API responses for their specific platform while sharing common backend microservices. This template shows how to avoid one-size-fits-all APIs by tailoring data aggregation and payload optimization per client type. Recommended for teams serving multiple frontend platforms from a shared microservices backend.", + "source_path": "", + "repo_path": "uncategorized/architecture/microservices-backend-for-frontend-architecture" +} diff --git a/uncategorized/architecture/microservices-backend-for-frontend-architecture/workflow.fz b/uncategorized/architecture/microservices-backend-for-frontend-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..db506996bb613fb7671c079bb3a33b1ab266361a --- /dev/null +++ b/uncategorized/architecture/microservices-backend-for-frontend-architecture/workflow.fz @@ -0,0 +1,41 @@ +WebApp { # Web Application +n1: circle label:"Browser Request" +n2: rectangle label:"Web BFF" +n15: rectangle label:"Render HTML Response" +n16: circle label:"Display Page" +n1.handle(right) -> n2.handle(left) +n2.handle(bottom) -> Services.n5.handle(top) [label="Fetch Data"] +n15.handle(right) -> n16.handle(left) +} +MobileApp { # Mobile Application +n3: circle label:"Mobile API Call" +n4: rectangle label:"Mobile BFF" +n17: rectangle label:"Optimized Payload" +n18: circle label:"Render Native UI" +n3.handle(right) -> n4.handle(left) +n4.handle(bottom) -> Services.n5.handle(top) [label="Fetch Data"] +n17.handle(right) -> n18.handle(left) +} +Services { # Shared Microservices +n5: rectangle label:"User Profile Service" +n6: rectangle label:"Content Service" +n7: rectangle label:"Notification Service" +n8: rectangle label:"Analytics Service" +n9: rectangle label:"Prepare Web Payload" +n10: rectangle label:"Prepare Mobile Payload" +n11: rectangle label:"Send Web Response" +n12: rectangle label:"Send Mobile Response" +n13: rectangle label:"Send Push Notification" +n14: rectangle label:"Log Analytics" +n5.handle(right) -> n6.handle(left) [label="User Context"] +n6.handle(right) -> n7.handle(left) +n7.handle(right) -> n8.handle(left) +n8.handle(right) -> n9.handle(left) +n9.handle(right) -> n10.handle(left) +n10.handle(right) -> n11.handle(left) +n11.handle(top) -> WebApp.n15.handle(bottom) [label="Full Payload"] +n11.handle(right) -> n12.handle(left) +n12.handle(top) -> MobileApp.n17.handle(bottom) [label="Compact Payload"] +n12.handle(right) -> n13.handle(left) +n13.handle(right) -> n14.handle(left) [label="Push + Track"] +} diff --git a/uncategorized/architecture/microservices-database-per-service-architecture/README.md b/uncategorized/architecture/microservices-database-per-service-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..4d75bd5fcd1b01b726dfb6953c73d2c5c5cf3826 --- /dev/null +++ b/uncategorized/architecture/microservices-database-per-service-architecture/README.md @@ -0,0 +1,19 @@ +# Microservices Database-Per-Service Architecture + +A database-per-service architecture diagram where each microservice owns its dedicated data store, with event-driven synchronization via Kafka for cross-service data consistency. This template demonstrates the core microservices data isolation principle, showing how PostgreSQL and MongoDB coexist in a polyglot persistence strategy. Critical for architects enforcing service autonomy while maintaining eventual consistency. + +**Template ID:** `microservices-database-per-service-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 16 +**Lanes:** 4 +**Tags:** [database-per-service, polyglot-persistence, microservices, kafka, event-driven, data-isolation, eventual-consistency, architecture-diagram] +**Source path:** `` +**Repo path:** `uncategorized/architecture/microservices-database-per-service-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/architecture/microservices-database-per-service-architecture/metadata.json b/uncategorized/architecture/microservices-database-per-service-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..ee2c3e54ca7ec42b632f0326ec765224bb70d2b5 --- /dev/null +++ b/uncategorized/architecture/microservices-database-per-service-architecture/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "microservices-database-per-service-architecture", + "workflow_id": "microservices-database-per-service-architecture", + "title": "Microservices Database-Per-Service Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 16, + "num_lanes": 4, + "tags": [ + "database-per-service", + "polyglot-persistence", + "microservices", + "kafka", + "event-driven", + "data-isolation", + "eventual-consistency", + "architecture-diagram" + ], + "description": "A database-per-service architecture diagram where each microservice owns its dedicated data store, with event-driven synchronization via Kafka for cross-service data consistency. This template demonstrates the core microservices data isolation principle, showing how PostgreSQL and MongoDB coexist in a polyglot persistence strategy. Critical for architects enforcing service autonomy while maintaining eventual consistency.", + "source_path": "", + "repo_path": "uncategorized/architecture/microservices-database-per-service-architecture" +} diff --git a/uncategorized/architecture/microservices-database-per-service-architecture/workflow.fz b/uncategorized/architecture/microservices-database-per-service-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..31e46e8dd6144521843aea7350d07c244fce27cd --- /dev/null +++ b/uncategorized/architecture/microservices-database-per-service-architecture/workflow.fz @@ -0,0 +1,39 @@ +Gateway { # API Gateway +n1: circle label:"Client Request" +n2: rectangle label:"Route to Service" +n15: rectangle label:"Aggregate Responses" +n16: circle label:"Return to Client" +n1.handle(right) -> n2.handle(left) +n2.handle(bottom) -> UserService.n3.handle(top) [label="User Data"] +n2.handle(bottom) -> OrderService.n7.handle(top) [label="Order Data"] +n15.handle(right) -> n16.handle(left) +} +UserService { # User Service +n3: rectangle label:"Handle User Request" +n4: rectangle label:"Query User DB" +n5: rectangle label:"User PostgreSQL" +n6: rectangle label:"Return User Data" +n3.handle(right) -> n4.handle(left) +n4.handle(right) -> n5.handle(left) [label="SELECT"] +n5.handle(right) -> n6.handle(left) [label="Result"] +n6.handle(top) -> Gateway.n15.handle(bottom) [label="User JSON"] +} +OrderService { # Order Service +n7: rectangle label:"Handle Order Request" +n8: rectangle label:"Query Order DB" +n9: rectangle label:"Order MongoDB" +n10: rectangle label:"Return Order Data" +n7.handle(right) -> n8.handle(left) +n8.handle(right) -> n9.handle(left) [label="find()"] +n9.handle(right) -> n10.handle(left) [label="Documents"] +n10.handle(top) -> Gateway.n15.handle(bottom) [label="Order JSON"] +} +EventBus { # Event Bus (Kafka) +n11: rectangle label:"Publish Domain Event" +n12: rectangle label:"Event Topic" +n13: rectangle label:"Consume Event" +n14: rectangle label:"Sync Read Model" +n11.handle(right) -> n12.handle(left) [label="UserUpdated"] +n12.handle(right) -> n13.handle(left) [label="Subscribe"] +n13.handle(right) -> n14.handle(left) [label="Update Denormalized"] +} diff --git a/uncategorized/architecture/microservices-decomposition-by-business-capability/README.md b/uncategorized/architecture/microservices-decomposition-by-business-capability/README.md new file mode 100644 index 0000000000000000000000000000000000000000..7987446d83b19d50f41d3d2099194ddd42160b8e --- /dev/null +++ b/uncategorized/architecture/microservices-decomposition-by-business-capability/README.md @@ -0,0 +1,19 @@ +# Microservices Decomposition by Business Capability + +A microservices decomposition architecture diagram organized by business capabilities: Identity, Product Catalog, Pricing, and Order Fulfillment, each with independent data stores and APIs. This template shows how to break a monolith into services aligned with business domains, using a Backend-for-Frontend (BFF) pattern for client-specific aggregation. Useful for architects planning domain-driven microservice boundaries. + +**Template ID:** `microservices-decomposition-by-business-capability` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 17 +**Lanes:** 5 +**Tags:** [microservices-decomposition, business-capability, bff, domain-driven-design, service-boundaries, monolith-to-microservices, architecture-diagram] +**Source path:** `` +**Repo path:** `uncategorized/architecture/microservices-decomposition-by-business-capability` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/architecture/microservices-decomposition-by-business-capability/metadata.json b/uncategorized/architecture/microservices-decomposition-by-business-capability/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..c39cf09c0abe16b28b85fdc7939044fe6cf719b5 --- /dev/null +++ b/uncategorized/architecture/microservices-decomposition-by-business-capability/metadata.json @@ -0,0 +1,25 @@ +{ + "template_id": "microservices-decomposition-by-business-capability", + "workflow_id": "microservices-decomposition-by-business-capability", + "title": "Microservices Decomposition by Business Capability", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 17, + "num_lanes": 5, + "tags": [ + "microservices-decomposition", + "business-capability", + "bff", + "domain-driven-design", + "service-boundaries", + "monolith-to-microservices", + "architecture-diagram" + ], + "description": "A microservices decomposition architecture diagram organized by business capabilities: Identity, Product Catalog, Pricing, and Order Fulfillment, each with independent data stores and APIs. This template shows how to break a monolith into services aligned with business domains, using a Backend-for-Frontend (BFF) pattern for client-specific aggregation. Useful for architects planning domain-driven microservice boundaries.", + "source_path": "", + "repo_path": "uncategorized/architecture/microservices-decomposition-by-business-capability" +} diff --git a/uncategorized/architecture/microservices-decomposition-by-business-capability/workflow.fz b/uncategorized/architecture/microservices-decomposition-by-business-capability/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..2b16a6c298bdd66f7dee88b5c89ec3563e93da27 --- /dev/null +++ b/uncategorized/architecture/microservices-decomposition-by-business-capability/workflow.fz @@ -0,0 +1,45 @@ +Frontend { # Frontend BFF +n1: circle label:"User Action" +n2: rectangle label:"BFF Layer" +n3: rectangle label:"Compose UI Response" +n4: circle label:"Render UI" +n1.handle(right) -> n2.handle(left) +n2.handle(bottom) -> Identity.n5.handle(top) [label="Auth Check"] +n3.handle(right) -> n4.handle(left) +} +Identity { # Identity & Access +n5: rectangle label:"Authenticate User" +n6: diamond label:"Authorized?" +n7: rectangle label:"Issue Access Token" +n8: rectangle label:"Deny Access" +n5.handle(right) -> n6.handle(left) +n6.handle(right) -> n7.handle(left) [label="Yes"] +n6.handle(bottom) -> n8.handle(top) [label="No"] +n7.handle(bottom) -> Catalog.n9.handle(top) [label="Token"] +n8.handle(top) -> Frontend.n3.handle(bottom) [label="403"] +} +Catalog { # Product Catalog +n9: rectangle label:"Fetch Product Details" +n10: rectangle label:"Product Database" +n11: rectangle label:"Return Catalog Data" +n9.handle(right) -> n10.handle(left) [label="Query"] +n10.handle(right) -> n11.handle(left) [label="Products"] +n11.handle(bottom) -> Pricing.n12.handle(top) [label="Product IDs"] +n11.handle(top) -> Frontend.n3.handle(bottom) [label="Catalog JSON"] +} +Pricing { # Pricing & Promotions +n12: rectangle label:"Calculate Price" +n13: rectangle label:"Apply Promotions" +n14: rectangle label:"Return Final Price" +n12.handle(right) -> n13.handle(left) [label="Base Price"] +n13.handle(right) -> n14.handle(left) [label="Discounted"] +n14.handle(top) -> Frontend.n3.handle(bottom) [label="Price JSON"] +} +Fulfillment { # Order Fulfillment +n15: rectangle label:"Reserve Inventory" +n16: rectangle label:"Create Shipment" +n17: rectangle label:"Update Order Status" +n15.handle(right) -> n16.handle(left) [label="Reserved"] +n16.handle(right) -> n17.handle(left) [label="Shipped"] +n17.handle(top) -> Frontend.n3.handle(bottom) [label="Status Update"] +} diff --git a/uncategorized/architecture/observability-three-pillars-architecture/README.md b/uncategorized/architecture/observability-three-pillars-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..f537071ce0bd687cbfe2db45dff3ef941c088517 --- /dev/null +++ b/uncategorized/architecture/observability-three-pillars-architecture/README.md @@ -0,0 +1,19 @@ +# Observability Three Pillars Architecture + +An observability architecture diagram implementing the three pillars (metrics, traces, logs) with OpenTelemetry SDK instrumentation, OTLP collector pipeline, Prometheus, Jaeger, and Loki backends, Grafana dashboards, SLO/SLI tracking, and PagerDuty alerting integration. This template provides a complete observability stack reference showing how telemetry data flows from application instrumentation through collection, storage, visualization, and incident response. Essential for SRE teams building production monitoring infrastructure. + +**Template ID:** `observability-three-pillars-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 17 +**Lanes:** 4 +**Tags:** [observability, three-pillars, opentelemetry, prometheus, jaeger, loki, grafana, slo-sli, architecture-diagram] +**Source path:** `` +**Repo path:** `uncategorized/architecture/observability-three-pillars-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/architecture/observability-three-pillars-architecture/metadata.json b/uncategorized/architecture/observability-three-pillars-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..81142dbbca9b8413b25d3d478eaf9d4403063a62 --- /dev/null +++ b/uncategorized/architecture/observability-three-pillars-architecture/metadata.json @@ -0,0 +1,27 @@ +{ + "template_id": "observability-three-pillars-architecture", + "workflow_id": "observability-three-pillars-architecture", + "title": "Observability Three Pillars Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 17, + "num_lanes": 4, + "tags": [ + "observability", + "three-pillars", + "opentelemetry", + "prometheus", + "jaeger", + "loki", + "grafana", + "slo-sli", + "architecture-diagram" + ], + "description": "An observability architecture diagram implementing the three pillars (metrics, traces, logs) with OpenTelemetry SDK instrumentation, OTLP collector pipeline, Prometheus, Jaeger, and Loki backends, Grafana dashboards, SLO/SLI tracking, and PagerDuty alerting integration. This template provides a complete observability stack reference showing how telemetry data flows from application instrumentation through collection, storage, visualization, and incident response. Essential for SRE teams building production monitoring infrastructure.", + "source_path": "", + "repo_path": "uncategorized/architecture/observability-three-pillars-architecture" +} diff --git a/uncategorized/architecture/observability-three-pillars-architecture/workflow.fz b/uncategorized/architecture/observability-three-pillars-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..071678cbe2d8054f21c167c076486550e4598ab1 --- /dev/null +++ b/uncategorized/architecture/observability-three-pillars-architecture/workflow.fz @@ -0,0 +1,44 @@ +Application { # Application Services +n1: rectangle label:"Service A" +n2: rectangle label:"Service B" +n3: rectangle label:"Service C" +n4: rectangle label:"OpenTelemetry SDK" +n1.handle(bottom) -> n4.handle(top) [label="Instrument"] +n2.handle(bottom) -> n4.handle(top) [label="Instrument"] +n3.handle(bottom) -> n4.handle(top) [label="Instrument"] +n4.handle(bottom) -> Collector.n5.handle(top) [label="OTLP Export"] +} +Collector { # OpenTelemetry Collector +n5: rectangle label:"Receive Telemetry" +n6: rectangle label:"Process and Batch" +n7: rectangle label:"Export Metrics" +n8: rectangle label:"Export Traces" +n9: rectangle label:"Export Logs" +n5.handle(right) -> n6.handle(left) [label="Pipeline"] +n6.handle(right) -> n7.handle(left) [label="Metrics"] +n6.handle(bottom) -> n8.handle(top) [label="Traces"] +n6.handle(bottom) -> n9.handle(top) [label="Logs"] +n7.handle(bottom) -> Backends.n10.handle(top) [label="Prometheus"] +n8.handle(bottom) -> Backends.n11.handle(top) [label="Jaeger"] +n9.handle(bottom) -> Backends.n12.handle(top) [label="Loki"] +} +Backends { # Observability Backends +n10: rectangle label:"Prometheus (Metrics)" +n11: rectangle label:"Jaeger (Distributed Traces)" +n12: rectangle label:"Loki (Log Aggregation)" +n13: rectangle label:"Alertmanager" +n10.handle(right) -> n13.handle(left) [label="Alert Rules"] +n10.handle(bottom) -> Visualization.n14.handle(top) [label="PromQL"] +n11.handle(bottom) -> Visualization.n14.handle(top) [label="Trace ID"] +n12.handle(bottom) -> Visualization.n14.handle(top) [label="LogQL"] +} +Visualization { # Visualization & Alerting +n14: rectangle label:"Grafana Dashboard" +n15: rectangle label:"SLO/SLI Tracking" +n16: rectangle label:"Incident Response" +n17: rectangle label:"PagerDuty / Slack" +n14.handle(right) -> n15.handle(left) [label="SLO Burn Rate"] +n15.handle(right) -> n16.handle(left) [label="SLO Breach"] +n16.handle(right) -> n17.handle(left) [label="Alert"] +n13.handle(bottom) -> Visualization.n17.handle(top) [label="Fire Alert"] +} diff --git a/uncategorized/architecture/outbox-pattern-reliable-messaging-architecture/README.md b/uncategorized/architecture/outbox-pattern-reliable-messaging-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..5761b5ea31f487c2b3d11172904d40c646951559 --- /dev/null +++ b/uncategorized/architecture/outbox-pattern-reliable-messaging-architecture/README.md @@ -0,0 +1,19 @@ +# Outbox Pattern for Reliable Messaging Architecture + +A transactional outbox architecture diagram where domain writes and event publishing happen in the same database transaction, with a relay process polling the outbox table and publishing events to a message broker with guaranteed delivery. This template solves the dual-write problem where updating a database and publishing an event are not atomic, ensuring exactly-once event delivery without distributed transactions. Critical for event-driven architectures requiring reliable message publishing. + +**Template ID:** `outbox-pattern-reliable-messaging-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 18 +**Lanes:** 4 +**Tags:** [outbox-pattern, transactional-outbox, reliable-messaging, dual-write, exactly-once, debezium, event-publishing, architecture-diagram] +**Source path:** `` +**Repo path:** `uncategorized/architecture/outbox-pattern-reliable-messaging-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/architecture/outbox-pattern-reliable-messaging-architecture/metadata.json b/uncategorized/architecture/outbox-pattern-reliable-messaging-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..abf05e45c139a6c310ef2ede2009d8c1856a916e --- /dev/null +++ b/uncategorized/architecture/outbox-pattern-reliable-messaging-architecture/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "outbox-pattern-reliable-messaging-architecture", + "workflow_id": "outbox-pattern-reliable-messaging-architecture", + "title": "Outbox Pattern for Reliable Messaging Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 18, + "num_lanes": 4, + "tags": [ + "outbox-pattern", + "transactional-outbox", + "reliable-messaging", + "dual-write", + "exactly-once", + "debezium", + "event-publishing", + "architecture-diagram" + ], + "description": "A transactional outbox architecture diagram where domain writes and event publishing happen in the same database transaction, with a relay process polling the outbox table and publishing events to a message broker with guaranteed delivery. This template solves the dual-write problem where updating a database and publishing an event are not atomic, ensuring exactly-once event delivery without distributed transactions. Critical for event-driven architectures requiring reliable message publishing.", + "source_path": "", + "repo_path": "uncategorized/architecture/outbox-pattern-reliable-messaging-architecture" +} diff --git a/uncategorized/architecture/outbox-pattern-reliable-messaging-architecture/workflow.fz b/uncategorized/architecture/outbox-pattern-reliable-messaging-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..205ae4d31c96d776c007b57d7c87b4efbd482117 --- /dev/null +++ b/uncategorized/architecture/outbox-pattern-reliable-messaging-architecture/workflow.fz @@ -0,0 +1,54 @@ +Application { # Application Service +n1: circle label:"Business Operation" +n2: rectangle label:"Begin Transaction" +n3: rectangle label:"Update Domain Table" +n4: rectangle label:"Insert into Outbox Table" +n9: rectangle label:"Write Confirmed" +n10: rectangle label:"Commit Transaction" +n11: circle label:"Return Success" +n1.handle(right) -> n2.handle(left) +n2.handle(right) -> n3.handle(left) [label="Atomic"] +n3.handle(right) -> n4.handle(left) [label="Same TX"] +n4.handle(bottom) -> Database.n5.handle(top) [label="Write"] +n9.handle(right) -> n10.handle(left) [label="Committed"] +n10.handle(right) -> n11.handle(left) +} +Database { # Database +n5: rectangle label:"Domain Table (Orders)" +n6: rectangle label:"Outbox Table (Events)" +n7: rectangle label:"Persist Records" +n8: rectangle label:"Confirm Write" +n12: rectangle label:"Outbox Row: Pending" +n24: rectangle label:"Row Marked Processed" +n5.handle(right) -> n6.handle(left) [label="Same Database"] +n6.handle(right) -> n7.handle(left) +n7.handle(right) -> n8.handle(left) +n8.handle(top) -> Application.n9.handle(bottom) [label="Confirmed"] +n12.handle(bottom) -> Relay.n13.handle(top) [label="Poll"] +} +Relay { # Outbox Relay (Debezium/Poller) +n13: rectangle label:"Poll Outbox Table" +n14: rectangle label:"Read Pending Events" +n15: rectangle label:"Publish to Message Broker" +n16: diamond label:"Published Successfully?" +n17: rectangle label:"Deliver to Consumers" +n18: rectangle label:"Schedule Retry" +n23: rectangle label:"Receive Consumer Ack" +n13.handle(right) -> n14.handle(left) [label="SELECT WHERE status=PENDING"] +n14.handle(right) -> n15.handle(left) [label="Serialize"] +n15.handle(right) -> n16.handle(left) +n16.handle(right) -> n17.handle(left) [label="Yes"] +n16.handle(bottom) -> n18.handle(top) [label="No"] +n17.handle(bottom) -> Consumers.n19.handle(top) [label="Deliver"] +n23.handle(top) -> Database.n24.handle(bottom) [label="Mark Processed"] +} +Consumers { # Downstream Consumers +n19: rectangle label:"Notification Service" +n20: rectangle label:"Analytics Service" +n21: rectangle label:"Search Index Service" +n22: rectangle label:"Acknowledge Receipt" +n19.handle(right) -> n20.handle(left) [label="OrderCreated"] +n20.handle(right) -> n21.handle(left) [label="OrderCreated"] +n21.handle(right) -> n22.handle(left) +n22.handle(top) -> Relay.n23.handle(bottom) [label="Ack"] +} diff --git a/uncategorized/architecture/rate-limiter-architecture/README.md b/uncategorized/architecture/rate-limiter-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..336593e038f3347de776c5b02177cee3193ab709 --- /dev/null +++ b/uncategorized/architecture/rate-limiter-architecture/README.md @@ -0,0 +1,19 @@ +# Rate Limiter Architecture + +A rate limiter architecture diagram implementing the token bucket algorithm with Redis-backed distributed counters, sliding window logs, API key identification, rate limit headers, and multi-node synchronization for consistent enforcement. This template shows how to protect APIs from abuse and ensure fair usage across clients, with proper HTTP 429 responses and Retry-After headers. Essential for API platform teams building production-grade rate limiting infrastructure. + +**Template ID:** `rate-limiter-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 17 +**Lanes:** 4 +**Tags:** [rate-limiter, token-bucket, sliding-window, redis, api-protection, throttling, distributed-rate-limiting, architecture-diagram] +**Source path:** `` +**Repo path:** `uncategorized/architecture/rate-limiter-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/architecture/rate-limiter-architecture/metadata.json b/uncategorized/architecture/rate-limiter-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..7b16ea754f914c9f6be9bb77f4d4d5e3ccef409c --- /dev/null +++ b/uncategorized/architecture/rate-limiter-architecture/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "rate-limiter-architecture", + "workflow_id": "rate-limiter-architecture", + "title": "Rate Limiter Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 17, + "num_lanes": 4, + "tags": [ + "rate-limiter", + "token-bucket", + "sliding-window", + "redis", + "api-protection", + "throttling", + "distributed-rate-limiting", + "architecture-diagram" + ], + "description": "A rate limiter architecture diagram implementing the token bucket algorithm with Redis-backed distributed counters, sliding window logs, API key identification, rate limit headers, and multi-node synchronization for consistent enforcement. This template shows how to protect APIs from abuse and ensure fair usage across clients, with proper HTTP 429 responses and Retry-After headers. Essential for API platform teams building production-grade rate limiting infrastructure.", + "source_path": "", + "repo_path": "uncategorized/architecture/rate-limiter-architecture" +} diff --git a/uncategorized/architecture/rate-limiter-architecture/workflow.fz b/uncategorized/architecture/rate-limiter-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..6cf96d61822afe23cb9c18c95b087bba5fdb9013 --- /dev/null +++ b/uncategorized/architecture/rate-limiter-architecture/workflow.fz @@ -0,0 +1,54 @@ +Client { # Client +n1: circle label:"API Request" +n2: rectangle label:"Attach API Key" +n22: rectangle label:"Receive Response" +n23: circle label:"End" +n1.handle(right) -> n2.handle(left) +n2.handle(bottom) -> RateLimiter.n3.handle(top) [label="Request"] +n22.handle(right) -> n23.handle(left) +} +RateLimiter { # Rate Limiter (Token Bucket) +n3: rectangle label:"Extract Client Identity" +n4: rectangle label:"Lookup Rate Limit Config" +n5: rectangle label:"Check Token Bucket" +n9: rectangle label:"Receive Bucket Status" +n10: diamond label:"Tokens Available?" +n11: rectangle label:"Consume Token" +n12: rectangle label:"Return 429 Too Many Requests" +n13: rectangle label:"Add Rate Limit Headers" +n14: rectangle label:"Forward to Backend" +n19: rectangle label:"Receive Backend Response" +n20: rectangle label:"Forward Response to Client" +n21: rectangle label:"Send to Client" +n3.handle(right) -> n4.handle(left) [label="API Key / IP"] +n4.handle(right) -> n5.handle(left) [label="100 req/min"] +n5.handle(bottom) -> Store.n6.handle(top) [label="INCR + EXPIRE"] +n9.handle(right) -> n10.handle(left) +n10.handle(right) -> n11.handle(left) [label="Yes"] +n10.handle(bottom) -> n12.handle(top) [label="No"] +n11.handle(right) -> n13.handle(left) [label="Decrement"] +n13.handle(right) -> n14.handle(left) [label="X-RateLimit-Remaining"] +n12.handle(top) -> Client.n22.handle(bottom) [label="429"] +n14.handle(bottom) -> Backend.n15.handle(top) [label="Allowed"] +n19.handle(right) -> n20.handle(left) +n20.handle(right) -> n21.handle(left) +n21.handle(top) -> Client.n22.handle(bottom) [label="200"] +} +Backend { # Backend Service +n15: rectangle label:"Process Request" +n16: rectangle label:"Return Response" +n17: rectangle label:"Send to RateLimiter" +n18: rectangle label:"Forward Response" +n15.handle(right) -> n16.handle(left) [label="Execute"] +n16.handle(right) -> n17.handle(left) +n17.handle(right) -> n18.handle(left) +n18.handle(top) -> RateLimiter.n19.handle(bottom) [label="Backend Response"] +} +Store { # Rate Limit Store (Redis) +n6: rectangle label:"Redis Counter" +n7: rectangle label:"Sliding Window Log" +n8: rectangle label:"Return Bucket Status" +n6.handle(right) -> n7.handle(left) [label="Window Check"] +n7.handle(right) -> n8.handle(left) +n8.handle(top) -> RateLimiter.n9.handle(bottom) [label="Bucket Status"] +} diff --git a/uncategorized/architecture/retry-with-exponential-backoff-architecture/README.md b/uncategorized/architecture/retry-with-exponential-backoff-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..70e4228d38fd4505c20d2e3bc18ce798373b13e9 --- /dev/null +++ b/uncategorized/architecture/retry-with-exponential-backoff-architecture/README.md @@ -0,0 +1,19 @@ +# Retry with Exponential Backoff Architecture + +A retry with exponential backoff architecture diagram showing the complete retry policy engine with retryable vs non-retryable error classification, exponential delay calculation with jitter, max retry thresholds, and graceful exhaustion handling. This template models the essential resilience pattern for handling transient failures in distributed systems, preventing thundering herd problems through randomized backoff delays. Foundational for any service-to-service communication in cloud architectures. + +**Template ID:** `retry-with-exponential-backoff-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 17 +**Lanes:** 3 +**Tags:** [retry-pattern, exponential-backoff, jitter, transient-failure, resilience, error-handling, thundering-herd, architecture-diagram] +**Source path:** `` +**Repo path:** `uncategorized/architecture/retry-with-exponential-backoff-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/architecture/retry-with-exponential-backoff-architecture/metadata.json b/uncategorized/architecture/retry-with-exponential-backoff-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..85bc7901f412cd10928377204fe3d7ad1337fe74 --- /dev/null +++ b/uncategorized/architecture/retry-with-exponential-backoff-architecture/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "retry-with-exponential-backoff-architecture", + "workflow_id": "retry-with-exponential-backoff-architecture", + "title": "Retry with Exponential Backoff Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 17, + "num_lanes": 3, + "tags": [ + "retry-pattern", + "exponential-backoff", + "jitter", + "transient-failure", + "resilience", + "error-handling", + "thundering-herd", + "architecture-diagram" + ], + "description": "A retry with exponential backoff architecture diagram showing the complete retry policy engine with retryable vs non-retryable error classification, exponential delay calculation with jitter, max retry thresholds, and graceful exhaustion handling. This template models the essential resilience pattern for handling transient failures in distributed systems, preventing thundering herd problems through randomized backoff delays. Foundational for any service-to-service communication in cloud architectures.", + "source_path": "", + "repo_path": "uncategorized/architecture/retry-with-exponential-backoff-architecture" +} diff --git a/uncategorized/architecture/retry-with-exponential-backoff-architecture/workflow.fz b/uncategorized/architecture/retry-with-exponential-backoff-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..786916bf9eb012fa4b29defbb88c324fb4d98e37 --- /dev/null +++ b/uncategorized/architecture/retry-with-exponential-backoff-architecture/workflow.fz @@ -0,0 +1,48 @@ +Caller { # Calling Service +n1: circle label:"Initiate Request" +n2: rectangle label:"Send HTTP Request" +n19: rectangle label:"Receive Response" +n20: circle label:"Request Complete" +n1.handle(right) -> n2.handle(left) +n2.handle(bottom) -> RetryPolicy.n3.handle(top) [label="Execute"] +n19.handle(right) -> n20.handle(left) +} +RetryPolicy { # Retry Policy Engine +n3: rectangle label:"Attempt Request" +n8: diamond label:"Response Status?" +n9: rectangle label:"Return Success" +n10: diamond label:"Retryable Error?" +n11: rectangle label:"Return Permanent Failure" +n12: rectangle label:"Calculate Backoff Delay" +n13: diamond label:"Max Retries Exceeded?" +n14: rectangle label:"Wait with Jitter" +n15: rectangle label:"Return Exhausted Error" +n16: rectangle label:"Forward Success" +n17: rectangle label:"Forward Failure" +n18: rectangle label:"Forward Exhausted" +n3.handle(bottom) -> Target.n4.handle(top) [label="HTTP"] +n8.handle(right) -> n9.handle(left) [label="2xx"] +n8.handle(bottom) -> n10.handle(top) [label="Error"] +n9.handle(right) -> n16.handle(left) +n10.handle(right) -> n12.handle(left) [label="429/503/Timeout"] +n10.handle(bottom) -> n11.handle(top) [label="400/401/404"] +n11.handle(right) -> n17.handle(left) +n12.handle(right) -> n13.handle(left) [label="2^n * base"] +n13.handle(bottom) -> n15.handle(top) [label="Yes"] +n13.handle(right) -> n14.handle(left) [label="No"] +n15.handle(right) -> n18.handle(left) +n16.handle(top) -> Caller.n19.handle(bottom) [label="Success"] +n17.handle(top) -> Caller.n19.handle(bottom) [label="Non-Retryable"] +n18.handle(top) -> Caller.n19.handle(bottom) [label="Max Retries"] +} +Target { # Target Service +n4: rectangle label:"Process Request" +n5: diamond label:"Service Healthy?" +n6: rectangle label:"Return 200 OK" +n7: rectangle label:"Return 503 Unavailable" +n4.handle(right) -> n5.handle(left) +n5.handle(right) -> n6.handle(left) [label="Yes"] +n5.handle(bottom) -> n7.handle(top) [label="No"] +n6.handle(top) -> RetryPolicy.n8.handle(bottom) [label="Success"] +n7.handle(top) -> RetryPolicy.n8.handle(bottom) [label="Error"] +} diff --git a/uncategorized/architecture/saga-choreography-pattern-architecture/README.md b/uncategorized/architecture/saga-choreography-pattern-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..68a0d6a8978c3322bd32fb244a15f1c0cf8ec32d --- /dev/null +++ b/uncategorized/architecture/saga-choreography-pattern-architecture/README.md @@ -0,0 +1,19 @@ +# Saga Choreography Pattern Architecture + +A saga choreography architecture diagram where Order, Payment, and Inventory services coordinate through domain events without a central orchestrator, with each service publishing and subscribing to events that drive the transaction forward or trigger compensation. This template models the decentralized saga approach where services autonomously react to events, reducing single points of failure at the cost of increased complexity in tracking saga state. Best for teams preferring service autonomy over centralized control. + +**Template ID:** `saga-choreography-pattern-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 18 +**Lanes:** 5 +**Tags:** [saga-choreography, event-driven-saga, decentralized, domain-events, compensation, autonomous-services, distributed-transaction, architecture-diagram] +**Source path:** `` +**Repo path:** `uncategorized/architecture/saga-choreography-pattern-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/architecture/saga-choreography-pattern-architecture/metadata.json b/uncategorized/architecture/saga-choreography-pattern-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..d949bc319c3bd71f1e9bee6e64e8eeb9fa5d6cf0 --- /dev/null +++ b/uncategorized/architecture/saga-choreography-pattern-architecture/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "saga-choreography-pattern-architecture", + "workflow_id": "saga-choreography-pattern-architecture", + "title": "Saga Choreography Pattern Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 18, + "num_lanes": 5, + "tags": [ + "saga-choreography", + "event-driven-saga", + "decentralized", + "domain-events", + "compensation", + "autonomous-services", + "distributed-transaction", + "architecture-diagram" + ], + "description": "A saga choreography architecture diagram where Order, Payment, and Inventory services coordinate through domain events without a central orchestrator, with each service publishing and subscribing to events that drive the transaction forward or trigger compensation. This template models the decentralized saga approach where services autonomously react to events, reducing single points of failure at the cost of increased complexity in tracking saga state. Best for teams preferring service autonomy over centralized control.", + "source_path": "", + "repo_path": "uncategorized/architecture/saga-choreography-pattern-architecture" +} diff --git a/uncategorized/architecture/saga-choreography-pattern-architecture/workflow.fz b/uncategorized/architecture/saga-choreography-pattern-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..39da016c13cda40f20c654a3d725b5358386f4b8 --- /dev/null +++ b/uncategorized/architecture/saga-choreography-pattern-architecture/workflow.fz @@ -0,0 +1,61 @@ +OrderService { # Order Service +n1: circle label:"Place Order" +n2: rectangle label:"Create Pending Order" +n3: rectangle label:"Emit OrderCreated" +n19: rectangle label:"Receive Saga Result" +n20: diamond label:"Saga Outcome?" +n21: rectangle label:"Confirm Order" +n22: rectangle label:"Cancel Order" +n23: rectangle label:"Acknowledge to EventBus" +n25: rectangle label:"Send Saga Ack" +n1.handle(right) -> n2.handle(left) +n2.handle(right) -> n3.handle(left) [label="Pending"] +n3.handle(bottom) -> EventBus.n4.handle(top) [label="Publish"] +n19.handle(right) -> n20.handle(left) +n20.handle(right) -> n21.handle(left) [label="Success"] +n20.handle(bottom) -> n22.handle(top) [label="Failure"] +n21.handle(right) -> n23.handle(left) +n22.handle(right) -> n25.handle(left) +n23.handle(bottom) -> EventBus.n26.handle(top) [label="Success Ack"] +n25.handle(bottom) -> EventBus.n26.handle(top) [label="Failure Ack"] +} +EventBus { # Event Bus +n4: rectangle label:"OrderCreated Topic" +n10: rectangle label:"PaymentProcessed Topic" +n14: rectangle label:"PaymentFailed Topic" +n18: rectangle label:"InventoryReserved Topic" +n24: rectangle label:"Compensation Ack Received" +n26: rectangle label:"Saga Ack Received" +n4.handle(bottom) -> PaymentService.n5.handle(top) [label="Subscribe"] +n10.handle(bottom) -> InventoryService.n11.handle(top) [label="Subscribe"] +n14.handle(bottom) -> InventoryService.n15.handle(top) [label="Subscribe"] +n18.handle(top) -> OrderService.n19.handle(bottom) [label="Notify Success"] +n24.handle(right) -> n26.handle(left) +} +PaymentService { # Payment Service +n5: rectangle label:"Process Payment" +n6: diamond label:"Payment OK?" +n7: rectangle label:"Emit PaymentProcessed" +n8: rectangle label:"Emit PaymentFailed" +n9: rectangle label:"Publish Result" +n5.handle(right) -> n6.handle(left) +n6.handle(right) -> n7.handle(left) [label="Success"] +n6.handle(bottom) -> n8.handle(top) [label="Declined"] +n7.handle(right) -> n9.handle(left) +n9.handle(top) -> EventBus.n10.handle(bottom) [label="Publish"] +n8.handle(top) -> EventBus.n14.handle(bottom) [label="Publish"] +} +InventoryService { # Inventory Service +n11: rectangle label:"Reserve Inventory" +n12: rectangle label:"Emit InventoryReserved" +n13: rectangle label:"Publish Reserved" +n15: rectangle label:"Compensate: Release Stock" +n16: rectangle label:"Stock Released" +n17: rectangle label:"Compensation Complete" +n11.handle(right) -> n12.handle(left) [label="Reserved"] +n12.handle(right) -> n13.handle(left) +n13.handle(top) -> EventBus.n18.handle(bottom) [label="Publish"] +n15.handle(right) -> n16.handle(left) [label="Released"] +n16.handle(right) -> n17.handle(left) +n17.handle(top) -> EventBus.n24.handle(bottom) [label="Compensation Ack"] +} diff --git a/uncategorized/architecture/serverless-event-processing-architecture/README.md b/uncategorized/architecture/serverless-event-processing-architecture/README.md new file mode 100644 index 0000000000000000000000000000000000000000..2b2e6936e407f6f48f1ffea53c344e98e060d0fa --- /dev/null +++ b/uncategorized/architecture/serverless-event-processing-architecture/README.md @@ -0,0 +1,19 @@ +# Serverless Event Processing Architecture + +A serverless event processing architecture diagram with S3, DynamoDB Streams, API Gateway, and CloudWatch triggers invoking Lambda functions, orchestrated by Step Functions with fan-out via SQS and dead letter queue error handling. This template shows how to build complex event processing pipelines entirely from managed serverless components, with no servers to provision or manage. Ideal for data processing workflows that need elastic scaling and built-in fault tolerance. + +**Template ID:** `serverless-event-processing-architecture` +**Kind:** architecture +**Source domain:** Architecture +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 17 +**Lanes:** 4 +**Tags:** [serverless, event-processing, step-functions, lambda-triggers, sqs, s3-events, dynamodb-streams, architecture-diagram] +**Source path:** `` +**Repo path:** `uncategorized/architecture/serverless-event-processing-architecture` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/architecture/serverless-event-processing-architecture/metadata.json b/uncategorized/architecture/serverless-event-processing-architecture/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..bba2490d70e7ab7bee3e6192c6ed8e6005ce80ec --- /dev/null +++ b/uncategorized/architecture/serverless-event-processing-architecture/metadata.json @@ -0,0 +1,26 @@ +{ + "template_id": "serverless-event-processing-architecture", + "workflow_id": "serverless-event-processing-architecture", + "title": "Serverless Event Processing Architecture", + "kind": "architecture", + "source_domain": "Architecture", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 17, + "num_lanes": 4, + "tags": [ + "serverless", + "event-processing", + "step-functions", + "lambda-triggers", + "sqs", + "s3-events", + "dynamodb-streams", + "architecture-diagram" + ], + "description": "A serverless event processing architecture diagram with S3, DynamoDB Streams, API Gateway, and CloudWatch triggers invoking Lambda functions, orchestrated by Step Functions with fan-out via SQS and dead letter queue error handling. This template shows how to build complex event processing pipelines entirely from managed serverless components, with no servers to provision or manage. Ideal for data processing workflows that need elastic scaling and built-in fault tolerance.", + "source_path": "", + "repo_path": "uncategorized/architecture/serverless-event-processing-architecture" +} diff --git a/uncategorized/architecture/serverless-event-processing-architecture/workflow.fz b/uncategorized/architecture/serverless-event-processing-architecture/workflow.fz new file mode 100644 index 0000000000000000000000000000000000000000..6fbe5ea14c7d7c1d813fb05a78ebff9db5f752b2 --- /dev/null +++ b/uncategorized/architecture/serverless-event-processing-architecture/workflow.fz @@ -0,0 +1,56 @@ +EventSources { # Event Sources +n1: rectangle label:"S3 Bucket Upload" +n2: rectangle label:"DynamoDB Stream" +n3: rectangle label:"API Gateway Webhook" +n4: rectangle label:"CloudWatch Scheduled Rule" +n24: rectangle label:"Receive Processing Acks" +n1.handle(bottom) -> Triggers.n5.handle(top) [label="ObjectCreated"] +n2.handle(bottom) -> Triggers.n6.handle(top) [label="StreamRecord"] +n3.handle(bottom) -> Triggers.n7.handle(top) [label="POST Event"] +n4.handle(bottom) -> Triggers.n8.handle(top) [label="Cron"] +} +Triggers { # Lambda Triggers +n5: rectangle label:"Image Processing Lambda" +n6: rectangle label:"Data Sync Lambda" +n7: rectangle label:"Webhook Handler Lambda" +n8: rectangle label:"Batch Job Lambda" +n20: rectangle label:"Receive Processing Ack" +n21: rectangle label:"Aggregate Trigger Results" +n22: rectangle label:"Prepare Source Ack" +n23: rectangle label:"Send Source Ack" +n5.handle(bottom) -> Processing.n9.handle(top) [label="Process Image"] +n6.handle(bottom) -> Processing.n11.handle(top) [label="Sync Data"] +n7.handle(bottom) -> Processing.n9.handle(top) [label="Handle Event"] +n8.handle(bottom) -> Processing.n12.handle(top) [label="Run Batch"] +n20.handle(right) -> n21.handle(left) +n21.handle(right) -> n22.handle(left) +n22.handle(right) -> n23.handle(left) +n23.handle(top) -> EventSources.n24.handle(bottom) [label="Triggers Ack"] +} +Processing { # Processing Pipeline +n9: rectangle label:"Step Functions Orchestrator" +n10: diamond label:"Processing Complete?" +n11: rectangle label:"Fan-Out with SQS" +n12: rectangle label:"Transform and Load" +n13: rectangle label:"Error Handler Lambda" +n18: rectangle label:"Receive Storage Ack" +n19: rectangle label:"Send Processing Ack" +n9.handle(right) -> n10.handle(left) +n10.handle(right) -> n11.handle(left) [label="Success"] +n10.handle(bottom) -> n13.handle(top) [label="Failure"] +n11.handle(right) -> n12.handle(left) [label="Parallel"] +n13.handle(bottom) -> Storage.n17.handle(top) [label="DLQ"] +n12.handle(bottom) -> Storage.n14.handle(top) [label="Store"] +n18.handle(right) -> n19.handle(left) +n19.handle(top) -> Triggers.n20.handle(bottom) [label="Processing Ack"] +} +Storage { # Managed Storage +n14: rectangle label:"DynamoDB Table" +n15: rectangle label:"S3 Results Bucket" +n16: rectangle label:"SNS Notification Topic" +n17: rectangle label:"Return Storage Ack" +n14.handle(right) -> n15.handle(left) [label="Archive"] +n15.handle(right) -> n16.handle(left) [label="Notify"] +n16.handle(right) -> n17.handle(left) +n17.handle(top) -> Processing.n18.handle(bottom) [label="Storage Ack"] +} diff --git a/uncategorized/business-operations/cohort-analysis-workflow/README.md b/uncategorized/business-operations/cohort-analysis-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..34687a659c17c4ec020313e54d38d61c181c1a69 --- /dev/null +++ b/uncategorized/business-operations/cohort-analysis-workflow/README.md @@ -0,0 +1,19 @@ +# Cohort Analysis Workflow + +Cohort analysis workflow with user segmentation by signup date, retention curve calculation, LTV projection, and behavioral pattern identification. + +**Template ID:** `cohort-analysis-workflow` +**Kind:** workflow +**Source domain:** business-operations +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 13 +**Lanes:** 4 +**Tags:** [cohort-analysis, retention-analysis, user-behavior, ltv, churn-prediction, analytics] +**Source path:** `business-operations/cohort-analysis` +**Repo path:** `uncategorized/business-operations/cohort-analysis-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/business-operations/cohort-analysis-workflow/metadata.json b/uncategorized/business-operations/cohort-analysis-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..73e948b1743b471d06cffa5a991ff617749e521e --- /dev/null +++ b/uncategorized/business-operations/cohort-analysis-workflow/metadata.json @@ -0,0 +1,24 @@ +{ + "template_id": "cohort-analysis-workflow", + "workflow_id": "cohort-analysis", + "title": "Cohort Analysis Workflow", + "kind": "workflow", + "source_domain": "business-operations", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 13, + "num_lanes": 4, + "tags": [ + "cohort-analysis", + "retention-analysis", + "user-behavior", + "ltv", + "churn-prediction", + "analytics" + ], + "description": "Cohort analysis workflow with user segmentation by signup date, retention curve calculation, LTV projection, and behavioral pattern identification.", + "source_path": "business-operations/cohort-analysis", + "repo_path": "uncategorized/business-operations/cohort-analysis-workflow" +} diff --git a/business-operations/cohort-analysis/workflow.fz b/uncategorized/business-operations/cohort-analysis-workflow/workflow.fz similarity index 100% rename from business-operations/cohort-analysis/workflow.fz rename to uncategorized/business-operations/cohort-analysis-workflow/workflow.fz diff --git a/uncategorized/business-operations/community-moderation-workflow/README.md b/uncategorized/business-operations/community-moderation-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..f2f606e34aaef5716df83260794cb1210b5a7cfa --- /dev/null +++ b/uncategorized/business-operations/community-moderation-workflow/README.md @@ -0,0 +1,19 @@ +# Community Moderation Workflow + +Community content moderation workflow with AI auto-flagging, user reports, human review queue, action enforcement, and appeals handling. + +**Template ID:** `community-moderation-workflow` +**Kind:** workflow +**Source domain:** business-operations +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [community-moderation, content-moderation, user-reports, trust-safety, ai-moderation, appeals] +**Source path:** `business-operations/community-moderation` +**Repo path:** `uncategorized/business-operations/community-moderation-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/business-operations/community-moderation-workflow/metadata.json b/uncategorized/business-operations/community-moderation-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..8e22f482271b4c8d25ba50a307d5b8772d0181e6 --- /dev/null +++ b/uncategorized/business-operations/community-moderation-workflow/metadata.json @@ -0,0 +1,24 @@ +{ + "template_id": "community-moderation-workflow", + "workflow_id": "community-moderation", + "title": "Community Moderation Workflow", + "kind": "workflow", + "source_domain": "business-operations", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "community-moderation", + "content-moderation", + "user-reports", + "trust-safety", + "ai-moderation", + "appeals" + ], + "description": "Community content moderation workflow with AI auto-flagging, user reports, human review queue, action enforcement, and appeals handling.", + "source_path": "business-operations/community-moderation", + "repo_path": "uncategorized/business-operations/community-moderation-workflow" +} diff --git a/business-operations/community-moderation/workflow.fz b/uncategorized/business-operations/community-moderation-workflow/workflow.fz similarity index 100% rename from business-operations/community-moderation/workflow.fz rename to uncategorized/business-operations/community-moderation-workflow/workflow.fz diff --git a/uncategorized/business-operations/email-campaign-workflow/README.md b/uncategorized/business-operations/email-campaign-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..8546f20569ecd359297b835565e16710e48ed35a --- /dev/null +++ b/uncategorized/business-operations/email-campaign-workflow/README.md @@ -0,0 +1,19 @@ +# Email Campaign Workflow + +Email marketing campaign workflow with audience segmentation, A/B testing, send scheduling, deliverability monitoring, and engagement analytics. + +**Template ID:** `email-campaign-workflow` +**Kind:** workflow +**Source domain:** business-operations +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 13 +**Lanes:** 4 +**Tags:** [email-campaign, marketing-automation, mailchimp, segmentation, a-b-testing, deliverability] +**Source path:** `business-operations/email-campaign` +**Repo path:** `uncategorized/business-operations/email-campaign-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/business-operations/email-campaign-workflow/metadata.json b/uncategorized/business-operations/email-campaign-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..528f55d39e0497ec63a75e5bee112fc01017aedb --- /dev/null +++ b/uncategorized/business-operations/email-campaign-workflow/metadata.json @@ -0,0 +1,24 @@ +{ + "template_id": "email-campaign-workflow", + "workflow_id": "email-campaign", + "title": "Email Campaign Workflow", + "kind": "workflow", + "source_domain": "business-operations", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 13, + "num_lanes": 4, + "tags": [ + "email-campaign", + "marketing-automation", + "mailchimp", + "segmentation", + "a-b-testing", + "deliverability" + ], + "description": "Email marketing campaign workflow with audience segmentation, A/B testing, send scheduling, deliverability monitoring, and engagement analytics.", + "source_path": "business-operations/email-campaign", + "repo_path": "uncategorized/business-operations/email-campaign-workflow" +} diff --git a/business-operations/email-campaign/workflow.fz b/uncategorized/business-operations/email-campaign-workflow/workflow.fz similarity index 100% rename from business-operations/email-campaign/workflow.fz rename to uncategorized/business-operations/email-campaign-workflow/workflow.fz diff --git a/uncategorized/business-operations/in-app-message-workflow/README.md b/uncategorized/business-operations/in-app-message-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..f8249702a321511aed20701f6b82fb639bfa86d5 --- /dev/null +++ b/uncategorized/business-operations/in-app-message-workflow/README.md @@ -0,0 +1,19 @@ +# In App Message Workflow + +In-app messaging workflow with trigger conditions, audience targeting, message display, user interaction tracking, and conversion measurement. + +**Template ID:** `in-app-message-workflow` +**Kind:** workflow +**Source domain:** business-operations +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 2/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [in-app-message, product-tours, tooltips, announcements, user-engagement, intercom] +**Source path:** `business-operations/in-app-message` +**Repo path:** `uncategorized/business-operations/in-app-message-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/business-operations/in-app-message-workflow/metadata.json b/uncategorized/business-operations/in-app-message-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..7ea4002582df71ce3a7d664671acaea8c446348e --- /dev/null +++ b/uncategorized/business-operations/in-app-message-workflow/metadata.json @@ -0,0 +1,24 @@ +{ + "template_id": "in-app-message-workflow", + "workflow_id": "in-app-message", + "title": "In App Message Workflow", + "kind": "workflow", + "source_domain": "business-operations", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 2, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "in-app-message", + "product-tours", + "tooltips", + "announcements", + "user-engagement", + "intercom" + ], + "description": "In-app messaging workflow with trigger conditions, audience targeting, message display, user interaction tracking, and conversion measurement.", + "source_path": "business-operations/in-app-message", + "repo_path": "uncategorized/business-operations/in-app-message-workflow" +} diff --git a/business-operations/in-app-message/workflow.fz b/uncategorized/business-operations/in-app-message-workflow/workflow.fz similarity index 100% rename from business-operations/in-app-message/workflow.fz rename to uncategorized/business-operations/in-app-message-workflow/workflow.fz diff --git a/uncategorized/business-operations/personalization-engine-workflow/README.md b/uncategorized/business-operations/personalization-engine-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..64a6cdaed0f422896b473b968ba54be361b3fe73 --- /dev/null +++ b/uncategorized/business-operations/personalization-engine-workflow/README.md @@ -0,0 +1,19 @@ +# Personalization Engine Workflow + +Make.com automation scenario for real-time personalization using Segment events, ML recommendation API, and Braze campaign delivery across email and push channels. + +**Template ID:** `personalization-engine-workflow` +**Kind:** workflow +**Source domain:** business-operations +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 20 +**Lanes:** 3 +**Tags:** [make-com, personalization, segment, braze, ml-recommendations, content-delivery, marketing-automation] +**Source path:** `business-operations/personalization-engine` +**Repo path:** `uncategorized/business-operations/personalization-engine-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/business-operations/personalization-engine-workflow/metadata.json b/uncategorized/business-operations/personalization-engine-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..1b829ccab3fec2267cb80ccf5e1633584c476ad9 --- /dev/null +++ b/uncategorized/business-operations/personalization-engine-workflow/metadata.json @@ -0,0 +1,25 @@ +{ + "template_id": "personalization-engine-workflow", + "workflow_id": "personalization-engine", + "title": "Personalization Engine Workflow", + "kind": "workflow", + "source_domain": "business-operations", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 20, + "num_lanes": 3, + "tags": [ + "make-com", + "personalization", + "segment", + "braze", + "ml-recommendations", + "content-delivery", + "marketing-automation" + ], + "description": "Make.com automation scenario for real-time personalization using Segment events, ML recommendation API, and Braze campaign delivery across email and push channels.", + "source_path": "business-operations/personalization-engine", + "repo_path": "uncategorized/business-operations/personalization-engine-workflow" +} diff --git a/business-operations/personalization-engine/workflow.fz b/uncategorized/business-operations/personalization-engine-workflow/workflow.fz similarity index 100% rename from business-operations/personalization-engine/workflow.fz rename to uncategorized/business-operations/personalization-engine-workflow/workflow.fz diff --git a/uncategorized/business-operations/push-notification-workflow/README.md b/uncategorized/business-operations/push-notification-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..03e5c90f429a9597acf9be49b20071bd70199001 --- /dev/null +++ b/uncategorized/business-operations/push-notification-workflow/README.md @@ -0,0 +1,19 @@ +# Push Notification Workflow + +Mobile push notification workflow with audience targeting, platform routing (iOS/Android), delivery tracking, and engagement analytics. + +**Template ID:** `push-notification-workflow` +**Kind:** workflow +**Source domain:** business-operations +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [push-notification, mobile-engagement, firebase-fcm, apns, segmentation, deep-linking] +**Source path:** `business-operations/push-notification` +**Repo path:** `uncategorized/business-operations/push-notification-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/business-operations/push-notification-workflow/metadata.json b/uncategorized/business-operations/push-notification-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..65ed4802ae965fb90143454abfc1c303546dfa51 --- /dev/null +++ b/uncategorized/business-operations/push-notification-workflow/metadata.json @@ -0,0 +1,24 @@ +{ + "template_id": "push-notification-workflow", + "workflow_id": "push-notification", + "title": "Push Notification Workflow", + "kind": "workflow", + "source_domain": "business-operations", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "push-notification", + "mobile-engagement", + "firebase-fcm", + "apns", + "segmentation", + "deep-linking" + ], + "description": "Mobile push notification workflow with audience targeting, platform routing (iOS/Android), delivery tracking, and engagement analytics.", + "source_path": "business-operations/push-notification", + "repo_path": "uncategorized/business-operations/push-notification-workflow" +} diff --git a/business-operations/push-notification/workflow.fz b/uncategorized/business-operations/push-notification-workflow/workflow.fz similarity index 100% rename from business-operations/push-notification/workflow.fz rename to uncategorized/business-operations/push-notification-workflow/workflow.fz diff --git a/uncategorized/business-operations/referral-program-workflow/README.md b/uncategorized/business-operations/referral-program-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..21220448508a060b268c056fe2946e6b1c028200 --- /dev/null +++ b/uncategorized/business-operations/referral-program-workflow/README.md @@ -0,0 +1,19 @@ +# Referral Program Workflow + +Customer referral program workflow with unique link generation, referral tracking, conversion validation, and dual-sided reward fulfillment. + +**Template ID:** `referral-program-workflow` +**Kind:** workflow +**Source domain:** business-operations +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 13 +**Lanes:** 4 +**Tags:** [referral-program, viral-growth, referral-tracking, reward-fulfillment, affiliate, word-of-mouth] +**Source path:** `business-operations/referral-program` +**Repo path:** `uncategorized/business-operations/referral-program-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/business-operations/referral-program-workflow/metadata.json b/uncategorized/business-operations/referral-program-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..04505881bd78552e2e3f3de34f8fb40ee0980576 --- /dev/null +++ b/uncategorized/business-operations/referral-program-workflow/metadata.json @@ -0,0 +1,24 @@ +{ + "template_id": "referral-program-workflow", + "workflow_id": "referral-program", + "title": "Referral Program Workflow", + "kind": "workflow", + "source_domain": "business-operations", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 13, + "num_lanes": 4, + "tags": [ + "referral-program", + "viral-growth", + "referral-tracking", + "reward-fulfillment", + "affiliate", + "word-of-mouth" + ], + "description": "Customer referral program workflow with unique link generation, referral tracking, conversion validation, and dual-sided reward fulfillment.", + "source_path": "business-operations/referral-program", + "repo_path": "uncategorized/business-operations/referral-program-workflow" +} diff --git a/business-operations/referral-program/workflow.fz b/uncategorized/business-operations/referral-program-workflow/workflow.fz similarity index 100% rename from business-operations/referral-program/workflow.fz rename to uncategorized/business-operations/referral-program-workflow/workflow.fz diff --git a/uncategorized/business-operations/search-optimization-workflow/README.md b/uncategorized/business-operations/search-optimization-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..103229d6f0ca2dc423df4590151ef88e864aca25 --- /dev/null +++ b/uncategorized/business-operations/search-optimization-workflow/README.md @@ -0,0 +1,19 @@ +# Search Optimization Workflow + +Search optimization workflow with query analysis, relevance tuning, synonym management, click-through tracking, and A/B testing of ranking algorithms. + +**Template ID:** `search-optimization-workflow` +**Kind:** workflow +**Source domain:** business-operations +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 13 +**Lanes:** 4 +**Tags:** [search-optimization, elasticsearch, relevance-tuning, query-analysis, algolia, search-analytics] +**Source path:** `business-operations/search-optimization` +**Repo path:** `uncategorized/business-operations/search-optimization-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/business-operations/search-optimization-workflow/metadata.json b/uncategorized/business-operations/search-optimization-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..6d981ecea1ce44f728a8181e53521e37dff514db --- /dev/null +++ b/uncategorized/business-operations/search-optimization-workflow/metadata.json @@ -0,0 +1,24 @@ +{ + "template_id": "search-optimization-workflow", + "workflow_id": "search-optimization", + "title": "Search Optimization Workflow", + "kind": "workflow", + "source_domain": "business-operations", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 13, + "num_lanes": 4, + "tags": [ + "search-optimization", + "elasticsearch", + "relevance-tuning", + "query-analysis", + "algolia", + "search-analytics" + ], + "description": "Search optimization workflow with query analysis, relevance tuning, synonym management, click-through tracking, and A/B testing of ranking algorithms.", + "source_path": "business-operations/search-optimization", + "repo_path": "uncategorized/business-operations/search-optimization-workflow" +} diff --git a/business-operations/search-optimization/workflow.fz b/uncategorized/business-operations/search-optimization-workflow/workflow.fz similarity index 100% rename from business-operations/search-optimization/workflow.fz rename to uncategorized/business-operations/search-optimization-workflow/workflow.fz diff --git a/uncategorized/business-operations/user-segmentation-workflow/README.md b/uncategorized/business-operations/user-segmentation-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..a6df10c7da0f8e571243de3baee989814fa8c406 --- /dev/null +++ b/uncategorized/business-operations/user-segmentation-workflow/README.md @@ -0,0 +1,19 @@ +# User Segmentation Workflow + +User segmentation workflow with attribute collection, behavioral event tracking, segment rule definition, dynamic membership, and downstream sync. + +**Template ID:** `user-segmentation-workflow` +**Kind:** workflow +**Source domain:** business-operations +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 2/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [user-segmentation, audience-targeting, behavioral-cohorts, customer-segments, segment, marketing-automation] +**Source path:** `business-operations/user-segmentation` +**Repo path:** `uncategorized/business-operations/user-segmentation-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/business-operations/user-segmentation-workflow/metadata.json b/uncategorized/business-operations/user-segmentation-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..add2edecce06ca369d9734df63b91cb693a492aa --- /dev/null +++ b/uncategorized/business-operations/user-segmentation-workflow/metadata.json @@ -0,0 +1,24 @@ +{ + "template_id": "user-segmentation-workflow", + "workflow_id": "user-segmentation", + "title": "User Segmentation Workflow", + "kind": "workflow", + "source_domain": "business-operations", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 2, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "user-segmentation", + "audience-targeting", + "behavioral-cohorts", + "customer-segments", + "segment", + "marketing-automation" + ], + "description": "User segmentation workflow with attribute collection, behavioral event tracking, segment rule definition, dynamic membership, and downstream sync.", + "source_path": "business-operations/user-segmentation", + "repo_path": "uncategorized/business-operations/user-segmentation-workflow" +} diff --git a/business-operations/user-segmentation/workflow.fz b/uncategorized/business-operations/user-segmentation-workflow/workflow.fz similarity index 100% rename from business-operations/user-segmentation/workflow.fz rename to uncategorized/business-operations/user-segmentation-workflow/workflow.fz diff --git a/uncategorized/business-operations/webhook-integration-workflow/README.md b/uncategorized/business-operations/webhook-integration-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..674a4e3e8ad394059e699fdb535f7a324501c823 --- /dev/null +++ b/uncategorized/business-operations/webhook-integration-workflow/README.md @@ -0,0 +1,19 @@ +# Webhook Integration Workflow + +Webhook integration workflow with endpoint registration, payload signing, delivery attempt, retry with backoff, and delivery status tracking. + +**Template ID:** `webhook-integration-workflow` +**Kind:** workflow +**Source domain:** business-operations +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 2/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [webhook, event-driven, http-callback, integration, retry-logic, payload-signing] +**Source path:** `business-operations/webhook-integration` +**Repo path:** `uncategorized/business-operations/webhook-integration-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/business-operations/webhook-integration-workflow/metadata.json b/uncategorized/business-operations/webhook-integration-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..3a51f21ecbf915a2dfd9dcdf614ad78c2c92ad7f --- /dev/null +++ b/uncategorized/business-operations/webhook-integration-workflow/metadata.json @@ -0,0 +1,24 @@ +{ + "template_id": "webhook-integration-workflow", + "workflow_id": "webhook-integration", + "title": "Webhook Integration Workflow", + "kind": "workflow", + "source_domain": "business-operations", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 2, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "webhook", + "event-driven", + "http-callback", + "integration", + "retry-logic", + "payload-signing" + ], + "description": "Webhook integration workflow with endpoint registration, payload signing, delivery attempt, retry with backoff, and delivery status tracking.", + "source_path": "business-operations/webhook-integration", + "repo_path": "uncategorized/business-operations/webhook-integration-workflow" +} diff --git a/business-operations/webhook-integration/workflow.fz b/uncategorized/business-operations/webhook-integration-workflow/workflow.fz similarity index 100% rename from business-operations/webhook-integration/workflow.fz rename to uncategorized/business-operations/webhook-integration-workflow/workflow.fz diff --git a/uncategorized/devops/chaos-engineering-workflow/README.md b/uncategorized/devops/chaos-engineering-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..96ba23400a394635e01c3718f221aefda44e3700 --- /dev/null +++ b/uncategorized/devops/chaos-engineering-workflow/README.md @@ -0,0 +1,19 @@ +# Chaos Engineering Workflow + +Chaos engineering workflow with hypothesis definition, steady-state monitoring, controlled fault injection, blast radius limitation, and resilience validation. + +**Template ID:** `chaos-engineering-workflow` +**Kind:** workflow +**Source domain:** devops +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 13 +**Lanes:** 4 +**Tags:** [chaos-engineering, fault-injection, resilience-testing, game-day, blast-radius, steady-state] +**Source path:** `devops/chaos-engineering` +**Repo path:** `uncategorized/devops/chaos-engineering-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/devops/chaos-engineering-workflow/metadata.json b/uncategorized/devops/chaos-engineering-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..2f64680fea6d0826b019d7ef9ebcf8f29f751c71 --- /dev/null +++ b/uncategorized/devops/chaos-engineering-workflow/metadata.json @@ -0,0 +1,24 @@ +{ + "template_id": "chaos-engineering-workflow", + "workflow_id": "chaos-engineering", + "title": "Chaos Engineering Workflow", + "kind": "workflow", + "source_domain": "devops", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 13, + "num_lanes": 4, + "tags": [ + "chaos-engineering", + "fault-injection", + "resilience-testing", + "game-day", + "blast-radius", + "steady-state" + ], + "description": "Chaos engineering workflow with hypothesis definition, steady-state monitoring, controlled fault injection, blast radius limitation, and resilience validation.", + "source_path": "devops/chaos-engineering", + "repo_path": "uncategorized/devops/chaos-engineering-workflow" +} diff --git a/devops/chaos-engineering/workflow.fz b/uncategorized/devops/chaos-engineering-workflow/workflow.fz similarity index 100% rename from devops/chaos-engineering/workflow.fz rename to uncategorized/devops/chaos-engineering-workflow/workflow.fz diff --git a/uncategorized/finance/bank-reconciliation-workflow/README.md b/uncategorized/finance/bank-reconciliation-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..1ff647c8260b8d7ec0f28e40e1d7798d3f6b249f --- /dev/null +++ b/uncategorized/finance/bank-reconciliation-workflow/README.md @@ -0,0 +1,19 @@ +# Bank Reconciliation Workflow + +Bank reconciliation workflow with automated transaction matching, variance reporting, discrepancy research, and journal entry creation for timing differences and bank errors. + +**Template ID:** `bank-reconciliation-workflow` +**Kind:** workflow +**Source domain:** finance +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 18 +**Lanes:** 3 +**Tags:** [bank-reconciliation, gl-matching, variance-analysis, journal-entries, auto-matching, discrepancy-resolution] +**Source path:** `finance/bank-reconciliation` +**Repo path:** `uncategorized/finance/bank-reconciliation-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/finance/bank-reconciliation/metadata.json b/uncategorized/finance/bank-reconciliation-workflow/metadata.json similarity index 56% rename from finance/bank-reconciliation/metadata.json rename to uncategorized/finance/bank-reconciliation-workflow/metadata.json index 50f370247e62907a4fe47f7b3b89cac42e979102..df83561de8db04afd525bbd86516e12cc549c168 100644 --- a/finance/bank-reconciliation/metadata.json +++ b/uncategorized/finance/bank-reconciliation-workflow/metadata.json @@ -1,6 +1,12 @@ { + "template_id": "bank-reconciliation-workflow", "workflow_id": "bank-reconciliation", - "domain": "finance", + "title": "Bank Reconciliation Workflow", + "kind": "workflow", + "source_domain": "finance", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], "complexity": 4, "num_nodes": 18, "num_lanes": 3, @@ -12,5 +18,7 @@ "auto-matching", "discrepancy-resolution" ], - "description": "Bank reconciliation workflow with automated transaction matching, variance reporting, discrepancy research, and journal entry creation for timing differences and bank errors." -} \ No newline at end of file + "description": "Bank reconciliation workflow with automated transaction matching, variance reporting, discrepancy research, and journal entry creation for timing differences and bank errors.", + "source_path": "finance/bank-reconciliation", + "repo_path": "uncategorized/finance/bank-reconciliation-workflow" +} diff --git a/finance/bank-reconciliation/workflow.fz b/uncategorized/finance/bank-reconciliation-workflow/workflow.fz similarity index 100% rename from finance/bank-reconciliation/workflow.fz rename to uncategorized/finance/bank-reconciliation-workflow/workflow.fz diff --git a/uncategorized/finance/cash-flow-forecast-workflow/README.md b/uncategorized/finance/cash-flow-forecast-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..e8f42f503f06696cb6e8170ca8fab3eb6547b0a3 --- /dev/null +++ b/uncategorized/finance/cash-flow-forecast-workflow/README.md @@ -0,0 +1,19 @@ +# Cash Flow Forecast Workflow + +Cash flow forecasting workflow with AR/AP projections, working capital analysis, liquidity gap identification, and short-term financing recommendations. + +**Template ID:** `cash-flow-forecast-workflow` +**Kind:** workflow +**Source domain:** finance +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [cash-flow-forecast, liquidity-planning, working-capital, ar-collections, ap-disbursements, treasury] +**Source path:** `finance/cash-flow-forecast` +**Repo path:** `uncategorized/finance/cash-flow-forecast-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/finance/cash-flow-forecast-workflow/metadata.json b/uncategorized/finance/cash-flow-forecast-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..f0fdece1221ee5f6ec7065db8f4ba4ae08f9d76d --- /dev/null +++ b/uncategorized/finance/cash-flow-forecast-workflow/metadata.json @@ -0,0 +1,24 @@ +{ + "template_id": "cash-flow-forecast-workflow", + "workflow_id": "cash-flow-forecast", + "title": "Cash Flow Forecast Workflow", + "kind": "workflow", + "source_domain": "finance", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "cash-flow-forecast", + "liquidity-planning", + "working-capital", + "ar-collections", + "ap-disbursements", + "treasury" + ], + "description": "Cash flow forecasting workflow with AR/AP projections, working capital analysis, liquidity gap identification, and short-term financing recommendations.", + "source_path": "finance/cash-flow-forecast", + "repo_path": "uncategorized/finance/cash-flow-forecast-workflow" +} diff --git a/finance/cash-flow-forecast/workflow.fz b/uncategorized/finance/cash-flow-forecast-workflow/workflow.fz similarity index 100% rename from finance/cash-flow-forecast/workflow.fz rename to uncategorized/finance/cash-flow-forecast-workflow/workflow.fz diff --git a/uncategorized/finance/cost-center-workflow/README.md b/uncategorized/finance/cost-center-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..f7db6c168d29ab222f6035a633594ca1f77143c4 --- /dev/null +++ b/uncategorized/finance/cost-center-workflow/README.md @@ -0,0 +1,19 @@ +# Cost Center Workflow + +This workflow models managing cost center budgets. + +**Template ID:** `cost-center-workflow` +**Kind:** workflow +**Source domain:** finance +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 2/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [cost, center, finance, decision] +**Source path:** `finance/cost-center` +**Repo path:** `uncategorized/finance/cost-center-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/finance/cost-center-workflow/metadata.json b/uncategorized/finance/cost-center-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..26b947a76597fd20dcaee739033979b1de56865b --- /dev/null +++ b/uncategorized/finance/cost-center-workflow/metadata.json @@ -0,0 +1,22 @@ +{ + "template_id": "cost-center-workflow", + "workflow_id": "cost-center", + "title": "Cost Center Workflow", + "kind": "workflow", + "source_domain": "finance", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 2, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "cost", + "center", + "finance", + "decision" + ], + "description": "This workflow models managing cost center budgets.", + "source_path": "finance/cost-center", + "repo_path": "uncategorized/finance/cost-center-workflow" +} diff --git a/finance/cost-center/workflow.fz b/uncategorized/finance/cost-center-workflow/workflow.fz similarity index 100% rename from finance/cost-center/workflow.fz rename to uncategorized/finance/cost-center-workflow/workflow.fz diff --git a/uncategorized/finance/credit-control-workflow/README.md b/uncategorized/finance/credit-control-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..d5b5f2f45da01956719d38c1bbd3e061422c9076 --- /dev/null +++ b/uncategorized/finance/credit-control-workflow/README.md @@ -0,0 +1,19 @@ +# Credit Control Workflow + +Customer credit control workflow with credit limit assessment, credit scoring, order hold management, collections escalation, and payment plan negotiation. + +**Template ID:** `credit-control-workflow` +**Kind:** workflow +**Source domain:** finance +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [credit-control, credit-limit, customer-credit, credit-scoring, collections, accounts-receivable] +**Source path:** `finance/credit-control` +**Repo path:** `uncategorized/finance/credit-control-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/finance/credit-control-workflow/metadata.json b/uncategorized/finance/credit-control-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..3dea052e098cbcb7ba48558be1ad288a3046f6aa --- /dev/null +++ b/uncategorized/finance/credit-control-workflow/metadata.json @@ -0,0 +1,24 @@ +{ + "template_id": "credit-control-workflow", + "workflow_id": "credit-control", + "title": "Credit Control Workflow", + "kind": "workflow", + "source_domain": "finance", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "credit-control", + "credit-limit", + "customer-credit", + "credit-scoring", + "collections", + "accounts-receivable" + ], + "description": "Customer credit control workflow with credit limit assessment, credit scoring, order hold management, collections escalation, and payment plan negotiation.", + "source_path": "finance/credit-control", + "repo_path": "uncategorized/finance/credit-control-workflow" +} diff --git a/finance/credit-control/workflow.fz b/uncategorized/finance/credit-control-workflow/workflow.fz similarity index 100% rename from finance/credit-control/workflow.fz rename to uncategorized/finance/credit-control-workflow/workflow.fz diff --git a/uncategorized/finance/expense-allocation-workflow/README.md b/uncategorized/finance/expense-allocation-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..2f2f81f152bf2c753c426fed91acc3d55eae8d0d --- /dev/null +++ b/uncategorized/finance/expense-allocation-workflow/README.md @@ -0,0 +1,19 @@ +# Expense Allocation Workflow + +This workflow models allocating costs to departments. + +**Template ID:** `expense-allocation-workflow` +**Kind:** workflow +**Source domain:** finance +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [expense, allocation, finance] +**Source path:** `finance/expense-allocation` +**Repo path:** `uncategorized/finance/expense-allocation-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/finance/expense-allocation-workflow/metadata.json b/uncategorized/finance/expense-allocation-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..d0c2acf2075600c678a469e0c1463653800e3eef --- /dev/null +++ b/uncategorized/finance/expense-allocation-workflow/metadata.json @@ -0,0 +1,21 @@ +{ + "template_id": "expense-allocation-workflow", + "workflow_id": "expense-allocation", + "title": "Expense Allocation Workflow", + "kind": "workflow", + "source_domain": "finance", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "expense", + "allocation", + "finance" + ], + "description": "This workflow models allocating costs to departments.", + "source_path": "finance/expense-allocation", + "repo_path": "uncategorized/finance/expense-allocation-workflow" +} diff --git a/finance/expense-allocation/workflow.fz b/uncategorized/finance/expense-allocation-workflow/workflow.fz similarity index 100% rename from finance/expense-allocation/workflow.fz rename to uncategorized/finance/expense-allocation-workflow/workflow.fz diff --git a/uncategorized/finance/fixed-assets-workflow/README.md b/uncategorized/finance/fixed-assets-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..16e554a7e672a0c4377e7e971b07818171b8c472 --- /dev/null +++ b/uncategorized/finance/fixed-assets-workflow/README.md @@ -0,0 +1,19 @@ +# Fixed Assets Workflow + +Fixed asset management workflow with asset capitalization, depreciation scheduling, physical inventory verification, and asset disposal/retirement processing. + +**Template ID:** `fixed-assets-workflow` +**Kind:** workflow +**Source domain:** finance +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [fixed-assets, asset-tracking, depreciation, capitalization, asset-disposal, physical-inventory] +**Source path:** `finance/fixed-assets` +**Repo path:** `uncategorized/finance/fixed-assets-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/finance/fixed-assets-workflow/metadata.json b/uncategorized/finance/fixed-assets-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..91808d0361a73699da232ccc823b9af1ad530dc8 --- /dev/null +++ b/uncategorized/finance/fixed-assets-workflow/metadata.json @@ -0,0 +1,24 @@ +{ + "template_id": "fixed-assets-workflow", + "workflow_id": "fixed-assets", + "title": "Fixed Assets Workflow", + "kind": "workflow", + "source_domain": "finance", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "fixed-assets", + "asset-tracking", + "depreciation", + "capitalization", + "asset-disposal", + "physical-inventory" + ], + "description": "Fixed asset management workflow with asset capitalization, depreciation scheduling, physical inventory verification, and asset disposal/retirement processing.", + "source_path": "finance/fixed-assets", + "repo_path": "uncategorized/finance/fixed-assets-workflow" +} diff --git a/finance/fixed-assets/workflow.fz b/uncategorized/finance/fixed-assets-workflow/workflow.fz similarity index 100% rename from finance/fixed-assets/workflow.fz rename to uncategorized/finance/fixed-assets-workflow/workflow.fz diff --git a/uncategorized/finance/monthly-close-workflow/README.md b/uncategorized/finance/monthly-close-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..3b83d08f0755cd7ea424246b0b982bc9c870d332 --- /dev/null +++ b/uncategorized/finance/monthly-close-workflow/README.md @@ -0,0 +1,19 @@ +# Monthly Close Workflow + +Corporate month-end financial close process including transaction posting, bank reconciliation, accruals, depreciation, trial balance validation, and financial statement generation. + +**Template ID:** `monthly-close-workflow` +**Kind:** workflow +**Source domain:** finance +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 22 +**Lanes:** 4 +**Tags:** [monthly-close, financial-reporting, accounting, reconciliation, trial-balance, period-close] +**Source path:** `finance/monthly-close` +**Repo path:** `uncategorized/finance/monthly-close-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/finance/monthly-close/metadata.json b/uncategorized/finance/monthly-close-workflow/metadata.json similarity index 56% rename from finance/monthly-close/metadata.json rename to uncategorized/finance/monthly-close-workflow/metadata.json index efe5e87aebd510174ff194ba4ccea0192d72acfe..3b6380bf22685f93917794fcab4b962d3399054f 100644 --- a/finance/monthly-close/metadata.json +++ b/uncategorized/finance/monthly-close-workflow/metadata.json @@ -1,6 +1,12 @@ { + "template_id": "monthly-close-workflow", "workflow_id": "monthly-close", - "domain": "finance", + "title": "Monthly Close Workflow", + "kind": "workflow", + "source_domain": "finance", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], "complexity": 4, "num_nodes": 22, "num_lanes": 4, @@ -12,5 +18,7 @@ "trial-balance", "period-close" ], - "description": "Corporate month-end financial close process including transaction posting, bank reconciliation, accruals, depreciation, trial balance validation, and financial statement generation." -} \ No newline at end of file + "description": "Corporate month-end financial close process including transaction posting, bank reconciliation, accruals, depreciation, trial balance validation, and financial statement generation.", + "source_path": "finance/monthly-close", + "repo_path": "uncategorized/finance/monthly-close-workflow" +} diff --git a/finance/monthly-close/workflow.fz b/uncategorized/finance/monthly-close-workflow/workflow.fz similarity index 100% rename from finance/monthly-close/workflow.fz rename to uncategorized/finance/monthly-close-workflow/workflow.fz diff --git a/uncategorized/finance/procurement-card-workflow/README.md b/uncategorized/finance/procurement-card-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..81ca935051f92123afcb549e830e4686fd79c6b1 --- /dev/null +++ b/uncategorized/finance/procurement-card-workflow/README.md @@ -0,0 +1,19 @@ +# Procurement Card Workflow + +This workflow models managing company credit cards. + +**Template ID:** `procurement-card-workflow` +**Kind:** workflow +**Source domain:** finance +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [procurement, card, finance] +**Source path:** `finance/procurement-card` +**Repo path:** `uncategorized/finance/procurement-card-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/finance/procurement-card-workflow/metadata.json b/uncategorized/finance/procurement-card-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..792c63966b70cf1fd855ed2bcd5025e7734b20a0 --- /dev/null +++ b/uncategorized/finance/procurement-card-workflow/metadata.json @@ -0,0 +1,21 @@ +{ + "template_id": "procurement-card-workflow", + "workflow_id": "procurement-card", + "title": "Procurement Card Workflow", + "kind": "workflow", + "source_domain": "finance", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "procurement", + "card", + "finance" + ], + "description": "This workflow models managing company credit cards.", + "source_path": "finance/procurement-card", + "repo_path": "uncategorized/finance/procurement-card-workflow" +} diff --git a/finance/procurement-card/workflow.fz b/uncategorized/finance/procurement-card-workflow/workflow.fz similarity index 100% rename from finance/procurement-card/workflow.fz rename to uncategorized/finance/procurement-card-workflow/workflow.fz diff --git a/uncategorized/finance/treasury-management-workflow/README.md b/uncategorized/finance/treasury-management-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..614e47ac1f631d8b4d761c4c1b809b9e72fc7a03 --- /dev/null +++ b/uncategorized/finance/treasury-management-workflow/README.md @@ -0,0 +1,19 @@ +# Treasury Management Workflow + +Corporate treasury management workflow with cash pooling, FX exposure hedging, short-term investment decisions, and bank relationship management. + +**Template ID:** `treasury-management-workflow` +**Kind:** workflow +**Source domain:** finance +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [treasury-management, cash-pooling, fx-hedging, investment-portfolio, bank-relationships, liquidity] +**Source path:** `finance/treasury-management` +**Repo path:** `uncategorized/finance/treasury-management-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/finance/treasury-management-workflow/metadata.json b/uncategorized/finance/treasury-management-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..ac91d7d53ba2783f8e9184c28d8a98cffca37687 --- /dev/null +++ b/uncategorized/finance/treasury-management-workflow/metadata.json @@ -0,0 +1,24 @@ +{ + "template_id": "treasury-management-workflow", + "workflow_id": "treasury-management", + "title": "Treasury Management Workflow", + "kind": "workflow", + "source_domain": "finance", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "treasury-management", + "cash-pooling", + "fx-hedging", + "investment-portfolio", + "bank-relationships", + "liquidity" + ], + "description": "Corporate treasury management workflow with cash pooling, FX exposure hedging, short-term investment decisions, and bank relationship management.", + "source_path": "finance/treasury-management", + "repo_path": "uncategorized/finance/treasury-management-workflow" +} diff --git a/finance/treasury-management/workflow.fz b/uncategorized/finance/treasury-management-workflow/workflow.fz similarity index 100% rename from finance/treasury-management/workflow.fz rename to uncategorized/finance/treasury-management-workflow/workflow.fz diff --git a/uncategorized/hr/background-check-workflow/README.md b/uncategorized/hr/background-check-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..642c8c3286bfec9e8b3f896c1a57583f206b175a --- /dev/null +++ b/uncategorized/hr/background-check-workflow/README.md @@ -0,0 +1,19 @@ +# Background Check Workflow + +Pre-employment background check workflow with criminal history search, employment verification, education verification, and drug screening coordination. + +**Template ID:** `background-check-workflow` +**Kind:** workflow +**Source domain:** hr +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [background-check, pre-employment, criminal-history, employment-verification, education-verification, drug-screening] +**Source path:** `hr/background-check` +**Repo path:** `uncategorized/hr/background-check-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/hr/background-check/metadata.json b/uncategorized/hr/background-check-workflow/metadata.json similarity index 51% rename from hr/background-check/metadata.json rename to uncategorized/hr/background-check-workflow/metadata.json index ad1e2a50ea511e80549bff9d8c81d7484115b951..157c7a2cf021bfda370bc6532df79c4f2b7df954 100644 --- a/hr/background-check/metadata.json +++ b/uncategorized/hr/background-check-workflow/metadata.json @@ -1,6 +1,12 @@ { + "template_id": "background-check-workflow", "workflow_id": "background-check", - "domain": "hr", + "title": "Background Check Workflow", + "kind": "workflow", + "source_domain": "hr", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], "complexity": 3, "num_nodes": 7, "num_lanes": 2, @@ -12,5 +18,7 @@ "education-verification", "drug-screening" ], - "description": "Pre-employment background check workflow with criminal history search, employment verification, education verification, and drug screening coordination." -} \ No newline at end of file + "description": "Pre-employment background check workflow with criminal history search, employment verification, education verification, and drug screening coordination.", + "source_path": "hr/background-check", + "repo_path": "uncategorized/hr/background-check-workflow" +} diff --git a/hr/background-check/workflow.fz b/uncategorized/hr/background-check-workflow/workflow.fz similarity index 100% rename from hr/background-check/workflow.fz rename to uncategorized/hr/background-check-workflow/workflow.fz diff --git a/uncategorized/hr/bonus-allocation-workflow/README.md b/uncategorized/hr/bonus-allocation-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..8acde335ef80f09e24493b80bb10b285623a3143 --- /dev/null +++ b/uncategorized/hr/bonus-allocation-workflow/README.md @@ -0,0 +1,19 @@ +# Bonus Allocation Workflow + +Annual bonus allocation workflow with budget pool distribution, performance-based calculation, manager calibration, executive approval, and payroll processing. + +**Template ID:** `bonus-allocation-workflow` +**Kind:** workflow +**Source domain:** hr +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [bonus-allocation, annual-bonus, performance-bonus, budget-pool, calibration, payout] +**Source path:** `hr/bonus-allocation` +**Repo path:** `uncategorized/hr/bonus-allocation-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/hr/bonus-allocation-workflow/metadata.json b/uncategorized/hr/bonus-allocation-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..58fcabc1a73666b2171ca70f78a5498f582edf8b --- /dev/null +++ b/uncategorized/hr/bonus-allocation-workflow/metadata.json @@ -0,0 +1,24 @@ +{ + "template_id": "bonus-allocation-workflow", + "workflow_id": "bonus-allocation", + "title": "Bonus Allocation Workflow", + "kind": "workflow", + "source_domain": "hr", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "bonus-allocation", + "annual-bonus", + "performance-bonus", + "budget-pool", + "calibration", + "payout" + ], + "description": "Annual bonus allocation workflow with budget pool distribution, performance-based calculation, manager calibration, executive approval, and payroll processing.", + "source_path": "hr/bonus-allocation", + "repo_path": "uncategorized/hr/bonus-allocation-workflow" +} diff --git a/hr/bonus-allocation/workflow.fz b/uncategorized/hr/bonus-allocation-workflow/workflow.fz similarity index 100% rename from hr/bonus-allocation/workflow.fz rename to uncategorized/hr/bonus-allocation-workflow/workflow.fz diff --git a/uncategorized/hr/candidate-rejection-workflow/README.md b/uncategorized/hr/candidate-rejection-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..395870c3614bef769aa75ff4923ad217cc3ad7d5 --- /dev/null +++ b/uncategorized/hr/candidate-rejection-workflow/README.md @@ -0,0 +1,19 @@ +# Candidate Rejection Workflow + +Candidate rejection workflow with stage-appropriate messaging, personalized rejection letters, talent pool consideration, ATS status update, and candidate experience feedback. + +**Template ID:** `candidate-rejection-workflow` +**Kind:** workflow +**Source domain:** hr +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [candidate-rejection, hiring-decision, rejection-letter, talent-pool, candidate-experience, ats-update] +**Source path:** `hr/candidate-rejection` +**Repo path:** `uncategorized/hr/candidate-rejection-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/hr/candidate-rejection/metadata.json b/uncategorized/hr/candidate-rejection-workflow/metadata.json similarity index 56% rename from hr/candidate-rejection/metadata.json rename to uncategorized/hr/candidate-rejection-workflow/metadata.json index 5aecbdea04a2b1ab45c463e854499fd144da7b05..5139452d6dcac0ccc38a98933444f99656a5b5f9 100644 --- a/hr/candidate-rejection/metadata.json +++ b/uncategorized/hr/candidate-rejection-workflow/metadata.json @@ -1,6 +1,12 @@ { + "template_id": "candidate-rejection-workflow", "workflow_id": "candidate-rejection", - "domain": "hr", + "title": "Candidate Rejection Workflow", + "kind": "workflow", + "source_domain": "hr", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], "complexity": 3, "num_nodes": 10, "num_lanes": 3, @@ -12,5 +18,7 @@ "candidate-experience", "ats-update" ], - "description": "Candidate rejection workflow with stage-appropriate messaging, personalized rejection letters, talent pool consideration, ATS status update, and candidate experience feedback." -} \ No newline at end of file + "description": "Candidate rejection workflow with stage-appropriate messaging, personalized rejection letters, talent pool consideration, ATS status update, and candidate experience feedback.", + "source_path": "hr/candidate-rejection", + "repo_path": "uncategorized/hr/candidate-rejection-workflow" +} diff --git a/hr/candidate-rejection/workflow.fz b/uncategorized/hr/candidate-rejection-workflow/workflow.fz similarity index 100% rename from hr/candidate-rejection/workflow.fz rename to uncategorized/hr/candidate-rejection-workflow/workflow.fz diff --git a/uncategorized/hr/diversity-initiative-workflow/README.md b/uncategorized/hr/diversity-initiative-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..341b5f84d09f819befea4a47092a0fbbba22b324 --- /dev/null +++ b/uncategorized/hr/diversity-initiative-workflow/README.md @@ -0,0 +1,19 @@ +# Diversity Initiative Workflow + +This workflow models promoting workplace diversity. + +**Template ID:** `diversity-initiative-workflow` +**Kind:** workflow +**Source domain:** hr +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [diversity, initiative, hr] +**Source path:** `hr/diversity-initiative` +**Repo path:** `uncategorized/hr/diversity-initiative-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/hr/diversity-initiative-workflow/metadata.json b/uncategorized/hr/diversity-initiative-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..70c991eb787145a9494a594987bc54d372d4d92d --- /dev/null +++ b/uncategorized/hr/diversity-initiative-workflow/metadata.json @@ -0,0 +1,21 @@ +{ + "template_id": "diversity-initiative-workflow", + "workflow_id": "diversity-initiative", + "title": "Diversity Initiative Workflow", + "kind": "workflow", + "source_domain": "hr", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "diversity", + "initiative", + "hr" + ], + "description": "This workflow models promoting workplace diversity.", + "source_path": "hr/diversity-initiative", + "repo_path": "uncategorized/hr/diversity-initiative-workflow" +} diff --git a/hr/diversity-initiative/workflow.fz b/uncategorized/hr/diversity-initiative-workflow/workflow.fz similarity index 100% rename from hr/diversity-initiative/workflow.fz rename to uncategorized/hr/diversity-initiative-workflow/workflow.fz diff --git a/uncategorized/hr/employee-engagement-workflow/README.md b/uncategorized/hr/employee-engagement-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..c0d062311c79cb33f121d7782e6de760923b8e91 --- /dev/null +++ b/uncategorized/hr/employee-engagement-workflow/README.md @@ -0,0 +1,19 @@ +# Employee Engagement Workflow + +This workflow models measuring and improving engagement. + +**Template ID:** `employee-engagement-workflow` +**Kind:** workflow +**Source domain:** hr +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 2/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [employee, engagement, hr, parallel] +**Source path:** `hr/employee-engagement` +**Repo path:** `uncategorized/hr/employee-engagement-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/hr/employee-engagement-workflow/metadata.json b/uncategorized/hr/employee-engagement-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..64caa7e8d95a99cfe678e7fc05834391b4f8ce1d --- /dev/null +++ b/uncategorized/hr/employee-engagement-workflow/metadata.json @@ -0,0 +1,22 @@ +{ + "template_id": "employee-engagement-workflow", + "workflow_id": "employee-engagement", + "title": "Employee Engagement Workflow", + "kind": "workflow", + "source_domain": "hr", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 2, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "employee", + "engagement", + "hr", + "parallel" + ], + "description": "This workflow models measuring and improving engagement.", + "source_path": "hr/employee-engagement", + "repo_path": "uncategorized/hr/employee-engagement-workflow" +} diff --git a/hr/employee-engagement/workflow.fz b/uncategorized/hr/employee-engagement-workflow/workflow.fz similarity index 100% rename from hr/employee-engagement/workflow.fz rename to uncategorized/hr/employee-engagement-workflow/workflow.fz diff --git a/uncategorized/hr/internship-program-workflow/README.md b/uncategorized/hr/internship-program-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..80e1f2b62a475f6770d7a79d5a4839ff2817f298 --- /dev/null +++ b/uncategorized/hr/internship-program-workflow/README.md @@ -0,0 +1,19 @@ +# Internship Program Workflow + +This workflow models managing an internship program. + +**Template ID:** `internship-program-workflow` +**Kind:** workflow +**Source domain:** hr +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 2/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [internship, program, hr] +**Source path:** `hr/internship-program` +**Repo path:** `uncategorized/hr/internship-program-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/hr/internship-program-workflow/metadata.json b/uncategorized/hr/internship-program-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..39ed2463bded31687496360ab9ad1134f29585fc --- /dev/null +++ b/uncategorized/hr/internship-program-workflow/metadata.json @@ -0,0 +1,21 @@ +{ + "template_id": "internship-program-workflow", + "workflow_id": "internship-program", + "title": "Internship Program Workflow", + "kind": "workflow", + "source_domain": "hr", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 2, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "internship", + "program", + "hr" + ], + "description": "This workflow models managing an internship program.", + "source_path": "hr/internship-program", + "repo_path": "uncategorized/hr/internship-program-workflow" +} diff --git a/hr/internship-program/workflow.fz b/uncategorized/hr/internship-program-workflow/workflow.fz similarity index 100% rename from hr/internship-program/workflow.fz rename to uncategorized/hr/internship-program-workflow/workflow.fz diff --git a/uncategorized/hr/interview-process-workflow/README.md b/uncategorized/hr/interview-process-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..1dfe5c16fb6d8e1838bb4bb5340118a5eeeb0a65 --- /dev/null +++ b/uncategorized/hr/interview-process-workflow/README.md @@ -0,0 +1,19 @@ +# Interview Process Workflow + +Multi-stage interview process with resume screening, phone screen, technical interview, onsite panel, team consensus decision, and offer/rejection handling. + +**Template ID:** `interview-process-workflow` +**Kind:** workflow +**Source domain:** hr +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 22 +**Lanes:** 3 +**Tags:** [interview-process, hiring, phone-screen, technical-interview, onsite-panel, talent-acquisition, offer-management] +**Source path:** `hr/interview-process` +**Repo path:** `uncategorized/hr/interview-process-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/hr/interview-process/metadata.json b/uncategorized/hr/interview-process-workflow/metadata.json similarity index 51% rename from hr/interview-process/metadata.json rename to uncategorized/hr/interview-process-workflow/metadata.json index e04b6280b692cf599651b2a7f43f525daa7c9a4a..ab468faf3fb0558736d40d6419e91cd7b4e19662 100644 --- a/hr/interview-process/metadata.json +++ b/uncategorized/hr/interview-process-workflow/metadata.json @@ -1,6 +1,12 @@ { + "template_id": "interview-process-workflow", "workflow_id": "interview-process", - "domain": "hr", + "title": "Interview Process Workflow", + "kind": "workflow", + "source_domain": "hr", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], "complexity": 4, "num_nodes": 22, "num_lanes": 3, @@ -13,5 +19,7 @@ "talent-acquisition", "offer-management" ], - "description": "Multi-stage interview process with resume screening, phone screen, technical interview, onsite panel, team consensus decision, and offer/rejection handling." -} \ No newline at end of file + "description": "Multi-stage interview process with resume screening, phone screen, technical interview, onsite panel, team consensus decision, and offer/rejection handling.", + "source_path": "hr/interview-process", + "repo_path": "uncategorized/hr/interview-process-workflow" +} diff --git a/hr/interview-process/workflow.fz b/uncategorized/hr/interview-process-workflow/workflow.fz similarity index 100% rename from hr/interview-process/workflow.fz rename to uncategorized/hr/interview-process-workflow/workflow.fz diff --git a/uncategorized/hr/job-posting-workflow/README.md b/uncategorized/hr/job-posting-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..1adc9a8a73c27ae9ad8f3eb8ee5d40ac12984e36 --- /dev/null +++ b/uncategorized/hr/job-posting-workflow/README.md @@ -0,0 +1,19 @@ +# Job Posting Workflow + +Job posting workflow with requisition approval, job description drafting, multi-channel posting (LinkedIn, Indeed, career sites), AI resume screening, and ATS candidate tracking. + +**Template ID:** `job-posting-workflow` +**Kind:** workflow +**Source domain:** hr +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 19 +**Lanes:** 3 +**Tags:** [job-posting, job-requisition, ats, linkedin, indeed, ai-screening, talent-acquisition] +**Source path:** `hr/job-posting` +**Repo path:** `uncategorized/hr/job-posting-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/hr/job-posting/metadata.json b/uncategorized/hr/job-posting-workflow/metadata.json similarity index 58% rename from hr/job-posting/metadata.json rename to uncategorized/hr/job-posting-workflow/metadata.json index 4da962ff6476cbd878c43323b7a1ab5df664682b..c235d7c6f7c72b5c494a22a54e3b2a4835b126ff 100644 --- a/hr/job-posting/metadata.json +++ b/uncategorized/hr/job-posting-workflow/metadata.json @@ -1,6 +1,12 @@ { + "template_id": "job-posting-workflow", "workflow_id": "job-posting", - "domain": "hr", + "title": "Job Posting Workflow", + "kind": "workflow", + "source_domain": "hr", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], "complexity": 4, "num_nodes": 19, "num_lanes": 3, @@ -13,5 +19,7 @@ "ai-screening", "talent-acquisition" ], - "description": "Job posting workflow with requisition approval, job description drafting, multi-channel posting (LinkedIn, Indeed, career sites), AI resume screening, and ATS candidate tracking." -} \ No newline at end of file + "description": "Job posting workflow with requisition approval, job description drafting, multi-channel posting (LinkedIn, Indeed, career sites), AI resume screening, and ATS candidate tracking.", + "source_path": "hr/job-posting", + "repo_path": "uncategorized/hr/job-posting-workflow" +} diff --git a/hr/job-posting/workflow.fz b/uncategorized/hr/job-posting-workflow/workflow.fz similarity index 100% rename from hr/job-posting/workflow.fz rename to uncategorized/hr/job-posting-workflow/workflow.fz diff --git a/uncategorized/hr/promotion-process-workflow/README.md b/uncategorized/hr/promotion-process-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..2d6df32c99abef8f3227bd48682edd5ea9d45a39 --- /dev/null +++ b/uncategorized/hr/promotion-process-workflow/README.md @@ -0,0 +1,19 @@ +# Promotion Process Workflow + +Employee promotion workflow with performance validation, job level assessment, compensation adjustment, title change, and announcement coordination. + +**Template ID:** `promotion-process-workflow` +**Kind:** workflow +**Source domain:** hr +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [promotion-process, career-advancement, job-leveling, title-change, compensation-adjustment, succession-planning] +**Source path:** `hr/promotion-process` +**Repo path:** `uncategorized/hr/promotion-process-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/hr/promotion-process/metadata.json b/uncategorized/hr/promotion-process-workflow/metadata.json similarity index 51% rename from hr/promotion-process/metadata.json rename to uncategorized/hr/promotion-process-workflow/metadata.json index 89822a6e64bfca665d98092c97a2a2441e7e78b3..7876b601990ecfd40aab1e3dd674139680817f6e 100644 --- a/hr/promotion-process/metadata.json +++ b/uncategorized/hr/promotion-process-workflow/metadata.json @@ -1,6 +1,12 @@ { + "template_id": "promotion-process-workflow", "workflow_id": "promotion-process", - "domain": "hr", + "title": "Promotion Process Workflow", + "kind": "workflow", + "source_domain": "hr", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], "complexity": 3, "num_nodes": 7, "num_lanes": 2, @@ -12,5 +18,7 @@ "compensation-adjustment", "succession-planning" ], - "description": "Employee promotion workflow with performance validation, job level assessment, compensation adjustment, title change, and announcement coordination." -} \ No newline at end of file + "description": "Employee promotion workflow with performance validation, job level assessment, compensation adjustment, title change, and announcement coordination.", + "source_path": "hr/promotion-process", + "repo_path": "uncategorized/hr/promotion-process-workflow" +} diff --git a/hr/promotion-process/workflow.fz b/uncategorized/hr/promotion-process-workflow/workflow.fz similarity index 100% rename from hr/promotion-process/workflow.fz rename to uncategorized/hr/promotion-process-workflow/workflow.fz diff --git a/uncategorized/hr/reference-check-workflow/README.md b/uncategorized/hr/reference-check-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..45a1aa815cf057b65473e57a672ddfcb7958d681 --- /dev/null +++ b/uncategorized/hr/reference-check-workflow/README.md @@ -0,0 +1,19 @@ +# Reference Check Workflow + +Professional reference check workflow with reference collection, outreach scheduling, structured interview questions, feedback documentation, and hiring recommendation. + +**Template ID:** `reference-check-workflow` +**Kind:** workflow +**Source domain:** hr +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [reference-check, employment-verification, professional-references, hiring-decision, candidate-vetting, feedback-collection] +**Source path:** `hr/reference-check` +**Repo path:** `uncategorized/hr/reference-check-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/hr/reference-check/metadata.json b/uncategorized/hr/reference-check-workflow/metadata.json similarity index 51% rename from hr/reference-check/metadata.json rename to uncategorized/hr/reference-check-workflow/metadata.json index 26762d58941c9d0310270223adcef2ae50033c29..ba60a99041fecbb81204dc118dfe2978d6dafef2 100644 --- a/hr/reference-check/metadata.json +++ b/uncategorized/hr/reference-check-workflow/metadata.json @@ -1,6 +1,12 @@ { + "template_id": "reference-check-workflow", "workflow_id": "reference-check", - "domain": "hr", + "title": "Reference Check Workflow", + "kind": "workflow", + "source_domain": "hr", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], "complexity": 3, "num_nodes": 10, "num_lanes": 3, @@ -12,5 +18,7 @@ "candidate-vetting", "feedback-collection" ], - "description": "Professional reference check workflow with reference collection, outreach scheduling, structured interview questions, feedback documentation, and hiring recommendation." -} \ No newline at end of file + "description": "Professional reference check workflow with reference collection, outreach scheduling, structured interview questions, feedback documentation, and hiring recommendation.", + "source_path": "hr/reference-check", + "repo_path": "uncategorized/hr/reference-check-workflow" +} diff --git a/hr/reference-check/workflow.fz b/uncategorized/hr/reference-check-workflow/workflow.fz similarity index 100% rename from hr/reference-check/workflow.fz rename to uncategorized/hr/reference-check-workflow/workflow.fz diff --git a/uncategorized/hr/relocation-assistance-workflow/README.md b/uncategorized/hr/relocation-assistance-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..40604e35e26360f9cbf91f4b15abec9a5c1ae0e6 --- /dev/null +++ b/uncategorized/hr/relocation-assistance-workflow/README.md @@ -0,0 +1,19 @@ +# Relocation Assistance Workflow + +This workflow models helping employees relocate. + +**Template ID:** `relocation-assistance-workflow` +**Kind:** workflow +**Source domain:** hr +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [relocation, assistance, hr, decision] +**Source path:** `hr/relocation-assistance` +**Repo path:** `uncategorized/hr/relocation-assistance-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/hr/relocation-assistance-workflow/metadata.json b/uncategorized/hr/relocation-assistance-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..139f1490adc3d33e891f9d946500e728b07ec2a4 --- /dev/null +++ b/uncategorized/hr/relocation-assistance-workflow/metadata.json @@ -0,0 +1,22 @@ +{ + "template_id": "relocation-assistance-workflow", + "workflow_id": "relocation-assistance", + "title": "Relocation Assistance Workflow", + "kind": "workflow", + "source_domain": "hr", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "relocation", + "assistance", + "hr", + "decision" + ], + "description": "This workflow models helping employees relocate.", + "source_path": "hr/relocation-assistance", + "repo_path": "uncategorized/hr/relocation-assistance-workflow" +} diff --git a/hr/relocation-assistance/workflow.fz b/uncategorized/hr/relocation-assistance-workflow/workflow.fz similarity index 100% rename from hr/relocation-assistance/workflow.fz rename to uncategorized/hr/relocation-assistance-workflow/workflow.fz diff --git a/uncategorized/logistics/carrier-selection-workflow/README.md b/uncategorized/logistics/carrier-selection-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..a97ee476f80b36850d74037b77130aa7db8a0a70 --- /dev/null +++ b/uncategorized/logistics/carrier-selection-workflow/README.md @@ -0,0 +1,19 @@ +# Carrier Selection Workflow + +Carrier selection workflow with rate shopping, transit time comparison, service level matching, carrier performance scoring, and optimal carrier assignment. + +**Template ID:** `carrier-selection-workflow` +**Kind:** workflow +**Source domain:** logistics +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [carrier-selection, rate-shopping, transit-time, service-level, tms, freight-optimization] +**Source path:** `logistics/carrier-selection` +**Repo path:** `uncategorized/logistics/carrier-selection-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/logistics/carrier-selection-workflow/metadata.json b/uncategorized/logistics/carrier-selection-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..34f9ed86cfc44615026c9a7dbd77dfda032f5910 --- /dev/null +++ b/uncategorized/logistics/carrier-selection-workflow/metadata.json @@ -0,0 +1,24 @@ +{ + "template_id": "carrier-selection-workflow", + "workflow_id": "carrier-selection", + "title": "Carrier Selection Workflow", + "kind": "workflow", + "source_domain": "logistics", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "carrier-selection", + "rate-shopping", + "transit-time", + "service-level", + "tms", + "freight-optimization" + ], + "description": "Carrier selection workflow with rate shopping, transit time comparison, service level matching, carrier performance scoring, and optimal carrier assignment.", + "source_path": "logistics/carrier-selection", + "repo_path": "uncategorized/logistics/carrier-selection-workflow" +} diff --git a/logistics/carrier-selection/workflow.fz b/uncategorized/logistics/carrier-selection-workflow/workflow.fz similarity index 100% rename from logistics/carrier-selection/workflow.fz rename to uncategorized/logistics/carrier-selection-workflow/workflow.fz diff --git a/uncategorized/logistics/container-loading-workflow/README.md b/uncategorized/logistics/container-loading-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..5fa7d1380c01c71b416b5137c23760959ed21ba3 --- /dev/null +++ b/uncategorized/logistics/container-loading-workflow/README.md @@ -0,0 +1,19 @@ +# Container Loading Workflow + +Container loading workflow with load plan optimization, weight distribution, cube utilization maximization, seal application, and bill of lading generation. + +**Template ID:** `container-loading-workflow` +**Kind:** workflow +**Source domain:** logistics +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [container-loading, load-planning, weight-distribution, cube-utilization, seal-verification, ocean-freight] +**Source path:** `logistics/container-loading` +**Repo path:** `uncategorized/logistics/container-loading-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/logistics/container-loading-workflow/metadata.json b/uncategorized/logistics/container-loading-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..b182af54c7d8dc4e496e8bfa20c788af34f9de2b --- /dev/null +++ b/uncategorized/logistics/container-loading-workflow/metadata.json @@ -0,0 +1,24 @@ +{ + "template_id": "container-loading-workflow", + "workflow_id": "container-loading", + "title": "Container Loading Workflow", + "kind": "workflow", + "source_domain": "logistics", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "container-loading", + "load-planning", + "weight-distribution", + "cube-utilization", + "seal-verification", + "ocean-freight" + ], + "description": "Container loading workflow with load plan optimization, weight distribution, cube utilization maximization, seal application, and bill of lading generation.", + "source_path": "logistics/container-loading", + "repo_path": "uncategorized/logistics/container-loading-workflow" +} diff --git a/logistics/container-loading/workflow.fz b/uncategorized/logistics/container-loading-workflow/workflow.fz similarity index 100% rename from logistics/container-loading/workflow.fz rename to uncategorized/logistics/container-loading-workflow/workflow.fz diff --git a/uncategorized/logistics/cross-docking-workflow/README.md b/uncategorized/logistics/cross-docking-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..50a187542e1013136ad39cf3de8ac271288ab833 --- /dev/null +++ b/uncategorized/logistics/cross-docking-workflow/README.md @@ -0,0 +1,19 @@ +# Cross Docking Workflow + +Cross-docking workflow with inbound scheduling, sortation by destination, outbound consolidation, and direct transfer without storage for just-in-time delivery. + +**Template ID:** `cross-docking-workflow` +**Kind:** workflow +**Source domain:** logistics +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [cross-docking, flow-through, dock-scheduling, sortation, consolidation, just-in-time] +**Source path:** `logistics/cross-docking` +**Repo path:** `uncategorized/logistics/cross-docking-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/logistics/cross-docking-workflow/metadata.json b/uncategorized/logistics/cross-docking-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..e2c820907ff528e9ec9d1082ffb04e489b9666ff --- /dev/null +++ b/uncategorized/logistics/cross-docking-workflow/metadata.json @@ -0,0 +1,24 @@ +{ + "template_id": "cross-docking-workflow", + "workflow_id": "cross-docking", + "title": "Cross Docking Workflow", + "kind": "workflow", + "source_domain": "logistics", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "cross-docking", + "flow-through", + "dock-scheduling", + "sortation", + "consolidation", + "just-in-time" + ], + "description": "Cross-docking workflow with inbound scheduling, sortation by destination, outbound consolidation, and direct transfer without storage for just-in-time delivery.", + "source_path": "logistics/cross-docking", + "repo_path": "uncategorized/logistics/cross-docking-workflow" +} diff --git a/logistics/cross-docking/workflow.fz b/uncategorized/logistics/cross-docking-workflow/workflow.fz similarity index 100% rename from logistics/cross-docking/workflow.fz rename to uncategorized/logistics/cross-docking-workflow/workflow.fz diff --git a/uncategorized/logistics/customs-clearance-workflow/README.md b/uncategorized/logistics/customs-clearance-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..d209779cdd96c7d24c8f375fbe171d86eb8b1a44 --- /dev/null +++ b/uncategorized/logistics/customs-clearance-workflow/README.md @@ -0,0 +1,19 @@ +# Customs Clearance Workflow + +International customs clearance workflow with importer documentation, customs broker HS code classification, duty calculation, customs authority inspection, and clearance certificate issuance. + +**Template ID:** `customs-clearance-workflow` +**Kind:** workflow +**Source domain:** logistics +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 19 +**Lanes:** 3 +**Tags:** [customs-clearance, international-trade, customs-broker, hs-codes, import-export, duties-taxes, inspection] +**Source path:** `logistics/customs-clearance` +**Repo path:** `uncategorized/logistics/customs-clearance-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/logistics/customs-clearance/metadata.json b/uncategorized/logistics/customs-clearance-workflow/metadata.json similarity index 55% rename from logistics/customs-clearance/metadata.json rename to uncategorized/logistics/customs-clearance-workflow/metadata.json index 6920160910f3d53d15ab114b8b528ced10af372f..e989d818a124141718f8724ba94c5f41bb2a61fd 100644 --- a/logistics/customs-clearance/metadata.json +++ b/uncategorized/logistics/customs-clearance-workflow/metadata.json @@ -1,6 +1,12 @@ { + "template_id": "customs-clearance-workflow", "workflow_id": "customs-clearance", - "domain": "logistics", + "title": "Customs Clearance Workflow", + "kind": "workflow", + "source_domain": "logistics", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], "complexity": 4, "num_nodes": 19, "num_lanes": 3, @@ -13,5 +19,7 @@ "duties-taxes", "inspection" ], - "description": "International customs clearance workflow with importer documentation, customs broker HS code classification, duty calculation, customs authority inspection, and clearance certificate issuance." -} \ No newline at end of file + "description": "International customs clearance workflow with importer documentation, customs broker HS code classification, duty calculation, customs authority inspection, and clearance certificate issuance.", + "source_path": "logistics/customs-clearance", + "repo_path": "uncategorized/logistics/customs-clearance-workflow" +} diff --git a/logistics/customs-clearance/workflow.fz b/uncategorized/logistics/customs-clearance-workflow/workflow.fz similarity index 100% rename from logistics/customs-clearance/workflow.fz rename to uncategorized/logistics/customs-clearance-workflow/workflow.fz diff --git a/uncategorized/logistics/damaged-goods-workflow/README.md b/uncategorized/logistics/damaged-goods-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..36b8fd8f0ad57cd67880024342a424e65d3f4887 --- /dev/null +++ b/uncategorized/logistics/damaged-goods-workflow/README.md @@ -0,0 +1,19 @@ +# Damaged Goods Workflow + +Damaged goods processing workflow with damage documentation, carrier claim filing, disposition decision (salvage/dispose), inventory adjustment, and loss tracking. + +**Template ID:** `damaged-goods-workflow` +**Kind:** workflow +**Source domain:** logistics +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [damaged-goods, damage-claim, inventory-write-off, carrier-claim, disposition, loss-prevention] +**Source path:** `logistics/damaged-goods` +**Repo path:** `uncategorized/logistics/damaged-goods-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/logistics/damaged-goods-workflow/metadata.json b/uncategorized/logistics/damaged-goods-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..fe8311929ecb8da9079757c2a053e4901c06e83e --- /dev/null +++ b/uncategorized/logistics/damaged-goods-workflow/metadata.json @@ -0,0 +1,24 @@ +{ + "template_id": "damaged-goods-workflow", + "workflow_id": "damaged-goods", + "title": "Damaged Goods Workflow", + "kind": "workflow", + "source_domain": "logistics", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "damaged-goods", + "damage-claim", + "inventory-write-off", + "carrier-claim", + "disposition", + "loss-prevention" + ], + "description": "Damaged goods processing workflow with damage documentation, carrier claim filing, disposition decision (salvage/dispose), inventory adjustment, and loss tracking.", + "source_path": "logistics/damaged-goods", + "repo_path": "uncategorized/logistics/damaged-goods-workflow" +} diff --git a/logistics/damaged-goods/workflow.fz b/uncategorized/logistics/damaged-goods-workflow/workflow.fz similarity index 100% rename from logistics/damaged-goods/workflow.fz rename to uncategorized/logistics/damaged-goods-workflow/workflow.fz diff --git a/uncategorized/logistics/delivery-confirmation-workflow/README.md b/uncategorized/logistics/delivery-confirmation-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..e2fcafbba21bc3b072ca2ff7c148ab8e1ffbe725 --- /dev/null +++ b/uncategorized/logistics/delivery-confirmation-workflow/README.md @@ -0,0 +1,19 @@ +# Delivery Confirmation Workflow + +Delivery confirmation workflow with proof of delivery capture, signature collection, photo documentation, order status update, and customer notification. + +**Template ID:** `delivery-confirmation-workflow` +**Kind:** workflow +**Source domain:** logistics +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 2/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [delivery-confirmation, pod, signature-capture, order-completion, customer-notification, tracking-update] +**Source path:** `logistics/delivery-confirmation` +**Repo path:** `uncategorized/logistics/delivery-confirmation-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/logistics/delivery-confirmation-workflow/metadata.json b/uncategorized/logistics/delivery-confirmation-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..7f30a0e887beb489133c682c3420b4bebfce1ab1 --- /dev/null +++ b/uncategorized/logistics/delivery-confirmation-workflow/metadata.json @@ -0,0 +1,24 @@ +{ + "template_id": "delivery-confirmation-workflow", + "workflow_id": "delivery-confirmation", + "title": "Delivery Confirmation Workflow", + "kind": "workflow", + "source_domain": "logistics", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 2, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "delivery-confirmation", + "pod", + "signature-capture", + "order-completion", + "customer-notification", + "tracking-update" + ], + "description": "Delivery confirmation workflow with proof of delivery capture, signature collection, photo documentation, order status update, and customer notification.", + "source_path": "logistics/delivery-confirmation", + "repo_path": "uncategorized/logistics/delivery-confirmation-workflow" +} diff --git a/logistics/delivery-confirmation/workflow.fz b/uncategorized/logistics/delivery-confirmation-workflow/workflow.fz similarity index 100% rename from logistics/delivery-confirmation/workflow.fz rename to uncategorized/logistics/delivery-confirmation-workflow/workflow.fz diff --git a/uncategorized/logistics/inventory-receipt-workflow/README.md b/uncategorized/logistics/inventory-receipt-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..79951cfa37fab478c9cfdf26fbc6de243cc13fcd --- /dev/null +++ b/uncategorized/logistics/inventory-receipt-workflow/README.md @@ -0,0 +1,19 @@ +# Inventory Receipt Workflow + +Inventory receiving workflow with ASN verification, PO matching, quantity count, damage inspection, and WMS inventory update. + +**Template ID:** `inventory-receipt-workflow` +**Kind:** workflow +**Source domain:** logistics +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [inventory-receipt, goods-receiving, po-matching, asn-verification, dock-scheduling, wms] +**Source path:** `logistics/inventory-receipt` +**Repo path:** `uncategorized/logistics/inventory-receipt-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/logistics/inventory-receipt-workflow/metadata.json b/uncategorized/logistics/inventory-receipt-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..8459c012c4ed62814e1f827fff008dfa130eb56b --- /dev/null +++ b/uncategorized/logistics/inventory-receipt-workflow/metadata.json @@ -0,0 +1,24 @@ +{ + "template_id": "inventory-receipt-workflow", + "workflow_id": "inventory-receipt", + "title": "Inventory Receipt Workflow", + "kind": "workflow", + "source_domain": "logistics", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "inventory-receipt", + "goods-receiving", + "po-matching", + "asn-verification", + "dock-scheduling", + "wms" + ], + "description": "Inventory receiving workflow with ASN verification, PO matching, quantity count, damage inspection, and WMS inventory update.", + "source_path": "logistics/inventory-receipt", + "repo_path": "uncategorized/logistics/inventory-receipt-workflow" +} diff --git a/logistics/inventory-receipt/workflow.fz b/uncategorized/logistics/inventory-receipt-workflow/workflow.fz similarity index 100% rename from logistics/inventory-receipt/workflow.fz rename to uncategorized/logistics/inventory-receipt-workflow/workflow.fz diff --git a/uncategorized/logistics/kitting-process-workflow/README.md b/uncategorized/logistics/kitting-process-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..e89f1c2ece1e47efb682485422a6b5d98619c4b0 --- /dev/null +++ b/uncategorized/logistics/kitting-process-workflow/README.md @@ -0,0 +1,19 @@ +# Kitting Process Workflow + +Kit assembly workflow with BOM explosion, component picking, assembly verification, kit labeling, and inventory conversion from components to finished kit. + +**Template ID:** `kitting-process-workflow` +**Kind:** workflow +**Source domain:** logistics +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 2/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [kitting-process, kit-assembly, bom, component-picking, value-added-services, bundling] +**Source path:** `logistics/kitting-process` +**Repo path:** `uncategorized/logistics/kitting-process-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/logistics/kitting-process-workflow/metadata.json b/uncategorized/logistics/kitting-process-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..1b772119ed7afea7a52cf74e26ff2b4ee146a325 --- /dev/null +++ b/uncategorized/logistics/kitting-process-workflow/metadata.json @@ -0,0 +1,24 @@ +{ + "template_id": "kitting-process-workflow", + "workflow_id": "kitting-process", + "title": "Kitting Process Workflow", + "kind": "workflow", + "source_domain": "logistics", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 2, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "kitting-process", + "kit-assembly", + "bom", + "component-picking", + "value-added-services", + "bundling" + ], + "description": "Kit assembly workflow with BOM explosion, component picking, assembly verification, kit labeling, and inventory conversion from components to finished kit.", + "source_path": "logistics/kitting-process", + "repo_path": "uncategorized/logistics/kitting-process-workflow" +} diff --git a/logistics/kitting-process/workflow.fz b/uncategorized/logistics/kitting-process-workflow/workflow.fz similarity index 100% rename from logistics/kitting-process/workflow.fz rename to uncategorized/logistics/kitting-process-workflow/workflow.fz diff --git a/uncategorized/logistics/last-mile-delivery-workflow/README.md b/uncategorized/logistics/last-mile-delivery-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..6e0b787e14d7b90109988e321a6a0528e256ffd6 --- /dev/null +++ b/uncategorized/logistics/last-mile-delivery-workflow/README.md @@ -0,0 +1,19 @@ +# Last Mile Delivery Workflow + +Last mile delivery workflow with route optimization, real-time GPS tracking, delivery attempt handling, proof of delivery capture, and customer notification. + +**Template ID:** `last-mile-delivery-workflow` +**Kind:** workflow +**Source domain:** logistics +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [last-mile-delivery, route-optimization, proof-of-delivery, delivery-exception, customer-notification, gps-tracking] +**Source path:** `logistics/last-mile-delivery` +**Repo path:** `uncategorized/logistics/last-mile-delivery-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/logistics/last-mile-delivery-workflow/metadata.json b/uncategorized/logistics/last-mile-delivery-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..78e7fdea9006d8bfff3cb7fb10192c784e86c46f --- /dev/null +++ b/uncategorized/logistics/last-mile-delivery-workflow/metadata.json @@ -0,0 +1,24 @@ +{ + "template_id": "last-mile-delivery-workflow", + "workflow_id": "last-mile-delivery", + "title": "Last Mile Delivery Workflow", + "kind": "workflow", + "source_domain": "logistics", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "last-mile-delivery", + "route-optimization", + "proof-of-delivery", + "delivery-exception", + "customer-notification", + "gps-tracking" + ], + "description": "Last mile delivery workflow with route optimization, real-time GPS tracking, delivery attempt handling, proof of delivery capture, and customer notification.", + "source_path": "logistics/last-mile-delivery", + "repo_path": "uncategorized/logistics/last-mile-delivery-workflow" +} diff --git a/logistics/last-mile-delivery/workflow.fz b/uncategorized/logistics/last-mile-delivery-workflow/workflow.fz similarity index 100% rename from logistics/last-mile-delivery/workflow.fz rename to uncategorized/logistics/last-mile-delivery-workflow/workflow.fz diff --git a/uncategorized/logistics/packing-process-workflow/README.md b/uncategorized/logistics/packing-process-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..854d3c141cad116dfd56d38b565aa4683e70c1fc --- /dev/null +++ b/uncategorized/logistics/packing-process-workflow/README.md @@ -0,0 +1,19 @@ +# Packing Process Workflow + +Order packing workflow with carton selection, item verification, packing slip insertion, weight check, and package sealing for shipment. + +**Template ID:** `packing-process-workflow` +**Kind:** workflow +**Source domain:** logistics +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 2/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [order-packing, box-selection, packing-slip, weight-verification, cartonization, fulfillment] +**Source path:** `logistics/packing-process` +**Repo path:** `uncategorized/logistics/packing-process-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/logistics/packing-process-workflow/metadata.json b/uncategorized/logistics/packing-process-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..6f3ba8ce1f571b1b5f4417779012da6d90039dbc --- /dev/null +++ b/uncategorized/logistics/packing-process-workflow/metadata.json @@ -0,0 +1,24 @@ +{ + "template_id": "packing-process-workflow", + "workflow_id": "packing-process", + "title": "Packing Process Workflow", + "kind": "workflow", + "source_domain": "logistics", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 2, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "order-packing", + "box-selection", + "packing-slip", + "weight-verification", + "cartonization", + "fulfillment" + ], + "description": "Order packing workflow with carton selection, item verification, packing slip insertion, weight check, and package sealing for shipment.", + "source_path": "logistics/packing-process", + "repo_path": "uncategorized/logistics/packing-process-workflow" +} diff --git a/logistics/packing-process/workflow.fz b/uncategorized/logistics/packing-process-workflow/workflow.fz similarity index 100% rename from logistics/packing-process/workflow.fz rename to uncategorized/logistics/packing-process-workflow/workflow.fz diff --git a/uncategorized/logistics/picking-process-workflow/README.md b/uncategorized/logistics/picking-process-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..97a6133ff5d782c1e1ed91b15b6811b162bc4b15 --- /dev/null +++ b/uncategorized/logistics/picking-process-workflow/README.md @@ -0,0 +1,19 @@ +# Picking Process Workflow + +Warehouse order picking workflow with pick list generation, zone routing, batch picking optimization, barcode scanning verification, and pick completion confirmation. + +**Template ID:** `picking-process-workflow` +**Kind:** workflow +**Source domain:** logistics +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [order-picking, warehouse-management, pick-list, batch-picking, wave-picking, wms] +**Source path:** `logistics/picking-process` +**Repo path:** `uncategorized/logistics/picking-process-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/logistics/picking-process-workflow/metadata.json b/uncategorized/logistics/picking-process-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..d13559f917fd13cb37d09b7cc834d16256f07110 --- /dev/null +++ b/uncategorized/logistics/picking-process-workflow/metadata.json @@ -0,0 +1,24 @@ +{ + "template_id": "picking-process-workflow", + "workflow_id": "picking-process", + "title": "Picking Process Workflow", + "kind": "workflow", + "source_domain": "logistics", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "order-picking", + "warehouse-management", + "pick-list", + "batch-picking", + "wave-picking", + "wms" + ], + "description": "Warehouse order picking workflow with pick list generation, zone routing, batch picking optimization, barcode scanning verification, and pick completion confirmation.", + "source_path": "logistics/picking-process", + "repo_path": "uncategorized/logistics/picking-process-workflow" +} diff --git a/logistics/picking-process/workflow.fz b/uncategorized/logistics/picking-process-workflow/workflow.fz similarity index 100% rename from logistics/picking-process/workflow.fz rename to uncategorized/logistics/picking-process-workflow/workflow.fz diff --git a/uncategorized/logistics/put-away-process-workflow/README.md b/uncategorized/logistics/put-away-process-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..12455e5d82564f64a6841355bdfd8c09b97d412b --- /dev/null +++ b/uncategorized/logistics/put-away-process-workflow/README.md @@ -0,0 +1,19 @@ +# Put Away Process Workflow + +Warehouse put-away workflow with location assignment, slotting optimization, forklift routing, barcode confirmation, and WMS location update. + +**Template ID:** `put-away-process-workflow` +**Kind:** workflow +**Source domain:** logistics +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 2/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [put-away, warehouse-storage, location-assignment, slotting, wms, inventory-placement] +**Source path:** `logistics/put-away-process` +**Repo path:** `uncategorized/logistics/put-away-process-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/logistics/put-away-process-workflow/metadata.json b/uncategorized/logistics/put-away-process-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..7a4efc5025de27693bc664d1bd2d00ab03cac7ec --- /dev/null +++ b/uncategorized/logistics/put-away-process-workflow/metadata.json @@ -0,0 +1,24 @@ +{ + "template_id": "put-away-process-workflow", + "workflow_id": "put-away-process", + "title": "Put Away Process Workflow", + "kind": "workflow", + "source_domain": "logistics", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 2, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "put-away", + "warehouse-storage", + "location-assignment", + "slotting", + "wms", + "inventory-placement" + ], + "description": "Warehouse put-away workflow with location assignment, slotting optimization, forklift routing, barcode confirmation, and WMS location update.", + "source_path": "logistics/put-away-process", + "repo_path": "uncategorized/logistics/put-away-process-workflow" +} diff --git a/logistics/put-away-process/workflow.fz b/uncategorized/logistics/put-away-process-workflow/workflow.fz similarity index 100% rename from logistics/put-away-process/workflow.fz rename to uncategorized/logistics/put-away-process-workflow/workflow.fz diff --git a/uncategorized/logistics/quality-inspection-workflow/README.md b/uncategorized/logistics/quality-inspection-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..f5314e331c2bdf4c21a825494ff66bd0c849fadc --- /dev/null +++ b/uncategorized/logistics/quality-inspection-workflow/README.md @@ -0,0 +1,19 @@ +# Quality Inspection Workflow + +Incoming quality inspection workflow with AQL sampling, defect classification, hold/release decision, supplier notification, and quality metrics tracking. + +**Template ID:** `quality-inspection-workflow` +**Kind:** workflow +**Source domain:** logistics +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [quality-inspection, incoming-inspection, aql-sampling, defect-tracking, supplier-quality, hold-release] +**Source path:** `logistics/quality-inspection` +**Repo path:** `uncategorized/logistics/quality-inspection-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/logistics/quality-inspection-workflow/metadata.json b/uncategorized/logistics/quality-inspection-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..261cde225e72266277f9c8410678eb650cddc565 --- /dev/null +++ b/uncategorized/logistics/quality-inspection-workflow/metadata.json @@ -0,0 +1,24 @@ +{ + "template_id": "quality-inspection-workflow", + "workflow_id": "quality-inspection", + "title": "Quality Inspection Workflow", + "kind": "workflow", + "source_domain": "logistics", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "quality-inspection", + "incoming-inspection", + "aql-sampling", + "defect-tracking", + "supplier-quality", + "hold-release" + ], + "description": "Incoming quality inspection workflow with AQL sampling, defect classification, hold/release decision, supplier notification, and quality metrics tracking.", + "source_path": "logistics/quality-inspection", + "repo_path": "uncategorized/logistics/quality-inspection-workflow" +} diff --git a/logistics/quality-inspection/workflow.fz b/uncategorized/logistics/quality-inspection-workflow/workflow.fz similarity index 100% rename from logistics/quality-inspection/workflow.fz rename to uncategorized/logistics/quality-inspection-workflow/workflow.fz diff --git a/uncategorized/logistics/reorder-process-workflow/README.md b/uncategorized/logistics/reorder-process-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..a4df0169372a05434f93472e829e5f1059e23bb3 --- /dev/null +++ b/uncategorized/logistics/reorder-process-workflow/README.md @@ -0,0 +1,19 @@ +# Reorder Process Workflow + +Inventory reorder workflow with reorder point monitoring, economic order quantity calculation, safety stock consideration, and automatic purchase requisition generation. + +**Template ID:** `reorder-process-workflow` +**Kind:** workflow +**Source domain:** logistics +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [reorder-process, reorder-point, safety-stock, eoq, demand-planning, auto-replenishment] +**Source path:** `logistics/reorder-process` +**Repo path:** `uncategorized/logistics/reorder-process-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/logistics/reorder-process-workflow/metadata.json b/uncategorized/logistics/reorder-process-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..0e3a6ca7cce162c1f7cbe65a6a77cf9f831c57d1 --- /dev/null +++ b/uncategorized/logistics/reorder-process-workflow/metadata.json @@ -0,0 +1,24 @@ +{ + "template_id": "reorder-process-workflow", + "workflow_id": "reorder-process", + "title": "Reorder Process Workflow", + "kind": "workflow", + "source_domain": "logistics", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "reorder-process", + "reorder-point", + "safety-stock", + "eoq", + "demand-planning", + "auto-replenishment" + ], + "description": "Inventory reorder workflow with reorder point monitoring, economic order quantity calculation, safety stock consideration, and automatic purchase requisition generation.", + "source_path": "logistics/reorder-process", + "repo_path": "uncategorized/logistics/reorder-process-workflow" +} diff --git a/logistics/reorder-process/workflow.fz b/uncategorized/logistics/reorder-process-workflow/workflow.fz similarity index 100% rename from logistics/reorder-process/workflow.fz rename to uncategorized/logistics/reorder-process-workflow/workflow.fz diff --git a/uncategorized/logistics/reverse-logistics-workflow/README.md b/uncategorized/logistics/reverse-logistics-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..e82b0e1be6ff6b40ec66fd08defc3e85d07beb0b --- /dev/null +++ b/uncategorized/logistics/reverse-logistics-workflow/README.md @@ -0,0 +1,19 @@ +# Reverse Logistics Workflow + +Reverse logistics workflow with return authorization, product grading, refurbishment decision, recycling coordination, and secondary market disposition. + +**Template ID:** `reverse-logistics-workflow` +**Kind:** workflow +**Source domain:** logistics +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [reverse-logistics, product-returns, refurbishment, recycling, disposition, sustainability] +**Source path:** `logistics/reverse-logistics` +**Repo path:** `uncategorized/logistics/reverse-logistics-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/logistics/reverse-logistics-workflow/metadata.json b/uncategorized/logistics/reverse-logistics-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..347836bfda17d8e264f2e834d331fe26199f2409 --- /dev/null +++ b/uncategorized/logistics/reverse-logistics-workflow/metadata.json @@ -0,0 +1,24 @@ +{ + "template_id": "reverse-logistics-workflow", + "workflow_id": "reverse-logistics", + "title": "Reverse Logistics Workflow", + "kind": "workflow", + "source_domain": "logistics", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "reverse-logistics", + "product-returns", + "refurbishment", + "recycling", + "disposition", + "sustainability" + ], + "description": "Reverse logistics workflow with return authorization, product grading, refurbishment decision, recycling coordination, and secondary market disposition.", + "source_path": "logistics/reverse-logistics", + "repo_path": "uncategorized/logistics/reverse-logistics-workflow" +} diff --git a/logistics/reverse-logistics/workflow.fz b/uncategorized/logistics/reverse-logistics-workflow/workflow.fz similarity index 100% rename from logistics/reverse-logistics/workflow.fz rename to uncategorized/logistics/reverse-logistics-workflow/workflow.fz diff --git a/uncategorized/patterns/a-b-testing-workflow/README.md b/uncategorized/patterns/a-b-testing-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..7c9fc7df75ad43b226d15f03946240a4caa35260 --- /dev/null +++ b/uncategorized/patterns/a-b-testing-workflow/README.md @@ -0,0 +1,19 @@ +# A B Testing Workflow + +This workflow models comparing two versions to see which performs better. + +**Template ID:** `a-b-testing-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [a, b, testing, patterns] +**Source path:** `patterns/a-b-testing` +**Repo path:** `uncategorized/patterns/a-b-testing-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/a-b-testing-workflow/metadata.json b/uncategorized/patterns/a-b-testing-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..46d48182328e8ec0d43bbd858ced4ab33fec551a --- /dev/null +++ b/uncategorized/patterns/a-b-testing-workflow/metadata.json @@ -0,0 +1,22 @@ +{ + "template_id": "a-b-testing-workflow", + "workflow_id": "a-b-testing", + "title": "A B Testing Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "a", + "b", + "testing", + "patterns" + ], + "description": "This workflow models comparing two versions to see which performs better.", + "source_path": "patterns/a-b-testing", + "repo_path": "uncategorized/patterns/a-b-testing-workflow" +} diff --git a/patterns/a-b-testing/workflow.fz b/uncategorized/patterns/a-b-testing-workflow/workflow.fz similarity index 100% rename from patterns/a-b-testing/workflow.fz rename to uncategorized/patterns/a-b-testing-workflow/workflow.fz diff --git a/uncategorized/patterns/batch-processing-workflow/README.md b/uncategorized/patterns/batch-processing-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..eee02302a430483c7c4948c1fe4c7efb368138d0 --- /dev/null +++ b/uncategorized/patterns/batch-processing-workflow/README.md @@ -0,0 +1,19 @@ +# Batch Processing Workflow + +Batch processing pattern with job scheduling, chunk-based processing, checkpoint/restart capability, error handling, and completion reporting. + +**Template ID:** `batch-processing-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [batch-processing, scheduled-jobs, bulk-operations, etl, chunk-processing, job-scheduler] +**Source path:** `patterns/batch-processing` +**Repo path:** `uncategorized/patterns/batch-processing-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/batch-processing-workflow/metadata.json b/uncategorized/patterns/batch-processing-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..9ad4ffbc33ea35b808a5086f5ddd86f1af4941a1 --- /dev/null +++ b/uncategorized/patterns/batch-processing-workflow/metadata.json @@ -0,0 +1,24 @@ +{ + "template_id": "batch-processing-workflow", + "workflow_id": "batch-processing", + "title": "Batch Processing Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "batch-processing", + "scheduled-jobs", + "bulk-operations", + "etl", + "chunk-processing", + "job-scheduler" + ], + "description": "Batch processing pattern with job scheduling, chunk-based processing, checkpoint/restart capability, error handling, and completion reporting.", + "source_path": "patterns/batch-processing", + "repo_path": "uncategorized/patterns/batch-processing-workflow" +} diff --git a/patterns/batch-processing/workflow.fz b/uncategorized/patterns/batch-processing-workflow/workflow.fz similarity index 100% rename from patterns/batch-processing/workflow.fz rename to uncategorized/patterns/batch-processing-workflow/workflow.fz diff --git a/uncategorized/patterns/cache-aside-workflow/README.md b/uncategorized/patterns/cache-aside-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..1cae4c99c0bbc4e6d7b37631e76eb40bb3229369 --- /dev/null +++ b/uncategorized/patterns/cache-aside-workflow/README.md @@ -0,0 +1,19 @@ +# Cache Aside Workflow + +Cache-aside pattern with cache lookup, database fallback on miss, cache population, TTL-based expiration, and write-through invalidation. + +**Template ID:** `cache-aside-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [cache-aside, lazy-loading, cache-miss, cache-invalidation, redis, performance] +**Source path:** `patterns/cache-aside` +**Repo path:** `uncategorized/patterns/cache-aside-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/cache-aside-workflow/metadata.json b/uncategorized/patterns/cache-aside-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..187ae225d2a91586e201b600ee49889fca04e297 --- /dev/null +++ b/uncategorized/patterns/cache-aside-workflow/metadata.json @@ -0,0 +1,24 @@ +{ + "template_id": "cache-aside-workflow", + "workflow_id": "cache-aside", + "title": "Cache Aside Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "cache-aside", + "lazy-loading", + "cache-miss", + "cache-invalidation", + "redis", + "performance" + ], + "description": "Cache-aside pattern with cache lookup, database fallback on miss, cache population, TTL-based expiration, and write-through invalidation.", + "source_path": "patterns/cache-aside", + "repo_path": "uncategorized/patterns/cache-aside-workflow" +} diff --git a/patterns/cache-aside/workflow.fz b/uncategorized/patterns/cache-aside-workflow/workflow.fz similarity index 100% rename from patterns/cache-aside/workflow.fz rename to uncategorized/patterns/cache-aside-workflow/workflow.fz diff --git a/uncategorized/patterns/callback-pattern-workflow/README.md b/uncategorized/patterns/callback-pattern-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..8e040aa77ba0d9c03379867bdc18683f291f51b9 --- /dev/null +++ b/uncategorized/patterns/callback-pattern-workflow/README.md @@ -0,0 +1,19 @@ +# Callback Pattern Workflow + +This workflow models an async operation that notifies a callback when done. + +**Template ID:** `callback-pattern-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [callback, pattern, patterns, decision, loop] +**Source path:** `patterns/callback-pattern` +**Repo path:** `uncategorized/patterns/callback-pattern-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/callback-pattern-workflow/metadata.json b/uncategorized/patterns/callback-pattern-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..de08922a5c542c21bc39191099e19c2f35f3cce3 --- /dev/null +++ b/uncategorized/patterns/callback-pattern-workflow/metadata.json @@ -0,0 +1,23 @@ +{ + "template_id": "callback-pattern-workflow", + "workflow_id": "callback-pattern", + "title": "Callback Pattern Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "callback", + "pattern", + "patterns", + "decision", + "loop" + ], + "description": "This workflow models an async operation that notifies a callback when done.", + "source_path": "patterns/callback-pattern", + "repo_path": "uncategorized/patterns/callback-pattern-workflow" +} diff --git a/patterns/callback-pattern/workflow.fz b/uncategorized/patterns/callback-pattern-workflow/workflow.fz similarity index 100% rename from patterns/callback-pattern/workflow.fz rename to uncategorized/patterns/callback-pattern-workflow/workflow.fz diff --git a/uncategorized/patterns/claim-check-workflow/README.md b/uncategorized/patterns/claim-check-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..935f36357ef8688a29ef46864b1a1b2aa82af346 --- /dev/null +++ b/uncategorized/patterns/claim-check-workflow/README.md @@ -0,0 +1,19 @@ +# Claim Check Workflow + +This workflow models keeping large payloads external and only passing references. + +**Template ID:** `claim-check-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 2/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [claim, check, patterns] +**Source path:** `patterns/claim-check` +**Repo path:** `uncategorized/patterns/claim-check-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/claim-check-workflow/metadata.json b/uncategorized/patterns/claim-check-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..f869e34f7263622764016419a25fd09d48f7cd46 --- /dev/null +++ b/uncategorized/patterns/claim-check-workflow/metadata.json @@ -0,0 +1,21 @@ +{ + "template_id": "claim-check-workflow", + "workflow_id": "claim-check", + "title": "Claim Check Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 2, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "claim", + "check", + "patterns" + ], + "description": "This workflow models keeping large payloads external and only passing references.", + "source_path": "patterns/claim-check", + "repo_path": "uncategorized/patterns/claim-check-workflow" +} diff --git a/patterns/claim-check/workflow.fz b/uncategorized/patterns/claim-check-workflow/workflow.fz similarity index 100% rename from patterns/claim-check/workflow.fz rename to uncategorized/patterns/claim-check-workflow/workflow.fz diff --git a/uncategorized/patterns/compensation-transaction-workflow/README.md b/uncategorized/patterns/compensation-transaction-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..0f7784f4724670dc0217dd1fca401c586e785f2e --- /dev/null +++ b/uncategorized/patterns/compensation-transaction-workflow/README.md @@ -0,0 +1,19 @@ +# Compensation Transaction Workflow + +This workflow models rolling back work when a later step fails. + +**Template ID:** `compensation-transaction-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 2/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [compensation, transaction, patterns, decision, loop] +**Source path:** `patterns/compensation-transaction` +**Repo path:** `uncategorized/patterns/compensation-transaction-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/compensation-transaction-workflow/metadata.json b/uncategorized/patterns/compensation-transaction-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..40e19b0572c974652d9d70acea03153f282e4ccd --- /dev/null +++ b/uncategorized/patterns/compensation-transaction-workflow/metadata.json @@ -0,0 +1,23 @@ +{ + "template_id": "compensation-transaction-workflow", + "workflow_id": "compensation-transaction", + "title": "Compensation Transaction Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 2, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "compensation", + "transaction", + "patterns", + "decision", + "loop" + ], + "description": "This workflow models rolling back work when a later step fails.", + "source_path": "patterns/compensation-transaction", + "repo_path": "uncategorized/patterns/compensation-transaction-workflow" +} diff --git a/patterns/compensation-transaction/workflow.fz b/uncategorized/patterns/compensation-transaction-workflow/workflow.fz similarity index 100% rename from patterns/compensation-transaction/workflow.fz rename to uncategorized/patterns/compensation-transaction-workflow/workflow.fz diff --git a/uncategorized/patterns/content-enricher-workflow/README.md b/uncategorized/patterns/content-enricher-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..21a0cb2be35d97ad3d7c30ebd61f649846dfee7a --- /dev/null +++ b/uncategorized/patterns/content-enricher-workflow/README.md @@ -0,0 +1,19 @@ +# Content Enricher Workflow + +This workflow models adding extra data from other sources. + +**Template ID:** `content-enricher-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [content, enricher, patterns, decision] +**Source path:** `patterns/content-enricher` +**Repo path:** `uncategorized/patterns/content-enricher-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/content-enricher-workflow/metadata.json b/uncategorized/patterns/content-enricher-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..78cef77c80b5be5709ba2ff16266f6bfcfd4a30b --- /dev/null +++ b/uncategorized/patterns/content-enricher-workflow/metadata.json @@ -0,0 +1,22 @@ +{ + "template_id": "content-enricher-workflow", + "workflow_id": "content-enricher", + "title": "Content Enricher Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "content", + "enricher", + "patterns", + "decision" + ], + "description": "This workflow models adding extra data from other sources.", + "source_path": "patterns/content-enricher", + "repo_path": "uncategorized/patterns/content-enricher-workflow" +} diff --git a/patterns/content-enricher/workflow.fz b/uncategorized/patterns/content-enricher-workflow/workflow.fz similarity index 100% rename from patterns/content-enricher/workflow.fz rename to uncategorized/patterns/content-enricher-workflow/workflow.fz diff --git a/uncategorized/patterns/cqrs-workflow/README.md b/uncategorized/patterns/cqrs-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..6c4e32c9c466c7ba2e1da653e17dc561502b702f --- /dev/null +++ b/uncategorized/patterns/cqrs-workflow/README.md @@ -0,0 +1,19 @@ +# Cqrs Workflow + +CQRS (Command Query Responsibility Segregation) pattern with separate command and query paths, domain event publishing, read model synchronization, and DTO transformation. + +**Template ID:** `cqrs-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 19 +**Lanes:** 4 +**Tags:** [cqrs, command-query-separation, event-sourcing, read-model, write-model, domain-events, eventual-consistency] +**Source path:** `patterns/cqrs` +**Repo path:** `uncategorized/patterns/cqrs-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/patterns/cqrs/metadata.json b/uncategorized/patterns/cqrs-workflow/metadata.json similarity index 51% rename from patterns/cqrs/metadata.json rename to uncategorized/patterns/cqrs-workflow/metadata.json index 787eb0023514e9beb9151859611f30c1df092f53..8e2f6217e42ad466f8771ca864593303cc04bb21 100644 --- a/patterns/cqrs/metadata.json +++ b/uncategorized/patterns/cqrs-workflow/metadata.json @@ -1,6 +1,12 @@ { + "template_id": "cqrs-workflow", "workflow_id": "cqrs", - "domain": "patterns", + "title": "Cqrs Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], "complexity": 4, "num_nodes": 19, "num_lanes": 4, @@ -13,5 +19,7 @@ "domain-events", "eventual-consistency" ], - "description": "CQRS (Command Query Responsibility Segregation) pattern with separate command and query paths, domain event publishing, read model synchronization, and DTO transformation." -} \ No newline at end of file + "description": "CQRS (Command Query Responsibility Segregation) pattern with separate command and query paths, domain event publishing, read model synchronization, and DTO transformation.", + "source_path": "patterns/cqrs", + "repo_path": "uncategorized/patterns/cqrs-workflow" +} diff --git a/patterns/cqrs/workflow.fz b/uncategorized/patterns/cqrs-workflow/workflow.fz similarity index 100% rename from patterns/cqrs/workflow.fz rename to uncategorized/patterns/cqrs-workflow/workflow.fz diff --git a/uncategorized/patterns/crud-user-browser-server-workflow/README.md b/uncategorized/patterns/crud-user-browser-server-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..c2c011a793184de32b5739a87c5860e20ae9f724 --- /dev/null +++ b/uncategorized/patterns/crud-user-browser-server-workflow/README.md @@ -0,0 +1,19 @@ +# Crud User Browser Server Workflow + +This workflow models user creates, reads, updates, and deletes data through a browser and server. + +**Template ID:** `crud-user-browser-server-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 2/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [crud, user, browser, server, patterns] +**Source path:** `patterns/crud-user-browser-server` +**Repo path:** `uncategorized/patterns/crud-user-browser-server-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/crud-user-browser-server-workflow/metadata.json b/uncategorized/patterns/crud-user-browser-server-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..32be813406aa4828253f8b71f30dd1ca631a4e8c --- /dev/null +++ b/uncategorized/patterns/crud-user-browser-server-workflow/metadata.json @@ -0,0 +1,23 @@ +{ + "template_id": "crud-user-browser-server-workflow", + "workflow_id": "crud-user-browser-server", + "title": "Crud User Browser Server Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 2, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "crud", + "user", + "browser", + "server", + "patterns" + ], + "description": "This workflow models user creates, reads, updates, and deletes data through a browser and server.", + "source_path": "patterns/crud-user-browser-server", + "repo_path": "uncategorized/patterns/crud-user-browser-server-workflow" +} diff --git a/patterns/crud-user-browser-server/workflow.fz b/uncategorized/patterns/crud-user-browser-server-workflow/workflow.fz similarity index 100% rename from patterns/crud-user-browser-server/workflow.fz rename to uncategorized/patterns/crud-user-browser-server-workflow/workflow.fz diff --git a/uncategorized/patterns/dead-letter-queue-workflow/README.md b/uncategorized/patterns/dead-letter-queue-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..d5045f98e99afe3827ac43297275aa3f3a9265e1 --- /dev/null +++ b/uncategorized/patterns/dead-letter-queue-workflow/README.md @@ -0,0 +1,19 @@ +# Dead Letter Queue Workflow + +Dead letter queue pattern for handling failed messages with retry exhaustion detection, DLQ routing, manual inspection, and reprocessing capability. + +**Template ID:** `dead-letter-queue-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [dead-letter-queue, dlq, message-retry, poison-message, error-handling, message-queue] +**Source path:** `patterns/dead-letter-queue` +**Repo path:** `uncategorized/patterns/dead-letter-queue-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/dead-letter-queue-workflow/metadata.json b/uncategorized/patterns/dead-letter-queue-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..74285a08dd41426229d427db51f08b55ddb260ca --- /dev/null +++ b/uncategorized/patterns/dead-letter-queue-workflow/metadata.json @@ -0,0 +1,24 @@ +{ + "template_id": "dead-letter-queue-workflow", + "workflow_id": "dead-letter-queue", + "title": "Dead Letter Queue Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "dead-letter-queue", + "dlq", + "message-retry", + "poison-message", + "error-handling", + "message-queue" + ], + "description": "Dead letter queue pattern for handling failed messages with retry exhaustion detection, DLQ routing, manual inspection, and reprocessing capability.", + "source_path": "patterns/dead-letter-queue", + "repo_path": "uncategorized/patterns/dead-letter-queue-workflow" +} diff --git a/patterns/dead-letter-queue/workflow.fz b/uncategorized/patterns/dead-letter-queue-workflow/workflow.fz similarity index 100% rename from patterns/dead-letter-queue/workflow.fz rename to uncategorized/patterns/dead-letter-queue-workflow/workflow.fz diff --git a/uncategorized/patterns/decision-diamond-workflow/README.md b/uncategorized/patterns/decision-diamond-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..68a4ea16fbd38a1443220e4733310eef768dc7d0 --- /dev/null +++ b/uncategorized/patterns/decision-diamond-workflow/README.md @@ -0,0 +1,19 @@ +# Decision Diamond Workflow + +This workflow models an if or then style branch for approval or rejection. + +**Template ID:** `decision-diamond-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [decision, diamond, patterns] +**Source path:** `patterns/decision-diamond` +**Repo path:** `uncategorized/patterns/decision-diamond-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/decision-diamond-workflow/metadata.json b/uncategorized/patterns/decision-diamond-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..1bf3f9b897f5ea519547e721c3b97c552b49a44d --- /dev/null +++ b/uncategorized/patterns/decision-diamond-workflow/metadata.json @@ -0,0 +1,21 @@ +{ + "template_id": "decision-diamond-workflow", + "workflow_id": "decision-diamond", + "title": "Decision Diamond Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "decision", + "diamond", + "patterns" + ], + "description": "This workflow models an if or then style branch for approval or rejection.", + "source_path": "patterns/decision-diamond", + "repo_path": "uncategorized/patterns/decision-diamond-workflow" +} diff --git a/patterns/decision-diamond/workflow.fz b/uncategorized/patterns/decision-diamond-workflow/workflow.fz similarity index 100% rename from patterns/decision-diamond/workflow.fz rename to uncategorized/patterns/decision-diamond-workflow/workflow.fz diff --git a/uncategorized/patterns/enricher-workflow/README.md b/uncategorized/patterns/enricher-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..223e0ba73092b99ebc0f69714faba373d59ec752 --- /dev/null +++ b/uncategorized/patterns/enricher-workflow/README.md @@ -0,0 +1,19 @@ +# Enricher Workflow + +This workflow models adding metadata to messages before passing them on. + +**Template ID:** `enricher-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [enricher, patterns] +**Source path:** `patterns/enricher` +**Repo path:** `uncategorized/patterns/enricher-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/enricher-workflow/metadata.json b/uncategorized/patterns/enricher-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..36959f5a987e3bb0b168ae61025f4a3903c4ceca --- /dev/null +++ b/uncategorized/patterns/enricher-workflow/metadata.json @@ -0,0 +1,20 @@ +{ + "template_id": "enricher-workflow", + "workflow_id": "enricher", + "title": "Enricher Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "enricher", + "patterns" + ], + "description": "This workflow models adding metadata to messages before passing them on.", + "source_path": "patterns/enricher", + "repo_path": "uncategorized/patterns/enricher-workflow" +} diff --git a/patterns/enricher/workflow.fz b/uncategorized/patterns/enricher-workflow/workflow.fz similarity index 100% rename from patterns/enricher/workflow.fz rename to uncategorized/patterns/enricher-workflow/workflow.fz diff --git a/uncategorized/patterns/error-retry-loop-workflow/README.md b/uncategorized/patterns/error-retry-loop-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..3b9613e2c66b50c9ce326316cf770f57af01b02e --- /dev/null +++ b/uncategorized/patterns/error-retry-loop-workflow/README.md @@ -0,0 +1,19 @@ +# Error Retry Loop Workflow + +This workflow models a failed operation that retries with backoff. + +**Template ID:** `error-retry-loop-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 2/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [error, retry, loop, patterns] +**Source path:** `patterns/error-retry-loop` +**Repo path:** `uncategorized/patterns/error-retry-loop-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/error-retry-loop-workflow/metadata.json b/uncategorized/patterns/error-retry-loop-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..103ab50ec2ab78e1ab3f29b5347842daca273821 --- /dev/null +++ b/uncategorized/patterns/error-retry-loop-workflow/metadata.json @@ -0,0 +1,22 @@ +{ + "template_id": "error-retry-loop-workflow", + "workflow_id": "error-retry-loop", + "title": "Error Retry Loop Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 2, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "error", + "retry", + "loop", + "patterns" + ], + "description": "This workflow models a failed operation that retries with backoff.", + "source_path": "patterns/error-retry-loop", + "repo_path": "uncategorized/patterns/error-retry-loop-workflow" +} diff --git a/patterns/error-retry-loop/workflow.fz b/uncategorized/patterns/error-retry-loop-workflow/workflow.fz similarity index 100% rename from patterns/error-retry-loop/workflow.fz rename to uncategorized/patterns/error-retry-loop-workflow/workflow.fz diff --git a/uncategorized/patterns/event-driven-workflow/README.md b/uncategorized/patterns/event-driven-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..caa62fa6aff51ecaaf4854ef730190a9557ccad7 --- /dev/null +++ b/uncategorized/patterns/event-driven-workflow/README.md @@ -0,0 +1,19 @@ +# Event Driven Workflow + +This workflow models reacting to incoming business events. + +**Template ID:** `event-driven-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [event, driven, patterns] +**Source path:** `patterns/event-driven` +**Repo path:** `uncategorized/patterns/event-driven-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/event-driven-workflow/metadata.json b/uncategorized/patterns/event-driven-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..d94b14e7e0dcb0c24735436461fd3d5541daf0eb --- /dev/null +++ b/uncategorized/patterns/event-driven-workflow/metadata.json @@ -0,0 +1,21 @@ +{ + "template_id": "event-driven-workflow", + "workflow_id": "event-driven", + "title": "Event Driven Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "event", + "driven", + "patterns" + ], + "description": "This workflow models reacting to incoming business events.", + "source_path": "patterns/event-driven", + "repo_path": "uncategorized/patterns/event-driven-workflow" +} diff --git a/patterns/event-driven/workflow.fz b/uncategorized/patterns/event-driven-workflow/workflow.fz similarity index 100% rename from patterns/event-driven/workflow.fz rename to uncategorized/patterns/event-driven-workflow/workflow.fz diff --git a/uncategorized/patterns/feature-toggle-workflow/README.md b/uncategorized/patterns/feature-toggle-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..80e9f8f945000eeea3735959b38f70d858ee79ef --- /dev/null +++ b/uncategorized/patterns/feature-toggle-workflow/README.md @@ -0,0 +1,19 @@ +# Feature Toggle Workflow + +Feature toggle pattern with flag configuration, user targeting rules, percentage rollouts, and instant kill-switch capability for production features. + +**Template ID:** `feature-toggle-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [feature-toggle, feature-flags, dark-launch, a-b-testing, gradual-rollout, kill-switch] +**Source path:** `patterns/feature-toggle` +**Repo path:** `uncategorized/patterns/feature-toggle-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/feature-toggle-workflow/metadata.json b/uncategorized/patterns/feature-toggle-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..c2df6403f349c7fd669d34b80039fa5e782589e0 --- /dev/null +++ b/uncategorized/patterns/feature-toggle-workflow/metadata.json @@ -0,0 +1,24 @@ +{ + "template_id": "feature-toggle-workflow", + "workflow_id": "feature-toggle", + "title": "Feature Toggle Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "feature-toggle", + "feature-flags", + "dark-launch", + "a-b-testing", + "gradual-rollout", + "kill-switch" + ], + "description": "Feature toggle pattern with flag configuration, user targeting rules, percentage rollouts, and instant kill-switch capability for production features.", + "source_path": "patterns/feature-toggle", + "repo_path": "uncategorized/patterns/feature-toggle-workflow" +} diff --git a/patterns/feature-toggle/workflow.fz b/uncategorized/patterns/feature-toggle-workflow/workflow.fz similarity index 100% rename from patterns/feature-toggle/workflow.fz rename to uncategorized/patterns/feature-toggle-workflow/workflow.fz diff --git a/uncategorized/patterns/filter-workflow/README.md b/uncategorized/patterns/filter-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..29d4101759d7d6bfa97474dd35970a8d946fbb3d --- /dev/null +++ b/uncategorized/patterns/filter-workflow/README.md @@ -0,0 +1,19 @@ +# Filter Workflow + +This workflow models removing items that do not meet criteria. + +**Template ID:** `filter-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 13 +**Lanes:** 4 +**Tags:** [filter, patterns, decision, loop] +**Source path:** `patterns/filter` +**Repo path:** `uncategorized/patterns/filter-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/filter-workflow/metadata.json b/uncategorized/patterns/filter-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..3c7e4f292397cb469c47372cc84416ef1f958d68 --- /dev/null +++ b/uncategorized/patterns/filter-workflow/metadata.json @@ -0,0 +1,22 @@ +{ + "template_id": "filter-workflow", + "workflow_id": "filter", + "title": "Filter Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 13, + "num_lanes": 4, + "tags": [ + "filter", + "patterns", + "decision", + "loop" + ], + "description": "This workflow models removing items that do not meet criteria.", + "source_path": "patterns/filter", + "repo_path": "uncategorized/patterns/filter-workflow" +} diff --git a/patterns/filter/workflow.fz b/uncategorized/patterns/filter-workflow/workflow.fz similarity index 100% rename from patterns/filter/workflow.fz rename to uncategorized/patterns/filter-workflow/workflow.fz diff --git a/uncategorized/patterns/idempotent-consumer-workflow/README.md b/uncategorized/patterns/idempotent-consumer-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..773ff45ebbbdf6e25af4a73e53ff6cd32d7f70fa --- /dev/null +++ b/uncategorized/patterns/idempotent-consumer-workflow/README.md @@ -0,0 +1,19 @@ +# Idempotent Consumer Workflow + +This workflow models processing each message safely only once. + +**Template ID:** `idempotent-consumer-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [idempotent, consumer, patterns] +**Source path:** `patterns/idempotent-consumer` +**Repo path:** `uncategorized/patterns/idempotent-consumer-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/idempotent-consumer-workflow/metadata.json b/uncategorized/patterns/idempotent-consumer-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..4065e37fdfd5f8ac934f464d585dce539ccdc63d --- /dev/null +++ b/uncategorized/patterns/idempotent-consumer-workflow/metadata.json @@ -0,0 +1,21 @@ +{ + "template_id": "idempotent-consumer-workflow", + "workflow_id": "idempotent-consumer", + "title": "Idempotent Consumer Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "idempotent", + "consumer", + "patterns" + ], + "description": "This workflow models processing each message safely only once.", + "source_path": "patterns/idempotent-consumer", + "repo_path": "uncategorized/patterns/idempotent-consumer-workflow" +} diff --git a/patterns/idempotent-consumer/workflow.fz b/uncategorized/patterns/idempotent-consumer-workflow/workflow.fz similarity index 100% rename from patterns/idempotent-consumer/workflow.fz rename to uncategorized/patterns/idempotent-consumer-workflow/workflow.fz diff --git a/uncategorized/patterns/materialized-view-workflow/README.md b/uncategorized/patterns/materialized-view-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..d65ce517cc86df8b7c997bb24477267ed93c3c8e --- /dev/null +++ b/uncategorized/patterns/materialized-view-workflow/README.md @@ -0,0 +1,19 @@ +# Materialized View Workflow + +This workflow models serving queries from a precomputed view. + +**Template ID:** `materialized-view-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 13 +**Lanes:** 4 +**Tags:** [materialized, view, patterns, decision, loop] +**Source path:** `patterns/materialized-view` +**Repo path:** `uncategorized/patterns/materialized-view-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/materialized-view-workflow/metadata.json b/uncategorized/patterns/materialized-view-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..ef4edebe763fb3b6d3fc8ebb26995700bcaca2e0 --- /dev/null +++ b/uncategorized/patterns/materialized-view-workflow/metadata.json @@ -0,0 +1,23 @@ +{ + "template_id": "materialized-view-workflow", + "workflow_id": "materialized-view", + "title": "Materialized View Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 13, + "num_lanes": 4, + "tags": [ + "materialized", + "view", + "patterns", + "decision", + "loop" + ], + "description": "This workflow models serving queries from a precomputed view.", + "source_path": "patterns/materialized-view", + "repo_path": "uncategorized/patterns/materialized-view-workflow" +} diff --git a/patterns/materialized-view/workflow.fz b/uncategorized/patterns/materialized-view-workflow/workflow.fz similarity index 100% rename from patterns/materialized-view/workflow.fz rename to uncategorized/patterns/materialized-view-workflow/workflow.fz diff --git a/uncategorized/patterns/message-queue-workflow/README.md b/uncategorized/patterns/message-queue-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..cf419f14cf3ecd45d0a2d6620c5e183dbed05781 --- /dev/null +++ b/uncategorized/patterns/message-queue-workflow/README.md @@ -0,0 +1,19 @@ +# Message Queue Workflow + +This workflow models asynchronous processing of work via a queue. + +**Template ID:** `message-queue-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [message, queue, patterns, decision] +**Source path:** `patterns/message-queue` +**Repo path:** `uncategorized/patterns/message-queue-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/message-queue-workflow/metadata.json b/uncategorized/patterns/message-queue-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..d7ba83a19fac5303f89d3fb0fc4a5657a1842aca --- /dev/null +++ b/uncategorized/patterns/message-queue-workflow/metadata.json @@ -0,0 +1,22 @@ +{ + "template_id": "message-queue-workflow", + "workflow_id": "message-queue", + "title": "Message Queue Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "message", + "queue", + "patterns", + "decision" + ], + "description": "This workflow models asynchronous processing of work via a queue.", + "source_path": "patterns/message-queue", + "repo_path": "uncategorized/patterns/message-queue-workflow" +} diff --git a/patterns/message-queue/workflow.fz b/uncategorized/patterns/message-queue-workflow/workflow.fz similarity index 100% rename from patterns/message-queue/workflow.fz rename to uncategorized/patterns/message-queue-workflow/workflow.fz diff --git a/uncategorized/patterns/nested-decisions-workflow/README.md b/uncategorized/patterns/nested-decisions-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..ea82031c9da9b20f4cb17be09c893f694a7f0c04 --- /dev/null +++ b/uncategorized/patterns/nested-decisions-workflow/README.md @@ -0,0 +1,19 @@ +# Nested Decisions Workflow + +This workflow models multiple layers of decisions before completion. + +**Template ID:** `nested-decisions-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [nested, decisions, patterns, decision, loop] +**Source path:** `patterns/nested-decisions` +**Repo path:** `uncategorized/patterns/nested-decisions-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/nested-decisions-workflow/metadata.json b/uncategorized/patterns/nested-decisions-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..7c1370fa48e50052d1e1f7cc8a4085e0d9f42378 --- /dev/null +++ b/uncategorized/patterns/nested-decisions-workflow/metadata.json @@ -0,0 +1,23 @@ +{ + "template_id": "nested-decisions-workflow", + "workflow_id": "nested-decisions", + "title": "Nested Decisions Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "nested", + "decisions", + "patterns", + "decision", + "loop" + ], + "description": "This workflow models multiple layers of decisions before completion.", + "source_path": "patterns/nested-decisions", + "repo_path": "uncategorized/patterns/nested-decisions-workflow" +} diff --git a/patterns/nested-decisions/workflow.fz b/uncategorized/patterns/nested-decisions-workflow/workflow.fz similarity index 100% rename from patterns/nested-decisions/workflow.fz rename to uncategorized/patterns/nested-decisions-workflow/workflow.fz diff --git a/uncategorized/patterns/normalizer-workflow/README.md b/uncategorized/patterns/normalizer-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..c03e24c6a4f47b4d6491306e41f01e25e395ab1b --- /dev/null +++ b/uncategorized/patterns/normalizer-workflow/README.md @@ -0,0 +1,19 @@ +# Normalizer Workflow + +This workflow models converting varied inputs to a standard format. + +**Template ID:** `normalizer-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 13 +**Lanes:** 4 +**Tags:** [normalizer, patterns] +**Source path:** `patterns/normalizer` +**Repo path:** `uncategorized/patterns/normalizer-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/normalizer-workflow/metadata.json b/uncategorized/patterns/normalizer-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..db5c02ab7aa6a133650095b3b93b48e601d28abc --- /dev/null +++ b/uncategorized/patterns/normalizer-workflow/metadata.json @@ -0,0 +1,20 @@ +{ + "template_id": "normalizer-workflow", + "workflow_id": "normalizer", + "title": "Normalizer Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 13, + "num_lanes": 4, + "tags": [ + "normalizer", + "patterns" + ], + "description": "This workflow models converting varied inputs to a standard format.", + "source_path": "patterns/normalizer", + "repo_path": "uncategorized/patterns/normalizer-workflow" +} diff --git a/patterns/normalizer/workflow.fz b/uncategorized/patterns/normalizer-workflow/workflow.fz similarity index 100% rename from patterns/normalizer/workflow.fz rename to uncategorized/patterns/normalizer-workflow/workflow.fz diff --git a/uncategorized/patterns/notification-pattern-workflow/README.md b/uncategorized/patterns/notification-pattern-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..f9044905c4a445783c6436dc40370091f810bc2a --- /dev/null +++ b/uncategorized/patterns/notification-pattern-workflow/README.md @@ -0,0 +1,19 @@ +# Notification Pattern Workflow + +This workflow models sending alerts via multiple channels. + +**Template ID:** `notification-pattern-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 2/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [notification, pattern, patterns] +**Source path:** `patterns/notification-pattern` +**Repo path:** `uncategorized/patterns/notification-pattern-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/notification-pattern-workflow/metadata.json b/uncategorized/patterns/notification-pattern-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..e3908f0596b7afda8d4bc44baf5e26181a3f7dfc --- /dev/null +++ b/uncategorized/patterns/notification-pattern-workflow/metadata.json @@ -0,0 +1,21 @@ +{ + "template_id": "notification-pattern-workflow", + "workflow_id": "notification-pattern", + "title": "Notification Pattern Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 2, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "notification", + "pattern", + "patterns" + ], + "description": "This workflow models sending alerts via multiple channels.", + "source_path": "patterns/notification-pattern", + "repo_path": "uncategorized/patterns/notification-pattern-workflow" +} diff --git a/patterns/notification-pattern/workflow.fz b/uncategorized/patterns/notification-pattern-workflow/workflow.fz similarity index 100% rename from patterns/notification-pattern/workflow.fz rename to uncategorized/patterns/notification-pattern-workflow/workflow.fz diff --git a/uncategorized/patterns/parallel-execution-workflow/README.md b/uncategorized/patterns/parallel-execution-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..4cc0f74cc8146112f09f3338fc2c8f671fb2a02e --- /dev/null +++ b/uncategorized/patterns/parallel-execution-workflow/README.md @@ -0,0 +1,19 @@ +# Parallel Execution Workflow + +This workflow models multiple tasks that run at the same time. + +**Template ID:** `parallel-execution-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 13 +**Lanes:** 4 +**Tags:** [parallel, execution, patterns, loop] +**Source path:** `patterns/parallel-execution` +**Repo path:** `uncategorized/patterns/parallel-execution-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/parallel-execution-workflow/metadata.json b/uncategorized/patterns/parallel-execution-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..790dadf2e43638c4d1a30da690fa5ec604eed6c7 --- /dev/null +++ b/uncategorized/patterns/parallel-execution-workflow/metadata.json @@ -0,0 +1,22 @@ +{ + "template_id": "parallel-execution-workflow", + "workflow_id": "parallel-execution", + "title": "Parallel Execution Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 13, + "num_lanes": 4, + "tags": [ + "parallel", + "execution", + "patterns", + "loop" + ], + "description": "This workflow models multiple tasks that run at the same time.", + "source_path": "patterns/parallel-execution", + "repo_path": "uncategorized/patterns/parallel-execution-workflow" +} diff --git a/patterns/parallel-execution/workflow.fz b/uncategorized/patterns/parallel-execution-workflow/workflow.fz similarity index 100% rename from patterns/parallel-execution/workflow.fz rename to uncategorized/patterns/parallel-execution-workflow/workflow.fz diff --git a/uncategorized/patterns/polling-pattern-workflow/README.md b/uncategorized/patterns/polling-pattern-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..87d65632d4cf611ab441d6f3b87e1667c662f3a3 --- /dev/null +++ b/uncategorized/patterns/polling-pattern-workflow/README.md @@ -0,0 +1,19 @@ +# Polling Pattern Workflow + +This workflow models periodically checking status until work is done. + +**Template ID:** `polling-pattern-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 13 +**Lanes:** 4 +**Tags:** [polling, pattern, patterns, loop] +**Source path:** `patterns/polling-pattern` +**Repo path:** `uncategorized/patterns/polling-pattern-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/polling-pattern-workflow/metadata.json b/uncategorized/patterns/polling-pattern-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..f86ef83d6850dafe37c38c58264e55a0a8adf19d --- /dev/null +++ b/uncategorized/patterns/polling-pattern-workflow/metadata.json @@ -0,0 +1,22 @@ +{ + "template_id": "polling-pattern-workflow", + "workflow_id": "polling-pattern", + "title": "Polling Pattern Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 13, + "num_lanes": 4, + "tags": [ + "polling", + "pattern", + "patterns", + "loop" + ], + "description": "This workflow models periodically checking status until work is done.", + "source_path": "patterns/polling-pattern", + "repo_path": "uncategorized/patterns/polling-pattern-workflow" +} diff --git a/patterns/polling-pattern/workflow.fz b/uncategorized/patterns/polling-pattern-workflow/workflow.fz similarity index 100% rename from patterns/polling-pattern/workflow.fz rename to uncategorized/patterns/polling-pattern-workflow/workflow.fz diff --git a/uncategorized/patterns/process-manager-workflow/README.md b/uncategorized/patterns/process-manager-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..d4cb3a251df6acf6ed97234424dcc51f3cd6acdc --- /dev/null +++ b/uncategorized/patterns/process-manager-workflow/README.md @@ -0,0 +1,19 @@ +# Process Manager Workflow + +This workflow models orchestrating multiple services to complete a process. + +**Template ID:** `process-manager-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [process, manager, patterns] +**Source path:** `patterns/process-manager` +**Repo path:** `uncategorized/patterns/process-manager-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/process-manager-workflow/metadata.json b/uncategorized/patterns/process-manager-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..eae901b971be588d31d1e9a7e3adad93260d71ca --- /dev/null +++ b/uncategorized/patterns/process-manager-workflow/metadata.json @@ -0,0 +1,21 @@ +{ + "template_id": "process-manager-workflow", + "workflow_id": "process-manager", + "title": "Process Manager Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "process", + "manager", + "patterns" + ], + "description": "This workflow models orchestrating multiple services to complete a process.", + "source_path": "patterns/process-manager", + "repo_path": "uncategorized/patterns/process-manager-workflow" +} diff --git a/patterns/process-manager/workflow.fz b/uncategorized/patterns/process-manager-workflow/workflow.fz similarity index 100% rename from patterns/process-manager/workflow.fz rename to uncategorized/patterns/process-manager-workflow/workflow.fz diff --git a/uncategorized/patterns/pub-sub-workflow/README.md b/uncategorized/patterns/pub-sub-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..da850162f3d3a51ff50e2ad1b2ccfb8340c4f44c --- /dev/null +++ b/uncategorized/patterns/pub-sub-workflow/README.md @@ -0,0 +1,19 @@ +# Pub Sub Workflow + +This workflow models one publisher notifying many subscribers of events. + +**Template ID:** `pub-sub-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 13 +**Lanes:** 4 +**Tags:** [pub, sub, patterns] +**Source path:** `patterns/pub-sub` +**Repo path:** `uncategorized/patterns/pub-sub-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/pub-sub-workflow/metadata.json b/uncategorized/patterns/pub-sub-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..fe487624001b0f1789c7553be996c082b70252bb --- /dev/null +++ b/uncategorized/patterns/pub-sub-workflow/metadata.json @@ -0,0 +1,21 @@ +{ + "template_id": "pub-sub-workflow", + "workflow_id": "pub-sub", + "title": "Pub Sub Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 13, + "num_lanes": 4, + "tags": [ + "pub", + "sub", + "patterns" + ], + "description": "This workflow models one publisher notifying many subscribers of events.", + "source_path": "patterns/pub-sub", + "repo_path": "uncategorized/patterns/pub-sub-workflow" +} diff --git a/patterns/pub-sub/workflow.fz b/uncategorized/patterns/pub-sub-workflow/workflow.fz similarity index 100% rename from patterns/pub-sub/workflow.fz rename to uncategorized/patterns/pub-sub-workflow/workflow.fz diff --git a/uncategorized/patterns/rate-limiter-workflow/README.md b/uncategorized/patterns/rate-limiter-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..334e2f781dab9fc42b3b1bc41746188a98e15d82 --- /dev/null +++ b/uncategorized/patterns/rate-limiter-workflow/README.md @@ -0,0 +1,19 @@ +# Rate Limiter Workflow + +This workflow models preventing too many requests from being processed. + +**Template ID:** `rate-limiter-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 13 +**Lanes:** 4 +**Tags:** [rate, limiter, patterns] +**Source path:** `patterns/rate-limiter` +**Repo path:** `uncategorized/patterns/rate-limiter-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/rate-limiter-workflow/metadata.json b/uncategorized/patterns/rate-limiter-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..fed1fb1b278f81b88bc22faf6d60a4287eaf8c6c --- /dev/null +++ b/uncategorized/patterns/rate-limiter-workflow/metadata.json @@ -0,0 +1,21 @@ +{ + "template_id": "rate-limiter-workflow", + "workflow_id": "rate-limiter", + "title": "Rate Limiter Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 13, + "num_lanes": 4, + "tags": [ + "rate", + "limiter", + "patterns" + ], + "description": "This workflow models preventing too many requests from being processed.", + "source_path": "patterns/rate-limiter", + "repo_path": "uncategorized/patterns/rate-limiter-workflow" +} diff --git a/patterns/rate-limiter/workflow.fz b/uncategorized/patterns/rate-limiter-workflow/workflow.fz similarity index 100% rename from patterns/rate-limiter/workflow.fz rename to uncategorized/patterns/rate-limiter-workflow/workflow.fz diff --git a/uncategorized/patterns/request-reply-workflow/README.md b/uncategorized/patterns/request-reply-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..de7360f04b3ed8598890a509de61505606d29a14 --- /dev/null +++ b/uncategorized/patterns/request-reply-workflow/README.md @@ -0,0 +1,19 @@ +# Request Reply Workflow + +This workflow models a synchronous request that waits for a reply. + +**Template ID:** `request-reply-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 2/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [request, reply, patterns] +**Source path:** `patterns/request-reply` +**Repo path:** `uncategorized/patterns/request-reply-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/request-reply-workflow/metadata.json b/uncategorized/patterns/request-reply-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..fe6872c6a3a8bada382b7645f67d70b75dca0b88 --- /dev/null +++ b/uncategorized/patterns/request-reply-workflow/metadata.json @@ -0,0 +1,21 @@ +{ + "template_id": "request-reply-workflow", + "workflow_id": "request-reply", + "title": "Request Reply Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 2, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "request", + "reply", + "patterns" + ], + "description": "This workflow models a synchronous request that waits for a reply.", + "source_path": "patterns/request-reply", + "repo_path": "uncategorized/patterns/request-reply-workflow" +} diff --git a/patterns/request-reply/workflow.fz b/uncategorized/patterns/request-reply-workflow/workflow.fz similarity index 100% rename from patterns/request-reply/workflow.fz rename to uncategorized/patterns/request-reply-workflow/workflow.fz diff --git a/uncategorized/patterns/retry-with-backoff-workflow/README.md b/uncategorized/patterns/retry-with-backoff-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..4a38e8e4a54a7fd8a2d1f68bd87275ec35af1de5 --- /dev/null +++ b/uncategorized/patterns/retry-with-backoff-workflow/README.md @@ -0,0 +1,19 @@ +# Retry With Backoff Workflow + +Exponential backoff retry pattern for API calls with configurable retry limits, delay calculation, retryable error detection, and graceful degradation on permanent failures. + +**Template ID:** `retry-with-backoff-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 20 +**Lanes:** 3 +**Tags:** [retry-pattern, exponential-backoff, fault-tolerance, api-resilience, transient-errors, http-retry, jitter] +**Source path:** `patterns/retry-with-backoff` +**Repo path:** `uncategorized/patterns/retry-with-backoff-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/patterns/retry-with-backoff/metadata.json b/uncategorized/patterns/retry-with-backoff-workflow/metadata.json similarity index 56% rename from patterns/retry-with-backoff/metadata.json rename to uncategorized/patterns/retry-with-backoff-workflow/metadata.json index b3d54571cdd698c212ce778641ae3c3781d20f7a..215d774a11b22b17925ae82a17633e5cd007c9cb 100644 --- a/patterns/retry-with-backoff/metadata.json +++ b/uncategorized/patterns/retry-with-backoff-workflow/metadata.json @@ -1,6 +1,12 @@ { + "template_id": "retry-with-backoff-workflow", "workflow_id": "retry-with-backoff", - "domain": "patterns", + "title": "Retry With Backoff Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], "complexity": 4, "num_nodes": 20, "num_lanes": 3, @@ -13,5 +19,7 @@ "http-retry", "jitter" ], - "description": "Exponential backoff retry pattern for API calls with configurable retry limits, delay calculation, retryable error detection, and graceful degradation on permanent failures." -} \ No newline at end of file + "description": "Exponential backoff retry pattern for API calls with configurable retry limits, delay calculation, retryable error detection, and graceful degradation on permanent failures.", + "source_path": "patterns/retry-with-backoff", + "repo_path": "uncategorized/patterns/retry-with-backoff-workflow" +} diff --git a/patterns/retry-with-backoff/workflow.fz b/uncategorized/patterns/retry-with-backoff-workflow/workflow.fz similarity index 100% rename from patterns/retry-with-backoff/workflow.fz rename to uncategorized/patterns/retry-with-backoff-workflow/workflow.fz diff --git a/uncategorized/patterns/router-workflow/README.md b/uncategorized/patterns/router-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..8061f5bbd5600ea04689135ecf6c7d00ece13580 --- /dev/null +++ b/uncategorized/patterns/router-workflow/README.md @@ -0,0 +1,19 @@ +# Router Workflow + +This workflow models routing messages based on their content. + +**Template ID:** `router-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 3/5 +**Nodes:** 10 +**Lanes:** 3 +**Tags:** [router, patterns, decision] +**Source path:** `patterns/router` +**Repo path:** `uncategorized/patterns/router-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/router-workflow/metadata.json b/uncategorized/patterns/router-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..d1ebb5f221c6abae99fd0993ec3381b03f0b8624 --- /dev/null +++ b/uncategorized/patterns/router-workflow/metadata.json @@ -0,0 +1,21 @@ +{ + "template_id": "router-workflow", + "workflow_id": "router", + "title": "Router Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 3, + "num_nodes": 10, + "num_lanes": 3, + "tags": [ + "router", + "patterns", + "decision" + ], + "description": "This workflow models routing messages based on their content.", + "source_path": "patterns/router", + "repo_path": "uncategorized/patterns/router-workflow" +} diff --git a/patterns/router/workflow.fz b/uncategorized/patterns/router-workflow/workflow.fz similarity index 100% rename from patterns/router/workflow.fz rename to uncategorized/patterns/router-workflow/workflow.fz diff --git a/uncategorized/patterns/snapshot-pattern-workflow/README.md b/uncategorized/patterns/snapshot-pattern-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..24261ead4774e02803f6c5d0d5f3a261ce28ec8a --- /dev/null +++ b/uncategorized/patterns/snapshot-pattern-workflow/README.md @@ -0,0 +1,19 @@ +# Snapshot Pattern Workflow + +This workflow models taking periodic snapshots of important state. + +**Template ID:** `snapshot-pattern-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 2/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [snapshot, pattern, patterns, decision, loop] +**Source path:** `patterns/snapshot-pattern` +**Repo path:** `uncategorized/patterns/snapshot-pattern-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/snapshot-pattern-workflow/metadata.json b/uncategorized/patterns/snapshot-pattern-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..8790c1feff28e4c7b17f86a7bab4a9b12aaa2e2e --- /dev/null +++ b/uncategorized/patterns/snapshot-pattern-workflow/metadata.json @@ -0,0 +1,23 @@ +{ + "template_id": "snapshot-pattern-workflow", + "workflow_id": "snapshot-pattern", + "title": "Snapshot Pattern Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 2, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "snapshot", + "pattern", + "patterns", + "decision", + "loop" + ], + "description": "This workflow models taking periodic snapshots of important state.", + "source_path": "patterns/snapshot-pattern", + "repo_path": "uncategorized/patterns/snapshot-pattern-workflow" +} diff --git a/patterns/snapshot-pattern/workflow.fz b/uncategorized/patterns/snapshot-pattern-workflow/workflow.fz similarity index 100% rename from patterns/snapshot-pattern/workflow.fz rename to uncategorized/patterns/snapshot-pattern-workflow/workflow.fz diff --git a/uncategorized/patterns/state-machine-workflow/README.md b/uncategorized/patterns/state-machine-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..36e6cf945eb9ab92781e03914fac365e9e489c11 --- /dev/null +++ b/uncategorized/patterns/state-machine-workflow/README.md @@ -0,0 +1,19 @@ +# State Machine Workflow + +This workflow models tracking object state changes over time. + +**Template ID:** `state-machine-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 13 +**Lanes:** 4 +**Tags:** [state, machine, patterns, parallel] +**Source path:** `patterns/state-machine` +**Repo path:** `uncategorized/patterns/state-machine-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/state-machine-workflow/metadata.json b/uncategorized/patterns/state-machine-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..5e5130d81f67e844c9168b6610a6ee79847dde45 --- /dev/null +++ b/uncategorized/patterns/state-machine-workflow/metadata.json @@ -0,0 +1,22 @@ +{ + "template_id": "state-machine-workflow", + "workflow_id": "state-machine", + "title": "State Machine Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 13, + "num_lanes": 4, + "tags": [ + "state", + "machine", + "patterns", + "parallel" + ], + "description": "This workflow models tracking object state changes over time.", + "source_path": "patterns/state-machine", + "repo_path": "uncategorized/patterns/state-machine-workflow" +} diff --git a/patterns/state-machine/workflow.fz b/uncategorized/patterns/state-machine-workflow/workflow.fz similarity index 88% rename from patterns/state-machine/workflow.fz rename to uncategorized/patterns/state-machine-workflow/workflow.fz index d805f8d42b24ef5b301837d6761f516b56221bc1..f117e572654fe7010a85f318b577339826965130 100644 --- a/patterns/state-machine/workflow.fz +++ b/uncategorized/patterns/state-machine-workflow/workflow.fz @@ -11,11 +11,11 @@ n4.handle(right) -> n5.handle(left) } StateMachine { # State Machine n6: diamond label:"Current state?" -n7: rectangle label:"Pending -> Confirmed" -n8: rectangle label:"Confirmed -> Processing" -n9: rectangle label:"Processing -> Shipped" -n10: rectangle label:"Shipped -> Delivered" -n11: rectangle label:"Any -> Cancelled" +n7: rectangle label:"Pending to Confirmed" +n8: rectangle label:"Confirmed to Processing" +n9: rectangle label:"Processing to Shipped" +n10: rectangle label:"Shipped to Delivered" +n11: rectangle label:"Any to Cancelled" n12: diamond label:"Valid transition?" n13: rectangle label:"Update state" n14: rectangle label:"Reject invalid transition" diff --git a/uncategorized/patterns/strangler-fig-workflow/README.md b/uncategorized/patterns/strangler-fig-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..5b2f711b6ecebc7dcc4784ecca6d831c2d534153 --- /dev/null +++ b/uncategorized/patterns/strangler-fig-workflow/README.md @@ -0,0 +1,19 @@ +# Strangler Fig Workflow + +This workflow models gradually replacing an old system with a new one. + +**Template ID:** `strangler-fig-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 2/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [strangler, fig, patterns, decision] +**Source path:** `patterns/strangler-fig` +**Repo path:** `uncategorized/patterns/strangler-fig-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/strangler-fig-workflow/metadata.json b/uncategorized/patterns/strangler-fig-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..dfdc5f78c74a808ad57966538c76822e79c57436 --- /dev/null +++ b/uncategorized/patterns/strangler-fig-workflow/metadata.json @@ -0,0 +1,22 @@ +{ + "template_id": "strangler-fig-workflow", + "workflow_id": "strangler-fig", + "title": "Strangler Fig Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 2, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "strangler", + "fig", + "patterns", + "decision" + ], + "description": "This workflow models gradually replacing an old system with a new one.", + "source_path": "patterns/strangler-fig", + "repo_path": "uncategorized/patterns/strangler-fig-workflow" +} diff --git a/patterns/strangler-fig/workflow.fz b/uncategorized/patterns/strangler-fig-workflow/workflow.fz similarity index 100% rename from patterns/strangler-fig/workflow.fz rename to uncategorized/patterns/strangler-fig-workflow/workflow.fz diff --git a/uncategorized/patterns/timeout-pattern-workflow/README.md b/uncategorized/patterns/timeout-pattern-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..1bdf4cb42ff21b38f655233183e5ef352d2dfc97 --- /dev/null +++ b/uncategorized/patterns/timeout-pattern-workflow/README.md @@ -0,0 +1,19 @@ +# Timeout Pattern Workflow + +This workflow models an operation that times out after a delay. + +**Template ID:** `timeout-pattern-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 13 +**Lanes:** 4 +**Tags:** [timeout, pattern, patterns] +**Source path:** `patterns/timeout-pattern` +**Repo path:** `uncategorized/patterns/timeout-pattern-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/timeout-pattern-workflow/metadata.json b/uncategorized/patterns/timeout-pattern-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..0c04982ce90dbcb5b1495a826e97c753b6e3dcef --- /dev/null +++ b/uncategorized/patterns/timeout-pattern-workflow/metadata.json @@ -0,0 +1,21 @@ +{ + "template_id": "timeout-pattern-workflow", + "workflow_id": "timeout-pattern", + "title": "Timeout Pattern Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 13, + "num_lanes": 4, + "tags": [ + "timeout", + "pattern", + "patterns" + ], + "description": "This workflow models an operation that times out after a delay.", + "source_path": "patterns/timeout-pattern", + "repo_path": "uncategorized/patterns/timeout-pattern-workflow" +} diff --git a/patterns/timeout-pattern/workflow.fz b/uncategorized/patterns/timeout-pattern-workflow/workflow.fz similarity index 100% rename from patterns/timeout-pattern/workflow.fz rename to uncategorized/patterns/timeout-pattern-workflow/workflow.fz diff --git a/uncategorized/patterns/transactional-outbox-workflow/README.md b/uncategorized/patterns/transactional-outbox-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..b1c9b5e17f50a15ad8087694e24598080a9ecd34 --- /dev/null +++ b/uncategorized/patterns/transactional-outbox-workflow/README.md @@ -0,0 +1,19 @@ +# Transactional Outbox Workflow + +This workflow models writing data and publishing messages in one transaction. + +**Template ID:** `transactional-outbox-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 4/5 +**Nodes:** 13 +**Lanes:** 4 +**Tags:** [transactional, outbox, patterns, parallel] +**Source path:** `patterns/transactional-outbox` +**Repo path:** `uncategorized/patterns/transactional-outbox-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/transactional-outbox-workflow/metadata.json b/uncategorized/patterns/transactional-outbox-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..ac1ca27b6737a02adbbbb367c39793e70467fd75 --- /dev/null +++ b/uncategorized/patterns/transactional-outbox-workflow/metadata.json @@ -0,0 +1,22 @@ +{ + "template_id": "transactional-outbox-workflow", + "workflow_id": "transactional-outbox", + "title": "Transactional Outbox Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 4, + "num_nodes": 13, + "num_lanes": 4, + "tags": [ + "transactional", + "outbox", + "patterns", + "parallel" + ], + "description": "This workflow models writing data and publishing messages in one transaction.", + "source_path": "patterns/transactional-outbox", + "repo_path": "uncategorized/patterns/transactional-outbox-workflow" +} diff --git a/patterns/transactional-outbox/workflow.fz b/uncategorized/patterns/transactional-outbox-workflow/workflow.fz similarity index 100% rename from patterns/transactional-outbox/workflow.fz rename to uncategorized/patterns/transactional-outbox-workflow/workflow.fz diff --git a/uncategorized/patterns/transform-workflow/README.md b/uncategorized/patterns/transform-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..9e45f1e17b92bc6e98000e2f2593f2786bfb2f14 --- /dev/null +++ b/uncategorized/patterns/transform-workflow/README.md @@ -0,0 +1,19 @@ +# Transform Workflow + +This workflow models converting messages into a new shape. + +**Template ID:** `transform-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 2/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [transform, patterns] +**Source path:** `patterns/transform` +**Repo path:** `uncategorized/patterns/transform-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/transform-workflow/metadata.json b/uncategorized/patterns/transform-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..64d7ec2790fa8b40c1d2315eda6fcffeebb07b7a --- /dev/null +++ b/uncategorized/patterns/transform-workflow/metadata.json @@ -0,0 +1,20 @@ +{ + "template_id": "transform-workflow", + "workflow_id": "transform", + "title": "Transform Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 2, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "transform", + "patterns" + ], + "description": "This workflow models converting messages into a new shape.", + "source_path": "patterns/transform", + "repo_path": "uncategorized/patterns/transform-workflow" +} diff --git a/patterns/transform/workflow.fz b/uncategorized/patterns/transform-workflow/workflow.fz similarity index 100% rename from patterns/transform/workflow.fz rename to uncategorized/patterns/transform-workflow/workflow.fz diff --git a/uncategorized/patterns/validator-workflow/README.md b/uncategorized/patterns/validator-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..a77b9889d48c6b84f670a1aa78a49c8e2cf24f78 --- /dev/null +++ b/uncategorized/patterns/validator-workflow/README.md @@ -0,0 +1,19 @@ +# Validator Workflow + +This workflow models checking that incoming data is valid. + +**Template ID:** `validator-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 2/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [validator, patterns, parallel] +**Source path:** `patterns/validator` +**Repo path:** `uncategorized/patterns/validator-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/validator-workflow/metadata.json b/uncategorized/patterns/validator-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..0f404820cc843f408a9ad379cbf8879705f3ccfa --- /dev/null +++ b/uncategorized/patterns/validator-workflow/metadata.json @@ -0,0 +1,21 @@ +{ + "template_id": "validator-workflow", + "workflow_id": "validator", + "title": "Validator Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 2, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "validator", + "patterns", + "parallel" + ], + "description": "This workflow models checking that incoming data is valid.", + "source_path": "patterns/validator", + "repo_path": "uncategorized/patterns/validator-workflow" +} diff --git a/patterns/validator/workflow.fz b/uncategorized/patterns/validator-workflow/workflow.fz similarity index 100% rename from patterns/validator/workflow.fz rename to uncategorized/patterns/validator-workflow/workflow.fz diff --git a/uncategorized/patterns/webhook-pattern-workflow/README.md b/uncategorized/patterns/webhook-pattern-workflow/README.md new file mode 100644 index 0000000000000000000000000000000000000000..a3e6b7ee302b422f3ce1230f7db7ec38d6b77bd6 --- /dev/null +++ b/uncategorized/patterns/webhook-pattern-workflow/README.md @@ -0,0 +1,19 @@ +# Webhook Pattern Workflow + +This workflow models an HTTP callback when an event occurs. + +**Template ID:** `webhook-pattern-workflow` +**Kind:** workflow +**Source domain:** patterns +**Primary use case:** uncategorized +**Secondary use cases:** None +**Complexity:** 2/5 +**Nodes:** 7 +**Lanes:** 2 +**Tags:** [webhook, pattern, patterns, decision, loop] +**Source path:** `patterns/webhook-pattern` +**Repo path:** `uncategorized/patterns/webhook-pattern-workflow` + +## Files +- `workflow.fz` — FlowZap Code source +- `metadata.json` — Structured metadata diff --git a/uncategorized/patterns/webhook-pattern-workflow/metadata.json b/uncategorized/patterns/webhook-pattern-workflow/metadata.json new file mode 100644 index 0000000000000000000000000000000000000000..2da287e73f0a6e45ab55a280f32c67e99a01d379 --- /dev/null +++ b/uncategorized/patterns/webhook-pattern-workflow/metadata.json @@ -0,0 +1,23 @@ +{ + "template_id": "webhook-pattern-workflow", + "workflow_id": "webhook-pattern", + "title": "Webhook Pattern Workflow", + "kind": "workflow", + "source_domain": "patterns", + "primary_use_case": "uncategorized", + "secondary_use_cases": [], + "use_cases": [], + "complexity": 2, + "num_nodes": 7, + "num_lanes": 2, + "tags": [ + "webhook", + "pattern", + "patterns", + "decision", + "loop" + ], + "description": "This workflow models an HTTP callback when an event occurs.", + "source_path": "patterns/webhook-pattern", + "repo_path": "uncategorized/patterns/webhook-pattern-workflow" +} diff --git a/patterns/webhook-pattern/workflow.fz b/uncategorized/patterns/webhook-pattern-workflow/workflow.fz similarity index 100% rename from patterns/webhook-pattern/workflow.fz rename to uncategorized/patterns/webhook-pattern-workflow/workflow.fz diff --git a/use-cases.index.json b/use-cases.index.json new file mode 100644 index 0000000000000000000000000000000000000000..8134bc8ff97008041675e11911e4a0aae92a3333 --- /dev/null +++ b/use-cases.index.json @@ -0,0 +1,1304 @@ +{ + "useCases": { + "handoff": { + "label": "Handoff", + "count": 15, + "templates": [ + { + "slug": "api-gateway-workflow", + "title": "Api Gateway Workflow", + "repoPath": "handoff/patterns/api-gateway-workflow" + }, + { + "slug": "escalation-pattern-workflow", + "title": "Escalation Pattern Workflow", + "repoPath": "handoff/patterns/escalation-pattern-workflow" + }, + { + "slug": "offboarding-workflow", + "title": "Offboarding Workflow", + "repoPath": "handoff/hr/offboarding-workflow" + }, + { + "slug": "on-call-rotation-workflow", + "title": "On Call Rotation Workflow", + "repoPath": "handoff/devops/on-call-rotation-workflow" + }, + { + "slug": "payment-run-workflow", + "title": "Payment Run Workflow", + "repoPath": "handoff/finance/payment-run-workflow" + }, + { + "slug": "routing-slip-workflow", + "title": "Routing Slip Workflow", + "repoPath": "handoff/patterns/routing-slip-workflow" + }, + { + "slug": "stock-transfer-workflow", + "title": "Stock Transfer Workflow", + "repoPath": "handoff/logistics/stock-transfer-workflow" + }, + { + "slug": "support-ticket-workflow", + "title": "Support Ticket Workflow", + "repoPath": "handoff/business-operations/support-ticket-workflow" + }, + { + "slug": "warehouse-transfer-workflow", + "title": "Warehouse Transfer Workflow", + "repoPath": "handoff/logistics/warehouse-transfer-workflow" + }, + { + "slug": "microservices-service-discovery-architecture", + "title": "Microservices Service Discovery Architecture", + "repoPath": "handoff/architecture/microservices-service-discovery-architecture" + }, + { + "slug": "serverless-edge-computing-architecture", + "title": "Serverless Edge Computing Architecture", + "repoPath": "handoff/architecture/serverless-edge-computing-architecture" + }, + { + "slug": "serverless-multi-cloud-architecture", + "title": "Serverless Multi-Cloud Architecture", + "repoPath": "handoff/architecture/serverless-multi-cloud-architecture" + }, + { + "slug": "bulkhead-isolation-architecture", + "title": "Bulkhead Isolation Architecture", + "repoPath": "handoff/architecture/bulkhead-isolation-architecture" + }, + { + "slug": "cell-based-architecture", + "title": "Cell-Based Architecture", + "repoPath": "handoff/architecture/cell-based-architecture" + }, + { + "slug": "mcp-tool-router", + "title": "MCP Tool Router Architecture", + "repoPath": "handoff/devops/mcp-tool-router" + } + ] + }, + "approval": { + "label": "Approval", + "count": 17, + "templates": [ + { + "slug": "access-review-workflow", + "title": "Access Review Workflow", + "repoPath": "approval/devops/access-review-workflow" + }, + { + "slug": "authorization-flow-workflow", + "title": "Authorization Flow Workflow", + "repoPath": "approval/patterns/authorization-flow-workflow" + }, + { + "slug": "billing-dispute-workflow", + "title": "Billing Dispute Workflow", + "repoPath": "approval/business-operations/billing-dispute-workflow" + }, + { + "slug": "budget-approval-workflow", + "title": "Budget Approval Workflow", + "repoPath": "approval/finance/budget-approval-workflow" + }, + { + "slug": "database-migration-workflow", + "title": "Database Migration Workflow", + "repoPath": "approval/devops/database-migration-workflow" + }, + { + "slug": "expense-approval-workflow", + "title": "Expense Approval Workflow", + "repoPath": "approval/hr/expense-approval-workflow" + }, + { + "slug": "expense-claim-workflow", + "title": "Expense Claim Workflow", + "repoPath": "approval/finance/expense-claim-workflow" + }, + { + "slug": "insurance-claim-workflow", + "title": "Insurance Claim Workflow", + "repoPath": "approval/finance/insurance-claim-workflow" + }, + { + "slug": "invoice-processing-workflow", + "title": "Invoice Processing Workflow", + "repoPath": "approval/finance/invoice-processing-workflow" + }, + { + "slug": "oauth-flow-workflow", + "title": "Oauth Flow Workflow", + "repoPath": "approval/business-operations/oauth-flow-workflow" + }, + { + "slug": "performance-review-workflow", + "title": "Performance Review Workflow", + "repoPath": "approval/hr/performance-review-workflow" + }, + { + "slug": "pto-request-workflow", + "title": "Pto Request Workflow", + "repoPath": "approval/hr/pto-request-workflow" + }, + { + "slug": "purchase-order-workflow", + "title": "Purchase Order Workflow", + "repoPath": "approval/finance/purchase-order-workflow" + }, + { + "slug": "review-collection-workflow", + "title": "Review Collection Workflow", + "repoPath": "approval/business-operations/review-collection-workflow" + }, + { + "slug": "salary-increase-workflow", + "title": "Salary Increase Workflow", + "repoPath": "approval/hr/salary-increase-workflow" + }, + { + "slug": "termination-process-workflow", + "title": "Termination Process Workflow", + "repoPath": "approval/hr/termination-process-workflow" + }, + { + "slug": "saga-order-fulfillment-architecture", + "title": "Saga Order Fulfillment Architecture", + "repoPath": "approval/architecture/saga-order-fulfillment-architecture" + } + ] + }, + "incident": { + "label": "Incident", + "count": 10, + "templates": [ + { + "slug": "canary-deploy-workflow", + "title": "Canary Deploy Workflow", + "repoPath": "incident/patterns/canary-deploy-workflow" + }, + { + "slug": "cold-chain-monitoring-workflow", + "title": "Cold Chain Monitoring Workflow", + "repoPath": "incident/logistics/cold-chain-monitoring-workflow" + }, + { + "slug": "deployment-rollback-workflow", + "title": "Deployment Rollback Workflow", + "repoPath": "incident/devops/deployment-rollback-workflow" + }, + { + "slug": "hazmat-handling-workflow", + "title": "Hazmat Handling Workflow", + "repoPath": "incident/logistics/hazmat-handling-workflow" + }, + { + "slug": "incident-response-workflow", + "title": "Incident Response Workflow", + "repoPath": "incident/devops/incident-response-workflow" + }, + { + "slug": "monitoring-alert-workflow", + "title": "Monitoring Alert Workflow", + "repoPath": "incident/devops/monitoring-alert-workflow" + }, + { + "slug": "event-driven-dead-letter-queue-architecture", + "title": "Event-Driven Dead Letter Queue Architecture", + "repoPath": "incident/architecture/event-driven-dead-letter-queue-architecture" + }, + { + "slug": "serverless-step-functions-orchestration-architecture", + "title": "Serverless Step Functions Orchestration Architecture", + "repoPath": "incident/architecture/serverless-step-functions-orchestration-architecture" + }, + { + "slug": "health-check-pattern-architecture", + "title": "Health Check Pattern Architecture", + "repoPath": "incident/architecture/health-check-pattern-architecture" + }, + { + "slug": "api-composition-pattern-architecture", + "title": "API Composition Pattern Architecture", + "repoPath": "incident/architecture/api-composition-pattern-architecture" + } + ] + }, + "onboarding": { + "label": "Onboarding", + "count": 6, + "templates": [ + { + "slug": "ab-test-setup-workflow", + "title": "Ab Test Setup Workflow", + "repoPath": "onboarding/business-operations/ab-test-setup-workflow" + }, + { + "slug": "onboarding-workflow", + "title": "Onboarding Workflow", + "repoPath": "onboarding/hr/onboarding-workflow" + }, + { + "slug": "two-factor-setup-workflow", + "title": "Two Factor Setup Workflow", + "repoPath": "onboarding/business-operations/two-factor-setup-workflow" + }, + { + "slug": "user-onboarding-workflow", + "title": "User Onboarding Workflow", + "repoPath": "onboarding/business-operations/user-onboarding-workflow" + }, + { + "slug": "vendor-onboarding-workflow", + "title": "Vendor Onboarding Workflow", + "repoPath": "onboarding/finance/vendor-onboarding-workflow" + }, + { + "slug": "webinar-registration-workflow", + "title": "Webinar Registration Workflow", + "repoPath": "onboarding/business-operations/webinar-registration-workflow" + } + ] + }, + "offboarding": { + "label": "Offboarding", + "count": 1, + "templates": [ + { + "slug": "account-deletion-workflow", + "title": "Account Deletion Workflow", + "repoPath": "offboarding/business-operations/account-deletion-workflow" + } + ] + }, + "billing": { + "label": "Billing & Payments", + "count": 8, + "templates": [ + { + "slug": "conflict-resolution-workflow", + "title": "Conflict Resolution Workflow", + "repoPath": "billing/hr/conflict-resolution-workflow" + }, + { + "slug": "dunning-flow-workflow", + "title": "Dunning Flow Workflow", + "repoPath": "billing/business-operations/dunning-flow-workflow" + }, + { + "slug": "payment-failure-workflow", + "title": "Payment Failure Workflow", + "repoPath": "billing/business-operations/payment-failure-workflow" + }, + { + "slug": "plan-downgrade-workflow", + "title": "Plan Downgrade Workflow", + "repoPath": "billing/business-operations/plan-downgrade-workflow" + }, + { + "slug": "plan-upgrade-workflow", + "title": "Plan Upgrade Workflow", + "repoPath": "billing/business-operations/plan-upgrade-workflow" + }, + { + "slug": "returns-processing-workflow", + "title": "Returns Processing Workflow", + "repoPath": "billing/logistics/returns-processing-workflow" + }, + { + "slug": "subscription-lifecycle-workflow", + "title": "Subscription Lifecycle Workflow", + "repoPath": "billing/business-operations/subscription-lifecycle-workflow" + }, + { + "slug": "shopify-universal-commerce-protocol", + "title": "Shopify Universal Commerce Protocol", + "repoPath": "billing/business-operations/shopify-universal-commerce-protocol" + } + ] + }, + "security": { + "label": "Security & Access", + "count": 13, + "templates": [ + { + "slug": "api-key-rotation-workflow", + "title": "Api Key Rotation Workflow", + "repoPath": "security/business-operations/api-key-rotation-workflow" + }, + { + "slug": "authentication-flow-workflow", + "title": "Authentication Flow Workflow", + "repoPath": "security/patterns/authentication-flow-workflow" + }, + { + "slug": "certificate-renewal-workflow", + "title": "Certificate Renewal Workflow", + "repoPath": "security/devops/certificate-renewal-workflow" + }, + { + "slug": "secret-rotation-workflow", + "title": "Secret Rotation Workflow", + "repoPath": "security/devops/secret-rotation-workflow" + }, + { + "slug": "security-scan-workflow", + "title": "Security Scan Workflow", + "repoPath": "security/devops/security-scan-workflow" + }, + { + "slug": "shipping-process-workflow", + "title": "Shipping Process Workflow", + "repoPath": "security/logistics/shipping-process-workflow" + }, + { + "slug": "sms-verification-workflow", + "title": "Sms Verification Workflow", + "repoPath": "security/business-operations/sms-verification-workflow" + }, + { + "slug": "vulnerability-patch-workflow", + "title": "Vulnerability Patch Workflow", + "repoPath": "security/devops/vulnerability-patch-workflow" + }, + { + "slug": "microservices-api-gateway-architecture", + "title": "Microservices API Gateway Architecture", + "repoPath": "security/architecture/microservices-api-gateway-architecture" + }, + { + "slug": "event-driven-domain-events-architecture", + "title": "Event-Driven Domain Events Architecture", + "repoPath": "security/architecture/event-driven-domain-events-architecture" + }, + { + "slug": "zero-trust-security-architecture", + "title": "Zero Trust Security Architecture", + "repoPath": "security/architecture/zero-trust-security-architecture" + }, + { + "slug": "multi-tenant-saas-architecture", + "title": "Multi-Tenant SaaS Architecture", + "repoPath": "security/architecture/multi-tenant-saas-architecture" + }, + { + "slug": "mcp-gateway-proxy", + "title": "MCP Gateway Proxy Architecture", + "repoPath": "security/devops/mcp-gateway-proxy" + } + ] + }, + "compliance": { + "label": "Compliance", + "count": 13, + "templates": [ + { + "slug": "audit-trail-workflow", + "title": "Audit Trail Workflow", + "repoPath": "compliance/patterns/audit-trail-workflow" + }, + { + "slug": "consent-management-workflow", + "title": "Consent Management Workflow", + "repoPath": "compliance/business-operations/consent-management-workflow" + }, + { + "slug": "cycle-counting-workflow", + "title": "Cycle Counting Workflow", + "repoPath": "compliance/logistics/cycle-counting-workflow" + }, + { + "slug": "data-export-workflow", + "title": "Data Export Workflow", + "repoPath": "compliance/business-operations/data-export-workflow" + }, + { + "slug": "event-sourcing-workflow", + "title": "Event Sourcing Workflow", + "repoPath": "compliance/patterns/event-sourcing-workflow" + }, + { + "slug": "financial-reporting-workflow", + "title": "Financial Reporting Workflow", + "repoPath": "compliance/finance/financial-reporting-workflow" + }, + { + "slug": "fleet-maintenance-workflow", + "title": "Fleet Maintenance Workflow", + "repoPath": "compliance/logistics/fleet-maintenance-workflow" + }, + { + "slug": "gdpr-deletion-workflow", + "title": "Gdpr Deletion Workflow", + "repoPath": "compliance/business-operations/gdpr-deletion-workflow" + }, + { + "slug": "internal-controls-workflow", + "title": "Internal Controls Workflow", + "repoPath": "compliance/finance/internal-controls-workflow" + }, + { + "slug": "payroll-processing-workflow", + "title": "Payroll Processing Workflow", + "repoPath": "compliance/finance/payroll-processing-workflow" + }, + { + "slug": "tax-filing-workflow", + "title": "Tax Filing Workflow", + "repoPath": "compliance/finance/tax-filing-workflow" + }, + { + "slug": "training-enrollment-workflow", + "title": "Training Enrollment Workflow", + "repoPath": "compliance/hr/training-enrollment-workflow" + }, + { + "slug": "yearly-audit-workflow", + "title": "Yearly Audit Workflow", + "repoPath": "compliance/finance/yearly-audit-workflow" + } + ] + }, + "delivery": { + "label": "Delivery & DevOps", + "count": 15, + "templates": [ + { + "slug": "backup-restore-workflow", + "title": "Backup Restore Workflow", + "repoPath": "delivery/devops/backup-restore-workflow" + }, + { + "slug": "blue-green-deploy-workflow", + "title": "Blue Green Deploy Workflow", + "repoPath": "delivery/patterns/blue-green-deploy-workflow" + }, + { + "slug": "ci-cd-pipeline-workflow", + "title": "Ci Cd Pipeline Workflow", + "repoPath": "delivery/devops/ci-cd-pipeline-workflow" + }, + { + "slug": "infrastructure-provisioning-workflow", + "title": "Infrastructure Provisioning Workflow", + "repoPath": "delivery/devops/infrastructure-provisioning-workflow" + }, + { + "slug": "load-testing-workflow", + "title": "Load Testing Workflow", + "repoPath": "delivery/devops/load-testing-workflow" + }, + { + "slug": "saga-pattern-workflow", + "title": "Saga Pattern Workflow", + "repoPath": "delivery/patterns/saga-pattern-workflow" + }, + { + "slug": "microservices-strangler-fig-migration", + "title": "Microservices Strangler Fig Migration Architecture", + "repoPath": "delivery/architecture/microservices-strangler-fig-migration" + }, + { + "slug": "event-driven-event-streaming-pipeline-architecture", + "title": "Event-Driven Streaming Pipeline Architecture", + "repoPath": "delivery/architecture/event-driven-event-streaming-pipeline-architecture" + }, + { + "slug": "serverless-data-pipeline-architecture", + "title": "Serverless Data Pipeline Architecture", + "repoPath": "delivery/architecture/serverless-data-pipeline-architecture" + }, + { + "slug": "saga-orchestration-pattern-architecture", + "title": "Saga Orchestration Pattern Architecture", + "repoPath": "delivery/architecture/saga-orchestration-pattern-architecture" + }, + { + "slug": "gitops-deployment-architecture", + "title": "GitOps Deployment Architecture", + "repoPath": "delivery/architecture/gitops-deployment-architecture" + }, + { + "slug": "ai-native-sequential-pipeline-architecture", + "title": "AI-Native Sequential Pipeline Architecture", + "repoPath": "delivery/architecture/ai-native-sequential-pipeline-architecture" + }, + { + "slug": "ai-native-parallel-fan-out-architecture", + "title": "AI-Native Parallel Fan-Out Architecture", + "repoPath": "delivery/architecture/ai-native-parallel-fan-out-architecture" + }, + { + "slug": "agentic-sequential-pipeline", + "title": "Agentic Sequential Pipeline Architecture", + "repoPath": "delivery/architecture/agentic-sequential-pipeline" + }, + { + "slug": "ai-orchestration-sequential-pipeline", + "title": "AI Orchestration - Sequential Pipeline", + "repoPath": "delivery/architecture/ai-orchestration-sequential-pipeline" + } + ] + }, + "support": { + "label": "Support", + "count": 1, + "templates": [ + { + "slug": "knowledge-base-workflow", + "title": "Knowledge Base Workflow", + "repoPath": "support/business-operations/knowledge-base-workflow" + } + ] + }, + "agentic": { + "label": "Agentic Teams", + "count": 15, + "templates": [ + { + "slug": "ai-native-single-agent-architecture", + "title": "AI-Native Single Agent Architecture", + "repoPath": "agentic/architecture/ai-native-single-agent-architecture" + }, + { + "slug": "ai-native-orchestrator-worker-architecture", + "title": "AI-Native Orchestrator-Worker Architecture", + "repoPath": "agentic/architecture/ai-native-orchestrator-worker-architecture" + }, + { + "slug": "ai-native-hierarchical-architecture", + "title": "AI-Native Hierarchical Architecture", + "repoPath": "agentic/architecture/ai-native-hierarchical-architecture" + }, + { + "slug": "ai-native-event-driven-kafka-architecture", + "title": "AI-Native Event-Driven Kafka Architecture", + "repoPath": "agentic/architecture/ai-native-event-driven-kafka-architecture" + }, + { + "slug": "ai-native-generator-critic-architecture", + "title": "AI-Native Generator-Critic Architecture", + "repoPath": "agentic/architecture/ai-native-generator-critic-architecture" + }, + { + "slug": "agentic-supervisor-worker", + "title": "Agentic Supervisor-Worker Architecture", + "repoPath": "agentic/architecture/agentic-supervisor-worker" + }, + { + "slug": "agentic-swarm", + "title": "Agentic Swarm Architecture", + "repoPath": "agentic/architecture/agentic-swarm" + }, + { + "slug": "agentic-hierarchical", + "title": "Agentic Hierarchical Architecture", + "repoPath": "agentic/architecture/agentic-hierarchical" + }, + { + "slug": "agentic-team-of-rivals", + "title": "Agentic Team of Rivals Architecture", + "repoPath": "agentic/architecture/agentic-team-of-rivals" + }, + { + "slug": "ai-orchestration-orchestrator-worker", + "title": "AI Orchestration - Orchestrator-Worker", + "repoPath": "agentic/architecture/ai-orchestration-orchestrator-worker" + }, + { + "slug": "ai-orchestration-hierarchical", + "title": "AI Orchestration - Hierarchical (Org Chart)", + "repoPath": "agentic/architecture/ai-orchestration-hierarchical" + }, + { + "slug": "ai-orchestration-parallel-fan-out", + "title": "AI Orchestration - Parallel Fan-Out (Map-Reduce)", + "repoPath": "agentic/architecture/ai-orchestration-parallel-fan-out" + }, + { + "slug": "ai-orchestration-competitive-generator-critic", + "title": "AI Orchestration - Competitive Generator-Critic", + "repoPath": "agentic/architecture/ai-orchestration-competitive-generator-critic" + }, + { + "slug": "mcp-agent-mesh", + "title": "MCP Agent Mesh Architecture", + "repoPath": "agentic/devops/mcp-agent-mesh" + }, + { + "slug": "context-shared-memory", + "title": "Context Management - Shared Memory", + "repoPath": "agentic/architecture/context-shared-memory" + } + ] + }, + "ai-orchestration": { + "label": "AI Orchestration", + "count": 6, + "templates": [ + { + "slug": "fan-out-fan-in-workflow", + "title": "Fan Out Fan In Workflow", + "repoPath": "ai-orchestration/patterns/fan-out-fan-in-workflow" + }, + { + "slug": "saga-distributed-transaction-architecture", + "title": "Saga Distributed Transaction Architecture", + "repoPath": "ai-orchestration/architecture/saga-distributed-transaction-architecture" + }, + { + "slug": "saga-travel-booking-architecture", + "title": "Saga Travel Booking Architecture", + "repoPath": "ai-orchestration/architecture/saga-travel-booking-architecture" + }, + { + "slug": "kubernetes-container-orchestration-architecture", + "title": "Kubernetes Container Orchestration Architecture", + "repoPath": "ai-orchestration/architecture/kubernetes-container-orchestration-architecture" + }, + { + "slug": "ai-orchestration-single-agent", + "title": "AI Orchestration - Single Agent (Monolith)", + "repoPath": "ai-orchestration/architecture/ai-orchestration-single-agent" + }, + { + "slug": "ai-orchestration-event-driven-mesh", + "title": "AI Orchestration - Event-Driven Mesh (Kafka-First)", + "repoPath": "ai-orchestration/architecture/ai-orchestration-event-driven-mesh" + } + ] + }, + "mcp": { + "label": "MCP Architecture", + "count": 10, + "templates": [ + { + "slug": "circuit-breaker-workflow", + "title": "Circuit Breaker Workflow", + "repoPath": "mcp/patterns/circuit-breaker-workflow" + }, + { + "slug": "microservices-service-mesh-architecture", + "title": "Microservices Service Mesh Architecture", + "repoPath": "mcp/architecture/microservices-service-mesh-architecture" + }, + { + "slug": "microservices-sidecar-pattern-architecture", + "title": "Microservices Sidecar Pattern Architecture", + "repoPath": "mcp/architecture/microservices-sidecar-pattern-architecture" + }, + { + "slug": "serverless-api-backend-architecture", + "title": "Serverless API Backend Architecture", + "repoPath": "mcp/architecture/serverless-api-backend-architecture" + }, + { + "slug": "circuit-breaker-resilience-architecture", + "title": "Circuit Breaker Resilience Architecture", + "repoPath": "mcp/architecture/circuit-breaker-resilience-architecture" + }, + { + "slug": "ambassador-pattern-architecture", + "title": "Ambassador Pattern Architecture", + "repoPath": "mcp/architecture/ambassador-pattern-architecture" + }, + { + "slug": "graphql-federation-architecture", + "title": "GraphQL Federation Architecture", + "repoPath": "mcp/architecture/graphql-federation-architecture" + }, + { + "slug": "mcp-direct-connect", + "title": "MCP Direct Connect Architecture", + "repoPath": "mcp/devops/mcp-direct-connect" + }, + { + "slug": "mcp-circuit-breaker", + "title": "MCP Circuit Breaker Architecture", + "repoPath": "mcp/devops/mcp-circuit-breaker" + }, + { + "slug": "mcp-context-proxy", + "title": "MCP Context Proxy Architecture", + "repoPath": "mcp/devops/mcp-context-proxy" + } + ] + }, + "context-management": { + "label": "Context Management", + "count": 6, + "templates": [ + { + "slug": "context-session-memory", + "title": "Context Management - Session Memory", + "repoPath": "context-management/architecture/context-session-memory" + }, + { + "slug": "context-rolling-summary-memory", + "title": "Context Management - Rolling Summary Memory", + "repoPath": "context-management/architecture/context-rolling-summary-memory" + }, + { + "slug": "context-profile-memory", + "title": "Context Management - Profile Memory", + "repoPath": "context-management/architecture/context-profile-memory" + }, + { + "slug": "context-semantic-memory", + "title": "Context Management - Semantic Memory", + "repoPath": "context-management/architecture/context-semantic-memory" + }, + { + "slug": "context-episodic-memory", + "title": "Context Management - Episodic Memory", + "repoPath": "context-management/architecture/context-episodic-memory" + }, + { + "slug": "context-hybrid-retrieval-memory", + "title": "Context Management - Hybrid Retrieval Memory", + "repoPath": "context-management/architecture/context-hybrid-retrieval-memory" + } + ] + }, + "uncategorized": { + "label": "Uncategorized", + "count": 106, + "templates": [ + { + "slug": "a-b-testing-workflow", + "title": "A B Testing Workflow", + "repoPath": "uncategorized/patterns/a-b-testing-workflow" + }, + { + "slug": "background-check-workflow", + "title": "Background Check Workflow", + "repoPath": "uncategorized/hr/background-check-workflow" + }, + { + "slug": "bank-reconciliation-workflow", + "title": "Bank Reconciliation Workflow", + "repoPath": "uncategorized/finance/bank-reconciliation-workflow" + }, + { + "slug": "batch-processing-workflow", + "title": "Batch Processing Workflow", + "repoPath": "uncategorized/patterns/batch-processing-workflow" + }, + { + "slug": "bonus-allocation-workflow", + "title": "Bonus Allocation Workflow", + "repoPath": "uncategorized/hr/bonus-allocation-workflow" + }, + { + "slug": "cache-aside-workflow", + "title": "Cache Aside Workflow", + "repoPath": "uncategorized/patterns/cache-aside-workflow" + }, + { + "slug": "callback-pattern-workflow", + "title": "Callback Pattern Workflow", + "repoPath": "uncategorized/patterns/callback-pattern-workflow" + }, + { + "slug": "candidate-rejection-workflow", + "title": "Candidate Rejection Workflow", + "repoPath": "uncategorized/hr/candidate-rejection-workflow" + }, + { + "slug": "carrier-selection-workflow", + "title": "Carrier Selection Workflow", + "repoPath": "uncategorized/logistics/carrier-selection-workflow" + }, + { + "slug": "cash-flow-forecast-workflow", + "title": "Cash Flow Forecast Workflow", + "repoPath": "uncategorized/finance/cash-flow-forecast-workflow" + }, + { + "slug": "chaos-engineering-workflow", + "title": "Chaos Engineering Workflow", + "repoPath": "uncategorized/devops/chaos-engineering-workflow" + }, + { + "slug": "claim-check-workflow", + "title": "Claim Check Workflow", + "repoPath": "uncategorized/patterns/claim-check-workflow" + }, + { + "slug": "cohort-analysis-workflow", + "title": "Cohort Analysis Workflow", + "repoPath": "uncategorized/business-operations/cohort-analysis-workflow" + }, + { + "slug": "community-moderation-workflow", + "title": "Community Moderation Workflow", + "repoPath": "uncategorized/business-operations/community-moderation-workflow" + }, + { + "slug": "compensation-transaction-workflow", + "title": "Compensation Transaction Workflow", + "repoPath": "uncategorized/patterns/compensation-transaction-workflow" + }, + { + "slug": "container-loading-workflow", + "title": "Container Loading Workflow", + "repoPath": "uncategorized/logistics/container-loading-workflow" + }, + { + "slug": "content-enricher-workflow", + "title": "Content Enricher Workflow", + "repoPath": "uncategorized/patterns/content-enricher-workflow" + }, + { + "slug": "cost-center-workflow", + "title": "Cost Center Workflow", + "repoPath": "uncategorized/finance/cost-center-workflow" + }, + { + "slug": "cqrs-workflow", + "title": "Cqrs Workflow", + "repoPath": "uncategorized/patterns/cqrs-workflow" + }, + { + "slug": "credit-control-workflow", + "title": "Credit Control Workflow", + "repoPath": "uncategorized/finance/credit-control-workflow" + }, + { + "slug": "cross-docking-workflow", + "title": "Cross Docking Workflow", + "repoPath": "uncategorized/logistics/cross-docking-workflow" + }, + { + "slug": "crud-user-browser-server-workflow", + "title": "Crud User Browser Server Workflow", + "repoPath": "uncategorized/patterns/crud-user-browser-server-workflow" + }, + { + "slug": "customs-clearance-workflow", + "title": "Customs Clearance Workflow", + "repoPath": "uncategorized/logistics/customs-clearance-workflow" + }, + { + "slug": "damaged-goods-workflow", + "title": "Damaged Goods Workflow", + "repoPath": "uncategorized/logistics/damaged-goods-workflow" + }, + { + "slug": "dead-letter-queue-workflow", + "title": "Dead Letter Queue Workflow", + "repoPath": "uncategorized/patterns/dead-letter-queue-workflow" + }, + { + "slug": "decision-diamond-workflow", + "title": "Decision Diamond Workflow", + "repoPath": "uncategorized/patterns/decision-diamond-workflow" + }, + { + "slug": "delivery-confirmation-workflow", + "title": "Delivery Confirmation Workflow", + "repoPath": "uncategorized/logistics/delivery-confirmation-workflow" + }, + { + "slug": "diversity-initiative-workflow", + "title": "Diversity Initiative Workflow", + "repoPath": "uncategorized/hr/diversity-initiative-workflow" + }, + { + "slug": "email-campaign-workflow", + "title": "Email Campaign Workflow", + "repoPath": "uncategorized/business-operations/email-campaign-workflow" + }, + { + "slug": "employee-engagement-workflow", + "title": "Employee Engagement Workflow", + "repoPath": "uncategorized/hr/employee-engagement-workflow" + }, + { + "slug": "enricher-workflow", + "title": "Enricher Workflow", + "repoPath": "uncategorized/patterns/enricher-workflow" + }, + { + "slug": "error-retry-loop-workflow", + "title": "Error Retry Loop Workflow", + "repoPath": "uncategorized/patterns/error-retry-loop-workflow" + }, + { + "slug": "event-driven-workflow", + "title": "Event Driven Workflow", + "repoPath": "uncategorized/patterns/event-driven-workflow" + }, + { + "slug": "expense-allocation-workflow", + "title": "Expense Allocation Workflow", + "repoPath": "uncategorized/finance/expense-allocation-workflow" + }, + { + "slug": "feature-toggle-workflow", + "title": "Feature Toggle Workflow", + "repoPath": "uncategorized/patterns/feature-toggle-workflow" + }, + { + "slug": "filter-workflow", + "title": "Filter Workflow", + "repoPath": "uncategorized/patterns/filter-workflow" + }, + { + "slug": "fixed-assets-workflow", + "title": "Fixed Assets Workflow", + "repoPath": "uncategorized/finance/fixed-assets-workflow" + }, + { + "slug": "idempotent-consumer-workflow", + "title": "Idempotent Consumer Workflow", + "repoPath": "uncategorized/patterns/idempotent-consumer-workflow" + }, + { + "slug": "in-app-message-workflow", + "title": "In App Message Workflow", + "repoPath": "uncategorized/business-operations/in-app-message-workflow" + }, + { + "slug": "internship-program-workflow", + "title": "Internship Program Workflow", + "repoPath": "uncategorized/hr/internship-program-workflow" + }, + { + "slug": "interview-process-workflow", + "title": "Interview Process Workflow", + "repoPath": "uncategorized/hr/interview-process-workflow" + }, + { + "slug": "inventory-receipt-workflow", + "title": "Inventory Receipt Workflow", + "repoPath": "uncategorized/logistics/inventory-receipt-workflow" + }, + { + "slug": "job-posting-workflow", + "title": "Job Posting Workflow", + "repoPath": "uncategorized/hr/job-posting-workflow" + }, + { + "slug": "kitting-process-workflow", + "title": "Kitting Process Workflow", + "repoPath": "uncategorized/logistics/kitting-process-workflow" + }, + { + "slug": "last-mile-delivery-workflow", + "title": "Last Mile Delivery Workflow", + "repoPath": "uncategorized/logistics/last-mile-delivery-workflow" + }, + { + "slug": "materialized-view-workflow", + "title": "Materialized View Workflow", + "repoPath": "uncategorized/patterns/materialized-view-workflow" + }, + { + "slug": "message-queue-workflow", + "title": "Message Queue Workflow", + "repoPath": "uncategorized/patterns/message-queue-workflow" + }, + { + "slug": "monthly-close-workflow", + "title": "Monthly Close Workflow", + "repoPath": "uncategorized/finance/monthly-close-workflow" + }, + { + "slug": "nested-decisions-workflow", + "title": "Nested Decisions Workflow", + "repoPath": "uncategorized/patterns/nested-decisions-workflow" + }, + { + "slug": "normalizer-workflow", + "title": "Normalizer Workflow", + "repoPath": "uncategorized/patterns/normalizer-workflow" + }, + { + "slug": "notification-pattern-workflow", + "title": "Notification Pattern Workflow", + "repoPath": "uncategorized/patterns/notification-pattern-workflow" + }, + { + "slug": "packing-process-workflow", + "title": "Packing Process Workflow", + "repoPath": "uncategorized/logistics/packing-process-workflow" + }, + { + "slug": "parallel-execution-workflow", + "title": "Parallel Execution Workflow", + "repoPath": "uncategorized/patterns/parallel-execution-workflow" + }, + { + "slug": "personalization-engine-workflow", + "title": "Personalization Engine Workflow", + "repoPath": "uncategorized/business-operations/personalization-engine-workflow" + }, + { + "slug": "picking-process-workflow", + "title": "Picking Process Workflow", + "repoPath": "uncategorized/logistics/picking-process-workflow" + }, + { + "slug": "polling-pattern-workflow", + "title": "Polling Pattern Workflow", + "repoPath": "uncategorized/patterns/polling-pattern-workflow" + }, + { + "slug": "process-manager-workflow", + "title": "Process Manager Workflow", + "repoPath": "uncategorized/patterns/process-manager-workflow" + }, + { + "slug": "procurement-card-workflow", + "title": "Procurement Card Workflow", + "repoPath": "uncategorized/finance/procurement-card-workflow" + }, + { + "slug": "promotion-process-workflow", + "title": "Promotion Process Workflow", + "repoPath": "uncategorized/hr/promotion-process-workflow" + }, + { + "slug": "pub-sub-workflow", + "title": "Pub Sub Workflow", + "repoPath": "uncategorized/patterns/pub-sub-workflow" + }, + { + "slug": "push-notification-workflow", + "title": "Push Notification Workflow", + "repoPath": "uncategorized/business-operations/push-notification-workflow" + }, + { + "slug": "put-away-process-workflow", + "title": "Put Away Process Workflow", + "repoPath": "uncategorized/logistics/put-away-process-workflow" + }, + { + "slug": "quality-inspection-workflow", + "title": "Quality Inspection Workflow", + "repoPath": "uncategorized/logistics/quality-inspection-workflow" + }, + { + "slug": "rate-limiter-workflow", + "title": "Rate Limiter Workflow", + "repoPath": "uncategorized/patterns/rate-limiter-workflow" + }, + { + "slug": "reference-check-workflow", + "title": "Reference Check Workflow", + "repoPath": "uncategorized/hr/reference-check-workflow" + }, + { + "slug": "referral-program-workflow", + "title": "Referral Program Workflow", + "repoPath": "uncategorized/business-operations/referral-program-workflow" + }, + { + "slug": "relocation-assistance-workflow", + "title": "Relocation Assistance Workflow", + "repoPath": "uncategorized/hr/relocation-assistance-workflow" + }, + { + "slug": "reorder-process-workflow", + "title": "Reorder Process Workflow", + "repoPath": "uncategorized/logistics/reorder-process-workflow" + }, + { + "slug": "request-reply-workflow", + "title": "Request Reply Workflow", + "repoPath": "uncategorized/patterns/request-reply-workflow" + }, + { + "slug": "retry-with-backoff-workflow", + "title": "Retry With Backoff Workflow", + "repoPath": "uncategorized/patterns/retry-with-backoff-workflow" + }, + { + "slug": "reverse-logistics-workflow", + "title": "Reverse Logistics Workflow", + "repoPath": "uncategorized/logistics/reverse-logistics-workflow" + }, + { + "slug": "router-workflow", + "title": "Router Workflow", + "repoPath": "uncategorized/patterns/router-workflow" + }, + { + "slug": "search-optimization-workflow", + "title": "Search Optimization Workflow", + "repoPath": "uncategorized/business-operations/search-optimization-workflow" + }, + { + "slug": "snapshot-pattern-workflow", + "title": "Snapshot Pattern Workflow", + "repoPath": "uncategorized/patterns/snapshot-pattern-workflow" + }, + { + "slug": "state-machine-workflow", + "title": "State Machine Workflow", + "repoPath": "uncategorized/patterns/state-machine-workflow" + }, + { + "slug": "strangler-fig-workflow", + "title": "Strangler Fig Workflow", + "repoPath": "uncategorized/patterns/strangler-fig-workflow" + }, + { + "slug": "timeout-pattern-workflow", + "title": "Timeout Pattern Workflow", + "repoPath": "uncategorized/patterns/timeout-pattern-workflow" + }, + { + "slug": "transactional-outbox-workflow", + "title": "Transactional Outbox Workflow", + "repoPath": "uncategorized/patterns/transactional-outbox-workflow" + }, + { + "slug": "transform-workflow", + "title": "Transform Workflow", + "repoPath": "uncategorized/patterns/transform-workflow" + }, + { + "slug": "treasury-management-workflow", + "title": "Treasury Management Workflow", + "repoPath": "uncategorized/finance/treasury-management-workflow" + }, + { + "slug": "user-segmentation-workflow", + "title": "User Segmentation Workflow", + "repoPath": "uncategorized/business-operations/user-segmentation-workflow" + }, + { + "slug": "validator-workflow", + "title": "Validator Workflow", + "repoPath": "uncategorized/patterns/validator-workflow" + }, + { + "slug": "webhook-integration-workflow", + "title": "Webhook Integration Workflow", + "repoPath": "uncategorized/business-operations/webhook-integration-workflow" + }, + { + "slug": "webhook-pattern-workflow", + "title": "Webhook Pattern Workflow", + "repoPath": "uncategorized/patterns/webhook-pattern-workflow" + }, + { + "slug": "microservices-database-per-service-architecture", + "title": "Microservices Database-Per-Service Architecture", + "repoPath": "uncategorized/architecture/microservices-database-per-service-architecture" + }, + { + "slug": "microservices-decomposition-by-business-capability", + "title": "Microservices Decomposition by Business Capability", + "repoPath": "uncategorized/architecture/microservices-decomposition-by-business-capability" + }, + { + "slug": "microservices-backend-for-frontend-architecture", + "title": "Microservices Backend-for-Frontend (BFF) Architecture", + "repoPath": "uncategorized/architecture/microservices-backend-for-frontend-architecture" + }, + { + "slug": "event-driven-publish-subscribe-architecture", + "title": "Event-Driven Publish-Subscribe Architecture", + "repoPath": "uncategorized/architecture/event-driven-publish-subscribe-architecture" + }, + { + "slug": "event-driven-event-sourcing-architecture", + "title": "Event-Driven Event Sourcing Architecture", + "repoPath": "uncategorized/architecture/event-driven-event-sourcing-architecture" + }, + { + "slug": "event-driven-cqrs-with-event-store-architecture", + "title": "Event-Driven CQRS with Event Store Architecture", + "repoPath": "uncategorized/architecture/event-driven-cqrs-with-event-store-architecture" + }, + { + "slug": "event-driven-choreography-architecture", + "title": "Event-Driven Choreography Architecture", + "repoPath": "uncategorized/architecture/event-driven-choreography-architecture" + }, + { + "slug": "event-driven-cdc-change-data-capture-architecture", + "title": "Event-Driven CDC (Change Data Capture) Architecture", + "repoPath": "uncategorized/architecture/event-driven-cdc-change-data-capture-architecture" + }, + { + "slug": "cqrs-read-write-separation-architecture", + "title": "CQRS Read-Write Separation Architecture", + "repoPath": "uncategorized/architecture/cqrs-read-write-separation-architecture" + }, + { + "slug": "cqrs-materialized-view-architecture", + "title": "CQRS Materialized View Architecture", + "repoPath": "uncategorized/architecture/cqrs-materialized-view-architecture" + }, + { + "slug": "cqrs-task-based-ui-architecture", + "title": "CQRS Task-Based UI Architecture", + "repoPath": "uncategorized/architecture/cqrs-task-based-ui-architecture" + }, + { + "slug": "serverless-event-processing-architecture", + "title": "Serverless Event Processing Architecture", + "repoPath": "uncategorized/architecture/serverless-event-processing-architecture" + }, + { + "slug": "saga-choreography-pattern-architecture", + "title": "Saga Choreography Pattern Architecture", + "repoPath": "uncategorized/architecture/saga-choreography-pattern-architecture" + }, + { + "slug": "retry-with-exponential-backoff-architecture", + "title": "Retry with Exponential Backoff Architecture", + "repoPath": "uncategorized/architecture/retry-with-exponential-backoff-architecture" + }, + { + "slug": "rate-limiter-architecture", + "title": "Rate Limiter Architecture", + "repoPath": "uncategorized/architecture/rate-limiter-architecture" + }, + { + "slug": "hexagonal-ports-adapters-architecture", + "title": "Hexagonal (Ports and Adapters) Architecture", + "repoPath": "uncategorized/architecture/hexagonal-ports-adapters-architecture" + }, + { + "slug": "clean-architecture-layers", + "title": "Clean Architecture Layers", + "repoPath": "uncategorized/architecture/clean-architecture-layers" + }, + { + "slug": "domain-driven-design-bounded-contexts-architecture", + "title": "Domain-Driven Design Bounded Contexts Architecture", + "repoPath": "uncategorized/architecture/domain-driven-design-bounded-contexts-architecture" + }, + { + "slug": "outbox-pattern-reliable-messaging-architecture", + "title": "Outbox Pattern for Reliable Messaging Architecture", + "repoPath": "uncategorized/architecture/outbox-pattern-reliable-messaging-architecture" + }, + { + "slug": "data-mesh-architecture", + "title": "Data Mesh Architecture", + "repoPath": "uncategorized/architecture/data-mesh-architecture" + }, + { + "slug": "observability-three-pillars-architecture", + "title": "Observability Three Pillars Architecture", + "repoPath": "uncategorized/architecture/observability-three-pillars-architecture" + }, + { + "slug": "event-driven-notification-hub-architecture", + "title": "Event-Driven Notification Hub Architecture", + "repoPath": "uncategorized/architecture/event-driven-notification-hub-architecture" + } + ] + } + } +}