muonroi-cli 1.7.1 → 1.8.0

package/dist/src/router/step-router.js

@@ -26,7 +26,80 @@
  */
 import { getModelByTier } from "../models/registry.js";
 import { detectProviderForModel } from "../providers/runtime.js";
+import { readTimeoutEnv } from "../utils/ee-logger.js";
 import { isModelDisabled, isProviderDisabled, loadUserSettings } from "../utils/settings.js";
+// ─── EE-guided SAMR override ─────────────────────────────────────────────────
+// EE_SAMR_TIMEOUT: per-call budget for consulting the EE brain about SAMR.
+// Default 2s, range 500ms..5s. Falls back to heuristics on timeout/error.
+const EE_SAMR_TIMEOUT_MS = readTimeoutEnv("MUONROI_EE_SAMR_TIMEOUT_MS", 2000, 500, 5000);
+/**
+ * Consult the EE brain + local heuristics to decide whether SAMR should be
+ * enabled for this turn even when the user config has it disabled.
+ *
+ * Resolution order:
+ *   1. Fast heuristic — mechanical/simple tasks skip EE entirely (zero cost).
+ *   2. EE brain — asks classifyViaBrain for a yes/no + execution tier.
+ *   3. Heuristic fallback — when EE is unreachable, uses taskType + complexity.
+ */
+export async function eeSamrGuidance(params) {
+    const { userMessage, taskType, taskConfidence, complexitySize, taskComplexity } = params;
+    // Step 1: fast heuristic — mechanical tasks never benefit from SAMR
+    const mechanicalTypes = new Set(["general", "documentation", "generate", "build", "chitchat"]);
+    if (taskType && mechanicalTypes.has(taskType)) {
+        return { overrideConfig: null, reason: `mechanical taskType=${taskType} — no SAMR benefit` };
+    }
+    // Step 2: fast heuristic — trivial tasks don't need a split
+    if (taskComplexity === "low" && (complexitySize === "small" || complexitySize === undefined)) {
+        return { overrideConfig: null, reason: "low complexity + small — no SAMR benefit" };
+    }
+    // Step 3: ask EE brain
+    try {
+        const { classifyViaBrain } = await import("../ee/bridge.js");
+        const eePrompt = [
+            `Task: ${userMessage.slice(0, 200)}`,
+            `Context: type=${taskType ?? "unknown"} complexity=${taskComplexity ?? "unknown"} size=${complexitySize ?? "unknown"}`,
+            `Question: Would splitting the work into (1) premium reasoning then (2) cheap execution save tokens without hurting quality?`,
+            `Reply valid JSON: {"samr":true,"executionTier":"balanced"} or {"samr":false}`,
+        ].join("\n");
+        const response = await classifyViaBrain(eePrompt, EE_SAMR_TIMEOUT_MS, {
+            systemPrompt: 'You are a SAMR (Step-Aware Model Routing) evaluator. Given a task description, context, and question, reply ONLY with valid JSON: {"samr":true,"executionTier":"balanced"} or {"samr":false}. No extra text, no markdown.',
+            responseFormat: { type: "json_object" },
+            maxTokens: 100,
+        });
+        if (!response) {
+            // Fallback heuristic when EE unreachable
+            return samrHeuristicFallback(taskType, taskComplexity, complexitySize);
+        }
+        const parsed = JSON.parse(response);
+        if (parsed.samr === true) {
+            const tier = parsed.executionTier === "fast" ? "fast" : "balanced";
+            return {
+                overrideConfig: { enabled: true, toolExecutionTier: tier, premiumSynthesis: false },
+                reason: `ee-guided: ${tier} execution phase`,
+            };
+        }
+        return { overrideConfig: null, reason: "ee-declined" };
+    }
+    catch {
+        return samrHeuristicFallback(taskType, taskComplexity, complexitySize);
+    }
+}
+/**
+ * Deterministic fallback when EE brain is unreachable.
+ * Reasoning-heavy tasks with high complexity are strong SAMR candidates.
+ */
+function samrHeuristicFallback(taskType, taskComplexity, complexitySize) {
+    const reasoningTypes = new Set(["plan", "analyze", "refactor", "debug", "architect"]);
+    if (taskType && reasoningTypes.has(taskType)) {
+        if (taskComplexity === "high" || complexitySize === "large") {
+            return {
+                overrideConfig: { enabled: true, toolExecutionTier: "balanced", premiumSynthesis: false },
+                reason: `heuristic: ${taskType}/${taskComplexity ?? "?"}/${complexitySize ?? "?"} benefits from SAMR`,
+            };
+        }
+    }
+    return { overrideConfig: null, reason: "heuristic: no benefit" };
+}
 // ─── Defaults ────────────────────────────────────────────────────────────────
 const DEFAULT_CONFIG = {
     enabled: false,

package/dist/src/scaffold/bb-ecosystem-apply.js

@@ -91,24 +91,24 @@ function buildSampleRuleCs(projectName, intent) {
         .map((w) => w.charAt(0).toUpperCase() + w.slice(1))
         .join("");
     const contextTypeName = `${projectName}RuleContext`;
-    return `using Muonroi.RuleEngine.Abstractions;
-using Muonroi.RuleEngine.Core;
-
-namespace ${projectName}.Domain.Rules;
-
-/// <summary>
-/// Sample rule for intent: ${intent}.
-/// Generated by muonroi-cli — replace stub logic with real business logic.
-/// </summary>
-[MExtractAsRule("SAMPLE_${intent.toUpperCase().replace(/[-\s]/g, "_")}", DependsOn = new string[] { })]
-public class Sample${intentPascal}Rule : IRule<${contextTypeName}>
-{
-    public Task<RuleResult> EvaluateAsync(${contextTypeName} context, CancellationToken cancellationToken = default)
-    {
-        // TODO: Replace with real ${intent} evaluation logic.
-        return Task.FromResult(RuleResult.Passed());
-    }
-}
+    return `using Muonroi.RuleEngine.Abstractions;
+using Muonroi.RuleEngine.Core;
+
+namespace ${projectName}.Domain.Rules;
+
+/// <summary>
+/// Sample rule for intent: ${intent}.
+/// Generated by muonroi-cli — replace stub logic with real business logic.
+/// </summary>
+[MExtractAsRule("SAMPLE_${intent.toUpperCase().replace(/[-\s]/g, "_")}", DependsOn = new string[] { })]
+public class Sample${intentPascal}Rule : IRule<${contextTypeName}>
+{
+    public Task<RuleResult> EvaluateAsync(${contextTypeName} context, CancellationToken cancellationToken = default)
+    {
+        // TODO: Replace with real ${intent} evaluation logic.
+        return Task.FromResult(RuleResult.Passed());
+    }
+}
 `;
 }
 export async function generateSampleRule(serverDir, projectName, intent, fsOps) {
@@ -133,32 +133,32 @@ function buildSampleRuleTestCs(projectName, intent) {
         .map((w) => w.charAt(0).toUpperCase() + w.slice(1))
         .join("");
     const contextTypeName = `${projectName}RuleContext`;
-    return `using Muonroi.RuleEngine.Abstractions;
-using Muonroi.RuleEngine.Core;
-using Xunit;
-
-namespace ${projectName}.UnitTests.Rules;
-
-/// <summary>
-/// Tests for Sample${intentPascal}Rule.
-/// Generated by muonroi-cli — extend with real test cases.
-/// </summary>
-public class Sample${intentPascal}RuleTests
-{
-    [Fact]
-    public async Task EvaluateAsync_ReturnsRuleResultPassed()
-    {
-        // Arrange — senior-grade: uses FactBag + reflection-free context construction
-        var context = new ${contextTypeName}();
-        var rule = new Sample${intentPascal}Rule();
-
-        // Act
-        var result = await rule.EvaluateAsync(context, CancellationToken.None);
-
-        // Assert
-        Assert.Equal(RuleResultStatus.Passed, result.Status);
-    }
-}
+    return `using Muonroi.RuleEngine.Abstractions;
+using Muonroi.RuleEngine.Core;
+using Xunit;
+
+namespace ${projectName}.UnitTests.Rules;
+
+/// <summary>
+/// Tests for Sample${intentPascal}Rule.
+/// Generated by muonroi-cli — extend with real test cases.
+/// </summary>
+public class Sample${intentPascal}RuleTests
+{
+    [Fact]
+    public async Task EvaluateAsync_ReturnsRuleResultPassed()
+    {
+        // Arrange — senior-grade: uses FactBag + reflection-free context construction
+        var context = new ${contextTypeName}();
+        var rule = new Sample${intentPascal}Rule();
+
+        // Act
+        var result = await rule.EvaluateAsync(context, CancellationToken.None);
+
+        // Assert
+        Assert.Equal(RuleResultStatus.Passed, result.Status);
+    }
+}
 `;
 }
 export async function generateSampleRuleTest(serverDir, projectName, intent, fsOps) {
@@ -246,9 +246,9 @@ export async function copyBoundaryScript(serverDir, bbRepoRoot, fsOps) {
         const ciContent = fsOps.readFile(ciYmlPath);
         // Idempotency: skip if already wired
         if (!ciContent.includes(BOUNDARIES_SCRIPT_NAME)) {
-            const boundaryStep = `
-      - name: Check modular boundaries
-        run: pwsh ./scripts/${BOUNDARIES_SCRIPT_NAME} -RepoRoot .
+            const boundaryStep = `
+      - name: Check modular boundaries
+        run: pwsh ./scripts/${BOUNDARIES_SCRIPT_NAME} -RepoRoot .
 `;
             // Append before the last line or after the last job step
             const updated = `${ciContent.trimEnd()}\n${boundaryStep}\n`;

package/dist/src/scaffold/bb-quality-gate.js

@@ -93,11 +93,11 @@ export async function runQualityGateWithRetry(opts, onRetryCodeGen) {
     const failureSummary = firstResult.failures
         .map((f) => `### ${f.step}\n\`\`\`\n${f.output.slice(0, 500)}\n\`\`\``)
         .join("\n\n");
-    const councilPrompt = `${opts.intentPrompt}
-
-## Gate failures (please fix in next iteration)
-${failureSummary}
-
+    const councilPrompt = `${opts.intentPrompt}
+
+## Gate failures (please fix in next iteration)
+${failureSummary}
+
 Please revise the BB ecosystem wiring to fix these compilation/boundary errors.`;
     // Call council once with failures appended
     await continueAsCouncil({

package/dist/src/scaffold/continuation-prompt.js

@@ -1,66 +1,66 @@
 export function buildIdealContinuationPrompt(input) {
     const { originalPrompt, projectDir, templateName, installedPackages } = input;
     const packagesSuffix = installedPackages && installedPackages.length > 0 ? ` with packages: ${installedPackages.join(", ")}` : "";
-    return `You are continuing a /ideal product loop. The project has been scaffolded at ${projectDir} using the BB template ${templateName}${packagesSuffix}.
-
-User's original request:
-"${originalPrompt}"
-
-You MUST implement this feature now. Do NOT ask the user for clarification unless a hard blocker is reached (missing API key, ambiguous schema requirement, etc.).
-
-Execute these steps in order:
-
-1. Discover structure (1-2 tool calls max)
-   - PREFERRED: if a \`muonroi-docs\` MCP tool is in your tool list (look for any \`mcp_*docs*_docs_search\` tool), call it with query \`"${templateName} structure overview"\`. This is faster than reading files.
-   - FALLBACK: list the project directory, then read whichever of \`README.md\`, \`AGENTS.md\`, \`Agent.md\`, \`EE-INTENT.md\` actually exist (do NOT assume — missing files are fine, just skip them).
-   - Identify: project name, main entry point (Program.cs / Gateway), modular boundaries, where to add new domain code.
-
-IMPORTANT — Template sample files are REFERENCE ONLY:
-   - The BB template ships example code (e.g. \`todo-app.Catalog\`, sample \`TodoRepository\`, \`Catalog\` controller, \`DocTemplateDbContext\`, \`BaseTemplateDbContext\`) named after the template/demo, NOT after the user's project.
-   - Read AT MOST ONE such sample file to learn the convention, then DELETE all template sample directories before generating your real domain code. They are reference, not the user's feature.
-   - Do not re-read the same sample file repeatedly. If you need its pattern again, recall from memory or rely on \`docs.search\`.
-   - RENAME every file/class/namespace that still contains the literal token \`BaseTemplate\`, \`DocTemplate\`, or \`TemplateSample\` to a project-appropriate name BEFORE writing domain code. After cleanup, \`git grep -i basetemplate\` MUST return zero hits — the post-scaffold quality gate fails if any survive.
-   - DELETE any stub \`<projectName>.Catalog/\` directory that lives at server root next to \`server/src/Services/\` — \`dotnet new\` may emit a duplicate empty stub.
-
-.NET / C# conventions to follow:
-   - Async methods MUST accept and forward \`CancellationToken\` to every downstream await; suffix names with \`Async\`.
-   - Prefer singular folder names that already exist in the template; if you add new folders, use \`Infrastructure\` (singular), \`Enums\` (plural), \`Authorization\` instead of "Permissioning".
-   - Namespace MUST mirror the folder path under the project, in PascalCase.
-   - DTO ≠ Entity. Don't return EF entities from controllers — always project to a DTO.
-   - DI registration uses \`AddX*\` extension methods in a static class under \`Extensions/\` or \`DependencyInjection/\`; wire them from \`Program.cs\`. Do not register services inline in \`Program.cs\`.
-
-Frontend / client/ conventions (apply ONLY if a \`client/\` directory exists in the scaffold):
-   - NEVER delete or overwrite \`SemanticProvider\`, \`createSemanticRegistry\`, or any \`<Semantic ...>\` wrapper that the scaffold wrote into \`main.tsx\` / \`app.component.ts\`. The agent harness depends on them — removing them silently breaks all E2E specs. If you rewrite \`main.tsx\`, re-include the existing SemanticProvider block verbatim.
-   - Wrap every NEW user-visible region with \`<Semantic id="..." role="..." name="...">\` (composer, list, listitem, modal, statusbar). Pick \`role\` from the union in \`@muonroi/agent-harness-core/protocol\`.
-   - NEVER hardcode API URLs in components. Read from \`import.meta.env.VITE_API_BASE\` (React/Vite) or \`environment.apiBase\` (Angular). If \`.env.example\` does not exist yet, create it with a sensible default; never inline \`http://localhost:5000\` or similar in source.
-   - Put HTTP + DTO code under \`client/src/api/\`. Define request/response types in \`api/types.ts\` (mirror the C# DTO names). Components import a typed client; never call \`fetch\` directly.
-   - Every async view needs THREE states: loading, empty, error. Surface errors via a toast/notification component, not \`console.error\`. Provide an \`ErrorBoundary\` at the app shell.
-   - No inline \`style={{...}}\` literals — use CSS modules (\`*.module.css\`) or utility classes (Tailwind if scaffolded). If neither is present, write tokens + reset into \`src/styles/app.css\` and import it ONCE in main; reference variables via \`var(--color-...)\`.
-   - TypeScript MUST be strict. If \`tsconfig.json\` does not have \`"strict": true\`, add it. Run \`bunx tsc --noEmit\` before declaring done — it must exit 0.
-   - Run \`bun run build\` from \`client/\` before declaring done — it must exit 0 with zero browser-side console errors.
-
-2. Design the feature
-   - List the domain entity(ies), DTOs, endpoints, persistence model.
-   - Match BB conventions (controller-per-resource, MediatR/CQRS if used, validation patterns observed in step 1).
-   - State your design in 5-10 lines before generating code.
-
-3. Generate code
-   - Create files in the locations identified in step 1.
-   - Wire DI in Program.cs (use BB extension methods if present).
-   - Mirror existing patterns — same namespaces, attributes, error-handling style.
-
-4. Verify
-   - Run \`dotnet build\` from the server root — must exit 0.
-   - If a \`client/\` directory exists, also run \`bun install\` and \`bun run build\` from \`client/\`.
-   - Report concrete evidence: build output excerpt + file list created.
-
-5. Summarize
-   - 3-5 bullets: what was added, where, how to test manually.
-
-Constraints:
-- Don't re-scaffold. Don't run \`dotnet new\` again.
-- Don't \`cd\` into ${projectDir} — your working directory is already there.
-- Don't ask "do you want me to continue?" — proceed end-to-end.
+    return `You are continuing a /ideal product loop. The project has been scaffolded at ${projectDir} using the BB template ${templateName}${packagesSuffix}.
+
+User's original request:
+"${originalPrompt}"
+
+You MUST implement this feature now. Do NOT ask the user for clarification unless a hard blocker is reached (missing API key, ambiguous schema requirement, etc.).
+
+Execute these steps in order:
+
+1. Discover structure (1-2 tool calls max)
+   - PREFERRED: if a \`muonroi-docs\` MCP tool is in your tool list (look for any \`mcp_*docs*_docs_search\` tool), call it with query \`"${templateName} structure overview"\`. This is faster than reading files.
+   - FALLBACK: list the project directory, then read whichever of \`README.md\`, \`AGENTS.md\`, \`Agent.md\`, \`EE-INTENT.md\` actually exist (do NOT assume — missing files are fine, just skip them).
+   - Identify: project name, main entry point (Program.cs / Gateway), modular boundaries, where to add new domain code.
+
+IMPORTANT — Template sample files are REFERENCE ONLY:
+   - The BB template ships example code (e.g. \`todo-app.Catalog\`, sample \`TodoRepository\`, \`Catalog\` controller, \`DocTemplateDbContext\`, \`BaseTemplateDbContext\`) named after the template/demo, NOT after the user's project.
+   - Read AT MOST ONE such sample file to learn the convention, then DELETE all template sample directories before generating your real domain code. They are reference, not the user's feature.
+   - Do not re-read the same sample file repeatedly. If you need its pattern again, recall from memory or rely on \`docs.search\`.
+   - RENAME every file/class/namespace that still contains the literal token \`BaseTemplate\`, \`DocTemplate\`, or \`TemplateSample\` to a project-appropriate name BEFORE writing domain code. After cleanup, \`git grep -i basetemplate\` MUST return zero hits — the post-scaffold quality gate fails if any survive.
+   - DELETE any stub \`<projectName>.Catalog/\` directory that lives at server root next to \`server/src/Services/\` — \`dotnet new\` may emit a duplicate empty stub.
+
+.NET / C# conventions to follow:
+   - Async methods MUST accept and forward \`CancellationToken\` to every downstream await; suffix names with \`Async\`.
+   - Prefer singular folder names that already exist in the template; if you add new folders, use \`Infrastructure\` (singular), \`Enums\` (plural), \`Authorization\` instead of "Permissioning".
+   - Namespace MUST mirror the folder path under the project, in PascalCase.
+   - DTO ≠ Entity. Don't return EF entities from controllers — always project to a DTO.
+   - DI registration uses \`AddX*\` extension methods in a static class under \`Extensions/\` or \`DependencyInjection/\`; wire them from \`Program.cs\`. Do not register services inline in \`Program.cs\`.
+
+Frontend / client/ conventions (apply ONLY if a \`client/\` directory exists in the scaffold):
+   - NEVER delete or overwrite \`SemanticProvider\`, \`createSemanticRegistry\`, or any \`<Semantic ...>\` wrapper that the scaffold wrote into \`main.tsx\` / \`app.component.ts\`. The agent harness depends on them — removing them silently breaks all E2E specs. If you rewrite \`main.tsx\`, re-include the existing SemanticProvider block verbatim.
+   - Wrap every NEW user-visible region with \`<Semantic id="..." role="..." name="...">\` (composer, list, listitem, modal, statusbar). Pick \`role\` from the union in \`@muonroi/agent-harness-core/protocol\`.
+   - NEVER hardcode API URLs in components. Read from \`import.meta.env.VITE_API_BASE\` (React/Vite) or \`environment.apiBase\` (Angular). If \`.env.example\` does not exist yet, create it with a sensible default; never inline \`http://localhost:5000\` or similar in source.
+   - Put HTTP + DTO code under \`client/src/api/\`. Define request/response types in \`api/types.ts\` (mirror the C# DTO names). Components import a typed client; never call \`fetch\` directly.
+   - Every async view needs THREE states: loading, empty, error. Surface errors via a toast/notification component, not \`console.error\`. Provide an \`ErrorBoundary\` at the app shell.
+   - No inline \`style={{...}}\` literals — use CSS modules (\`*.module.css\`) or utility classes (Tailwind if scaffolded). If neither is present, write tokens + reset into \`src/styles/app.css\` and import it ONCE in main; reference variables via \`var(--color-...)\`.
+   - TypeScript MUST be strict. If \`tsconfig.json\` does not have \`"strict": true\`, add it. Run \`bunx tsc --noEmit\` before declaring done — it must exit 0.
+   - Run \`bun run build\` from \`client/\` before declaring done — it must exit 0 with zero browser-side console errors.
+
+2. Design the feature
+   - List the domain entity(ies), DTOs, endpoints, persistence model.
+   - Match BB conventions (controller-per-resource, MediatR/CQRS if used, validation patterns observed in step 1).
+   - State your design in 5-10 lines before generating code.
+
+3. Generate code
+   - Create files in the locations identified in step 1.
+   - Wire DI in Program.cs (use BB extension methods if present).
+   - Mirror existing patterns — same namespaces, attributes, error-handling style.
+
+4. Verify
+   - Run \`dotnet build\` from the server root — must exit 0.
+   - If a \`client/\` directory exists, also run \`bun install\` and \`bun run build\` from \`client/\`.
+   - Report concrete evidence: build output excerpt + file list created.
+
+5. Summarize
+   - 3-5 bullets: what was added, where, how to test manually.
+
+Constraints:
+- Don't re-scaffold. Don't run \`dotnet new\` again.
+- Don't \`cd\` into ${projectDir} — your working directory is already there.
+- Don't ask "do you want me to continue?" — proceed end-to-end.
 - If you hit a blocker that genuinely needs the user, state EXACTLY which decision is blocking and stop.`;
 }
 //# sourceMappingURL=continuation-prompt.js.map