⚔️ Defining the Blades

⚔️ Defining the Blades: What are your "Must Have" Features for Ronin?

We are building Ronin with a single, non-negotiable purpose: to provide a masterless coding agent that serves only your code.

We’ve established the Ronin Covenant because we are tired of volatile proprietary tools that shift their terms, cap productivity, and act as black boxes. We are building deterministic infrastructure, not another shifting service.

The Rules of Engagement
As we roadmap the next phase of development, we are committed to respecting our core values to the death:

1. Sovereignty (BYOK): You bring the brains (OpenAI, Anthropic, DeepSeek, Minimax, etc.). We provide the body. No middleman markup.
2. Privacy (Local-First): localhost is a first-class citizen. If it can't run offline or via your own keys, it doesn't belong here.
3. Transparency: No hidden "fair usage" policies. No rug-pulls.
4. Open Source: The best of all, completely open-source.

The Question
We are serious about making Ronin your daily driver. To do that, we need to know what is missing from your arsenal.

What are the "Must Have" features that would make Ronin your default coding companion?

We aren't looking for "nice-to-haves." We want to know the critical blockers—the features so essential that you cannot work without them.

Is it specific context-awareness capabilities?
Deeper integration with local LLMs (Ollama, kimi k2, Minimax)?
Specific diff views or commit generation workflows?
Tell us below. If it respects the Covenant, we will build it.

Build freely.

[Foxomax]

If Ronin is intended to be a daily-use infrastructure and not just a chat container, these are the critical components I'm missing:

1. Recursive Directory Context (The "Body" of the Code) Working file-by-file is a friction point that kills flow. To truly serve the code, the agent needs the ability to ingest full directory trees (e.g., passing src/components or lib/utils) as a single context unit. The agent must understand module relationships and architectural scope, not just isolated text files.

2. Deterministic Repo Configuration (.roninrc) In the spirit of sovereignty, the context shouldn't live in the tool's history; it should live in my repo. I need a configuration file committed to the root (like .roninrc or ronin.json) to define:

Persistent project context (tech stack, patterns).

Ignored paths (distinct from .gitignore).

Agent parameters.

This ensures immediate alignment when opening a repo, making the agent deterministic and project-aware from prompt zero.

[xangcastle]

Hey @Foxomax, thanks for laying these out.

I have some updates regarding these points:

1. Recursive Directory Context: Good news—this is already implemented! The agent is currently capable of ingesting full directory trees to understand module relationships as you described.
2. Deterministic Config (.roninrc): I reviewed this idea, but I found the file-based approach to be a bit too fragile for what we are aiming for (prone to sync issues and lack of strict validation).

Instead, I’m proposing a more robust architecture based on "Stances". I just published the details in Discussion #5 and would love to get your thoughts on that approach:

👉 ⚔️ The Stances: Deterministic Context & The End of Model Selection