DEV Community: Le Anh Phi

Muonroi Building Block: an open-core .NET foundation for rule engines, decision tables, and multi-tenancy

Le Anh Phi — Tue, 14 Apr 2026 11:16:47 +0000

Repository: https://github.com/muonroi/muonroi-building-block

Status: public repo, open-core (Apache-2.0 OSS packages + commercial-licensed packages).

Target audience: unknown (repo docs suggest teams building .NET services that need rule orchestration, decision tables, multi-tenancy, and governance primitives).

Version: 1.0.0-alpha.9 (repo-wide versioning is configured via Directory.Build.props).

Executive summary

Muonroi Building Block is the .NET foundation of the Muonroi ecosystem. It bundles a rule engine stack (strongly typed rules + orchestration + tracing), decision tables (with common hit policies), and supporting infrastructure like governance/licensing concepts and multi-tenancy helpers. The repository is open-core: OSS packages are Apache 2.0, while commercial packages are distributed under a separate commercial license and are expected to be gated at runtime.

A key differentiator is its developer experience around rule authoring: write rule logic in normal C#, mark it with an attribute, then let source generators and CLI tools generate rule classes and DI registration glue. This reduces handmade boilerplate and allows verification steps (e.g., dependency checks) before runtime.

Key features and use cases

Key features (as described by repo README + deep map)

Strongly typed rule abstraction (IRule<TContext>) and shared state via a FactBag.
Rule orchestration with execution hooks, ordering, and dependency constraints.
Decision table engine with widely used hit policies (Unique, Any, First, All, Collect, RuleOrder).
Source generators + analyzers to extract rules from code and generate DI registration.
CLI toolchain (RuleGen) for extract/verify/register/watch flows.
Multi-tenancy packages for resolving tenant context and linking per-tenant resources.
Explicit OSS/commercial boundary enforcement via scripts (modular boundary checks).

Practical use cases

Policy/risk/fraud scoring where rules evolve faster than deployments.
Decision tables for business-friendly rule maintenance with deterministic evaluation.
Multi-tenant SaaS foundations: consistent tenant resolution + quota enforcement primitives.
Preproduction verification: catch rule dependency errors (and other analyzer-driven issues) before runtime.

Architecture and main components

Big-picture: rule execution pipeline

flowchart TD
  Input[Input context + facts] --> Orchestrator[IMRuleOrchestrator.ExecuteAsync]
  Orchestrator --> FactBag[FactBag shared state]
  FactBag --> Rules[Compiled rules / FEEL / decision tables / flow graph]
  Rules --> Result[OrchestratorResult + updated facts]

Big-picture: code-first rule authoring + generation

flowchart LR
  Dev[Developer writes C# method] --> Attr[[MExtractAsRule]]
  Attr --> CLI[muonroi-rule extract/register/verify]
  CLI --> Gen[Generated rule classes + DI registration]
  Gen --> DI[services.AddRuleEngine<T>() + AddGeneratedRules()]
  DI --> Runtime[Runtime executes rules via orchestrator]

Monorepo layout (high level)

muonroi-building-block/
  src/
    Muonroi.RuleEngine.Abstractions/
    Muonroi.RuleEngine.Core/
    Muonroi.RuleEngine.DecisionTable/
    Muonroi.RuleEngine.SourceGenerators/
    Muonroi.Tenancy.*
    Muonroi.Governance.*
    Muonroi.Observability
    (...more packages...)
  tools/
    Muonroi.RuleGen/                  # CLI for rule extraction/registration/verification
    Muonroi.DecisionTableGen/         # decision table tooling (per deep map)
    Muonroi.RuleGen.VisualStudio/     # VS extension (per deep map)
    Muonroi.RuleGen/vscode-extension/ # VS Code extension (per deep map)
  samples/
    Quickstart.RuleEngine/
    Quickstart.DecisionTable/
    FraudDetection/
    LoanApproval/
    MultiTenantSaaS/
    RuleSourceGen/
  REPO_DEEP_MAP.md
  OSS-BOUNDARY.md
  LICENSE-APACHE / LICENSE-COMMERCIAL

If you want the “map of everything,” the repo provides it:

https://github.com/muonroi/muonroi-building-block/blob/main/REPO_DEEP_MAP.md

Installation and quickstart

Install the core rule engine packages

dotnet add package Muonroi.RuleEngine.Core
dotnet add package Muonroi.RuleEngine.SourceGenerators

Exact versions are unknown here; prefer pinning versions explicitly for production.

Quick example: write a rule in plain C

[MExtractAsRule("HIGH_VALUE_ORDER", DependsOn = new[] { "CREDIT_SCORE" })]
public RuleResult HighValue(OrderContext context, FactBag facts)
{
    if (context.Amount <= 1000m) return RuleResult.Failure("Below threshold.");
    facts["requiresReview"] = true;
    return RuleResult.Success();
}

Generate the glue code and wire up DI

muonroi-rule extract --source src/Rules --output Generated/Rules
muonroi-rule register --rules Generated/Rules --output Generated/RuleEngineRegistrationExtensions.g.cs

using Muonroi.RuleEngine.Generated;

builder.Services.AddRuleEngine<OrderContext>();
builder.Services.AddGeneratedRules();

Run a sample (Rule Engine quickstart)

cd <workspace-root>\muonroi-building-block\samples\Quickstart.RuleEngine\src\Quickstart.RuleEngine.Api
dotnet restore
dotnet run

Test request:

curl -X POST http://localhost:5000/api/orders/evaluate `
  -H "Content-Type: application/json" `
  -d "{\"amount\":1200,\"customerType\":\"premium\",\"countryCode\":\"US\"}"

Run a sample (Decision Table quickstart)

Start Postgres locally:

docker run --name muonroi-sample-postgres `
  -e POSTGRES_USER=admin -e POSTGRES_PASSWORD=admin -e POSTGRES_DB=muonroi_decision_tables `
  -p 5432:5432 -d postgres:16

Run the API sample:

cd <workspace-root>\muonroi-building-block\samples\Quickstart.DecisionTable\src\Quickstart.DecisionTable.Api
dotnet restore
dotnet run

Create and execute a table via REST APIs:

Invoke-RestMethod -Method Post -Uri "http://localhost:5000/api/v1/decision-tables" `
  -ContentType "application/json" -InFile ".\assets\discount-table.json"

$body = '{"inputs":{"amount":1200,"customerType":"premium","country":"US"}}'
Invoke-RestMethod -Method Post -Uri "http://localhost:5000/api/v1/decision-tables/discount-rules/execute" `
  -ContentType "application/json" -Body $body

Contribution guide and license

Contributing

The contribution guide emphasizes “boundary-safe” work:

Default working branch: develop
Prereqs: .NET SDK 8+, PowerShell 7+; Postgres/Redis only if your change needs them
Run tests + the modular boundary check before opening a PR:

pwsh ./scripts/check-modular-boundaries.ps1 -RepoRoot .
dotnet test Muonroi.BuildingBlock.sln -c Debug

Contributing guide:

https://github.com/muonroi/muonroi-building-block/blob/main/CONTRIBUTING.md

License (open-core)

OSS packages: Apache 2.0 (LICENSE-APACHE)
Commercial packages: Muonroi commercial license (LICENSE-COMMERCIAL)
The repo documents an OSS/commercial boundary rule and checks it via a script:
- OSS packages MUST NOT depend on commercial packages.
- Commercial packages MAY depend on OSS packages.

Key boundary doc:

https://github.com/muonroi/muonroi-building-block/blob/main/OSS-BOUNDARY.md

License files:

Comparison to similar projects (brief)

Microsoft RulesEngine: JSON-defined workflows and dynamic expression evaluation; Muonroi Building Block offers a more “code-first + source-generated” workflow (plus decision tables, tenancy/governance packages).

References:
- https://microsoft.github.io/RulesEngine/
- https://github.com/microsoft/RulesEngine
NRules: Rete-based .NET rules engine with an internal DSL in C#. Muonroi’s approach leans more toward orchestration + multiple rule types (compiled rules, decision tables, FEEL, flow graphs) and a CLI/source-generator pipeline.

Reference: https://github.com/NRules/NRules
Drools / DMN decision tables: DMN decision tables and FEEL are widely used in decision modeling; Muonroi explicitly implements decision tables and FEEL-related pieces in its runtime/tooling.

Reference: https://docs.drools.org/7.73.0.Final/drools-docs/html_single/index.html

Suggested tags and social blurb

Suggested dev.to tags

dotnet, csharp, rulesengine, decisiontable, opensource, multitenant, architecture, sourcegenerators, cli, observability

Social blurb (3–5 lines)

Muonroi Building Block is an open-core .NET foundation for rule engines, decision tables, and multi-tenant services.

It supports code-first rules + source-generated registration, decision table evaluation, and runtime orchestration with shared FactBag state.

If you’re building policy-heavy systems (risk/fraud/pricing) and want strong DX around rule authoring, it’s worth a deep look.

Repo: https://github.com/muonroi/muonroi-building-block

References

Repo deep map: https://github.com/muonroi/muonroi-building-block/blob/main/REPO_DEEP_MAP.md
OSS boundary doc: https://github.com/muonroi/muonroi-building-block/blob/main/OSS-BOUNDARY.md
Microsoft RulesEngine: https://github.com/microsoft/RulesEngine
NRules: https://github.com/NRules/NRules
Drools DMN + decision tables: https://docs.drools.org/7.73.0.Final/drools-docs/html_single/index.html

Muonroi UI Engine: a manifest-driven UI runtime + rule-authoring web components (open-core)

Le Anh Phi — Tue, 14 Apr 2026 11:16:02 +0000

Repository: https://github.com/muonroi/muonroi-ui-engine

Status: public repo, open-core (some packages are Apache-2.0 OSS, some are commercial-licensed).

Target audience: unknown (repo docs suggest teams building backend-driven UI + rule-authoring UIs).

Version: workspace 0.1.22 (from package.json); MVC package 0.1.0 (from .csproj).

Executive summary

Muonroi UI Engine is the frontend / host-integration layer of the Muonroi ecosystem. Its core idea is backend-driven UI: a host app fetches a manifest that describes navigation, screens, components, actions, and the component registry, then a runtime turns it into a render plan for your framework (React / Angular / PrimeNG).

The repo also contains open-core rule-authoring UI surfaces built as Web Components (Lit): decision tables, rule flow designer, FEEL playground, tracing, etc. These appear to require a commercial license / “activation proof” at runtime, while the base runtime + adapters stay usable without commercial dependencies.

Key features and use cases

Key features (from repo structure and deep map)

Manifest schema (v1/v2) that models navigation groups, screens, components, actions, data sources, registry, auth profile, and more.
Core runtime that resolves screens by route and checks what can render/execute.
Framework adapters for:
- React (@muonroi/ui-engine-react)
- Angular (@muonroi/ui-engine-angular)
- PrimeNG (@muonroi/ui-engine-primeng)
Web Components (Lit) rule-authoring widgets (commercial modules), exposed via tags like:
- <mu-decision-table>
- <mu-rule-flow-designer>
- <mu-feel-playground>
- <mu-rule-trace-viewer>
ASP.NET MVC bridge (Muonroi.Ui.Engine.Mvc) for server-rendered hosts: manifest models + helper extensions.

Practical use cases

Backend-driven admin portals where navigation + screen composition are shipped from a server.
Composable UIs across multiple frontend stacks: reuse the same manifest across React and Angular apps via adapters.
Embedded rule-authoring experiences (decision tables / flow designer) inside an internal control plane.
Server-rendered hosts that need to load a manifest and drive “what to show” in MVC views.

Architecture and main components

Big-picture (how the UI engine flows)

flowchart LR
  Host[Host app (React / Angular / MVC)] -->|fetch JSON manifest| Manifest[MUiEngineManifest]
  Manifest --> Runtime[MUiEngineRuntime]
  Runtime --> Plan[Render plan / layout plan]
  Plan --> Adapter[Framework adapter<br/>(React/Angular/PrimeNG)]
  Adapter --> UI[Actual UI components<br/>+ custom elements]
  UI -->|calls| APIs[Backend endpoints]

Monorepo layout (high level)

muonroi-ui-engine/
  packages/
    m-ui-engine-core/                 # OSS runtime + schema contracts
    m-ui-engine-react/                # OSS React wrappers
    m-ui-engine-angular/              # OSS Angular mappers
    m-ui-engine-primeng/              # OSS PrimeNG adapter
    m-ui-engine-rule-components/      # Commercial: decision tables, flow designer, FEEL, trace...
    m-ui-engine-rule-components-primeng  # Commercial: PrimeNG adapter for rule components
    m-ui-engine-signalr/              # Commercial: schema watcher via SignalR
    m-ui-engine-sync/                 # Commercial: CLI sync tooling
  src/
    Muonroi.Ui.Engine.Mvc/            # OSS .NET MVC bridge package
  tests/
    Muonroi.Ui.Engine.Mvc.Tests/      # tests mostly concentrated here (per repo README)
  REPO_DEEP_MAP.md                    # file-level map of the monorepo
  LICENSE / LICENSE-APACHE / LICENSE-COMMERCIAL

Core runtime package: what’s inside

The file-level map highlights core “building blocks” such as:

contracts.ts: the manifest schema (MUiEngineManifest, MUiEngineScreen, MUiEngineAction, etc.).
runtime.ts: MUiEngineRuntime (screen resolution, permission checks).
bootstrap.ts: bootstrapper, manifest provider, schema watcher, telemetry.
adapters.ts: render adapters + render-plan builders.
license/MLicenseVerifier.ts: license verification used to gate commercial modules.

If you only read one file before diving deeper, start here:

https://github.com/muonroi/muonroi-ui-engine/blob/main/REPO_DEEP_MAP.md

Optional commercial rule-authoring surface

The deep map lists many UI widgets shipped as custom elements (Lit). A typical flow is:

flowchart TD
  App[Host app] -->|bootstraps custom elements| Loader[MLoadRuleEngineCustomElements]
  Loader --> Gate[Commercial license check]
  Gate -->|license ok| Widgets[Decision table / Flow designer / FEEL / Trace widgets]
  Gate -->|not licensed| Prompt[Upgrade prompt / restricted UI]

Installation and quickstart

Build the monorepo locally (TypeScript workspace)

pnpm install
pnpm build

Notes:

The root package.json indicates a workspace layout with packages/* and scripts that run workspace builds/tests.
Tooling includes TypeScript and Vitest (for tests), and the repo references Vite configs for certain bundles.

Install the ASP.NET MVC host bridge

dotnet add package Muonroi.Ui.Engine.Mvc

Compatibility warning: the .csproj targets net9.0 (check your runtime/SDK availability).

Example usage

1) Bootstrapping rule-authoring custom elements from React

The README shows a React setup that loads custom elements and renders the flow designer:

import {
  MLoadRuleEngineCustomElements,
  MuRuleFlowDesignerReact
} from "@muonroi/ui-engine-react";

await MLoadRuleEngineCustomElements({ activationProof });

<MuRuleFlowDesignerReact
  graph={{
    nodes: [],
    edges: [],
    metadata: { version: 1, workflowName: "wf.orders" }
  }}
  apiBaseUrl="/api/v1"
  height={720}
/>;

What’s unknown: how activationProof is obtained and what exact fields it contains (it’s part of the commercial story).

2) A minimal (illustrative) manifest snippet

Based on the TypeScript contracts, a manifest is shaped roughly like this:

{
  "schemaVersion": "mui.engine.v2",
  "generatedAtUtc": "2026-04-14T00:00:00Z",
  "userId": "00000000-0000-0000-0000-000000000000",
  "tenantId": "tenant-a",
  "navigationGroups": [],
  "screens": [],
  "actions": [],
  "dataSources": [],
  "componentRegistry": {
    "components": {}
  }
}

3) MVC host: working with manifest models

The MVC package includes manifest models like MUiEngineManifest, MUiEngineNavigationGroup, MUiEngineScreen, etc. You can also use extension helpers like MVisibleItems() for view-level rendering logic:

@using Muonroi.Ui.Engine.Mvc
@using Muonroi.Ui.Engine.Mvc.Models
@model MUiEngineManifest

<nav>
  @foreach (var group in Model.NavigationGroups)
  {
    <h3>@group.GroupDisplayName</h3>
    <ul>
      @foreach (var item in group.MVisibleItems())
      {
        <li>@item.Title</li>
      }
    </ul>
  }
</nav>

Contribution guide and license

Contributing

The repo’s contributing guide highlights:

Default branch: develop
Prereqs: Node.js 20+, pnpm
Usual workflow: pnpm install, pnpm test, pnpm build
Keep the OSS/commercial boundary intact; add docs/tests when behavior changes.

Contributing guide:

https://github.com/muonroi/muonroi-ui-engine/blob/main/CONTRIBUTING.md

License (open-core / dual license)

The root license file describes a dual-license structure:

OSS core + adapters: Apache 2.0 (LICENSE-APACHE)
Commercial modules: Muonroi commercial license (LICENSE-COMMERCIAL)

License files:

Comparison to similar approaches (brief)

Compared to microfrontend orchestrators (e.g., single-spa): Muonroi UI Engine is centered on a backend-driven manifest + runtime + component registry, not only on “mount multiple frontends into one shell.”

Reference (microfrontends concept): https://single-spa.js.org/docs/microfrontends-concept/
Compared to low-code/internal tool builders (e.g., Appsmith): Appsmith focuses on a visual app builder with drag-and-drop widgets + integrations, while Muonroi UI Engine looks like a programmable runtime + adapters with optional embedded rule-authoring widgets.

Reference: https://www.appsmith.com/
Compared to form builders (e.g., Form.io): Form.io’s open source core is strongly focused on form rendering/builder, whereas Muonroi UI Engine’s scope includes navigation/screen composition plus rule-authoring widgets (decision tables/flows).

Reference: https://form.io/open-source/

Suggested tags and social blurb

Suggested dev.to tags

muonroi, typescript, webcomponents, react, angular, dotnet, lit, backenddrivenui, monorepo, opensource

Social blurb (3–5 lines)

Muonroi UI Engine is a manifest-driven UI runtime (open-core) that lets your backend describe navigation/screens/components—and renders them through React/Angular/PrimeNG adapters.

It also ships optional Lit-based rule-authoring widgets (decision tables, flow designer, FEEL playground, tracing).

If you’re exploring backend-driven UI + embeddable rule tooling, this monorepo is worth a look.

Repo: https://github.com/muonroi/muonroi-ui-engine

References

Repo deep map: https://github.com/muonroi/muonroi-ui-engine/blob/main/REPO_DEEP_MAP.md
single-spa microfrontends concept: https://single-spa.js.org/docs/microfrontends-concept/
Appsmith: https://www.appsmith.com/
Form.io open source: https://form.io/open-source/

Quick Codex: a lightweight workflow layer for Codex CLI

Le Anh Phi — Tue, 14 Apr 2026 09:50:02 +0000

Codex is very good at focused execution.

But once a task gets a little bigger, a familiar problem shows up: the work starts living in chat memory.

You clarify the task in one turn, research a few gaps in the next, begin implementation, then come back later and wonder:

What exactly was the agreed scope?
Which part is done?
What is the next safe step?
Can I trust the current state, or am I already drifting?

That pain point is why I built Quick Codex.

It is an open-source, lightweight workflow layer for Codex CLI. The goal is simple: make medium-sized work more resumable, auditable, and harder to derail.

Not bigger. Not more complex. Just more durable.

The problem is not coding, it is continuity

In my experience, raw Codex is strongest when the task is already clear and the execution window is short.

The trouble starts when a task spans multiple turns and the workflow stays implicit.

Something like this happens:

You explain the problem
Codex explores a few files
A plan starts to form
Implementation begins
Context gets fuzzy
The next step is no longer obvious
Drift starts

At that point, you are not fighting code generation anymore. You are fighting state loss.

That is the gap Quick Codex is trying to close.

What Quick Codex actually does

Quick Codex adds a small local workflow surface around Codex CLI.

Core capabilities

qc-flow → front-half work
qc-lock → strict execution

CLI utilities

status
resume
doctor-run
repair-run
lock-check
verify-wave
close-wave

Key idea: workflow state should live in files, not only in chat memory.

Two modes, two different jobs

qc-flow

Use when the task is still unclear.

qc-lock

Use when the scope is already defined and needs strict control.

Example commands

npx quick-codex install
node bin/quick-codex.js status --dir /path/to/project
node bin/quick-codex.js resume --dir /path/to/project
node bin/quick-codex.js doctor-run --dir /path/to/project

Experience Engine: AI Memory That Shrinks As Your Agent Learns

Le Anh Phi — Fri, 10 Apr 2026 01:44:43 +0000

Every AI coding session, my agent made the same mistakes.

DbContext as singleton — state corruption, 15 minutes debugging. Again. ILogger instead of IMLog — lost tenant context. Again. Wrong project reference path — build fails. Again.

I had 500 memory notes. My agent was still a junior with a bigger notebook.

So I built something different.

The Problem With AI Memory

Every AI memory tool — Mem0, Letta, Zep — stores facts. More sessions = more entries = more tokens = more cost. They're giving your agent a bigger notebook.

But here's the thing: a notebook doesn't make you experienced.

A junior developer with 500 notes is still a junior. A mid-level developer with 15 principles understands why things work. The difference isn't how much you remember — it's whether you can generalize.

Junior (500 notes):
  "DbContext singleton caused bug"
  "HttpClient singleton caused leak"  
  "SmtpClient singleton caused corruption"
  → Encounters RedisConnection singleton → NO MATCH → makes the mistake

Mid-level (1 principle):
  "Stateful objects must be scoped, never singleton"
  → Encounters RedisConnection singleton → MATCHES → avoids the mistake

That's what Experience Engine does. It doesn't store more facts. It evolves facts into principles, then deletes the facts.

How It Works

When you code with any AI agent (Claude Code, Gemini CLI, Codex CLI), Experience Engine runs silently in the background:

Before every Edit/Write/Bash:
A hook queries the experience store: "Have I seen this mistake before?" If yes, it injects a warning directly into the agent's context:

⚠️ [Experience - High Confidence (0.85)]: Stateful objects must be 
scoped, never singleton. Last time SingleInstance caused state 
corruption in DbContext.

The agent reads this warning and avoids the mistake. No human intervention needed.

After every session:
An extractor scans the session transcript for mistake patterns:

Retry loops (same tool call 3+ times)
User corrections ("no, not that", "wrong", "undo")
Test fail → fix cycles
Git reverts

Each detected mistake gets extracted into a structured Q&A entry and stored in a vector database.

Weekly (automatic):
The evolution engine runs:

Promote: entries confirmed 3+ times move from cache → behavioral rules
Abstract: clusters of 3+ similar entries → one general principle
Demote: entries ignored 3+ times get deprioritized
Archive: entries unused for 90 days get cleaned up

The result: memory shrinks as capability grows.

The 4-Tier Architecture

T0 Principles  (~400 tokens)  — generalized rules, always loaded
    "Stateful objects must be scoped, never singleton"

T1 Behavioral  (~600 tokens)  — specific reflexes, always loaded
    "WHEN DbContext + DI → MUST check lifetime FIRST"

T2 QA Cache    (semantic)     — detailed Q&A, retrieved on match
    Q: "Why not singleton?" → A: "State corruption across requests"

T3 Raw         (staging)      — unprocessed mistakes, TTL 30 days

Lifecycle: T3 → extract → T2 → promote (3x confirmed) → T1 
           → generalize (cluster 3+) → T0
           Memory SHRINKS as capability GROWS

What Makes This Different

	Mem0	Letta	Zep	Experience Engine
Over time	Entries grow forever	Entries grow forever	Entries grow forever	Entries shrink into principles
Novel cases	Only exact matches	Only exact matches	Only exact matches	Principles generalize
Mistake learning	No	No	No	5 detection patterns
Dependencies	Python + SDK	PostgreSQL	PostgreSQL	Zero (Node.js built-in)
Local-first	Optional	Optional	Partial	Default
Data ownership	Cloud vendor	SaaS terms	Cloud vendor	You own everything

Experience Graph

Experiences aren't isolated entries — they're linked with typed edges:

DbContext singleton ──generalizes──→ "Stateful objects: always scoped"
                    ──relates-to───→ HttpClient singleton  
                    ──supersedes───→ [old] "Use transient for DbContext"
                    ──contradicts──→ [demoted] "Singleton is fine for DbContext"

When one experience matches your current action, the engine follows edges to surface related experiences too. This is how it catches RedisConnection singleton — not because it's seen Redis before, but because it's connected to the principle about stateful objects.

Temporal Reasoning

Knowledge evolves. What was true in January might be wrong in March:

January:  "Use singleton for HttpClient" (confirmed 5x)
March:    "Use IHttpClientFactory instead" (contradicts January)
          → January entry superseded, not deleted
          → March entry ranks higher (recent confirmation)
          → GET /api/timeline?topic=httpclient shows the evolution

The engine tracks confirmedAt[] arrays — not just "what was learned" but "when it was last confirmed." Stale knowledge gets penalized. Recent confirmations get boosted.

REST API

Everything is accessible via HTTP — not just CLI hooks:

# Start the server
node server.js
# Experience Engine API running on http://localhost:8082

# Check health
curl localhost:8082/health

# Query experience before a tool call
curl -X POST localhost:8082/api/intercept \
  -H "Content-Type: application/json" \
  -d '{"toolName":"Write","toolInput":{"file_path":"src/Startup.cs"}}'

# Response:
{
  "suggestions": "⚠️ [High Confidence (0.85)]: Stateful objects must be scoped",
  "hasSuggestions": true
}

# Trigger evolution
curl -X POST localhost:8082/api/evolve
# {"promoted":2,"abstracted":1,"demoted":0,"archived":3,"success":true}

# View stats
curl localhost:8082/api/stats?since=30d

# Knowledge timeline
curl "localhost:8082/api/timeline?topic=dependency+injection"

# Experience graph
curl "localhost:8082/api/graph?id=abc-123"

10 endpoints total. Zero dependencies — uses Node.js built-in http module. CORS enabled for browser extensions.

Python SDK

from muonroi_experience import Client

client = Client("http://localhost:8082")

# Query experience
result = client.intercept("Write", {"file_path": "app.py"})
if result["hasSuggestions"]:
    print(result["suggestions"])

# Extract lessons
client.extract("Agent tried singleton for DbContext, caused corruption...")

# Trigger evolution  
evolution = client.evolve()
print(f"Promoted: {evolution['promoted']}, Abstracted: {evolution['abstracted']}")

# Check stats
stats = client.stats(since="7d")
print(f"Mistakes avoided: {stats['suggestions']}")

# View knowledge timeline
timeline = client.timeline("dependency injection")
for entry in timeline["timeline"]:
    status = "[superseded]" if entry["superseded"] else ""
    print(f"  {status} {entry['solution']}")

Zero dependencies — uses Python stdlib urllib. Python 3.8+.

Multi-User Support

Multiple developers on the same machine get isolated stores:

EXP_USER=alice node server.js    # Alice's experiences
EXP_USER=bob node server.js      # Bob's (completely isolated)

Share principles without sharing personal data:

# Alice shares a principle she evolved
curl -X POST localhost:8082/api/principles/share \
  -d '{"principleId": "abc-123"}'
# Returns portable JSON — no personal data included

# Bob imports it
curl -X POST localhost:8082/api/principles/import \
  -d '{"principle":"Stateful objects must be scoped","solution":"...","confidence":0.85}'
# Bob's evolution engine manages it independently from here

Quick Start (5 minutes)

git clone https://github.com/muonroi/experience-engine.git
cd experience-engine
bash .experience/setup.sh --local   # Docker Qdrant + Ollama (100% free)

The setup wizard handles everything. After setup, your agent starts learning automatically through hooks.

Supported providers

You're not locked to Ollama. The engine supports:

Embedding: Ollama, OpenAI, Gemini, VoyageAI, SiliconFlow, or any OpenAI-compatible API

Brain (extraction): Ollama, OpenAI, Gemini, Claude, DeepSeek, SiliconFlow, or any OpenAI-compatible API

Mix and match — e.g., SiliconFlow for cheap embeddings + Ollama for free extraction.

Anti-Noise Scoring

Not all experiences are equal. Results are ranked by:

Hit frequency — confirmed experiences rank higher
Recency — recently confirmed > stale (60+ days penalty)
Confidence aging — new entries start lower, climb with confirmation
Ignore tracking — suggestions ignored 3x get demoted
Domain match — editing .ts file → TypeScript experiences rank higher
Temporal boost — confirmed in last 7 days → score boost
Superseded penalty — replaced knowledge ranks lower

This means your agent gets the most relevant, most trusted experience for the current context — not just the most similar vector match.

The Philosophy

Every AI memory company stores your data on their cloud and charges you to access it. Mem0 stores your memories. Letta stores your agent state. You pay monthly to access your own knowledge.

Experience Engine is different:

Your data never leaves your machine (unless you choose cloud sync)
Zero vendor lock-in — standard formats, portable profiles
Zero dependencies — Node.js built-in modules only
The engine is open source — you pay for convenience, never for capability

"Enterprise AI replaces you. Personal AI empowers you. Same technology. Different owner."

What's Next

The engine is live and working. I'm dogfooding it on my own projects right now. After 2 weeks:

47 suggestions fired
12 mistakes avoided
5 principles evolved from ~50 raw entries
Memory footprint decreased (entries compressed into principles)

Next up: dashboard for visualizing the "Saves" feed (mistakes the agent didn't make), and a browser extension that injects experience into ChatGPT/Claude/Gemini web interfaces.

DEV Community: Le Anh Phi

Muonroi Building Block: an open-core .NET foundation for rule engines, decision tables, and multi-tenancy

Executive summary

Key features and use cases

Key features (as described by repo README + deep map)

Practical use cases

Architecture and main components

Big-picture: rule execution pipeline

Big-picture: code-first rule authoring + generation

Monorepo layout (high level)

Installation and quickstart

Install the core rule engine packages

Quick example: write a rule in plain C

Generate the glue code and wire up DI

Run a sample (Rule Engine quickstart)

Run a sample (Decision Table quickstart)

Contribution guide and license

Contributing

License (open-core)

Comparison to similar projects (brief)

Suggested tags and social blurb

Suggested dev.to tags

Social blurb (3–5 lines)

References

Muonroi UI Engine: a manifest-driven UI runtime + rule-authoring web components (open-core)

Executive summary

Key features and use cases

Key features (from repo structure and deep map)

Practical use cases

Architecture and main components

Big-picture (how the UI engine flows)

Monorepo layout (high level)

Core runtime package: what’s inside

Optional commercial rule-authoring surface

Installation and quickstart

Build the monorepo locally (TypeScript workspace)

Install the ASP.NET MVC host bridge

Example usage

1) Bootstrapping rule-authoring custom elements from React

2) A minimal (illustrative) manifest snippet

3) MVC host: working with manifest models

Contribution guide and license

Contributing

License (open-core / dual license)

Comparison to similar approaches (brief)

Suggested tags and social blurb

Suggested dev.to tags

Social blurb (3–5 lines)

References

Quick Codex: a lightweight workflow layer for Codex CLI

The problem is not coding, it is continuity

What Quick Codex actually does

Core capabilities

CLI utilities

Two modes, two different jobs

qc-flow

qc-lock

Example commands

Links

Experience Engine: AI Memory That Shrinks As Your Agent Learns

The Problem With AI Memory

How It Works

The 4-Tier Architecture

What Makes This Different

Experience Graph

Temporal Reasoning

REST API

Python SDK

Multi-User Support

Quick Start (5 minutes)

Supported providers

Anti-Noise Scoring

The Philosophy

What's Next

Links