emanuele-em/kanzo

Source
GitHub
First trending
Category
Workflow
GitHub stars
602
Main language
Rust

This page introduces an external open-source repository. It is not an HDATF product.

emanuele-em/kanzo

What it does

Kanzo is a self-hosted task board that lets people and coding agents work on the same projects. People enter tasks, descriptions, comments and images through a browser, while agents use MCP, a protocol connecting AI tools, or the command line. The Rust program provides a REST-style JSON API and MCP over standard input and output or HTTP, stores tasks in SQLite and images as local files, and updates the browser through polling. A default launch opens localhost:4242, while sharing and joined modes provide a shared host board and relay remote requests. Tasks support todo, doing, review and done with optional backlog, tags, ordering, comments and timestamps, but the inspected schema does not provide assignees, dependencies or an audit history. The next_task operation selects a non-Human todo task and changes it to doing inside a write transaction, preventing competing selections by design without granting exclusive ownership. Human tasks are omitted from agent listing and automatic selection, but update and delete operations do not enforce Human protection when an agent knows the identifier. There is no separate read-only token, and anyone who can reach the shared port can change the board, so choosing local or shared operation, the data directory and network restrictions is a prerequisite. Distribution targets macOS, Linux and Windows under AGPL-3.0-only, while advertised size, memory use, start time and token savings remain upstream measurements rather than independently verified results.

License

AGPL-3.0 Network copyleft. Offering a modified version as a service also requires releasing the source. Review before any product use.

More in this category

  • thtbee/nectarlink
    NectarLink is a device companion for people who move between an Android phone and a Windows PC. With permission, phone notifications, messages, clipboard content, files, photos and screen content become available on the paired PC, and selected controls work in the other direction. A shared Rust core handles device identity and pairing, while the desktop and Android applications provide their respective interfaces. Devices normally communicate directly over the local network or USB using encrypted connections, and mobile-data relay is optional. Setup involves installing both applications, confirming pairing and enabling only the features the user wants; some advanced Android features require separately authorized debugging access. An optional local HTTP and JSON automation API supports actions such as sending files, notifications and camera requests, requires a Bearer token and is disabled by default. The documented v0.1.4 packages cover Windows x64 and Android, while Linux and Windows ARM64 packages are described as forthcoming and macOS remains a preview. This is not a cloud collaboration service, third-party chat history is limited by notification access, and call audio still stays on the phone even when calls are controlled from the PC.
  • immortal71/openoncology
    OpenOncology is a research platform that combines tumor alteration evidence and ranks drug candidates for expert review, not a validated treatment recommendation service. Documented inputs include mutations, copy number changes and fusions, while the submission API accepts biopsy and DNA files with cancer type and requires patient authentication. Outputs include variants, evidence levels, source records and candidate drug rankings through separate results and repurposing APIs. The FastAPI server works with a Next.js interface, PostgreSQL, Redis, object storage and background workers, and the Docker configuration uses Python 3.11 and Node.js 20. Genomic processing has additional workflow and reference-data requirements, so starting the development containers does not establish that raw sequencing analysis will finish. Candidate scoring combines several evidence sources with renormalized weights, penalties and evidence-level rules, and its current configuration differs from an older README weight description. The default worker centers candidate generation on the first targetable mutation, so the whole-patient description should not be assumed to describe every execution path. Setup requires service secrets and configured evidence access, and unavailable OncoKB access can use a static fallback whose provenance limitations matter. Official documents retract an earlier circular oncologist-agreement evaluation, and the retrospective MSK CHORD comparison measures agreement with label-matched drugs rather than treatment benefit. The risk analysis states that clinical validation gates are unmet and results must not guide treatment, while this investigation only read sources and did not verify medical validity, performance or deployment readiness.
  • KKKKhazix/agent-autoloop
    This automation layer lets terminal agents react to events and ask a person only when a decision is needed. It calls already installed and authenticated executors such as Claude Code and Codex rather than supplying its own model. Schedules, GitHub events and external HTTP events are assigned to agents and workspaces by rules. Final replies and structured receipts become completion records, question cards, notices or deferred follow-ups. While awaiting an answer, the agent process exits and can resume the existing session after a response. It requires macOS or Linux, Node 24, Git, curl and an authenticated agent; the README currently states Windows is unsupported. Event sources, notification channels, agents and delivery pipelines are plugins requiring configuration. Some channels and business recipes have only simulated validation, and the generic command adapter does not enforce every executor's permissions. Model usage belongs to the connected account, while hostile input and file access under the same system account require separate controls.
  • warmbly/warmbly
    Warmbly is a self-hostable sales-email and mailbox-warmup platform for teams using mailboxes they already own. Users connect Gmail, Microsoft or SMTP and IMAP accounts and provide contacts, message sequences, timing and sending limits. It produces campaign records, opening and click events, replies, shared-inbox views and customer-management records. Mailbox warmup means gradually exchanging scheduled messages within monitored mailbox pools, not a guarantee that future mail reaches the inbox. The architecture separates state-owning Go backend and consumer services from interchangeable Go workers, with Postgres, Redis and an event bus, a React dashboard and a separate realtime service. Workers submit mail through each mailbox provider rather than delivering directly to recipients, and the default local stack uses NATS, local key management and filesystem storage. REST interfaces, webhooks and documented integrations support external connections, while AI functionality requires separate model-provider configuration. The documented start uses Docker Compose release images or a source build, then a one-time instance claim and mailbox connection, with OAuth application configuration needed for Google and Microsoft accounts. Development seeding shares the database with self-hosting and publishes demo administrator credentials, so production secrets, encryption-key backups and demo separation are essential; sending performance, inbox placement and ATF integration were not verified in this review.
  • every-app/every-app
    EveryApp addresses the hosting, sign-in and permission work that remains after a coding agent creates an internal web application. It targets teams and developers who want to operate those applications in their own Cloudflare account. Inputs include an application definition, resource declarations and browser or AI tool requests, while outputs include a deployed application and authorized application results. A public Gateway checks access and forwards requests to private application Workers through internal connections, with signed identity verified at the application entry. The starter application scopes its database queries to the authenticated user's identifier, showing that row visibility remains the application's responsibility. Its tools declare separate read, write and destructive risk levels and are exposed to AI clients through the Gateway's MCP interface, a shared protocol for calling tools. Application declarations also specify allowed capabilities, while the Gateway keeps credentials and mediates external API access. The documented setup requires a Cloudflare account with Workers Paid and a Cloudflare managed domain, and the supplied stack uses Workers, D1, R2 and KV as applicable. The project explicitly remains in early development, so its access architecture is not proof of complete security, universal SaaS compatibility or production readiness.

Only repositories in the ranked Trendshift lists are included, and the lists are used only to find candidates. We do not copy their ranks. Descriptions, licenses and star counts come from each GitHub repository. The notes are our own reading. We have not tested these projects, and a place on a trending list does not prove quality.

View on GitHub (opens in a new tab)