Find meaningful ways to contribute

This issue serves as a central hub for advisory findings from Hive agents, particularly at lower ACMM levels where agents analyze code without creating direct issues or PRs. A governor agent periodically posts digest comments summarizing these advisory findings. This issue is intended to be a living document and should not be closed.

This issue points out that the `StreamWriter` example in the `crypto/cipher` package uses a deprecated function or approach. The reporter suggests updating the example to use a different cipher mode like CBC or CTR instead of the current OFB implementation, which might be considered outdated or less secure in certain contexts.

This issue proposes the creation of a validating webhook for the Burrito project. The webhook will be responsible for validating resources before they are applied, specifically focusing on the `remediationStrategy` enum and complex interactions between various options.

This issue requests the implementation of a new Git provider for Bitbucket. It specifically mentions building upon the new structural changes introduced in a recent pull request, indicating a need to integrate with an existing framework.

This issue proposes adding a new configuration setting to the Burrito tool. This setting would prevent Burrito from executing 'apply' operations if the 'plan' output indicates that any resources are scheduled for destruction. The goal is to enhance safety and facilitate adoption on critical Terraform code by preventing accidental resource deletion.

A bug exists in the `cadence_of()` function where it incorrectly converts 24-hour times (e.g., 14:30) to a 12-hour format, causing jobs to be scheduled 12 hours early. The fix involves modifying the function to only apply the 12-hour conversion when 'am' or 'pm' is explicitly stated and adding corresponding test cases.

This issue addresses documentation errors in the CUGA tool registry. Specifically, it corrects incorrect paths in test commands that prevent pytest from finding tests and fixes dead links to non-existent sample configuration files and example scripts. The proposed changes involve adding the missing 'src/' prefix to test command paths and updating the locations of the linked files.

This issue requests the addition of a new `validate_json` tool to the `code` MCP server. This tool will function similarly to the existing `check_python_syntax` tool, but for JSON, providing precise error locations when JSON is malformed. The goal is to improve AI agent capabilities in handling and debugging JSON data.

This issue proposes adding a new example to the CUGA documentation that demonstrates how to connect an agent to a public tool server (MCP). The example will showcase how an agent can borrow tools from this server to answer questions, simplifying the process compared to existing examples that require separate registry services.

This issue proposes adding a new tool to the `text` MCP server that calculates basic text statistics like word count, sentence count, character count, and estimated reading time. This tool is intended to provide reliable text analysis for AI agents, which currently struggle with such estimations. The task involves adding a plain Python function to an existing server file.

This issue addresses inaccuracies in the descriptions of MCP servers used by CUGA agents. Five out of seven server descriptions in the `mcp_servers_cuga_apps.yaml` file are misleading, either listing tools the server doesn't provide or omitting most of its actual functionalities. The goal is to update these descriptions to accurately reflect the tools each server offers.

This issue proposes adding a new, minimal example to the CUGA agent documentation. The goal is to create a simple runnable agent with two basic Python tools, allowing newcomers to quickly understand and test CUGA's functionality. This example will be significantly smaller than existing ones and will not require an AI API key to set up.

This issue proposes adding a new section to the CUGA project's roster documentation. The new section, titled 'Write your own roster in 10 minutes', will provide a minimal skeleton, a list of valid server names, explanations of server tools, and tips for writing effective agent instructions. This aims to make it easier for users to create their own AI agent rosters.

This issue proposes adding a test to ensure all example roster YAML files are well-formed and valid. Currently, only one roster is fully validated, while others are only checked for a single forbidden word. The goal is to implement a quick, offline test that catches common errors like typos, missing instructions, or duplicate agent names.

This issue proposes adding a new "Learning Desk" roster to the CUGA agent project. This roster will create a team of AI agents designed to assist students and self-learners with their studies, utilizing existing tools and requiring no API keys or extra infrastructure. The new roster file should be modeled after the existing "research desk" roster.

This issue addresses a missing `examples:` field in the skill template and conversion playbook. Currently, all existing skills include this field for user-facing examples, but the template and playbook do not mention it, leading to new skills potentially lacking examples. The fix involves adding the `examples:` field to the template and updating the playbook to include it.

This issue proposes adding a "Try it" section with example prompts to the README files of four specific applications. The example prompts are already available in a data file and need to be copied and integrated into the respective READMEs after the "Quick Start" section.

This issue addresses a discrepancy between the documented default port for the newsletter app and its actual default port in the code. The README states the default port is 28793, but the code uses 18793, leading users to an incorrect address. The fix involves updating the default port in the newsletter's main script and its README, and also correcting a similar issue in the ibm_docs_qa app's help text.

This issue addresses failing tests in the `stock_alert` app due to a rewrite of its `main.py` file. Ten tests are broken because they call non-existent helper functions. The task is to remove these broken tests and update the remaining one to properly execute the module and verify its entry points.

This issue addresses an inconsistency in the `/health` endpoint response across three FastAPI applications within the cuga-apps repository. Currently, these three apps return `{"status": "ok"}` instead of the documented `{"ok": true}`, causing scripts that rely on the `ok` key to incorrectly flag them as down. The fix involves updating the return statements in the respective `main.py` files and adjusting the documentation in one README file.

This issue addresses an inconsistency in the "How to run" commands displayed for 21 applications within the cuga-apps gallery. The commands currently show outdated port numbers (18xxx or 8xxx) instead of the correct, recently updated ports (28xxx range) that are already reflected in each app's `appUrl` field. The fix involves updating these port numbers in the `ui/src/data/usecases.ts` file to match the `appUrl` for each respective app, with one specific exception noted.

The `get_paper_references` function on the knowledge MCP server currently fails when provided with a bare arXiv ID (e.g., '1706.03762') because the Semantic Scholar API requires the 'arXiv:' prefix. This issue proposes adding a regular expression to prepend 'arXiv:' to bare IDs and remove version suffixes, ensuring compatibility with the API and fixing a failing smoke test.

This issue proposes adding a `/health` endpoint to three FastAPI applications: `wiki_dive`, `paper_scout`, and `smart_todo`. This endpoint is intended to return `{"ok": true}` to indicate that the application is running, aligning with the project's contributing guidelines. The change involves adding a small FastAPI route definition to the `main.py` file of each specified application.

The `chunk_text` tool in the `mcp-text` server incorrectly drops separators when recursively chunking text. This happens because the code uses an identity check (`is not`) to determine if a chunk is the last one, leading to separators being lost when identical short strings are reused by Python. The fix involves changing this check to a positional comparison (`i < len(parts) - 1`).

The `detect_language` tool incorrectly identifies plain JavaScript and C code as CSS due to overly broad marker strings. The fix involves refining the CSS marker list to be more specific, preventing false positives for other languages. An optional test case is also suggested to ensure the fix.

The `mcp` Python package has released version 2.x, which contains breaking changes. This update causes MCP servers and the test client to crash on import because they are built on the older 1.x version. The fix involves pinning the `mcp` dependency to `mcp>=1.0,<2` in specific requirements files.

The `chunk_text` tool on the text MCP server hangs indefinitely when the `overlap` parameter is equal to or greater than the `size` parameter. This issue can be resolved by adding input validation to the `chunk_text` function to reject these invalid argument combinations with a clear error message, preventing server tie-ups.

This issue addresses inconsistencies in the `cuga` command-line tool. Specifically, the `--help` output for `start`, `stop`, and `status` commands does not accurately reflect the full list of supported services. Additionally, the `cuga status demo_knowledge` command currently produces no output.

This issue addresses failing unit tests in a Python project that occur when the `OPENAI_API_KEY` environment variable is not set. The failures stem from tests attempting to instantiate an OpenAI client without a key and tests requiring an optional package that isn't installed by default. The proposed solution involves providing a dummy OpenAI key in test configurations and using `pytest.importorskip` for optional dependencies.

The `provider` key in a supervisor's YAML configuration is silently ignored because the `LLMManager` class expects a `platform` key instead. This causes the specified LLM to be dropped and the system to fall back to a default, without any warning to the user. The fix involves updating the configuration parsing logic to correctly handle the `provider` key.