What a Principal Engineer's Codebase Actually Looks Like: A Deep Dive into iching.rocks

This is what a Principal Engineer’s codebase actually looks like — a live, unscripted walkthrough of iching.rocks.

This post was generated with an assist from Claude, querying my self-hosted Engram MCP server against the live iching.rocks repository — itself a demonstration of the semantic-memory infrastructure described below. Nothing here is hypothetical; every snippet was pulled directly from the codebase.

I get asked a version of the same question in almost every interview loop for Principal/Staff-level roles: “show me something you’ve built end-to-end.” Resumes and LeetCode rounds don’t really answer that. So instead, here’s an unscripted walkthrough of iching.rocks — a production .NET 10 system I designed, built, and operate solo — with real code, pulled live from the repo via my own MCP tooling.

The memory server that made this possible — Engram — is also the foundation of Continuum, the persistent-memory product for AI coding agents I’m building at Network-Ideas.

The shape of the system
Designing the MCP server like a hostile-traffic target, because it is one
The MCP tool layer itself
Prompt-injection hardening on the paid OpenAI pipeline
“Wait, it’s just Razor Pages?” — yes, on purpose
Engineering process, not just code
Why all this matters

A note on the code below: a couple of specific numeric constants (rate-limit window sizes, capacity caps) have been withheld or described qualitatively rather than shown as literal values, since publishing exact thresholds would just hand an attacker a tuning target. Everything else — every snippet, comment, and code block — is reproduced unmodified, live, from the repository via Engram; it’s not paraphrased or reconstructed from memory, just selectively redacted where a number could be misused.

The shape of the system

iching.rocks isn’t a toy. It’s a five-project solution:

<Solution>
  <Project Path="iching.rocks.admin/iching.rocks.admin.csproj" />
  <Project Path="iching.rocks.Core/iching.rocks.Core.csproj" />
  <Project Path="iching.rocks/iching.rocks.csproj" />
  <Project Path="iching.rocks.mcp/iching.rocks.mcp.csproj" />
  <Project Path="iching.rocks.Tests/iching.rocks.Tests.csproj" />
</Solution>Code language: HTML, XML (xml)

iching.rocks — the public ASP.NET Core Razor Pages site: readings, Stripe-backed paid interpretations, an OpenAI-driven interpretation pipeline.
iching.rocks.admin — an internal admin app, deployed and versioned separately.
iching.rocks.Core — a deliberately dependency-free domain library. No web, no DB, no Stripe, no OpenAI. Just the hexagram corpus and pure query logic.
iching.rocks.mcp — a public, unauthenticated Model Context Protocol server exposing the I Ching corpus to AI agents (Claude, ChatGPT, etc.) as callable tools.
iching.rocks.Tests — xUnit + Testcontainers.MsSql + Moq, exercising all three runtime projects.

What I want a hiring manager to notice isn’t the hexagram trivia — it’s the boundaries. iching.rocks.Core is architecturally locked out of touching infrastructure:

“iching.rocks.Core stays free of web, DB, Stripe, OpenAI, encryption, and Data Protection references; the casting RNG stays in the web app.”

That’s not a suggestion in a wiki somewhere — it’s an enforced constraint that gets checked on every AI-assisted code review pass (more on that pipeline below). The MCP server project makes the same commitment explicit in its .csproj:

<ItemGroup>
  <!--
    iching.rocks.Core only. This project must never reference the main
    iching.rocks web project: no Stripe, OpenAI, DB, encryption, Data
    Protection, or member/auth dependencies (design-spec-final.md §3.1).
  -->
  <ProjectReference Include="..\iching.rocks.Core\iching.rocks.Core.csproj" />
</ItemGroup>Code language: HTML, XML (xml)

A public-facing MCP endpoint physically cannot reach the payment stack, the auth stack, or the encryption layer, because the project reference graph doesn’t allow it. That’s a security boundary enforced by the build, not by code review discipline alone.

Designing the MCP server like a hostile-traffic target, because it is one

The MCP server (mcp.iching.rocks) is public and unauthenticated by design — that’s the point of MCP, agents need to be able to connect without a login flow. Which means every hardening decision has to assume adversarial input from day one.

Origin validation against DNS rebinding, applied as ASP.NET Core middleware:

/// <summary>
/// Origin validation for a public unauthenticated Streamable HTTP server
/// (design-spec-final.md §3.2.3, DNS-rebinding defense). Absent Origin is
/// allowed — normal non-browser MCP clients send none. A present Origin
/// outside the allowed list is rejected with 403. CORS stays closed by
/// default: no permissive policy is registered anywhere in this app.
/// </summary>
public class OriginValidationMiddleware(RequestDelegate next, IOptions<McpServerSettings> options)
{
    private readonly RequestDelegate _next = next;
    private readonly HashSet<string> _allowedOrigins =
        new(options.Value.AllowedOrigins, StringComparer.OrdinalIgnoreCase);

    public async Task InvokeAsync(HttpContext context)
    {
        string? sOrigin = context.Request.Headers.Origin.FirstOrDefault();

        if (!string.IsNullOrEmpty(sOrigin) && !_allowedOrigins.Contains(sOrigin))
        {
            context.Response.StatusCode = StatusCodes.Status403Forbidden;
            context.Response.ContentType = "application/json";
            await context.Response.WriteAsync("{\"error\":\"Origin not allowed.\"}");
            return;
        }

        await _next(context);
    }
}Code language: C# (cs)

Notice the reasoning captured in the comment: this check is specifically scoped to defend against browser-based DNS rebinding, where a page in a victim’s browser tries to make the browser itself send a mismatched Origin at the server. Non-browser MCP clients don’t participate in that threat model the same way, so the middleware’s design deliberately targets the case it can actually defend — a naive implementation blocks legitimate agent traffic trying to close a gap it can’t close from this layer alone; a careless one claims a broader guarantee than it delivers. Origin checking is one layer in a defense-in-depth stack, not the whole story — it’s paired with the rate limiting below and closed-by-default CORS.

A two-bucket rate limiter with a bounded key table. This is the part I’d actually walk a Principal-level interviewer through, because it demonstrates concurrency reasoning, not just “add a rate limit”:

/// <summary>
/// App-level two-bucket rate limiter (design-spec-final.md §3.9): standard
/// (all non-bulk tools/resources) and bulk (get_all_hexagrams + dataset
/// resources). A bulk call is charged against both buckets.
/// </summary>
public interface IMcpRateLimiter
{
    RateLimitDecision TryAcquire(string clientKey, bool isBulk);
}

public class McpRateLimiter(IOptions<McpServerSettings> options, TimeProvider timeProvider) : IMcpRateLimiter
{
    private readonly ConcurrentDictionary<string, ClientWindow> _windows = new();
    private long _lastPrunedWindowIndex = -1;
    ...
}Code language: C# (cs)

A few things worth calling out to a reviewer:

Two independent budgets, not one. Expensive “bulk” calls (get_all_hexagrams, dataset dumps) draw down both a standard bucket and a bulk-specific bucket, so a client can’t starve normal traffic by hammering the cheap endpoints while also camping the expensive ones.
Bounded memory under adversarial load. The key table is capped at a fixed size, because an unauthenticated public server is exactly the kind of thing that attracts high-cardinality key churn — the limiter’s own footprint has to stay bounded no matter what arrives. The cap and window size are configuration, not constants I’d publish.
Pruning is concurrency-safe. Stale-entry cleanup runs at most once per window boundary, guarded with Interlocked.CompareExchange rather than a lock, so concurrent requests racing the rollover don’t each kick off a full-table scan. That’s the kind of primitive where getting the compare-and-swap right is the whole point — the reasoning lives in a comment next to it so a future reader doesn’t have to reconstruct the argument from scratch.

The MCP tool layer itself

Above the rate limiter and origin check sits the actual tool surface agents call — HexagramTools.cs, decorated with the official C# MCP SDK’s attributes:

/// <summary>
/// The read-only MCP tool surface (design-spec-final.md §3.2.1). Every tool is
/// a thin wrapper over the deterministic Core query service: log the call,
/// charge the rate limiter, map argument violations to structured
/// invalid-params errors, and return the typed payload so the SDK emits
/// outputSchema + structuredContent + the JSON text fallback.
/// </summary>
[McpServerToolType]
public sealed class HexagramTools(
    IHexagramQueryService queryService,
    IMcpRateLimiter rateLimiter,
    IMcpCallLogger callLogger,
    IHttpContextAccessor httpContextAccessor)
{
    ...
    // Array arguments are formatted through the bounded joiner before any
    // logging so an oversized array never materializes a full string.Join
    // ahead of the rate limiter and Core input caps (CR007 IC-SEC-017).Code language: C# (cs)

Every tool call is: rate-limited, logged (with bounded/truncated argument formatting so an attacker can’t blow up the log volume by sending huge arrays), validated against the deterministic query service in iching.rocks.Core, and returned as a typed payload the SDK turns into schema-validated structured content. It’s a thin, disciplined wrapper — the interesting logic lives in Core, where it can be unit tested without spinning up an HTTP server.

Prompt-injection hardening on the paid OpenAI pipeline

The site also has a paid, OpenAI-backed interpretation feature — users submit a natural-language question that gets woven into a prompt. That’s a textbook injection surface, and it got treated as one. From the design spec (ai_upgrades/010):

“The fix has three load-bearing legs plus a builder refactor that carries them:

Role boundary — every trusted instruction moves to the system message; the user message carries data only.

Nonce fence — the untrusted question is delivered inside a server-generated, per-request nonce fence, removing the last unfenced copy.

Structured Outputs — the response contract is enforced at the API layer via a strict json_schema, so injection cannot alter the output shape.

Drop any one leg and we are back to hardening-by-persuasion. All three ship together.”

The structured-output schema itself:

{
  "type": "json_schema",
  "json_schema": {
    "name": "paid_interpretation",
    "strict": true,
    "schema": {
      "type": "object",
      "properties": { "response": { "type": "array", "items": { "type": "string" } } },
      "required": ["response"],
      "additionalProperties": false
    }
  }
}Code language: JSON / JSON with Comments (json)

I want to flag one thing in particular: during the design-review pass, a collaborating AI reviewer (Codex, cross-checking the spec) pushed back on the phrase “structurally impossible” as overclaiming, and the spec was revised to the more honest:

“The fix structurally separates trusted instructions from untrusted question text, makes delimiter breakout infeasible with a per-request nonce, and API-constrains the response shape. It reduces prompt-injection risk from ‘mixed authority in one user payload’ to ‘untrusted content inside an explicit data boundary,’ but live regression testing still verifies that the model does not obey adversarial instructions.”

That correction — refusing to claim a stronger security property than the design actually delivers — is the kind of precision I want engineers on my team to have, and it’s the kind of precision a two-model adversarial review pipeline (see below) is good at catching.

There’s also a nice bit of self-reference here: the nonce-fence pattern built for that OpenAI prompt boundary was later reused, in my own words, as “Engram’s own read-surface idiom” — it’s the same nonce-fenced ENGRAM-DATA convention wrapping every tool result you’d see if you queried my Engram MCP server directly (as I did to write this post). Every result above literally came back inside BEGIN/END ENGRAM-DATA nonce=... fences, marking repository content as data, not instructions, to whatever model is reading it — same defensive pattern, different service.

“Wait, it’s just Razor Pages?” — yes, on purpose

Here’s a reaction I get a lot: someone opens iching.rocks, sees what looks like a plain, text-heavy I Ching site, hears it’s built on Razor Pages instead of some SPA framework, and reads that as “oh, so nothing fancy.” I want to push back on that directly, because the choice was deliberate and the numbers back it up.

There’s no database on the read path. The entire hexagram corpus — all 64 hexagrams, judgments, images, line texts — is authored as JSON, assembled at build time, and loaded once into an in-memory cache that never expires:

public class IChing(IMemoryCache memoryCache, IHexagramCorpus hexagramCorpus) : IIChing
{
    private readonly IMemoryCache _memoryCache = memoryCache;
    private readonly string sHexagramsCacheKey = "HexagramsCacheKey";Code language: C# (cs)

“HexagramCorpus loads from the application base directory and IChing.GetAllHexagrams() caches with CacheItemPriority.NeverRemove… Since upgrade 011 the proprietary corpus is not web-served — nothing under wwwroot contains it.”

So a hexagram page request never touches SQL Server, never touches disk beyond the first cold read, and never round-trips to a client-side framework to hydrate. Razor renders server-side HTML directly from an object already sitting in memory. There’s genuinely nothing in the way between “request arrives” and “HTML goes out.”

On top of that, wwwroot/js/qlickdo.js runs a mouseover-triggered prefetch — the instant your cursor lands on a link, the browser starts fetching that page in the background, using the quicklink library with a manual fallback:

document.addEventListener('mouseover', event => {
    const target = event.target.closest('a');
    if (
        target &&
        target.href &&
        target.origin === location.origin &&
        target.href !== window.location.href &&
        !target.href.includes('/help-us') &&
        !target.href.includes('#')
    ) {
        preloadPage(target.href);
    }
});Code language: JavaScript (javascript)

By the time you actually click, the page is often already sitting in the browser’s cache. Combined with zero-DB, in-memory-cached rendering, clicking around the site doesn’t feel like navigating pages — it feels instant.

I don’t have to guess at this. I pulled nginx access logs and measured it directly: the main iching.rocks app (/oracle, /hexagrams, /readings) averaged ~5ms server response time, against ~250ms for a database-backed CMS on comparable hardware. Both Claude and ChatGPT, independently, when I handed them the raw log data, called out the main site’s response times as unusually fast without me prompting for that observation.

That’s the actual argument for Razor Pages here: it’s not “the old thing,” it’s the tool that gets a request from proxy to rendered HTML in single-digit milliseconds because there’s no ORM, no API round trip, and no client bundle standing between the data and the page. SPA frameworks solve a problem this site doesn’t have — client-side interactivity across a large, stateful UI. This site’s problem is “serve a mostly-static, deeply-linked reference corpus as fast as physically possible,” and the architecture is chosen for that problem, not for résumé keywords.

Engineering process, not just code

The thing I think differentiates this codebase from a typical solo side project is the review discipline. Every non-trivial change runs through a documented, two-model adversarial code review pipeline before it merges — currently at cycle 008. The hard constraints for that pipeline are written down and enforced, not aspirational:

Paid-prompt trust boundary (IC-SEC-016): trusted instructions only in the system message; the querent’s question only inside the nonce-fenced userQuestionBlock; strict response_format: json_schema; refusals/incomplete completions are retried, never persisted.
Metadata-only OpenAI logging (IC-PRIV-001): no response body, refusal text, or rendered content in logs or thrown exceptions.
Core determinism boundary: iching.rocks.Core stays free of web, DB, Stripe, OpenAI, encryption, and Data Protection references.
Middleware pipeline order (exception/HSTS → HTTPS → static files → routing → endpoints) is not reordered without justification.
No NotImplementedException behind feature flags — a remediation that cannot fully implement a flagged path is split or deferred instead.
Historical records: review artifacts and SQL history are append-only; never edited or deleted.

Each review cycle produces a PR review from one model, an independent PR review from a second model, a combined remediation pass, a final validation pass, and a doc review — five artifacts, every cycle, stored and searchable. Cycle 008 alone shipped five concrete remediations: owner-gated terminal status writes, threading a shutdown token through OpenAI dispatch, refreshed safety-contract comments, honest UX for budget-exhausted failure states, and removal of a dead-code cluster.

Why all this matters

None of this is exotic technology — it’s ASP.NET Core, Dapper, SQL Server, a rate limiter, some middleware. What I want it to demonstrate is judgment: knowing where the trust boundaries are in a system that talks to unauthenticated AI agents and a third-party LLM API, encoding those boundaries at the architecture level (project references, not just code review), choosing a “boring” server-rendering stack over a trendier SPA because the numbers say it’s faster for this problem, writing concurrency-safe primitives with the reasoning captured in the code, and running a review process rigorous enough to catch your own overclaiming.

That’s the kind of ownership — and the kind of Principal Engineer’s codebase — I bring to any Staff role. It’s also, not coincidentally, exactly the kind of codebase context an Engram-backed AI coding session can pull up on demand, which is how this post got written. Using this prompt in Claude to be exact:

“Use the engram mcp to look at the iching.rocks repo. Return a description of the code that a hiring manager looking for a principal software engineer position would want/need. Do a deep dive and provide code samples where appropriate. Make your output suitable for a blog post on https://codematters.johnbelthoff.com/ taking this question as evidence of the engram mcp server.”

Questions about the architecture, the MCP tooling, or the review pipeline? Get in touch.

What a Principal Engineer’s Codebase Actually Looks Like: A Deep Dive into iching.rocks

Table of Contents