zrb 1.13.1__py3-none-any.whl → 1.21.17__py3-none-any.whl

zrb/task/llm/conversation_history.py

@@ -1,18 +1,45 @@
 import json
+import os
 from collections.abc import Callable
 from copy import deepcopy
 from typing import Any
 
 from zrb.attr.type import StrAttr
+from zrb.config.llm_context.config import llm_context_config
 from zrb.context.any_context import AnyContext
-from zrb.context.any_shared_context import AnySharedContext
 from zrb.task.llm.conversation_history_model import ConversationHistory
 from zrb.task.llm.typing import ListOfDict
 from zrb.util.attr import get_str_attr
-from zrb.util.file import write_file
+from zrb.util.file import read_file, write_file
+from zrb.util.markdown import make_markdown_section
 from zrb.util.run import run_async
 
 
+def inject_conversation_history_notes(conversation_history: ConversationHistory):
+    conversation_history.long_term_note = _fetch_long_term_note(
+        conversation_history.project_path
+    )
+    conversation_history.contextual_note = _fetch_contextual_note(
+        conversation_history.project_path
+    )
+
+
+def _fetch_long_term_note(project_path: str) -> str:
+    contexts = llm_context_config.get_notes(cwd=project_path)
+    return contexts.get("/", "")
+
+
+def _fetch_contextual_note(project_path: str) -> str:
+    contexts = llm_context_config.get_notes(cwd=project_path)
+    return "\n".join(
+        [
+            make_markdown_section(header, content)
+            for header, content in contexts.items()
+            if header != "/"
+        ]
+    )
+
+
 def get_history_file(
     ctx: AnyContext,
     conversation_history_file_attr: StrAttr | None,
@@ -27,16 +54,59 @@ def get_history_file(
     )
 
 
+async def _read_from_source(
+    ctx: AnyContext,
+    reader: Callable[[AnyContext], dict[str, Any] | list | None] | None,
+    file_path: str | None,
+) -> "ConversationHistory | None":
+    # Priority 1: Reader function
+    if reader:
+        try:
+            raw_data = await run_async(reader(ctx))
+            if raw_data:
+                instance = ConversationHistory.parse_and_validate(
+                    ctx, raw_data, "reader"
+                )
+                if instance:
+                    return instance
+        except Exception as e:
+            ctx.log_warning(
+                f"Error executing conversation history reader: {e}. Ignoring."
+            )
+    # Priority 2: History file
+    if file_path and os.path.isfile(file_path):
+        try:
+            content = read_file(file_path)
+            raw_data = json.loads(content)
+            instance = ConversationHistory.parse_and_validate(
+                ctx, raw_data, f"file '{file_path}'"
+            )
+            if instance:
+                return instance
+        except json.JSONDecodeError:
+            ctx.log_warning(
+                f"Could not decode JSON from history file '{file_path}'. "
+                "Ignoring file content."
+            )
+        except Exception as e:
+            ctx.log_warning(
+                f"Error reading history file '{file_path}': {e}. "
+                "Ignoring file content."
+            )
+    # Fallback: Return default value
+    return None
+
+
 async def read_conversation_history(
     ctx: AnyContext,
     conversation_history_reader: (
-        Callable[[AnySharedContext], ConversationHistory | dict | list | None] | None
+        Callable[[AnyContext], ConversationHistory | dict | list | None] | None
     ),
     conversation_history_file_attr: StrAttr | None,
     render_history_file: bool,
     conversation_history_attr: (
         ConversationHistory
-        | Callable[[AnySharedContext], ConversationHistory | dict | list]
+        | Callable[[AnyContext], ConversationHistory | dict | list]
         | dict
         | list
     ),
@@ -46,7 +116,7 @@ async def read_conversation_history(
         ctx, conversation_history_file_attr, render_history_file
     )
     # Use the class method defined above
-    history_data = await ConversationHistory.read_from_source(
+    history_data = await _read_from_source(
         ctx=ctx,
         reader=conversation_history_reader,
         file_path=history_file,
@@ -80,7 +150,7 @@ async def write_conversation_history(
     ctx: AnyContext,
     history_data: ConversationHistory,
     conversation_history_writer: (
-        Callable[[AnySharedContext, ConversationHistory], None] | None
+        Callable[[AnyContext, ConversationHistory], None] | None
     ),
     conversation_history_file_attr: StrAttr | None,
     render_history_file: bool,

zrb/task/llm/conversation_history_model.py

@@ -1,14 +1,9 @@
 import json
 import os
-from collections.abc import Callable
 from typing import Any
 
-from zrb.config.llm_context.config import llm_context_config
 from zrb.context.any_context import AnyContext
 from zrb.task.llm.typing import ListOfDict
-from zrb.util.file import read_file
-from zrb.util.llm.prompt import make_prompt_section
-from zrb.util.run import run_async
 
 
 class ConversationHistory:
@@ -41,50 +36,6 @@ class ConversationHistory:
     def model_dump_json(self, indent: int = 2) -> str:
         return json.dumps(self.to_dict(), indent=indent)
 
-    @classmethod
-    async def read_from_source(
-        cls,
-        ctx: AnyContext,
-        reader: Callable[[AnyContext], dict[str, Any] | list | None] | None,
-        file_path: str | None,
-    ) -> "ConversationHistory | None":
-        # Priority 1: Reader function
-        if reader:
-            try:
-                raw_data = await run_async(reader(ctx))
-                if raw_data:
-                    instance = cls.parse_and_validate(ctx, raw_data, "reader")
-                    if instance:
-                        return instance
-            except Exception as e:
-                ctx.log_warning(
-                    f"Error executing conversation history reader: {e}. Ignoring."
-                )
-        # Priority 2: History file
-        if file_path and os.path.isfile(file_path):
-            try:
-                content = read_file(file_path)
-                raw_data = json.loads(content)
-                instance = cls.parse_and_validate(ctx, raw_data, f"file '{file_path}'")
-                if instance:
-                    return instance
-            except json.JSONDecodeError:
-                ctx.log_warning(
-                    f"Could not decode JSON from history file '{file_path}'. "
-                    "Ignoring file content."
-                )
-            except Exception as e:
-                ctx.log_warning(
-                    f"Error reading history file '{file_path}': {e}. "
-                    "Ignoring file content."
-                )
-        # Fallback: Return default value
-        return None
-
-    def fetch_newest_notes(self):
-        self._fetch_long_term_note()
-        self._fetch_contextual_note()
-
     @classmethod
     def parse_and_validate(
         cls, ctx: AnyContext, data: Any, source: str
@@ -121,122 +72,3 @@ class ConversationHistory:
                 f"Error validating/parsing history data from {source}: {e}. Ignoring."
             )
         return cls()
-
-    def write_past_conversation_summary(self, past_conversation_summary: str):
-        """
-        Write or update the past conversation summary.
-
-        Use this tool to store or update a summary of previous conversations for
-        future reference. This is useful for providing context to LLMs or other tools
-        that need a concise history.
-
-        Args:
-            past_conversation_summary (str): The summary text to store.
-
-        Returns:
-            str: A JSON object indicating the success or failure of the operation.
-
-        Raises:
-            Exception: If the summary cannot be written.
-        """
-        self.past_conversation_summary = past_conversation_summary
-        return json.dumps({"success": True})
-
-    def write_past_conversation_transcript(self, past_conversation_transcript: str):
-        """
-        Write or update the past conversation transcript.
-
-        Use this tool to store or update the full transcript of previous conversations.
-        This is useful for providing detailed context to LLMs or for record-keeping.
-
-        Args:
-            past_conversation_transcript (str): The transcript text to store.
-
-        Returns:
-            str: A JSON object indicating the success or failure of the operation.
-
-        Raises:
-            Exception: If the transcript cannot be written.
-        """
-        self.past_conversation_transcript = past_conversation_transcript
-        return json.dumps({"success": True})
-
-    def read_long_term_note(self) -> str:
-        """
-        Read the content of the long-term references.
-
-        This tool helps you retrieve knowledge or notes stored for long-term reference.
-        If the note does not exist, you may want to create it using the write tool.
-
-        Returns:
-            str: JSON with content of the notes.
-
-        Raises:
-            Exception: If the note cannot be read.
-        """
-        return json.dumps({"content": self._fetch_long_term_note()})
-
-    def write_long_term_note(self, content: str) -> str:
-        """
-        Write the entire content of the long-term references.
-        This will overwrite any existing long-term notes.
-
-        Args:
-            content (str): The full content of the long-term notes.
-
-        Returns:
-            str: JSON indicating success.
-        """
-        llm_context_config.write_context(content, context_path="/")
-        return json.dumps({"success": True})
-
-    def read_contextual_note(self) -> str:
-        """
-        Read the content of the contextual references for the current project.
-
-        This tool helps you retrieve knowledge or notes stored for contextual reference.
-        If the note does not exist, you may want to create it using the write tool.
-
-        Returns:
-            str: JSON with content of the notes.
-
-        Raises:
-            Exception: If the note cannot be read.
-        """
-        return json.dumps({"content": self._fetch_contextual_note()})
-
-    def write_contextual_note(
-        self, content: str, context_path: str | None = None
-    ) -> str:
-        """
-        Write the entire content of the contextual references for a specific path.
-        This will overwrite any existing contextual notes for that path.
-
-        Args:
-            content (str): The full content of the contextual notes.
-            context_path (str, optional): The directory path for the context.
-                                        Defaults to the current project path.
-
-        Returns:
-            str: JSON indicating success.
-        """
-        if context_path is None:
-            context_path = self.project_path
-        llm_context_config.write_context(content, context_path=context_path)
-        return json.dumps({"success": True})
-
-    def _fetch_long_term_note(self):
-        contexts = llm_context_config.get_contexts(cwd=self.project_path)
-        self.long_term_note = contexts.get("/", "")
-        return self.long_term_note
-
-    def _fetch_contextual_note(self):
-        contexts = llm_context_config.get_contexts(cwd=self.project_path)
-        self.contextual_note = "\n".join(
-            [
-                make_prompt_section(header, content)
-                for header, content in contexts.items()
-                if header != "/"
-            ]
-        )
-        return self.contextual_note

zrb/task/llm/default_workflow/coding/workflow.md

@@ -0,0 +1,41 @@
+---
+description: "A comprehensive workflow for software engineering tasks, including writing, modifying, and debugging code, as well as creating new applications. ALWAYS activate this workflow whenever you need to deal with software engineering tasks."
+---
+
+This workflow provides a structured approach to software engineering tasks. Adhere to these guidelines to deliver high-quality, idiomatic code that respects the project's existing patterns and conventions.
+
+# Workflow Loading Strategy
+
+This is a general-purpose coding workflow. For tasks involving specific languages or tools, you **MUST** load the relevant specialized workflows.
+
+- **If the task involves Python:** Load the `python` workflow.
+- **If the task involves Git:** Load the `git` workflow.
+- **If the task involves shell scripting:** Load the `shell` workflow.
+- **If the task involves Go:** Load the `golang` workflow.
+- **If the task involves Java:** Load the `java` workflow.
+- **If the task involves Javascript/Typescript:** Load the `javascript` workflow.
+- **If the task involves HTML/CSS:** Load the `html-css` workflow.
+- **If the task involves Rust:** Load the `rust` workflow.
+
+Always consider if a more specific workflow is available and appropriate for the task at hand.
+
+# Core Mandates
+
+- **Conventions:** Rigorously adhere to existing project conventions when reading or modifying code. Analyze surrounding code, tests, and configuration first.
+- **Libraries/Frameworks:** NEVER assume a library/framework is available or appropriate. Verify its established usage within the project (check imports, configuration files like 'package.json', 'Cargo.toml', 'requirements.txt', 'build.gradle', etc., or observe neighboring files) before employing it.
+- **Style & Structure:** Mimic the style (formatting, naming), structure, framework choices, typing, and architectural patterns of existing code in the project.
+- **Idiomatic Changes:** When editing, understand the local context (imports, functions/classes) to ensure your changes integrate naturally and idiomatically.
+- **Comments:** Add code comments sparingly. Focus on *why* something is done, especially for complex logic, rather than *what* is done. Only add high-value comments if necessary for clarity or if requested by the user. Do not edit comments that are separate from the code you are changing. *NEVER* talk to the user or describe your changes through comments.
+- **Proactiveness:** Fulfill the user's request thoroughly. When adding features or fixing bugs, this includes adding tests to ensure quality. Consider all created files, especially tests, to be permanent artifacts unless the user says otherwise.
+- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If asked *how* to do something, explain first, don't just do it.
+- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
+- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
+
+# Software Engineering Tasks
+When requested to perform tasks like fixing bugs, adding features, refactoring, or explaining code, follow this sequence:
+1. **Understand & Strategize:** Think about the user's request and the relevant codebase context. When the task involves **complex refactoring, codebase exploration or system-wide analysis**, your **first and primary tool** must be 'codebase_investigator'. Use it to build a comprehensive understanding of the code, its structure, and dependencies. For **simple, targeted searches** (like finding a specific function name, file path, or variable declaration), you should use 'search_file_content' or 'glob' directly.
+2. **Plan:** Build a coherent and grounded (based on the understanding in step 1) plan for how you intend to resolve the user's task. Share an extremely concise yet clear plan with the user if it would help the user understand your thought process. As part of the plan, you should use an iterative development process that includes writing unit tests to verify your changes. Use output logs or debug statements as part of this process to arrive at a solution.
+3. **Implement:** Use the available tools (e.g., 'replace_in_file', 'write_to_file' 'run_shell_command' ...) to act on the plan, strictly adhering to the project's established conventions (detailed under 'Core Mandates').
+4. **Verify (Tests):** If applicable and feasible, verify the changes using the project's testing procedures. Identify the correct test commands and frameworks by examining 'README' files, build/package configuration (e.g., 'package.json'), or existing test execution patterns. NEVER assume standard test commands.
+5. **Verify (Standards):** VERY IMPORTANT: After making code changes, execute the project-specific build, linting and type-checking commands (e.g., 'tsc', 'npm run lint', 'ruff check .') that you have identified for this project (or obtained from the user). This ensures code quality and adherence to standards. If unsure about these commands, you can ask the user if they'd like you to run them and if so how to.
+6. **Finalize:** After all verification passes, consider the task complete. Do not remove or revert any changes or created files (like tests). Await the user's next instruction.

zrb/task/llm/default_workflow/copywriting/workflow.md

@@ -0,0 +1,68 @@
+---
+description: "A workflow for creating, refining, and organizing textual content."
+---
+Follow this workflow to produce content that is not just correct, but compelling, clear, and perfectly suited to its purpose.
+
+# Core Mandates
+
+- **Audience-First:** Always understand who you're writing for and what they need to know
+- **Purpose-Driven:** Every piece of content must serve a clear objective
+- **Quality Standards:** Deliver polished, professional content that meets the highest standards
+- **Iterative Refinement:** Content improves through multiple rounds of review and editing
+
+# Tool Usage Guideline
+- Use `read_from_file` to analyze existing content and style guides
+- Use `write_to_file` for creating new content drafts
+- Use `replace_in_file` for targeted edits and refinements
+
+# Step 1: Understand Intent and Audience
+
+1. **Define the Goal:** What is this text supposed to achieve? (e.g., persuade, inform, entertain, sell). If the user is vague, ask for clarification.
+2. **Identify the Audience:** Who are you writing for? (e.g., experts, beginners, customers). This dictates your tone, vocabulary, and level of detail.
+3. **Determine the Tone:** Choose a voice that serves the goal and resonates with the audience (e.g., formal, witty, technical, urgent).
+4. **Analyze Existing Content:** Review any provided examples, style guides, or reference materials to understand established patterns.
+
+# Step 2: Plan and Outline
+
+1. **Create Logical Structure:** Develop an outline that flows naturally from introduction to conclusion
+2. **Key Sections:** Identify main talking points and supporting arguments
+3. **Call-to-Action:** Define what you want the reader to do or think after reading
+4. **Get Approval:** Present the outline to the user for confirmation before proceeding
+
+# Step 3: Draft with Purpose
+
+1. **Hook the Reader:** Start with a strong opening that grabs attention
+2. **Use Active Voice:** Make your writing direct and energetic
+3. **Show, Don't Just Tell:** Use examples, stories, and data to illustrate your points
+4. **Maintain Consistency:** Stick to the established tone and style throughout
+
+# Step 4: Refine and Polish
+
+1. **Read Aloud:** Catch awkward phrasing and grammatical errors
+2. **Cut Mercilessly:** Remove anything that doesn't serve the goal
+3. **Enhance Readability:** Use short paragraphs, headings, bullet points, and bold text
+4. **Verify Accuracy:** Ensure all facts, figures, and claims are correct
+
+# Step 5: Task-Specific Execution
+
+## Summarization
+- Distill the essence while preserving key information
+- Be objective and ruthless in cutting fluff
+- Maintain the original meaning and context
+
+## Proofreading
+- Correct grammar, spelling, and punctuation
+- Improve sentence flow and clarity
+- Preserve the original meaning and voice
+
+## Refining/Editing
+- Sharpen the author's message
+- Strengthen arguments and improve clarity
+- Ensure consistent tone while respecting the original voice
+
+# Step 6: Finalize and Deliver
+
+- Present the final content to the user
+- Be prepared to make additional refinements based on feedback
+- Ensure the content meets all stated objectives
+- Confirm the content is ready for its intended use

zrb/task/llm/default_workflow/git/workflow.md

@@ -0,0 +1,118 @@
+---
+description: "A workflow for managing version control with git."
+---
+Follow this workflow for safe, consistent, and effective version control operations.
+
+# Core Mandates
+
+- **Safety First:** Never force operations that could lose data
+- **Atomic Commits:** One logical change per commit
+- **Descriptive Messages:** Explain the "why" in imperative mood
+- **Clean History:** Maintain a readable and useful commit history
+
+# Tool Usage Guideline
+- Use `run_shell_command` for all git operations
+- Use `read_from_file` to examine git configuration files
+- Use `search_files` to find specific commit messages or patterns
+
+# Step 1: Pre-Operation Safety Check
+
+1. **Check Status:** Always run `git status` before operations
+2. **Verify Working Directory:** Ensure the working directory is clean before destructive operations
+3. **Review Changes:** Use `git diff` and `git diff --staged` to understand what will be committed
+4. **Backup Important Changes:** Consider stashing or creating a backup branch for risky operations
+
+# Step 2: Standard Development Workflow
+
+1. **Create Feature Branch:** `git checkout -b <branch-name>`
+2. **Make Changes:** Implement features or fixes
+3. **Stage Changes:** Use `git add -p` for precision staging
+4. **Commit with Description:** Write clear, descriptive commit messages
+5. **Review and Amend:** Use `git log -1` to review, amend if needed
+6. **Push to Remote:** `git push origin <branch-name>`
+
+# Step 3: Commit Message Standards
+
+```
+feat: Add user authentication endpoint
+
+Implement the /login endpoint using JWT for token-based auth.
+This resolves issue #123 by providing a mechanism for users to
+log in and receive an access token.
+```
+
+- **Type Prefix:** feat, fix, docs, style, refactor, test, chore
+- **Imperative Mood:** "Add feature" not "Added feature"
+- **50/72 Rule:** 50 character subject, 72 character body lines
+
+# Step 4: Branch Management
+
+## Safe Branch Operations
+- **Create:** `git checkout -b <name>` or `git switch -c <name>`
+- **Switch:** `git switch <name>`
+- **Update:** `git rebase main` (use with care)
+- **Merge:** `git merge --no-ff <branch>` for explicit merge commits
+
+## Remote Branch Operations
+- **Fetch Updates:** `git fetch origin`
+- **Push:** `git push origin <branch>`
+- **Delete Remote:** `git push origin --delete <branch>`
+
+# Step 5: Advanced Operations (Use with Caution)
+
+## Rebasing
+- **Update Branch:** `git rebase main`
+- **Interactive:** `git rebase -i <commit>` for history editing
+- **Safety:** Never rebase shared/public branches
+
+## Stashing
+- **Save Changes:** `git stash push -m "message"`
+- **List Stashes:** `git stash list`
+- **Apply:** `git stash pop` or `git stash apply`
+
+## Cherry-picking
+- **Apply Specific Commit:** `git cherry-pick <commit-hash>`
+- **Use Case:** Only when absolutely necessary to avoid duplicate commits
+
+# Step 6: Verification and Cleanup
+
+1. **Verify Operations:** Check `git status` and `git log` after operations
+2. **Run Tests:** Ensure all tests pass after changes
+3. **Clean Up:** Remove temporary branches and stashes when no longer needed
+4. **Document:** Update documentation if workflow changes affect team processes
+
+# Risk Assessment Guidelines
+
+## Low Risk (Proceed Directly)
+- `git status`, `git log`, `git diff`
+- Creating new branches
+- Stashing changes
+
+## Moderate Risk (Explain and Confirm)
+- `git rebase` operations
+- `git push --force-with-lease`
+- Deleting branches
+
+## High Risk (Refuse and Explain)
+- `git push --force` (use --force-with-lease instead)
+- Operations that could lose commit history
+- Modifying shared/public branches
+
+# Common Commands Reference
+
+## Status & History
+- `git status`: Check working directory status
+- `git diff`: See uncommitted changes to tracked files
+- `git diff --staged`: See staged changes
+- `git log --oneline --graph -10`: View recent commit history
+- `git blame <file>`: See who changed what in a file
+
+## Branch Operations
+- `git branch -a`: List all branches (local and remote)
+- `git branch -d <branch>`: Delete a local branch
+- `git remote prune origin`: Clean up remote tracking branches
+
+## Configuration
+- `git config --list`: View current configuration
+- `git config user.name "Your Name"`: Set user name
+- `git config user.email "your.email@example.com"`: Set user email

zrb/task/llm/default_workflow/golang/workflow.md

@@ -0,0 +1,128 @@
+---
+description: "A workflow for developing with Go, including project analysis and best practices."
+---
+Follow this workflow to deliver high-quality, idiomatic Go code that respects project conventions.
+
+# Core Mandates
+
+- **Simplicity First:** Write clear, simple, and readable code
+- **Idiomatic Go:** Follow Go conventions and community standards
+- **Tool Integration:** Leverage Go's excellent tooling ecosystem
+- **Safety and Reliability:** Write robust, well-tested code
+
+# Tool Usage Guideline
+- Use `read_from_file` to analyze Go modules and configuration
+- Use `search_files` to find Go patterns and conventions
+- Use `run_shell_command` for Go toolchain operations
+- Use `list_files` to understand project structure
+
+# Step 1: Project Analysis
+
+1. **Module Information:** Examine `go.mod` for module path and dependencies
+2. **Workspace:** Check for `go.work` for multi-module workspace configuration
+3. **Tooling:** Look for `Makefile` with build, test, and lint commands
+4. **CI/CD Configuration:** Check `.github/workflows/go.yml` for verification commands
+5. **Linting Config:** Examine `.golangci.yml` for linting rules
+6. **Package Structure:** Analyze `pkg/`, `internal/`, and `cmd/` directories
+
+# Step 2: Understand Conventions
+
+1. **Formatting:** `go fmt` is mandatory for all code
+2. **Linting:** Adhere to project's `golangci-lint` configuration
+3. **Package Naming:** Use short, concise, all-lowercase package names
+4. **Error Handling:** Match existing error handling patterns
+5. **Testing:** Follow established test structure and patterns
+
+# Step 3: Implementation Planning
+
+1. **File Structure:** Plan where new code should be placed based on project conventions
+2. **Dependencies:** Identify if new dependencies are needed and verify they're appropriate
+3. **API Design:** Consider how new code integrates with existing APIs
+4. **Testing Strategy:** Plan comprehensive tests for new functionality
+
+# Step 4: Write Code
+
+## Code Quality Standards
+- **Formatting:** All code must be `go fmt` compliant
+- **Linting:** Address all `golangci-lint` warnings
+- **Naming:** Follow Go naming conventions (camelCase for variables, PascalCase for exports)
+- **Documentation:** Add godoc comments for exported functions and types
+
+## Implementation Patterns
+- **Error Handling:** Use appropriate error wrapping based on project patterns
+- **Concurrency:** Follow existing goroutine and channel usage patterns
+- **Interfaces:** Define small, focused interfaces
+- **Composition:** Prefer composition over inheritance
+
+# Step 5: Testing and Verification
+
+1. **Write Tests:** Create comprehensive tests for all new functionality
+2. **Run Tests:** Execute `go test ./...` to verify functionality
+3. **Format Code:** Run `go fmt ./...` to ensure proper formatting
+4. **Lint Code:** Run `golangci-lint run` to catch issues
+5. **Build Verification:** Run `go build ./...` to ensure code compiles
+
+# Step 6: Quality Assurance
+
+## Testing Standards
+- **Table-Driven Tests:** Use for comprehensive test coverage
+- **Test Files:** Place tests in `_test.go` files within the same package
+- **Benchmarks:** Add benchmarks for performance-critical code
+- **Examples:** Include example code in documentation
+
+## Code Review Checklist
+- [ ] Code follows project formatting standards
+- [ ] All tests pass
+- [ ] No linting warnings
+- [ ] Error handling is appropriate
+- [ ] Documentation is complete
+- [ ] Performance considerations addressed
+
+# Step 7: Finalize and Deliver
+
+1. **Verify Dependencies:** Run `go mod tidy` to clean up dependencies
+2. **Run Full Test Suite:** Ensure all existing tests still pass
+3. **Document Changes:** Update relevant documentation
+4. **Prepare for Review:** Ensure code is ready for team review
+
+# Common Commands Reference
+
+## Development
+- `go fmt ./...`: Format all Go code
+- `go vet ./...`: Report suspicious constructs
+- `go build ./...`: Build all packages
+- `go run ./cmd/my-app`: Run a specific application
+
+## Testing
+- `go test ./...`: Run all tests
+- `go test -v ./...`: Run tests with verbose output
+- `go test -race ./...`: Run tests with race detector
+- `go test -bench=. ./...`: Run benchmarks
+
+## Dependency Management
+- `go mod tidy`: Add missing and remove unused modules
+- `go mod download`: Download modules to local cache
+- `go list -m all`: List all dependencies
+- `go get package@version`: Add or update a dependency
+
+## Debugging
+- `dlv debug`: Debug with Delve
+- `go tool pprof`: Performance profiling
+- `go tool trace`: Execution tracing
+
+# Risk Assessment Guidelines
+
+## Low Risk (Proceed Directly)
+- Reading configuration files
+- Running tests and linters
+- Adding tests to existing packages
+
+## Moderate Risk (Explain and Confirm)
+- Adding new dependencies
+- Modifying core business logic
+- Changing public API interfaces
+
+## High Risk (Refuse and Explain)
+- Modifying critical system paths
+- Operations that could break the build
+- Changes that affect multiple teams