zrb 1.16.3__tar.gz → 1.16.4__tar.gz

{zrb-1.16.3 → zrb-1.16.4}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.3
 Name: zrb
-Version: 1.16.3
+Version: 1.16.4
 Summary: Your Automation Powerhouse
 License: AGPL-3.0-or-later
 Keywords: Automation,Task Runner,Code Generator,Monorepo,Low Code

{zrb-1.16.3 → zrb-1.16.4}/pyproject.toml

@@ -1,6 +1,6 @@
 [tool.poetry]
 name = "zrb"
-version = "1.16.3"
+version = "1.16.4"
 description = "Your Automation Powerhouse"
 authors = ["Go Frendi Gunawan <gofrendiasgard@gmail.com>"]
 license = "AGPL-3.0-or-later"

{zrb-1.16.3 → zrb-1.16.4}/src/zrb/builtin/llm/llm_ask.py

@@ -19,6 +19,12 @@ from zrb.builtin.llm.tool.file import (
     write_many_files,
     write_to_file,
 )
+from zrb.builtin.llm.tool.note import (
+    read_contextual_note,
+    read_long_term_note,
+    write_contextual_note,
+    write_long_term_note,
+)
 from zrb.builtin.llm.tool.web import (
     create_search_internet_tool,
     open_web_page,
@@ -57,7 +63,12 @@ def _get_toolset(ctx: AnyContext) -> list["AbstractToolset[None] | str"]:
 
 
 def _get_tool(ctx: AnyContext) -> list["ToolOrCallable"]:
-    tools = []
+    tools = [
+        read_long_term_note,
+        write_long_term_note,
+        read_contextual_note,
+        write_contextual_note,
+    ]
     if CFG.LLM_ALLOW_ANALYZE_REPO:
         tools.append(analyze_repo)
     if CFG.LLM_ALLOW_ANALYZE_FILE:
@@ -97,8 +108,8 @@ def _get_default_yolo_mode(ctx: AnyContext) -> str:
 def _render_yolo_mode_input(ctx: AnyContext) -> list[str] | bool | None:
     if ctx.input.yolo.strip() == "":
         return None
-    elements = ctx.input.yolo.split(",")
-    if len(elements) == 0:
+    elements = [element.strip() for element in ctx.input.yolo.split(",")]
+    if len(elements) == 1:
         try:
             return to_boolean(elements[0])
         except Exception:

{zrb-1.16.3 → zrb-1.16.4}/src/zrb/builtin/llm/tool/file.py

@@ -104,8 +104,10 @@ def list_files(
 
     This is a fundamental tool for exploring the file system. Use it to
     discover the structure of a directory, find specific files, or get a
-
     general overview of the project layout before performing other operations.
+    **NOTE:**
+    User might provide inaccurate file path, so if you failed to read a file,
+    it is a good idea to list the files to get the accurate file path.
 
     Args:
         path (str, optional): The directory path to list. Defaults to the
@@ -228,9 +230,16 @@ def read_from_file(
     end line.
 
     This tool is essential for inspecting file contents. It can read both text
-    and PDF files. The returned content is prefixed with line numbers, which is
-    crucial for providing context when you need to modify the file later with
-    the `apply_diff` tool.
+    and PDF files. The `content` field in the returned dictionary is **always**
+    prefixed with line numbers (`line_number | `) for each line. These prefixes
+    are added by the tool for internal processing and to provide contextual
+    information to the AI agent (e.g., for accurately applying diffs or for
+    referencing specific lines). They are **not** part of the actual file content.
+
+    When presenting the file content to a user, the AI agent **MUST** omit these
+    line number prefixes by default for better readability. They should only
+    be included if explicitly requested by the user or if the request inherently
+    requires line number context (e.g., 'show me lines 10-20').
 
     Use this tool to:
     - Examine the source code of a file.
@@ -246,18 +255,28 @@ def read_from_file(
 
     Returns:
         dict[str, Any]: A dictionary containing the file path, the requested content
-            with line numbers, the start and end lines, and the total number
+            (always with line numbers), the start and end lines, and the total number
             of lines in the file.
             Example:
             ```
             {
                 "path": "src/main.py",
-                "content": "1| import os\n2|3| print(\"Hello, World!\")",
+                "content": "1| import os\n2|\n3| print(\"Hello, World!\")",
                 "start_line": 1,
                 "end_line": 3,
                 "total_lines": 3
             }
             ```
+            If the file 'src/main.py' contains:
+            ```
+            import os
+
+            print("Hello, World!")
+            ```
+            The 'content' field in the returned dictionary will be:
+            `"1| import os\n2|\n3| print(\"Hello, World!\")"`
+            **IMPORTANT:** The "1|", "2|", "3|" prefixes are NOT part of the
+            original file. They are for internal agent use.
     Raises:
         FileNotFoundError: If the specified file does not exist.
     """
@@ -561,6 +580,17 @@ def read_many_files(paths: list[str]) -> dict[str, str]:
     project relate to each other, or when you need to inspect a set of related
     configuration or source code files.
 
+    The content for each file in the returned dictionary is **always** prefixed
+    with line numbers (`line_number | `) for each line. These prefixes are added
+    by the tool for internal processing and to provide contextual information to
+    the AI agent (e.g., for accurately applying diffs or for referencing specific
+    lines). They are **not** part of the actual file content.
+
+    When presenting the file content to a user, the AI agent **MUST** omit these
+    line number prefixes by default for better readability. They should only
+    be included if explicitly requested by the user or if the request inherently
+    requires line number context (e.g., 'show me lines 10-20').
+
     Args:
         paths (list[str]): A list of paths to the files you want to read. It is
             crucial to provide accurate paths. Use the `list_files` tool first
@@ -568,9 +598,25 @@ def read_many_files(paths: list[str]) -> dict[str, str]:
 
     Returns:
         dict[str, str]:  a dictionary where keys are the file paths and values
-            are their corresponding contents, prefixed with line numbers.
+            are their corresponding contents (always with line numbers).
             If a file cannot be read, its value will be an error message.
-            Example: {"src/api.py": "1| import ...", "config.yaml": "1| key: value"}
+            Example:
+            ```
+            {
+                "src/api.py": "1| import os\n2|\n3| print("Hello, World!")",
+                "config.yaml": "1| key: value"
+            }
+            ```
+            If the file 'src/api.py' contains:
+            ```
+            import os
+
+            print("Hello, World!")
+            ```
+            The content for 'src/api.py' in the returned dictionary will be:
+            `"1| import os\n2|\n3| print("Hello, World!")"`
+            **IMPORTANT:** The "1|", "2|", "3|" prefixes are NOT part of the
+            original file. They are for internal agent use.
     """
     results = {}
     for path in paths:

zrb-1.16.4/src/zrb/builtin/llm/tool/note.py

@@ -0,0 +1,72 @@
+import os
+
+from zrb.config.llm_context.config import llm_context_config
+
+
+def read_long_term_note() -> str:
+    """
+    Reads the global long-term note.
+    This note is shared across all projects and conversations.
+
+    Returns:
+        The content of the long-term note.
+    """
+    contexts = llm_context_config.get_notes()
+    return contexts.get("/", "")
+
+
+def write_long_term_note(content: str) -> str:
+    """
+    Writes content to the global long-term note.
+    The content of this note is intended to be read by the AI Agent in the future.
+    It should contain global information/preference.
+
+    Args:
+        content: The content to write to the long-term note (overwriting the existing one).
+
+    Returns:
+        A confirmation message.
+    """
+    llm_context_config.write_note(content, "/")
+    return "Long term note saved"
+
+
+def read_contextual_note(path: str | None = None) -> str:
+    """
+    Reads a contextual note for a specific path.
+    If no path is provided, it defaults to the current working directory.
+
+    Args:
+        path: The file or directory path to read the note for.
+              Defaults to the current working directory.
+
+    Returns:
+        The content of the contextual note.
+    """
+    if path is None:
+        path = os.getcwd()
+    abs_path = os.path.abspath(path)
+    contexts = llm_context_config.get_notes(cwd=abs_path)
+    return contexts.get(abs_path, "")
+
+
+def write_contextual_note(content: str, path: str | None = None) -> str:
+    """
+    Writes a contextual note for a specific path.
+    The content of this note is intended to be read by the AI Agent in the future.
+    The content should contain contextual information.
+
+    If no path is provided, it defaults to the current working directory.
+
+    Args:
+        content: The new content of the note (overwriting the existing one).
+        path: The file or directory path to associate the note with.
+              Defaults to the current working directory.
+
+    Returns:
+        A confirmation message indicating where the note was saved.
+    """
+    if path is None:
+        path = os.getcwd()
+    llm_context_config.write_note(content, path)
+    return f"Contextual note saved to {path}"

{zrb-1.16.3 → zrb-1.16.4}/src/zrb/config/default_prompt/interactive_system_prompt.md

@@ -1,7 +1,7 @@
 You are an expert interactive AI agent. You MUST follow this workflow for this interactive session. Respond in GitHub-flavored Markdown.
 
 # Core Principles
-- **Be Tool-Centric:** Do not describe what you are about to do. When a decision is made, call the tool directly. Only communicate with the user to ask for clarification/confirmation or to report the final result of an action.
+- **Be Tool-Centric:** Describe what you are about to do. When a decision is made, call the tool directly. Only communicate with the user to ask for clarification/confirmation or to report the final result of an action.
 - **Efficiency:** Use your tools to get the job done with the minimum number of steps. Combine commands where possible.
 - **One Tool at a Time** Only call one tool at a time, wait for the result first before calling the next tool.
 - **Adhere to Conventions:** When modifying existing files or data, analyze the existing content to match its style and format.
@@ -31,4 +31,4 @@ You are an expert interactive AI agent. You MUST follow this workflow for this i
     * **CRITICAL:** Do not ask the user for help or report the failure until you have exhausted all reasonable attempts to fix it yourself.
 
 5. **Report Results:**
-    * Provide a concise summary of the action taken and explicitly state how you verified it.
+    * Provide a concise summary of the action taken and explicitly state how you verified it.

{zrb-1.16.3 → zrb-1.16.4}/src/zrb/config/default_prompt/summarization_prompt.md

@@ -6,11 +6,6 @@ Follow these instructions carefully:
 2. **Transcript:** Extract ONLY the last 4 (four) turns of the `Recent Conversation` to serve as the new transcript.
     * **Do not change or shorten the content of these turns, with one exception:** If a tool call returns a very long output, do not include the full output. Instead, briefly summarize the result of the tool call.
     * Ensure the timestamp format is `[YYYY-MM-DD HH:MM:SS UTC+Z] Role: Message/Tool name being called`.
-3. **Notes:** Review the `Notes` and `Recent Conversation` to identify new or updated facts.
-    * Update `long_term_note` with global facts about the user.
-    * Update `contextual_note` with facts specific to the current project/directory.
-    * **CRITICAL:** When updating `contextual_note`, you MUST determine the correct `context_path`. For example, if a fact was established when the working directory was `/app`, the `context_path` MUST be `/app`.
-    * **CRITICAL:** Note content must be **brief**, raw, unformatted text, not a log of events. Only update notes if information has changed.
-4. **Update Memory:** Call the `final_result` tool with all the information you consolidated.
+3. **Update Memory:** Call the `final_result` tool with all the information you consolidated.
 
 After you have called the tool, your task is complete.

{zrb-1.16.3 → zrb-1.16.4}/src/zrb/config/llm_context/config.py

@@ -54,7 +54,7 @@ class LLMContextConfig:
             f.write(new_file_content)
 
     def get_notes(self, cwd: str | None = None) -> dict[str, str]:
-        """Gathers all relevant contexts for a given path."""
+        """Gathers all notes for a given path."""
         if cwd is None:
             cwd = os.getcwd()
         config_file = self._get_home_config_file()

{zrb-1.16.3 → zrb-1.16.4}/src/zrb/group/any_group.py

@@ -1,13 +1,9 @@
 from abc import ABC, abstractmethod
-from typing import Generic, TypeVar
 
 from zrb.task.any_task import AnyTask
 
-GroupType = TypeVar("GroupType", bound="AnyGroup")
-TaskType = TypeVar("TaskType", bound=AnyTask)
 
-
-class AnyGroup(ABC, Generic[GroupType, TaskType]):
+class AnyGroup(ABC):
     @property
     @abstractmethod
     def name(self) -> str:
@@ -39,11 +35,11 @@ class AnyGroup(ABC, Generic[GroupType, TaskType]):
         pass
 
     @abstractmethod
-    def add_group(self, group: GroupType, alias: str | None) -> GroupType:
+    def add_group(self, group: "AnyGroup", alias: str | None) -> "AnyGroup":
         pass
 
     @abstractmethod
-    def add_task(self, task: TaskType, alias: str | None = None) -> TaskType:
+    def add_task(self, task: "AnyTask", alias: str | None = None) -> "AnyTask":
         pass
 
     @abstractmethod

{zrb-1.16.3 → zrb-1.16.4}/src/zrb/group/group.py

@@ -1,10 +1,8 @@
-from typing import Generic, TypeVar
-
-from zrb.group.any_group import AnyGroup, GroupType, TaskType
+from zrb.group.any_group import AnyGroup
 from zrb.task.any_task import AnyTask
 
 
-class Group(AnyGroup, Generic[GroupType, TaskType]):
+class Group(AnyGroup):
     def __init__(
         self, name: str, description: str | None = None, banner: str | None = None
     ):
@@ -35,21 +33,21 @@ class Group(AnyGroup, Generic[GroupType, TaskType]):
     def subgroups(self) -> dict[str, AnyGroup]:
         names = list(self._groups.keys())
         names.sort()
-        return {name: self._groups.get(name) for name in names}
+        return {name: self._groups[name] for name in names}
 
     @property
     def subtasks(self) -> dict[str, AnyTask]:
         alias = list(self._tasks.keys())
         alias.sort()
-        return {name: self._tasks.get(name) for name in alias}
+        return {name: self._tasks[name] for name in alias}
 
-    def add_group(self, group: GroupType, alias: str | None = None) -> GroupType:
-        real_group: GroupType = Group(group) if isinstance(group, str) else group
+    def add_group(self, group: AnyGroup, alias: str | None = None) -> AnyGroup:
+        real_group = Group(group) if isinstance(group, str) else group
         alias = alias if alias is not None else real_group.name
         self._groups[alias] = real_group
         return real_group
 
-    def add_task(self, task: TaskType, alias: str | None = None) -> TaskType:
+    def add_task(self, task: AnyTask, alias: str | None = None) -> AnyTask:
         alias = alias if alias is not None else task.name
         self._tasks[alias] = task
         return task

zrb-1.16.4/src/zrb/task/llm/default_workflow/coding.md

@@ -0,0 +1,64 @@
+When your primary task is to write, refactor, or fix code, you MUST follow this comprehensive software development workflow. This process is designed to ensure your contributions are safe, high-quality, and align with existing project conventions.
+
+# 1. Core Mandates & Prohibitions
+
+These are non-negotiable rules.
+
+- **Conventions First:** Rigorously adhere to existing project conventions. Your primary goal is to make it look like the existing codebase's author wrote the code.
+- **Mimic Style & Structure:** Match the formatting, naming, structure, framework choices, typing, and architectural patterns of the code you're editing.
+- **NEVER Assume Dependencies:** You MUST NOT use a library, framework, or package unless you have first verified it is an existing project dependency (e.g., by checking `package.json`, `requirements.txt`, `pyproject.toml`, etc.).
+- **NEVER Commit Without Verification:** You MUST NOT use version control tools like `git commit` until you have staged the changes and successfully run the project's own verification steps (tests, linter, build).
+
+# 2. The Software Development Workflow
+
+Follow this sequence for all coding tasks.
+
+### Step 1: Understand & Strategize
+
+Before writing a single line of code, you MUST gather context.
+
+- **Analyze the Request:** Break down the user's request into concrete requirements.
+- **Explore the Codebase:** Use file search and read tools extensively to build a mental model.
+  - **Identify Relevant Files:** Locate the primary files that need modification.
+  - **Discover Conventions:** Look for configuration files (`.eslintrc`, `.prettierrc`, `ruff.toml`, etc.). Analyze surrounding source files to determine naming conventions, typing style, error handling patterns, and architecture.
+  - **Understand the Safety Net:** Find existing tests. Understanding how the project tests its code is critical for your implementation and verification steps.
+- **Check Dependencies:** Verify that any libraries you plan to use are already part of the project.
+
+### Step 2: Plan
+
+Based on your understanding, create and communicate a clear plan.
+
+- **Formulate a Plan:** Build a coherent, step-by-step plan to implement the required changes.
+- **Share the Plan:** Present a concise summary of your plan to the user before you begin writing code. This ensures alignment and allows for course correction.
+
+### Step 3: Implement Idiomatically
+
+Execute your plan, adhering strictly to the patterns discovered in the "Understand" phase.
+
+- **Write/Modify Code:** Make the necessary changes.
+- **CRITICAL: Design for Testability:** Produce code that is easy to test automatically. This is a core principle of good software engineering.
+  - **Prefer `return` over `print`:** Core logic functions MUST `return` values. I/O operations like `print()` should be separated into different, testable functions.
+  - **Embrace Modularity:** Decompose complex tasks into smaller, single-responsibility functions or classes that can be tested independently.
+  - **Use Function Arguments:** Avoid relying on global state. Pass necessary data into functions as arguments to make them pure and predictable.
+
+### Step 4: Verify with Tests
+
+This is the first of two critical verification phases. You are responsible for ensuring your changes work as expected.
+
+- **Run Existing Tests:** Execute the project's full test suite (e.g., `npm run test`, `pytest`).
+- **Add New Tests:** For new features or bug fixes, add corresponding unit or integration tests to prove your code works and prevent future regressions.
+- **Debug and Fix:** If any tests fail, you MUST enter a debugging loop. Analyze the errors, fix the code, and re-run the tests until they all pass.
+
+### Step 5: Verify with Standards
+
+This second verification phase ensures your code meets the project's quality standards.
+
+- **Run Linters & Formatters:** Use the project's linting and formatting commands (e.g., `npm run lint`, `ruff check .`).
+- **Run Build Processes:** If applicable, run the build command (e.g., `npm run build`, `tsc`) to check for compilation or type-checking errors.
+- **Debug and Fix:** Just as with testing, if any of these checks fail, you MUST debug and fix the issues until all standards are met.
+
+### Step 6: Finalize
+
+Only after all verification steps have passed is the task complete.
+
+- **Await Instruction:** Do not remove any created files (like tests). Await the user's next instruction. If they are satisfied, you can suggest committing the changes.

{zrb-1.16.3 → zrb-1.16.4}/src/zrb/task/llm/history_summarization.py

@@ -124,23 +124,6 @@ async def summarize_history(
                 json.dumps(truncate_str(conversation_history.history, 1000)),
                 as_code=True,
             ),
-            make_prompt_section(
-                "Notes",
-                "\n".join(
-                    [
-                        make_prompt_section(
-                            "Long Term",
-                            conversation_history.long_term_note,
-                            as_code=True,
-                        ),
-                        make_prompt_section(
-                            "Contextual",
-                            conversation_history.contextual_note,
-                            as_code=True,
-                        ),
-                    ]
-                ),
-            ),
         ]
     )
     summarize = create_history_summarization_tool(conversation_history)

{zrb-1.16.3 → zrb-1.16.4}/src/zrb/task/llm/history_summarization_tool.py

@@ -7,32 +7,20 @@ from zrb.task.llm.conversation_history_model import ConversationHistory
 
 def create_history_summarization_tool(
     conversation_history: ConversationHistory,
-) -> Callable[[str, str, str | None, str | None, str | None], str]:
+) -> Callable[[str, str], str]:
     def update_conversation_memory(
         past_conversation_summary: str,
         past_conversation_transcript: str,
-        long_term_note: str | None = None,
-        contextual_note: str | None = None,
-        context_path: str | None = None,
     ) -> str:
         """
-        Update the conversation memory including summary, transcript, and notes.
+        Update the conversation memory including summary and transcript.
         - past_conversation_summary: A concise narrative that integrates the
           previous summary with the recent conversation.
         - past_conversation_transcript: MUST be ONLY the last 4 (four) turns
           of the conversation.
-        - long_term_note: Global facts about the user or their preferences.
-        - contextual_note: Facts specific to the current project or directory.
-        - context_path: The directory path for the contextual note.
         """
         conversation_history.past_conversation_summary = past_conversation_summary
         conversation_history.past_conversation_transcript = past_conversation_transcript
-        if long_term_note is not None:
-            llm_context_config.write_note(long_term_note, context_path="/")
-        if contextual_note is not None:
-            if context_path is None:
-                context_path = conversation_history.project_path
-            llm_context_config.write_note(contextual_note, context_path=context_path)
         return "Conversation memory updated"
 
     return update_conversation_memory

{zrb-1.16.3 → zrb-1.16.4}/src/zrb/task/llm/tool_wrapper.py

@@ -111,16 +111,24 @@ def _create_wrapper(
             # somehow provided it.
             kwargs[any_context_param_name] = ctx
         try:
+            has_ever_edited = False
             if not ctx.is_web_mode and ctx.is_tty:
                 if (
                     isinstance(yolo_mode, list) and func.__name__ not in yolo_mode
                 ) or not yolo_mode:
-                    approval, reason = await _handle_user_response(
+                    approval, reason, has_ever_edited = await _handle_user_response(
                         ctx, func, args, kwargs
                     )
                     if not approval:
                         raise ToolExecutionCancelled(f"User disapproving: {reason}")
-            return await run_async(func(*args, **kwargs))
+            result = await run_async(func(*args, **kwargs))
+            if has_ever_edited:
+                return {
+                    "tool_call_result": result,
+                    "new_tool_parameters": kwargs,
+                    "message": "User has intercepted tool call and updated the parameters",
+                }
+            return result
         except KeyboardInterrupt as e:
             raise e
         except Exception as e:
@@ -140,7 +148,8 @@ async def _handle_user_response(
     func: Callable,
     args: list[Any] | tuple[Any],
     kwargs: dict[str, Any],
-) -> tuple[bool, str]:
+) -> tuple[bool, str, bool]:
+    has_ever_edited = False
     while True:
         func_call_str = _get_func_call_str(func, args, kwargs)
         complete_confirmation_message = "\n".join(
@@ -156,13 +165,15 @@ async def _handle_user_response(
         new_kwargs, is_edited = _get_edited_kwargs(ctx, user_response, kwargs)
         if is_edited:
             kwargs = new_kwargs
+            has_ever_edited = True
             continue
         approval_and_reason = _get_user_approval_and_reason(
             ctx, user_response, func_call_str
         )
         if approval_and_reason is None:
             continue
-        return approval_and_reason
+        approval, reason = approval_and_reason
+        return approval, reason, has_ever_edited
 
 
 def _get_edited_kwargs(

{zrb-1.16.3 → zrb-1.16.4}/src/zrb/task/llm_task.py

@@ -205,8 +205,6 @@ class LLMTask(BaseTask):
         self.append_toolset(*toolset)
 
     def append_toolset(self, *toolset: "AbstractToolset[None] | str"):
-        from pydantic_ai.mcp import load_mcp_servers
-
         for single_toolset in toolset:
             self._additional_toolsets.append(single_toolset)
 

zrb-1.16.3/src/zrb/task/llm/default_workflow/coding.md

@@ -1,24 +0,0 @@
-When the user's request involves writing or modifying code, you MUST follow these domain-specific rules in addition to your core workflow.
-
-## 1. Critical Prohibitions
-- **NEVER Assume Dependencies:** You MUST NOT use a library, framework, or package unless you have first verified it is an existing project dependency (e.g., in `package.json`, `requirements.txt`, `pyproject.toml`, etc.).
-- **NEVER Commit Without Verification:** You MUST NOT use `git commit` until you have staged the changes and run the project's own verification steps (tests, linter, build).
-
-## 2. Code Development Workflow
-This expands on your core "Execute and Verify" loop with steps specific to coding.
-
-1.  **CRITICAL: Gather Context First:** Before writing or modifying any code, you MUST gather context to ensure your changes are idiomatic and correct.
-    *   **Project Structure & Dependencies:** Check for `README.md`, `package.json`, etc., to understand the project's scripts (lint, test, build).
-    *   **Code Style & Conventions:** Look for `.eslintrc`, `.prettierrc`, `ruff.toml`, etc. Analyze surrounding source files to determine naming conventions, typing style, error handling, and architectural patterns.
-    *   **For new tests:** You MUST read the full source code of the module(s) you are testing.
-    *   **For new features:** You MUST look for existing tests and related modules to understand conventions.
-
-2.  **Implement Idiomatically:** Make the changes, strictly adhering to the patterns and conventions discovered in the context-gathering phase.
-
-3.  **CRITICAL: Design for Testability:** Your primary goal is to produce code that is easy to test automatically.
-    *   **Prefer `return` over `print`:** Core logic functions MUST `return` values. I/O operations like `print()` should be separated into different functions.
-    *   **Embrace Modularity:** Decompose complex tasks into smaller, single-responsibility functions or classes.
-    *   **Use Function Arguments:** Avoid relying on global state. Pass necessary data into functions as arguments.
-
-4.  **Verify with Project Tooling:** After implementation, run all relevant project-specific commands (e.g., `npm run test`, `pytest`, `npm run lint`). This is the verification step for code.
-    *   **CRITICAL:** If any verification step fails, you MUST enter your standard Debugging Loop. You are responsible for fixing the code until all project-specific verifications pass. Do not stop until the code is working correctly.