Reactor

[nelsonic]

mentioned by @ndrean in #163 and #159 (comment) 💬

https://github.com/ash-project/reactor

"Reactor is a dynamic, concurrent, dependency resolving saga orchestrator."

• Saga orchestrator A saga is a way of providing
  transaction-like semantics across multiple distinct resources.
• Dependency resolving reactor allows you to describe the dependencies
  between your saga steps using arguments which are converted into a
  [DAG][dag] and used to compute execution order.
• Concurrent unless otherwise specified reactor will run as many steps as
  possible concurrently whilst taking into account the results of the dependency
  resolution.
• Dynamic whilst you can define a reactor statically using our awesome DSL,
  you can also build workflows dynamically - and even add steps while the
  reactor is running.

Getting started: https://github.com/ash-project/reactor/blob/main/documentation/tutorials/01-getting-started.md

[ndrean]

@nelsonic

Quick question: do you find yourself researching through all your repos? researching through all issues in your repos?

I was thinking of an MCP server based on your repos/issues, and a basic interface and a simple AI-assisted interface ((for natural language dialogue) using a very cheap Mistral API "ministral-small" (https://mistral.ai/pricing/api/)

Cost: $0.10 | $0.10, per million token
An input could be 10k token, so 100 queries is 0.10. Cheap.

GitHub supports semantic search :

# Full-text search issues in a specific repo
gh api search/issues -X GET -f q="repo:dwyl/auth authentication login"

# Semantic search (finds conceptually related results, not just keyword matches)
gh api search/issues -X GET -f q="repo:dwyl/auth how to handle sessions" -f search_type=semantic

# Hybrid (keyword + semantic combined)
gh api search/issues -X GET -f q="repo:dwyl/auth authentication" -f search_type=hybrid

# Search code in a repo
gh api search/code -X GET -f q="repo:dwyl/auth defmodule"

Aproject architecture could be:

  User: "find how dwyl handles authentication"
    │
    ├─ MCP tool 1: search_repos(org, query)
    │   → GitHub API: /search/repositories?q=org:dwyl+authentication
    │   → returns: dwyl/auth, dwyl/auth_plug, dwyl/phoenix-auth-example
    │
    ├─ MCP tool 2: search_issues(repo, query)
    │   → GitHub API: /search/issues?q=repo:dwyl/auth+authentication&search_type=hybrid
    │   → returns: top N issues with title + body snippet
    │
    └─ LLM synthesizes the answer from tool results

GitHub already does semantic matching on their side. Then MCP server would just be a thin wrapper around gh api search/* with the repo: qualifier.

=> 3 MCP tools (search_repos, search_issues, search_code), no database, no cron, no embeddings. Just GitHub API calls + authentication.

MCP libraries: https://hex.pm/packages/ex_mcp or https://hex.pm/packages/hermes_mcp

Sources:

• REST API endpoints for search - GitHub Docs
• Improved search for GitHub Issues (semantic/hybrid)
• API support for advanced search

[nelsonic]

@ndrean sounds like a fun project.
Only question is: how easy is it for the person using the interface to abuse it?

[ndrean]

Without even talking about obvious rate limiting, what do you mean by abuse? because you are essentially hitting the read-only Github API of limited scope public repos. The AI is a classifier with no execution capability and uses read-only tools (the "MCP"). It is not an agent (this is where things become dangerous). Spoofing? again, read-only.