muonroi-cli 1.4.1 → 1.6.0

package/dist/src/providers/mcp-vision-bridge.js

@@ -48,27 +48,27 @@ const IMAGE_EXTENSIONS = new Set([".png", ".jpg", ".jpeg", ".gif", ".webp", ".bm
  * Downstream agents consume this JSON directly instead of re-parsing markdown.
  * Kept embedded in the prompt (not strict JSON-schema mode) for cross-provider portability.
  */
-export const UI_LAYOUT_SCHEMA_HINT = `{
-  "viewport": { "width": number, "height": number, "deviceClass": "mobile" | "tablet" | "desktop" },
-  "tokens": {
-    "colors": [{ "name": string, "hex": string, "role": "primary" | "secondary" | "accent" | "bg" | "fg" | "border" | "muted" }],
-    "typography": [{ "role": "heading" | "body" | "caption" | "label", "fontFamily": string, "sizePx": number, "weight": number }],
-    "spacingScalePx": number[],
-    "radiusScalePx": number[]
-  },
-  "layout": { "type": "stack" | "grid" | "flex" | "absolute", "direction": "row" | "column", "gapPx": number, "columns": number | null },
-  "components": [{
-    "id": string,
-    "role": "button" | "input" | "card" | "nav" | "header" | "footer" | "image" | "icon" | "text" | "list" | "modal" | "tabs" | "table" | "chart" | "container" | "other",
-    "label": string,
-    "text": string | null,
-    "bbox": { "x": number, "y": number, "w": number, "h": number },
-    "style": { "bgHex": string | null, "fgHex": string | null, "borderHex": string | null, "radiusPx": number | null, "shadow": string | null },
-    "state": "default" | "hover" | "active" | "disabled" | "focus" | "error",
-    "children": string[]
-  }],
-  "hierarchy": [{ "level": 1 | 2 | 3, "text": string, "componentId": string }],
-  "notes": string[]
+export const UI_LAYOUT_SCHEMA_HINT = `{
+  "viewport": { "width": number, "height": number, "deviceClass": "mobile" | "tablet" | "desktop" },
+  "tokens": {
+    "colors": [{ "name": string, "hex": string, "role": "primary" | "secondary" | "accent" | "bg" | "fg" | "border" | "muted" }],
+    "typography": [{ "role": "heading" | "body" | "caption" | "label", "fontFamily": string, "sizePx": number, "weight": number }],
+    "spacingScalePx": number[],
+    "radiusScalePx": number[]
+  },
+  "layout": { "type": "stack" | "grid" | "flex" | "absolute", "direction": "row" | "column", "gapPx": number, "columns": number | null },
+  "components": [{
+    "id": string,
+    "role": "button" | "input" | "card" | "nav" | "header" | "footer" | "image" | "icon" | "text" | "list" | "modal" | "tabs" | "table" | "chart" | "container" | "other",
+    "label": string,
+    "text": string | null,
+    "bbox": { "x": number, "y": number, "w": number, "h": number },
+    "style": { "bgHex": string | null, "fgHex": string | null, "borderHex": string | null, "radiusPx": number | null, "shadow": string | null },
+    "state": "default" | "hover" | "active" | "disabled" | "focus" | "error",
+    "children": string[]
+  }],
+  "hierarchy": [{ "level": 1 | 2 | 3, "text": string, "componentId": string }],
+  "notes": string[]
 }`;
 const MIME_MAP = {
     ".png": "image/png",
@@ -319,33 +319,33 @@ export async function askVisionProxy(question, imageIdOrPath, cwd, signal) {
 export function getVisionGuidanceForTextOnly(modelId) {
     if (!needsVisionProxy(modelId))
         return "";
-    return `
-VISION PROXY (text-only model):
-You cannot see images directly. You have vision proxy tools to work with ANY image:
-
-TOOLS:
-- analyze_image: Proactively analyze an image from a file path, URL, or base64. Use this FIRST when you encounter or need to work with an image.
-- ask_vision_proxy: Ask a specific follow-up question about any cached image (or provide a file path for a new image).
-- list_vision_cache: See all cached images available for querying.
-
-WHEN TO USE (be PROACTIVE, not passive):
-- User mentions an image file → analyze_image immediately
-- User pastes or references a screenshot → it's auto-analyzed, use ask_vision_proxy for details
-- Working with UI/web pages → prefer browser_snapshot (text-based), use screenshot + ask_vision_proxy when visual details matter
-- Reviewing design mockups, diagrams, charts → analyze_image the file
-- Debugging visual issues (CSS, layout, colors) → take screenshot, then ask_vision_proxy specific questions
-- Comparing before/after → analyze both images, ask about differences
-- Reading text from images (OCR) → analyze_image with a question like "transcribe all text"
-- Any file with image extension (.png, .jpg, .gif, .webp, .svg, etc.) → analyze_image
-
-WORKFLOW:
-1. Encounter image → analyze_image (or it's auto-analyzed from tool results)
-2. Need more detail → ask_vision_proxy with specific question
-3. Need to verify changes → take new screenshot/analyze new image → compare
-
-Images are cached (up to ${IMAGE_CACHE_MAX}, ${IMAGE_CACHE_TTL_MS / 60000}min TTL). You can reference them by ID for follow-ups.
-
-IMPORTANT: Do NOT guess what an image contains. Always use the proxy to get accurate information.
+    return `
+VISION PROXY (text-only model):
+You cannot see images directly. You have vision proxy tools to work with ANY image:
+
+TOOLS:
+- analyze_image: Proactively analyze an image from a file path, URL, or base64. Use this FIRST when you encounter or need to work with an image.
+- ask_vision_proxy: Ask a specific follow-up question about any cached image (or provide a file path for a new image).
+- list_vision_cache: See all cached images available for querying.
+
+WHEN TO USE (be PROACTIVE, not passive):
+- User mentions an image file → analyze_image immediately
+- User pastes or references a screenshot → it's auto-analyzed, use ask_vision_proxy for details
+- Working with UI/web pages → prefer browser_snapshot (text-based), use screenshot + ask_vision_proxy when visual details matter
+- Reviewing design mockups, diagrams, charts → analyze_image the file
+- Debugging visual issues (CSS, layout, colors) → take screenshot, then ask_vision_proxy specific questions
+- Comparing before/after → analyze both images, ask about differences
+- Reading text from images (OCR) → analyze_image with a question like "transcribe all text"
+- Any file with image extension (.png, .jpg, .gif, .webp, .svg, etc.) → analyze_image
+
+WORKFLOW:
+1. Encounter image → analyze_image (or it's auto-analyzed from tool results)
+2. Need more detail → ask_vision_proxy with specific question
+3. Need to verify changes → take new screenshot/analyze new image → compare
+
+Images are cached (up to ${IMAGE_CACHE_MAX}, ${IMAGE_CACHE_TTL_MS / 60000}min TTL). You can reference them by ID for follow-ups.
+
+IMPORTANT: Do NOT guess what an image contains. Always use the proxy to get accurate information.
 `;
 }
 // Keep backward compat export

package/dist/src/reporter/index.js

@@ -28,7 +28,7 @@ const HEARTBEAT_EVERY_N_POLLS = 12; // ~60s at default 5s poll interval
 function emitHeartbeat(runId) {
     try {
         const db = getDatabase();
-        db.prepare(`INSERT INTO interaction_logs (session_id, event_type, event_subtype, metadata_json, created_at)
+        db.prepare(`INSERT INTO interaction_logs (session_id, event_type, event_subtype, metadata_json, created_at)
        VALUES (?, 'reporter', 'heartbeat', '{}', ?)`).run(runId, new Date().toISOString());
     }
     catch {

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