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

[xangcastle]

In Discussion #1, we sharpened the blade. Now, we must learn how to wield it in the chaos of the battlefield.

We are seeing a pattern in large organizations: The Monorepo Fatigue.
When working in a massive Bazel workspace with thousands of targets, a generalist agent fails. It burns tokens reading irrelevant files, gets confused by similar class names in different modules, and forces you to pay for "Frontier Models" (Opus, GPT-5) just to filter out the noise.

I propose a fundamental shift in how Ronin operates, moving away from "Chat with a File" to "Adopting a Stance".

1. The Concept: Stances over Prompts

A "Stance" is a pre-configured state of mind. It is not just a prompt; it is a deterministic boundary around a specific set of Bazel targets or modules.

In a massive Monorepo, Ronin shouldn't try to "know" everything.

• Without Stance: The agent sees core, api, web, analytics, infra. It hallucinates dependencies between web and infra.
• With Stance:
  • Stance: Core Systems $\rightarrow$ Scope: //core/logic/... + //core/shared-libs/.... (The agent is blind to the frontend).
  • Stance: Web Frontend $\rightarrow$ Scope: //web/app/... + //api/client/.... (The agent ignores the database schemas).

2. The Abstraction: Select the Expert, Not the Model

We need to stop asking developers to be AI engineers. "Which model should I use? Temperature 0.7 or 0.2?" This is friction.

By defining a Stance, we solve the model access problem:

• Frontier Models are Overkill: If Ronin is in the "Web Stance" and only sees the relevant React files, it does not need a frontier model. A highly optimized, faster, and cheaper model (like Haiku, Flash, or a local quantized Llama) is sufficient because the Context Pollution is gone.
• The User Experience: The dropdown menu changes.
  • Old Way: Select Model $\rightarrow$ GPT-5.2
  • The Ronin Way: Select Stance $\rightarrow$ ⚔️ Frontend React Expert (Internally maps to a fast model + React System Prompt + @web scope).

3. Implementation: Native Settings (No More YAML Hell)

While file-based config (.roninrc) was suggested, true stability requires integration. Stances should live inside the Plugin Settings (IDE Preferences), not as loose YAML files cluttering the repo root.

This leverages the IntelliJ SDK’s persistent state components. The configuration is strict, validated by the IDE, and immune to accidental deletion during a git clean.

4. Enterprise Sovereignty: The "Plug & Play" Build

Large organizations with Bazel monorepos struggle to onboard thousands of devs with custom settings.

Ronin should support Configuration Injection at Compile Time.
Using Gradle resource processing, an organization can define a ronin-profile.json containing their specific Stances (e.g., "Corporate Auth Module", "Legacy Payment System").

When compiling their internal version of the plugin:

// build.gradle.kts
tasks.register("embedCorporateStances") {
    // Injects the organization's specific Bazel targets and Model Mappings
    // into the plugin resources before distribution.
}

This produces a "Plug & Play" artifact. A new developer joins the company, installs the corporate Ronin build, and immediately sees the "Payment System Expert" stance ready to use. Zero configuration required.

The Question:
Does abstracting the model away feel like a loss of control, or the ultimate form of focus?
Are we ready to treat "Context" as a compile-time dependency?

[xangcastle]

The Stances: Full support for personas like "The Shinobi" (Speed) and "The Daimyo" (Quality)