Find meaningful ways to contribute

A race condition exists where a runner can be marked as failed even after it has successfully reconnected. This occurs when a disconnect grace period expires, and the system attempts to mark the session as failed just as the runner re-establishes its connection. The proposed fix involves re-validating the runner's connection status after an asynchronous session lookup before marking it as failed.

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.

When Claude Code's own tools (Skill, ToolSearch) are used within the claude-sdk harness, subsequent Omnigent tool calls in the same turn are incorrectly recorded twice. This happens because the SDK executor doesn't mark these internal tools as 'internally_executed', leading to duplicate dispatch and observed entries with mismatched call IDs.

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.

Sandboxed sessions using the claude-sdk harness on a self-hosted runner are getting stuck indefinitely on the 'Starting up…' spinner in the web UI. This appears to be due to a failure in the automatic creation of the Omnigent REPL terminal, which prevents the `terminal_pending` flag from being cleared.

This issue involves replacing explicit `any` type annotations with more specific types in the `NoCode.vue` and `Task.vue` Vue components. The goal is to improve type safety and code maintainability by eliminating the use of `any`, which is often a sign of missing type information. Guidance on where to find the correct types and how to proceed with the PR is available in a linked epic.

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 involves replacing explicit `any` type declarations with more specific types in two Vue components: `TaskTask.vue` and `TaskString.vue`. The goal is to improve type safety and maintainability within the frontend codebase. Detailed guidance on how to approach this task, including where to find the correct types, is available in a linked epic issue.

This issue proposes implementing internationalization (i18n) for the publisher tools to address hard-coded text, improve maintainability, and enable multi-language support. The plan involves setting up i18n infrastructure, defining translation conventions, migrating components, and creating locale files.

This issue is a beginner-friendly task to add a new Japanese example sentence to a JSON file. It requires no coding and can be completed directly in the browser by forking the repository, editing the file, and submitting a pull request. This is an excellent opportunity for new contributors to get involved in open source, especially during Hacktoberfest.

This issue describes a critical bug in the AI terminal's command cancellation on Windows. When a command is cancelled, it fails to report the 'canceled' state correctly and instead returns a generic error. Furthermore, the process termination mechanism on Windows uses `execSync`, which blocks the Node.js event loop, leading to UI unresponsiveness.

The AWS SQS and S3 polling triggers in Kestra are missing a `kill()` method. This prevents workers from interrupting hung AWS SDK calls, potentially blocking worker threads. The suggested solution is to implement `kill()` for the SQS trigger by mirroring the Kafka realtime trigger's pattern, and to investigate if the S3 SDK client supports interruption for its polling mechanism.

This issue involves replacing explicit `any` type declarations with more specific types in two Vue components: `FlowPropertiesEdit.vue` and `InputText.vue`. The goal is to improve type safety and maintainability within the frontend codebase. Detailed guidance on how to approach this task, including the source of types and expected outcomes, is available in a linked epic.

This issue involves replacing an explicit `any` type with a more specific type in the `TaskSecret.vue` component. The goal is to improve type safety and maintainability within the frontend codebase. Further guidance on how to approach this task and where to find the necessary types is available in the linked epic.

This issue proposes adding a new data-source connector for Postman to the cognee-community project. The connector should handle API key authentication, ingest collections, request descriptions, and documentation, and support incremental syncing and deletion.

This issue involves refactoring the `TaskEditor.vue` component by replacing seven instances of the `any` type with more specific TypeScript types. The goal is to improve code maintainability and clarity by leveraging strong typing. Guidance on how to approach this task and where to find the necessary type definitions is available in a linked epic issue.

This issue highlights outdated documentation in `console-live-promote-no-alert.md` that incorrectly states a rollback gap for live semantic and browser-matrix tests remains unresolved. The fix, implemented in PR #23520, has already added the necessary rollback steps, making the documentation inaccurate and potentially misleading for operators.

This issue involves replacing six instances of the explicit `any` type with more specific TypeScript types within the `TaskArray.vue` component. The goal is to improve type safety and maintainability of the frontend code. Guidance on how to approach this task, including the source of types and expected outcomes, is available in a linked epic.

This issue involves replacing explicit `any` type annotations with more specific TypeScript types in two files: `cleanUp.ts` and `useFieldNavigation.ts`. The goal is to improve code clarity and maintainability by leveraging TypeScript's type system. Guidance on how to approach this task, including where to find the correct types, is available in a linked epic.

The application makes a Hugging Face API request for every keystroke after the second character in the model search, leading to excessive requests and potential rate limiting. This issue proposes implementing caching and debouncing mechanisms on both the frontend and backend to reduce API calls and improve user experience.

This issue involves replacing five instances of the `any` type with more specific types in the `TaskDict.vue` component. The goal is to improve type safety and maintainability within the frontend codebase. Guidance on how to approach this task, including the source of types and expected outcomes, is available in a linked epic issue.

This issue involves replacing explicit `any` type declarations with more specific types in `TaskList.vue` and `TaskComplex.vue`. The goal is to improve type safety and maintainability within the frontend components. Detailed guidance on how to approach this task, including the source of types and expected outcomes, is available in the linked epic.

This issue involves replacing explicit `any` type annotations with more specific types in two TypeScript files: `useBlockComponent.ts` and `MixinTask.ts`. The goal is to improve type safety and code maintainability within the `src/components/no-code` directory. Guidance on finding the correct types and the process for submitting a pull request is available in a linked epic issue.

This issue addresses the presence of 114 explicit `any` type usages across 25 files within the `src/components/no-code` directory. The goal is to replace these `any` types with more specific, real types to improve code clarity and maintainability. Further guidance and context are available in the linked epic.

This issue involves replacing explicit `any` types with more specific types in two Vue components: `TaskExpression.vue` and `TaskLabelWithBoolean.vue`. The goal is to improve type safety and maintainability within the frontend codebase. This is a straightforward refactoring task.

This issue requires replacing explicit `any` type annotations with more specific types in `Gantt.vue` and `Topology.vue`. The goal is to improve code clarity and maintainability by leveraging TypeScript's type system. Guidance on finding the correct types and submitting the pull request is available in a linked epic.

This issue involves replacing five instances of the `any` type with more specific TypeScript types in the `MetricsTable.vue` component. This is a refactoring task aimed at improving code clarity and maintainability by leveraging the benefits of static typing. The necessary context and guidance for this task can be found in the linked epic issue.

This issue involves refactoring the `Resume.vue` component to replace six instances of the `any` type with more specific TypeScript types. This is part of a larger effort to improve type safety within the frontend codebase, aiming to surface potential type-related issues during development.

This issue involves refactoring the `ChangeStatus.vue` component to replace eight instances of the `any` type with more specific and accurate TypeScript types. The goal is to improve code maintainability and type safety within the frontend codebase. Guidance on how to approach this task and where to find relevant type information is available in a linked epic issue.