Rules: Mermaid Graph to Python Pipeline (Explicit Graph Coverage)
## Rules:
- Implement all explicit flows present in the Mermaid diagram:
For each branch, path, or construct that appears in the graph, generate a stub or code for it. Do not block, skip, or invent missing paths; only work with what is actually in the graph.

 - If only one branch is present at a decision, follow it:
Do not infer or fabricate other branches. Mark possible extension points as TODOs if relevant.

 - For all Mermaid constructs (decisions, branches, loops, parallel flows, etc.):

- Handle and map every construct that exists in the diagram, using Python stubs or orchestrator logic as appropriate.

 - For anything not present or any potential future extension:

 - Add a TODO comment or placeholder, describing what might be added and how to extend the pipeline.

 - All class/function stubs must include type hints and detailed docstrings (even if logic is not present).

 - The pipeline orchestrator (controller function/class) should execute all present graph logic, with clear extension points for future logic.

 - Use PEP 8, async/await where relevant, and logging/error handling as stubs or comments.

 - Provide both module and notebook output templates, so the user can choose which to extend.

 - Supply a minimal usage example for all implemented paths.

 - Add a brief rationale at the end: explain what is implemented and where further logic can be added later.

## Definitions:

###Stub:
 Class or function with signature, type hints, and descriptive docstring; logic may be missing or replaced by a TODO.

Create a Mermaid `flowchart TD` diagram visualizing the functional structure and call flow of the current software project.  

**Diagram Content:**

*  **Structure:** Use subgraphs to represent files or modules containing functions/methods from the primary source code directories (e.g., `src/`, `app/`, exclude tests, dependencies).

*  **Functions:** Represent key functions/methods within their respective subgraphs as nodes (labeled `FileName.functionName` or `ClassName.methodName`).

*  **Function Purpose:** For each function node, provide a concise description. *Prioritize* extracting this from existing code comments (docstrings, JSDoc). If comments are absent, *attempt* to infer the purpose based on name and code, clearly marking it as inferred (e.g., "[inferred] Does X").  Display the function purpose as a tooltip associated with the node rather than directly in the node label to maintain visual clarity.

*  **Call Relationships:** Draw directed arrows between function nodes to indicate direct calls made *within* the analyzed project source code.

**Analysis & Highlighting:**

*  **Unused Functions:** Clearly identify and visually distinguish function nodes that are not called by any other analyzed function (potential dead code).

*  **Similar Functionality:** *Attempt* to identify functions that appear to perform highly similar tasks, even if not syntactically identical. Highlight these nodes distinctly and potentially add a note about suspected similarity.

*  **Highlighting** Use Mermaid classDef statements to define distinct styles (e.g., different border color/stroke, fill color) for 'unused' and 'similar' function nodes, and apply these classes to the relevant nodes in the diagram.

**Scope**

*   Focus analysis on primary source code, explicitly excluding test suites, configuration files, and third-party libraries unless instructed otherwise.

*   Exclude any files excluded by .gitignore

**Output:**

*   Use Github flavored markdown.

*   Document has the following layout:
    *   A mermaid graph of the call graph.
    *  A table listing all functions with a brief summary of their purpose.
    *  A table listing dead code (unused functions).
    *  A table listing similar functions.


*   Save it as `docs/CALLGRAPH.md`.    

**Process:**

Follow this step by step process:

1.  Start by creating a list of all appropriate source files.  If a file tree wasn't provided in the prompt create one first.

2.  For each file, parse out function definitions and their direct calls.

3.  Build the graph structure.

4.  For each function analyze it's purpose and add a summary to each function on the graph.

5.  Analyze for unused functions and similar functionality.

6.  Generate the markdown output.
        a. Generate mermaid graph
        b. Generate list of functions with their purposes in markdown table
        c. List dead code in markdown table
        d. List similar functions in markdown table

  You are a Python developer tasked with converting a Mermaid diagram into a Python pipeline scaffold. 
  For each node and flow explicitly present in the graph (including all branches, decisions, loops, and parallelism), generate a Python class/function stub with docstring and type hints. 
  For any branch or path not present in the diagram, do not invent logic; simply proceed with what is shown and add a TODO comment or placeholder if you think extension might be relevant.
  Handle all actual Mermaid constructs as shown in the diagram. 
  Provide output as both a Python module and a notebook template. 
  Include a minimal usage example for the implemented paths. 
  At the end, add a brief rationale explaining what is covered by the scaffold and what could be extended later.