DEV Community: Tatted Dev

Building HoneyDrunk.Lore: My LLM Wiki and Daily News Blast

Tatted Dev — Sun, 21 Jun 2026 12:05:16 +0000

I know I am late to the party talking about LLM wikis after Andrej Karpathy first put the pattern in public, but here is how I implemented it in my own flow.

The pattern clicked for me because it names a problem I had been living inside for a while. I read a lot. Model announcements, agent infrastructure posts, .NET and Azure updates, architecture writeups, indie software notes, game-dev tooling, security research, random high-signal threads that appear before the official writeup exists. All of it can matter to HoneyDrunk eventually, but almost none of it matters at the exact moment I read it.

That is the place where normal bookmarks fall apart. Bookmarks preserve the link and lose the understanding. Chat history preserves the conversation and loses the durable structure. RAG gives me retrievable chunks, then makes me rebuild the synthesis every time I ask a question.

The LLM wiki idea works at a different layer. Raw sources go in. An LLM reads them, extracts the useful claims, updates topic pages, links concepts together, tracks contradictions, and keeps a maintained markdown wiki between me and the source pile. The wiki becomes a compiled artifact. The model rediscovers context once, writes it down, and keeps it warm for the next query.

Karpathy's LLM Wiki gist, created on April 4, 2026, and the X post that pointed people at it gave the pattern a crisp public shape. My implementation became HoneyDrunk.Lore.

The Shape of Lore

HoneyDrunk.Lore is my compiled research knowledge surface for the studio. It is a flat-file wiki: markdown on disk, source-backed, Obsidian-friendly, versioned in git, and maintained by agents under an explicit schema.

The pipeline is intentionally boring:

raw sources
  -> compiled wiki
  -> AGENTS/schema
  -> query/output
  -> compile/lint

The raw/ layer is the evidence locker. Articles, notes, clipped pages, selected social posts, and research outputs land there as immutable source material. Once something is in raw/, the rule is simple: add, do not rewrite history.

The wiki/ layer is the compiled surface. It is where source material turns into concept pages, entity pages, topic indexes, confidence notes, and links. This is where claims get reinforced, weakened, superseded, or connected to other things I already know. The work that makes it more than a pile of summaries happens here.

The AGENTS.md file is the schema and operating manual. It tells the agent what the directories mean, what operations exist, how to treat citations, when to record gaps, how to handle contradictions, and what counts as a durable claim. This matters more than it sounds. Without the schema, an LLM wiki is just a helpful assistant making markdown. With the schema, it becomes a maintained knowledge system with rules.

Queries write back into output/. If I ask, "what does today's agent security signal imply for HoneyHub?" I want the answer filed as a dated artifact with citations, confidence, and gaps. Later compile passes can crystallize durable parts of that answer back into the wiki. The question becomes another source of learning instead of disappearing into a chat transcript.

Compile and lint are the maintenance loop. Compile ingests unprocessed sources, reconciles claims, updates indexes, and promotes durable query outputs. Lint looks for orphans, stale claims, contradictions, weak sourcing, and missing links. The payoff is the rhythm. The wiki has a standing process for staying healthy, so it keeps working long after the first burst of writing.

The Daily Blast

The most recent work on Lore made the system feel less like a personal archive and more like an operator surface.

Every day, Lore can produce a news blast for Discord. It reviews the latest saved source window, pulls out the useful signal, and turns it into a compact daily briefing. The blast stays small on purpose: a decision-support summary for the parts of the world that matter to HoneyDrunk right now.

The shape is deliberately strict:

Top 10 web stories.
Top 10 X/Twitter posts.
Actual source URLs and tweet URLs.
Two or three sentence summaries.
A HoneyDrunk angle for why each item matters.
Discord messages split before they hit platform limits.
No private internal tool names in the public-facing blast.

That last line matters. The public blast should say what happened, where it came from, and why it matters. It should not leak the names of whatever private worker, script, lane, or local process happened to collect the source. Public signal should be clean signal.

The X/Twitter lane is selective on purpose. I do not want Lore broadly crawling social media. That turns into noise immediately, and it makes the wiki depend on the most chaotic surface in the stack. But sometimes the useful signal really does appear there first: a primary-source launch post, a developer thread, an early warning, a discussion around a new agent pattern before the canonical blog post exists.

So Lore treats X/Twitter as an early-signal lane that has to earn its way into the durable record. Selected posts can be captured with the actual tweet URL, marked as early signal, and compiled like any other raw source. When a durable source appears later, an official blog post, docs page, changelog, model card, transcript, or technical writeup, that source should join or supersede the social capture. The tweet stays useful as first-report context, and it has to wait for corroboration before it carries any authority.

That distinction is the difference between "I saw a thing" and "the wiki knows a thing."

Why I Wanted This

HoneyDrunk is not a single-product company in my head. It is a many-decade personal workshop: a computing platform, a studio, a lab, and a place to keep building strange useful things with AI agents over a long horizon.

That changes what research means.

I collect sources because they eventually affect decisions. Agent security patterns can shape how I build the agent tooling. Delivery and idempotency writeups can affect the messaging pipeline. Unity, asset pipeline, and game tooling posts can feed the game-dev work. Pricing, product, and solo-dev notes can change how I package the next experiment. A random model-routing benchmark might not matter today, then become exactly the missing context three months from now.

Lore gives that material somewhere to compound.

It is important to say what Lore is not. It is not HoneyDrunk governance. Governance lives in the architecture docs, ADRs, invariants, and repo contracts. Lore can inform a decision, but it does not make the decision official.

It is also not agent memory. Agent memory is runtime state, preferences, session history, and working context. Lore is source-backed decision support. If Lore says something, it should be able to point at the sources, report confidence, and name the gaps. I do not want uncited wiki prose becoming doctrine just because an agent wrote it once.

That boundary is the whole point. Lore is allowed to be useful because it is not allowed to be magic.

The Part That Feels Different

The big unlock is that the wiki is a built artifact. It gets compiled, maintained, and carried forward the way code is.

Search asks, "can I find the thing again?" Lore asks, "has the thing been digested into the shape of what I already know?" Those are different questions. One retrieves. The other compounds.

The daily Discord blast made that visible. A source goes from a raw article or tweet into a reviewed daily signal. The signal keeps the original URL attached. The summary is short enough to read on a phone. The HoneyDrunk angle makes the relevance explicit. Later, if the item is durable, compile can fold it into the wiki. If it is weak, lint can let it decay. If a better source appears, the older claim can be superseded instead of silently overwritten.

That is the kind of system I want around a long-running workshop. Something that runs on its own rhythm, keeps what I have already learned, and stays warm between sessions.

A maintained wiki. A daily signal review. Source URLs attached. Confidence kept visible. Gaps named instead of hidden.

It is still rough in places, because every useful personal system starts rough. But it already changes the feel of reading. Sources do not just pass through my attention anymore. They have a place to land, a way to be compiled, and a chance to become part of the workshop's long memory without pretending to be governance or truth.

That is the version of the LLM wiki pattern I needed: a source-backed research surface for a studio I plan to keep building in for decades.

Two Terminals, One Screen: Building an Agent Cockpit That Tells the Truth About Cost

Tatted Dev — Sun, 14 Jun 2026 15:06:56 +0000

The setup that pushed me to build this was embarrassingly low-tech. Two terminal windows, side by side. One running the Claude Code CLI on a refactor. One running Codex on a different repo. Two live coding agents, two different repos, two different ways of telling me what just happened.

Each window has its own dialect for reporting a turn. Claude prints a tidy result line with tokens and a dollar figure. Codex streams whole messages and reports tokens but no money. So at any given moment I had a pair of agents running and no single place that could answer the one question I actually cared about: how much have I spent today, and on what.

I kept Alt-Tabbing between windows trying to add that up in my head. That is a stupid way to run a studio. So I built a cockpit.

This post is about that cockpit, which I call HoneyHub, and specifically about the part that was much harder than the windowing: making a single cost view that pulls from two tools which measure cost in completely different units, without lying to me about either of them.

What HoneyHub Is

HoneyHub is a local control panel for AI coding agents. It runs on my own machine, serves a small web app I open in a browser (phone or desktop), and drives the official command-line tools I already pay for: the Claude Code CLI and the Codex CLI. Nothing gets proxied through a server I rent. Nothing holds my subscription credentials. HoneyHub shells out to the same binaries I was running by hand, reads their output, and shows it on one screen.

The core is a Rust crate (bridge) that owns the child processes, and a TypeScript web app that renders the sessions. Between them is a contract: every backend, no matter how differently its CLI behaves, gets adapted into the same stream of events. A message event. A status event. A usage event. The web app never has to know which tool produced a given line.

That contract is the whole trick, and the usage event is where it earns its keep.

The Problem: Two Tools, Two Definitions of "Cost"

Before I wrote a line of the cost view, I ran each CLI and read exactly what it hands back when a turn finishes. The two could not report cost more differently.

Claude Code is the generous one. When a turn completes, it emits a result line carrying exact input and output token counts and a real dollar figure (total_cost_usd) computed on its side. I don't have to guess anything. I take the number it gives me.

Codex reports exact token counts but no money at all. It tells me a turn used 1,000 input tokens and 1,000 output tokens, and then it stops. If I want a dollar figure, I have to multiply those tokens by a rate I supply myself. The tokens are ground truth. The dollars are something I compute, and only if I've configured a rate.

So even with just these two, I had two genuinely different kinds of number staring at me:

A measured dollar figure that a vendor computed (Claude).
A dollar figure I derive from exact tokens and a rate I supply (Codex).

Those are not the same thing, and pretending they are is how a dashboard starts lying to you. The lazy move is to mash both into one "total spend" number and call it a day. I refused to, because the moment a derived estimate and a measured figure get added together you can no longer tell which dollars are real. The whole reason I wanted a cockpit was to trust the readout. A blurred total is worse than no total.

So the design rule became: the system has to know, for every cost figure it shows, how that figure came to exist. And it has to refuse to blend a measurement with a guess.

The Solution: Fidelity Is a First-Class Field

Inside the bridge, every usage report carries a fidelity tag. There are exactly three values, ranked from most trustworthy to least, and the order matters:

// filepath: crates/bridge/src/session.rs
#[derive(Debug, Clone, PartialEq, Eq, PartialOrd, Ord, Hash, Serialize, Deserialize)]
#[serde(rename_all = "snake_case")]
pub enum UsageFidelity {
    Exact,
    Derived,
    Estimated,
}

Exact means the CLI handed me the dollars directly. Derived means I computed dollars from exact tokens and a rate table. Estimated means the numbers are a proxy and should never be read as money. Today's two backends use only the first two tiers: Claude reports Exact, Codex reports Derived. Estimated is built in and waiting for the kind of backend that can only guess at what it spent, a tool whose CLI hands back neither a dollar figure nor a real token count. I have no such backend wired in right now, but the tier exists so that when one shows up, its guesses can never quietly pass as measurements. Every adapter is required to tag its usage signal honestly, and each one does it differently because each tool is different.

Claude: take the number, don't touch it

The Claude adapter reads the result line and copies the dollar figure straight through. No arithmetic. The only cleverness here is folding cache-read and cache-creation tokens into the total so an "exact" signal never under-reports:

// filepath: crates/bridge/src/adapters/claude_local.rs
UsageSignal {
    backend: AgentBackend::ClaudeLocal,
    // Claude Code reports exact tokens + USD; taken directly, no computation.
    // USD is never derived from a rate table for this backend.
    fidelity: UsageFidelity::Exact,
    input_tokens,
    output_tokens,
    total_tokens,
    total_usd: value.get("total_cost_usd").and_then(Value::as_f64),
    confidence: Some(UsageConfidence::High),
    // ...
}

Codex: exact tokens, dollars only if I asked for them

The Codex adapter has the exact tokens but has to derive the dollars. The rate lookup is injected into the adapter rather than hardcoded, so the bridge crate never bakes a vendor's prices into itself. And here is the part I care about most: if no rate is configured, the tokens stay exact and the dollar figure is simply absent. It is never fabricated.

// filepath: crates/bridge/src/adapters/codex_local.rs
// Tokens are exact; USD is derived from the injected rate table.
// With no rate configured the cost is absent — never fabricated.
let total_usd = match (model, input_tokens, output_tokens) {
    (Some(model), Some(input), Some(output)) => (rate)(model, input, output),
    _ => None,
};

The default rate lookup wired in when nothing is configured returns None for everything, on purpose:

// filepath: crates/bridge/src/adapters/codex_local.rs
/// The default lookup: no rate table wired, so USD is always absent (tokens exact).
pub fn no_rate_lookup() -> UsdRateLookup {
    Arc::new(|_model, _input, _output| None)
}

So out of the box, Codex shows you exact tokens and an honest blank where the dollars would be. You opt into derived dollars by handing it a rate. That ordering is the whole point. When the system has no grounds for a number, it says "I don't know" and leaves the space empty. It never fills that space with a guess.

The Centerpiece: The Two-Way Usage Table

Here is the whole problem on one page. Same question, two tools, and what each one can actually tell you:

Backend	Tokens	Dollars	Real billing unit	Fidelity tag	Shown as
Claude Code	exact	exact (`total_cost_usd`)	dollars	`exact`	`$0.0123`
Codex	exact	derived from a rate, or absent	tokens	`derived`	`≈$0.0030`

The "shown as" column is not cosmetic. The display layer formats every figure with a prefix that encodes its fidelity, so an estimate can never visually pass as a measurement:

// filepath: packages/ui/src/usageFormat.ts
export function usdPrefix(fidelity: UsageFidelity | undefined): string {
  if (fidelity === "estimated") return "~$";
  if (fidelity === "derived") return "≈$";
  return "$";
}

A plain $ is a number a vendor measured. A ≈$ is a number I computed from a rate. A ~$ is a soft guess. You can tell at a glance which is which without reading a legend. And when a rollup has no dollar figure to show at all, the cell renders an em dash rather than a fabricated zero:

// filepath: packages/ui/src/routes/spend/spendModel.ts
export function rollupCost(rollup: UsageRollup): string {
  if (rollup.totalUsd !== undefined) {
    return formatUsd(rollup.totalUsd, rollup.fidelity);
  }
  return "—";
}

The Headline Number Sums Only What It Can Measure

The cockpit shows one big number at the top: today's spend. The temptation, the entire reason this was hard, is to make that number include everything. It doesn't. The grounded total sums only the dollar figures that are real, which is to say exact and derived. Anything tagged estimated is excluded by construction, so the day a guessing backend gets wired in it still cannot touch the headline:

// filepath: packages/ui/src/routes/spend/spendModel.ts
const grounded = rollups.filter(
  (rollup) => rollup.fidelity === "exact" || rollup.fidelity === "derived"
);
const anyGroundedUsd = grounded.some((rollup) => rollup.totalUsd !== undefined);
const groundedTotalUsd = anyGroundedUsd
  ? grounded.reduce((sum, rollup) => sum + (rollup.totalUsd ?? 0), 0)
  : undefined;

When nothing grounded has been recorded yet, the headline is undefined, not $0.00. That distinction is deliberate. There is a real difference between "you have spent zero dollars" and "I have no measured spend to report," and a tool that collapses the second into the first is lying to you about a number you might make decisions on. So the view says "no measured spend yet" rather than inventing a confident zero.

The Rust side enforces the same rule, with a comment that is basically the thesis of the whole feature:

// filepath: crates/bridge/src/session.rs
/// Sum of USD across **exact + derived** rollups only — a real dollar figure.
/// Estimated rollups are excluded so a guess can never inflate the headline
/// spend. `None` when no grounded signal reported USD.

Two implementations, one in Rust on the host and one in TypeScript for the offline mock, and they agree on the rollup shape down to the ordering. That redundancy is on purpose too: the formatting honesty lives in tested code on both sides of the wire, so neither can quietly drift into showing an estimate as a fact.

What I Learned

The engineering lesson here is smaller than it looks and more useful than I expected: fidelity is data, not presentation. My first instinct was to compute one blended dollar total and then sprinkle a "(estimated)" label on the UI somewhere. That fails the moment anything reads the number, because by then the measurement and the guess are already added together and you can't pull them back apart. Tagging every single usage signal at the source, the instant it leaves the adapter, is what makes the honest rollup even possible downstream. The guess and the measurement never touch.

The product lesson is the one I keep coming back to. I built this so I would trust the readout, and a tool you can't trust is worse than the two terminal windows I started with, because at least the windows weren't pretending. A dashboard that confidently sums a measurement and a wild guess into one number trains you to distrust it, and then you go back to adding it up in your head anyway. The blank where Codex's dollars would be, and the "no measured spend yet" instead of a fake zero, are the features. They are the reason I look at the number and believe it.

Next Steps

The cost view is one panel. The cockpit also surfaces live sessions, per-session diagnostics, and cross-session coaching, and the same fidelity discipline runs through all of it: a capability either exists for a backend or it doesn't, and the UI declares which honestly rather than faking a uniform experience. Codex can't do a live mid-turn reply, so the cockpit doesn't pretend it can; it routes the follow-up through a fresh resumed run instead. That honesty-by-construction posture is the through-line of the whole thing.

What's left is the part no amount of code can do for me: running it for a real day of work and seeing whether the number at the top actually changes how I spend. That's the test that matters.

If a tool is going to tell you what something cost, it owes you the truth about how sure it is. A blank is more honest than a guess wearing a dollar sign.

Stop Receiving Webhooks, Start Polling: Rebuilding the Grid Review Runner

Tatted Dev — Sun, 07 Jun 2026 16:44:28 +0000

Every pull request I open gets an automated code review from an AI agent before I merge it. It reads the diff, checks it against my project's conventions, and posts its findings as a comment, like a second set of eyes that never sleeps. I run a whole studio's worth of repos solo, so that reviewer is load-bearing infrastructure. I call it the Grid Review Runner.

One weekend it went quiet, and I didn't notice for two days.

A pull request sat in one of my repos with no review on it. I was on the road. When I finally opened my laptop, I had no idea whether the reviewer had looked at the PR and decided it was fine, or whether it had never been told the PR existed in the first place. There was no log to check. There was no signal either way. The review just... wasn't there.

That ambiguity is the whole story. The way the system worked back then, GitHub was supposed to push a notification to my reviewer the instant a PR opened (a webhook, in the usual web plumbing sense). If that push went missing, the reviewer never woke up, and nothing told me it had been skipped. Did the reviewer decline, or did the notification never fire? I couldn't tell. The runner worked beautifully when I was sitting at my desk and fell apart the moment I wasn't. So I rebuilt the transport from the ground up. This post is about that rebuild, and the one architectural decision underneath it: stop waiting to be told about work, and go looking for it instead.

The Old Shape: Inbound Webhook Over a Tunnel

The Grid Review Runner is the piece of the HoneyDrunk Grid that runs an AI code review on pull requests. The review logic was never the problem. The rubric, the context-loading contract, the advisory posture all worked. The problem was the rail it rode in on.

The original design (ADR-0044) looked like this:

GitHub PR event
  → GitHub Action fires an HMAC-signed webhook
    → GitHub pushes it over a Cloudflare Tunnel
      → a local webhook bridge on my home server
        → which invokes OpenClaw/Codex to run the review

Every arrow there is a thing that has to be up at the exact moment a PR event happens. OpenClaw was the execution runtime. The Cloudflare Tunnel was its inbound rail. The home server (ADR-0081) was the always-on box that hosted both. On paper it's clean: GitHub talks to a narrow, signed, authenticated endpoint, and the endpoint does the work.

In practice it was three single points of failure stacked on top of each other, and all three were coupled to me.

Why It Failed

Three failure modes compounded over the weeks after it landed:

Webhook delivery flaked. GitHub redelivery is best-effort. On long PR sessions the bridge missed synchronize events, and I had no inexpensive way to tell whether a missing review meant "the runner declined" or "the event never arrived."
Tunnel uptime was coupled to me. The Cloudflare Tunnel ran on the home server, and it was the single inbound path. When I traveled, when the box rebooted, when the tunnel daemon hiccuped, the rail was down. No rail, no review.
OpenClaw process stability wasn't set-and-forget. Crashes, session-credential expiry, dashboard-coupled state. "Did the review run?" was a non-trivial question to answer, every time.

The symptoms were all different. They had one root cause: an always-on inbound HTTP receiver on operator infrastructure does not fit an operator whose laptop travels.

That shape works for a team with an on-call rotation absorbing the misses. It is mis-sized for one person and a single low-power box at home. I could have kept patching it (better redelivery handling, a hardier tunnel daemon, hardening OpenClaw against crashes), but every one of those is repair work on a house that doesn't fit the lot. The failure modes are intrinsic to the inbound-webhook shape on a solo setup. No tactical fix removes the category.

So I stopped trying to fix the rail and changed the direction it ran.

The Pivot: Push Becomes Pull

Here is the load-bearing decision, and everything else is downstream of it: invert the transport. Instead of GitHub pushing a trigger into my infrastructure, my worker reaches out and pulls the trigger inward. The queue it pulls from is GitHub itself, so there's no server of mine that has to stay alive to hold it.

The new critical path:

GitHub PR event
  → cheap GitHub Action (no LLM work)
    → enqueue: add `needs-agent-review` label + structured queue comment
      → local worker polls GitHub on a 60s tick
        → claims one PR, runs the review locally under Codex CLI + Claude Code CLI
          → posts the verdict, swaps the label to its final state

No inbound webhook. No tunnel for review traffic. No OpenClaw on the path at all.

The GitHub Action got dumber on purpose. It does exactly two API calls and exits: it normalizes the PR's managed labels, adds needs-agent-review, and upserts a single structured queue comment carrying the repo, PR number, head SHA, author class, and the resolved review config. It invokes no LLM. Its entire cost is the GitHub Actions minute floor: a label write, a comment write, done. No tokens are spent in the cloud, by design.

The label is the queue index. The comment is the audit trail and the metadata carrier. That's the trick that makes the whole thing durable: the queue lives in GitHub. When my worker is offline (traveling, home server rebooting, machine powered off) PRs just accumulate in the needs-agent-review state and wait. Nothing is lost, because there's no local queue to lose. When the machine comes back, the next tick reads GitHub's state and resumes. A powered-off worker just pauses the poll, and the events are still sitting in GitHub when it wakes up.

The Worker (and Why the Scheduler Is Boring on Purpose)

The worker is a PowerShell script invoked by Windows Task Scheduler on the same home-server hardware that used to host OpenClaw. The mini-PC survived the rebuild. Only OpenClaw, the webhook bridge, and the tunnel hostname came off it.

One thing is easy to misread here, so I'll say it plainly: the headline is push → pull, and Task Scheduler is just the boring scheduler adapter sitting on top of that decision. The scheduler could be cron, systemd, or a cloud VM tomorrow without changing a single job spec. PowerShell + Task Scheduler is simply the lowest-friction option on a Windows box that's already on: no compile step, no runtime to deploy, sub-second per-tick boot. I deliberately wanted boring plumbing here.

The Task Scheduler entry starts at logon and startup, repeats on a 60-second interval, restarts on failure, and refuses to overlap runs. The claim protocol uses GitHub's own primitives as the atomic operations:

List every PR carrying needs-agent-review (one search call per tick, cheap at solo-dev volume).
Claim the oldest one by swapping the label needs-agent-review → agent-review-in-progress and recording claimed_by and head_sha in the queue comment.
Run the canonical .claude/agents/review.md agent locally under subscription-auth CLIs.
Post the verdict and swap to agent-reviewed (clean) or changes-requested-by-agent (findings).

If the worker crashes mid-review, a stale-claim sweep runs at the top of each tick and releases any agent-review-in-progress claim older than ~15 minutes back to the queue. If a new commit lands while a review is in flight, the head SHA in the comment no longer matches the claim, the now-stale verdict is discarded, and the next tick re-reviews against the new head. The marginal cost of that wasted run is operator-machine CPU only. The review runs under my existing subscription CLIs, so the LLM cost is $0.

The job spec itself is just data. Here's the relevant slice of the review job:

# filepath: infrastructure/workers/grid-agent-runner/config/jobs/grid-review.psd1
@{
    JobId        = "grid-review"
    TriggerKind  = "label-queue"
    Schedule     = @{ Type = "interval"; IntervalSeconds = 60; AtStartup = $true; AtLogon = $true }
    PromptPath   = ".claude/agents/review.md"
    AgentCommands = @(
        @{ Name = "codex";  Executable = "codex";  PromptStdin = $true }
        @{ Name = "claude"; Executable = "claude"; PromptStdin = $true; RiskClasses = @("high"); Optional = $true }
    )
    WriteMode    = "comment-only"
}

The worker holds no secret-bearing inbound port. Its trust boundary collapsed to GitHub auth plus the local filesystem. There's no public ingress for review traffic to attack anymore, because there's no public ingress at all.

What I Learned

The most useful thing this rebuild taught me: the discipline was right the whole time. The shape it rode on was the part that was broken.

Everything that made the reviewer good came through untouched: the context-loading contract, the review rubric, the advisory posture (a missing review never blocks a merge). All of that is a property of the agent prompt, and the prompt didn't change. The transport only ever carried diffs. So I got to rip out an entire failure-prone rail and the actual review behavior survived intact. When you can cleanly separate "what hurts" from "what works," a scary-sounding rebuild turns out to be a narrow one.

The second thing: inverting the transport let me delete infrastructure instead of adding it. OpenClaw, the webhook bridge, and the tunnel hostname all came off the home server (ADR-0088 finished that teardown). The HMAC webhook-signing secret got retired instead of perpetually rotated. The box itself stayed. The hardware was always fine. What was dead was the OpenClaw-centric way of organizing everything on top of it.

And a bonus I didn't fully plan for: once the runner stopped being a one-off review script and became a job framework with a scheduler adapter, every other scheduled agent job I'd been parking on OpenClaw came home to it too. hive-sync, the Lore sourcing and ingest passes, all of it. One substrate, one scheduler story, one recovery story.

Next Steps

The worker runs two model families on every high-risk review: Codex CLI under one subscription, Claude Code CLI under another, synthesized into a single verdict. Why the Grid runs that many review layers (this runner plus CodeRabbit, Copilot, the Actions gates, and SonarQube) is a whole post on its own, and it's the next one I'm writing. This post was only ever about the transport.

The lesson I'm keeping: when an always-on inbound receiver keeps failing for a solo operator, a more reliable receiver is rarely the fix. Stop receiving. Reach out and pull instead, and let the queue live somewhere that's already always on.

Treating Azure Infrastructure Like a Pull Request: Bicep and what-if

Tatted Dev — Sun, 07 Jun 2026 16:42:51 +0000

For a long time, the complete and authoritative definition of my production infrastructure was a scratch file of az commands and the order I remembered running them in. I'd click through the Azure Portal, paste in a few commands, and the service would come up: a container app, a Key Vault, some App Configuration, a Service Bus namespace, the role assignments that wire them together. It worked.

It worked because I remembered the sequence. There was an order to it, a set of steps that mattered, and the only place that order lived was in my head. That holds up fine when there's one environment and you set it up once. It falls apart the moment you need a second one. I run a lot of these services solo, so "I'll just remember it" had quietly become the load-bearing plan across every repo I own.

This post is about the moment I needed a second environment, watched my from-memory process fall apart on contact, and decided to stop provisioning from memory entirely. The fix has a thesis I'll keep coming back to: infrastructure should be a diff you review before it lands, the same way code is.

The Problem: I Provisioned From Memory

Here's what "provisioning from memory" actually looked like in practice.

My dev environment apps started life as hello-world placeholders. I'd create a container app in the Portal, get something trivial running, and then evolve it into the real service over time. Every time I did that, the real service needed things the placeholder didn't, and I added them by hand, one at a time, as I noticed they were missing.

The list of things I noticed missing, the hard way:

The app's managed identity had no AcrPull role, so it couldn't pull its own container image from the registry.
It had no Key Vault or App Configuration read access, so it couldn't load any of its config or secrets.
It had never actually joined the shared Container Apps environment, so it wasn't wired into the logging and networking I assumed it was.
The App Configuration store was never seeded with the keys the app expected to find.
Ingress was configured for port 80 with health probes pointed there, while the app actually listens on 8080. So it was "running" and failing every health check.

Every one of those was fixed live, by hand, while the thing was already deployed and broken. And the role assignments in particular fought me: the obvious az role assignment create path kept throwing a MissingSubscription error in my setup, so I ended up making the RBAC grants through raw az rest calls against the management API instead. Each fix was a small thing. The sum of them was a service that only worked because I'd personally walked it through a recovery I never wrote down.

The real failure was bigger than any single missing role. The complete, correct sequence for standing up one of my services lived only in my own hands, a thing I had done and could repeat but could never open and read. There was no artifact. There was no review. If someone asked me "what does it take to bring this service up in a fresh region for disaster recovery," the honest answer was "give me a day and let me remember."

So when a second environment showed up on the roadmap, I didn't want to redo the from-memory walk. I wanted the walk to be a file.

What Bicep Is (and What It Buys a Solo Dev)

The tool I committed to is Bicep. If you haven't used it: Bicep is Microsoft's own infrastructure-as-code language for Azure. You describe the resources you want in a terse, typed DSL, and it compiles down to ARM, the JSON template format Azure deploys natively. There's no separate state file to manage the way Terraform has one; a deployment reconciles directly against whatever already exists in Azure. For an Azure-only shop run by one person, that's one fewer artifact to secure and back up, which I appreciated.

I put all of it in one repo. Reusable modules are organized by concern (compute, data, secrets, messaging, observability) and a composition template stitches them together per environment. The modules are referenced by plain local file paths. I looked at publishing them to a Bicep registry and decided against it; for a single operator, a registry was overhead with no payoff, so modules just sit next to the templates that consume them and resolve off the filesystem at build time.

The shared foundation for an environment composes the pieces that no single service owns:

// filepath: platform/main.bicep
module containerAppEnvironment '../modules/compute/containerAppEnvironment.bicep' = {
  name: 'platform-cae'
  params: {
    env: env
    location: location
    tags: tags
    logAnalyticsWorkspaceId: logAnalyticsWorkspace.outputs.id
  }
}

module appConfigurationStore '../modules/secrets/appConfigurationStore.bicep' = {
  name: 'platform-appcs'
  params: {
    env: env
    location: location
    tags: tags
  }
}

The interesting part is what's now impossible to forget. Remember the port-80-versus-8080 mess? Here's the relevant slice of the container app module:

// filepath: modules/compute/containerApp.bicep
@description('Ingress target port the container listens on.')
param targetPort int = 8080

resource containerApp 'Microsoft.App/containerApps@2025-07-01' = {
  name: 'ca-hd-${service}-${env}'
  identity: { type: 'SystemAssigned' }
  properties: {
    managedEnvironmentId: containerAppEnvironmentId
    configuration: {
      ingress: {
        external: externalIngress
        targetPort: targetPort
        transport: 'auto'
      }
    }
    // ...
  }
}

@description('Principal ID of the system-assigned managed identity. Grant AcrPull / Key Vault / App Configuration RBAC to this.')
output principalId string = containerApp.identity.principalId

The port default is 8080, written down once, applied everywhere. The module won't deploy a container app without joining the managed environment, because managedEnvironmentId is a required parameter. The managed identity's principal ID comes out as an output specifically so the role assignments (the AcrPull, the Key Vault read, the App Configuration read) get wired to it in the same deploy instead of being remembered later. Every individual thing that bit me by hand is now a property of a file that gets compiled and checked.

That's the difference between memory and code: the file can't quietly skip a step.

Infra as a Diff You Review Before It Lands

Having the resources in Bicep is half of it. The half I actually care about is what happens when I change them.

Azure has a command called what-if. It's a dry run: you point it at a template and it tells you exactly what a real deployment would do (what it would create, what it would modify, what it would delete) without touching anything. It prints a diff of your infrastructure.

My deploy pipeline is built around that command. Before it applies anything, it runs the same three preflight steps every time: compile the Bicep, lint it, then run what-if. Only after that does it consider applying. And whether it applies at all is a switch:

# filepath: .github/workflows/job-deploy-bicep.yml
- name: What-if preflight
  run: |
    az deployment group what-if \
      --resource-group "$RG" \
      --parameters "$PARAMS"

- name: Apply deployment
  if: ${{ inputs.what-if-only != true }}
  run: |
    az deployment group create \
      --name "hd-infra-${ENV}-${RUN_ID}-${RUN_ATTEMPT}" \
      --resource-group "$RG" \
      --parameters "$PARAMS"

I trigger deploys in two modes. Plan runs the build, lint, and what-if, then stops and tells me nothing was applied. Apply does all of that and then actually deploys. The default is plan. So my normal loop is: run plan, read the diff, confirm it's doing what I expect, then re-run as apply.

Reading the diff is the whole point. The discipline I hold myself to is simple: every resource that should already exist needs to show up as no change. If something I wasn't expecting shows as Modify or, worse, Delete, that's the signal to stop and look before anything happens to live infrastructure. The dry run turns "I think this is safe" into "I can see that this is safe."

That's why I call it treating infrastructure like a pull request. A pull request is a diff you read before you merge it. what-if is a diff you read before you deploy it. Same loop, same safety, just pointed at Azure resources instead of source files. The change stops being an action I take from memory and becomes a proposal I review.

Two supporting pieces, each worth only a sentence here because each could be its own post. The pipeline authenticates to Azure with GitHub's OIDC federation, so there are no long-lived Azure credentials stored anywhere; the deploy identity is allowed to provision resources but not to read secret values. And promotion across environments is gated: dev is easy, while staging and prod sit behind GitHub Environment approvals so nothing reaches them without a deliberate sign-off. Both of those deserve their own write-ups later.

The Payoff

The real fix was turning that memory into an artifact, something I could read, review, and re-run. Trying to remember harder was never going to survive past one environment.

Once the infrastructure was a set of files, the part that used to terrify me (standing up another environment) became boring in the best way. A new environment is a new parameter file pointed at the same modules. The sequence I used to carry in my head is now enforced by required parameters and module composition. The container app can't come up without joining its environment. The identity comes out as an output so its roles get granted in the same breath. The port is 8080 because the file says so.

And the dry run changed how changes feel. Before, every az command against a real environment was a small leap of faith. Now I get to look first. The worst-case surprise moved from "I deleted something in production" to "the plan showed something I didn't expect, so I didn't run apply." That's a much better worst case to live with when there's no one else around to catch the mistake.

What's Left to Codify

There's more to build on top of this. The role assignments and App Configuration seeding that I described as the painful hand-fixes are exactly the parts I want fully codified into the per-service templates next, so that "fresh environment" means one plan-and-apply with nothing left to remember. And the environment-gated promotion model deserves its own post, because the approval gates are doing real work.

But the load-bearing change already happened. My infrastructure stopped being a thing I remember how to do and became a thing I can read. Provision from a file, not from memory. Look at the diff before it lands.

A Field Guide to Hand-Provisioning Azure Functions and Container Apps

Tatted Dev — Sun, 07 Jun 2026 16:41:06 +0000

I asked the Azure CLI for my function app's hostname and it handed me back null. The app was running. The hostname existed. The tool whose entire job is to tell me about the app just refused to say what it was. That was the first of a week's worth of moments where the platform looked me in the eye and lied.

I'd been standing up cloud services on Azure by hand, one small repo at a time, some running as Azure Functions and some as Container Apps. I do this solo, so each one starts as a hello-world placeholder, gets something trivial running, then grows into the real service as I add whatever it turns out to need. The work itself was fine. The part that cost me evenings was Azure's own tooling handing me wrong answers while I did it. I'd ask the CLI a direct question and get back null. I'd hit the hostname the docs implied and get a connection that failed completely. I'd reach for the official deploy action and find it blocked. Every one of these burned an evening of squinting at output that made no sense, usually around midnight, usually while googling the exact error and finding nothing.

This is the post I wish I'd found on one of those nights. Five concrete gotchas, each with the symptom I actually saw and the fix that actually worked. If you're hand-standing-up Functions or Container Apps on Azure and the platform is gaslighting you, start here.

A bit of grounding first, because this blog gets read by people who don't know my stack. Flex Consumption is a newer Azure Functions hosting plan, the pay-for-what-you-use serverless tier with faster scaling than the old Consumption plan. Container Apps is Azure's managed platform for running containers without standing up Kubernetes yourself. A managed identity is an Azure-issued identity attached to your app so it can authenticate to other Azure services without you storing a password. An RBAC role assignment is the grant that says "this identity is allowed to do this specific thing." Those four show up in every story below.

Gotcha 1: `az functionapp show` returns null on Flex Consumption

Symptom. I deployed a Function on the Flex Consumption plan and went to grab its basic facts the obvious way:

az functionapp show --name <app> --resource-group <rg> \
  --query "{host:defaultHostName, state:state, names:hostNames}"

Back came null for defaultHostName, null for state, null for hostNames. Not an error. Not an empty string. Just null fields on an app I could see existed in the Portal.

Cause. On Flex Consumption those properties simply aren't populated on the object az functionapp show reads. The command works fine elsewhere. On this plan it just doesn't surface those fields through that path, so you ask a perfectly reasonable question and the tool answers with a confident nothing.

Fix. Go around it. Read the resource directly through the generic resource commands or the ARM REST API:

# Generic resource read returns the populated properties
az resource show --ids <function-app-resource-id> \
  --query "properties.defaultHostName"

# Or hit ARM directly
az rest --method get --url "<function-app-resource-id>?api-version=<api-version>"

az resource show and az rest read the underlying resource record, where the real values live. The lesson I took from this: when a high-level az command hands you null on a newer plan, drop down a layer before you assume your app is broken. The app was fine. The convenience command just couldn't see it.

Gotcha 2: the hostname you expect returns HTTP 000

Symptom. Once I had a hostname, I tried to hit the app at the address you'd guess from years of Azure muscle memory: <app-name>.azurewebsites.net. The request didn't return a 404. It didn't return a 503. It returned HTTP 000, which is curl's way of telling you the connection never completed at all. The host wasn't answering on that name, period.

Cause. Flex Consumption apps answer only on a regional hostname shaped like this:

<app-name>-<hash>.<region>-01.azurewebsites.net

The bare <app-name>.azurewebsites.net you'd expect, the one every older tutorial uses, just isn't a live endpoint for these apps. So you're hitting an address that resolves to nothing useful and getting a dead connection for your trouble.

Fix. Use the regional hostname, and get it from the resource itself rather than constructing it by hand:

az resource show --ids <function-app-resource-id> \
  --query "properties.defaultHostName" --output tsv

This one is nasty because it compounds with Gotcha 1. The tool that should hand you the correct hostname returns null, so you fall back to guessing, and the address you guess refuses the connection. Two failures stacked: the right answer is hidden, and the wrong answer fails silently. Once I knew the regional shape was the only one that answers, the dead connections stopped being a mystery.

Gotcha 3: the official deploy GitHub Action was blocked

Symptom. I was deploying my Functions from GitHub Actions using azure/functions-action, the official Microsoft-published action for the job. At some point it became unusable in my setup for terms-of-service reasons. The action I'd built my deploy step around was off the table.

Cause. This one came down to a licensing and terms constraint on using that action in my context. Doesn't matter how clean your workflow is if the step it depends on is contractually off the table.

Fix. Drop the action and deploy with the az CLI directly inside the workflow. The CLI does the same job without the dependency on a third-party action:

# filepath: .github/workflows/deploy.yml
- name: Deploy function app
  run: |
    az functionapp deployment source config-zip \
      --name "$APP_NAME" \
      --resource-group "$RG" \
      --src "$ZIP_PATH"

I made this change in my Actions repo and never looked back (the commit that dropped the action lives in my history as 17b7362). The broader takeaway: a deploy step that leans on a single vendor action is a step that can disappear out from under you. The az CLI is the stable substrate. When an action gets blocked or deprecated, the CLI underneath it almost always still does the work.

Gotcha 4: Container Apps probes defaulted to port 80, my app listens on 8080

Symptom. A hand-provisioned Container App came up and looked dead. Ingress was reachable in name but every health probe failed, so the platform kept treating the revision as unhealthy and cycling it. The container itself was running fine. The platform just couldn't get a healthy response out of it.

Cause. The app came up with ingress and health probes pointed at port 80. My container listens on 8080. So every probe knocked on a door nobody was behind, marked the app unhealthy, and the app looked broken while being completely fine internally.

Fix. Set the ingress target port and the probe ports to where the app actually listens:

az containerapp ingress update \
  --name <app> --resource-group <rg> \
  --target-port 8080

And make sure any liveness and readiness probes point at 8080 too, not the default. This is a small fix that wastes a lot of time, because "running but failing every health check" presents exactly like a crashed app from the outside. The first thing I check now on any new Container App is whether the probe port and the listen port agree.

Gotcha 5: role assignments threw MissingSubscription, so I used az rest

Symptom. A freshly hand-made app has none of the permissions it needs. I went to grant its managed identity the roles it required:

AcrPull, so it can pull its own container image from the registry.
Key Vault access, so it can read its secrets (Key Vault is Azure's managed secret store).
App Configuration Data Reader, so it can read its config (App Configuration is Azure's managed settings store).

The obvious command for each grant is az role assignment create. In my environment it threw a MissingSubscription error and refused to make the assignment. The subscription context was set, other commands worked, but this specific path insisted it couldn't find a subscription.

Cause. I never got a clean root cause for the MissingSubscription failure on that command in my setup. What I could prove was that the same role assignment went through fine when I made it against the ARM REST API directly.

Fix. Create the role assignments through az rest, calling the management API yourself:

az rest --method put \
  --url "<scope>/providers/Microsoft.Authorization/roleAssignments/<guid>?api-version=<api-version>" \
  --body '{
    "properties": {
      "roleDefinitionId": "<role-definition-id>",
      "principalId": "<app-managed-identity-principal-id>",
      "principalType": "ServicePrincipal"
    }
  }'

It's more verbose, you build the request body by hand, but it works where the convenience command wouldn't.

The deeper problem here is the shape of the whole situation, well beyond the one error. A freshly hand-made app is missing every one of these by default: AcrPull, Key Vault access, App Configuration Data Reader, joining the managed environment, and having its App Configuration store seeded with the keys it expects. Nothing tells you any of them are missing. The app doesn't announce "I have no permission to pull my image." It just fails quietly, one missing grant at a time, and you discover each one by watching the app fail in a slightly new way and reasoning backward to what it must have needed.

What I Took From All of It

Every fix above was applied live, by hand, to a running dev environment, discovered by trial and error at the moment the thing broke. None of it was in a runbook, because there was no runbook. The whole sequence lived in trial-and-error scar tissue and nowhere a teammate, or a future me, could go look it up.

There's a thread running through all five. The platform's convenient answer was the wrong one often enough that I learned to drop a layer down by reflex. az functionapp show lies on Flex, so read the resource directly. The friendly hostname is dead, so pull the regional one off the resource. The official action is blocked, so call the CLI underneath it. The defaults point at the wrong port, so set them explicitly. The role-assignment helper fails, so hit ARM directly. The generic, lower-level path was the reliable one almost every time.

This pile of hand-fixes is exactly what pushed me to describe my infrastructure in Bicep instead, so the next environment is reviewed as code before it exists rather than debugged after (that's its own post). But that's the cure. This post is the disease, written down, so the next person googling HTTP 000 azurewebsites.net flex consumption at midnight finds something.

When the platform tells you null, don't believe it. Go ask the resource.

Four Reviewers and a Gauntlet: Verifying AI-Authored Code

Tatted Dev — Sun, 07 Jun 2026 16:39:22 +0000

Almost none of the code I ship was typed by me. I describe what I want, an AI coding agent writes the implementation, and I read what comes back. That one fact, still strange to say out loud, has quietly reorganized my entire job. I run a studio's worth of services solo, and across all of those repos the bulk of the actual authoring now happens on the other side of a prompt.

That changes the job. When you're the one writing every line, your judgment lives in the writing. You feel the design as you type it. When an AI writes the lines, that feeling is gone, and you can fool yourself into thinking the work is done the moment the code looks plausible. Plausible is exactly the failure mode. AI-authored code is usually fluent, often correct, and occasionally confidently wrong in a way that reads great and breaks in production.

So my judgment had to move somewhere. It moved to the verification layer. These days my attention goes to one thing: making sure what lands is solid. Every pull request in my repos runs a gauntlet of layered review before it's allowed to merge. This post is about that gauntlet, why it has so many layers, and why the economics of it actually favor a one-person shop.

What "AI Writes the Code" Means Here

Quick grounding before the jargon, because this is a public post and the setup is specific.

I'm a solo founder building HoneyDrunk Studios. The bulk of the code authoring is done by AI coding agents (think command-line tools that take a task and produce a diff). My leverage is in two places now: specifying intent clearly enough that the agent builds the right thing, and verifying the output well enough that I trust it in production. The first half is prompts and design notes. The second half is the review gauntlet.

A couple of terms I'll use repeatedly:

A CI gate is an automated check that runs on every pull request and has to pass before the code can merge. Build the project, run the tests, check formatting, measure test coverage. If any required gate fails, the merge button stays off. CI stands for continuous integration; for my purposes it's just "the robot that won't let bad code in."
A pull request (PR) is the unit of change. One proposed diff, opened for review, merged when it passes. Every layer below operates on a PR.

With that established, here are the layers.

The Layers

Every PR I open can face up to five distinct reviewers before it merges. Each one is good at something different, and the overlap is the point.

1. CodeRabbit. An AI service that reviews pull requests. It reads the diff, comments inline on specific lines, flags likely bugs and convention violations, and summarizes the change. I deploy it across all my repos from one org-level configuration rather than copying a config file into every repo by hand. One file governs the whole studio, which matters when "the whole studio" is dozens of repos and one person maintaining them.

2. GitHub Copilot review. GitHub's own built-in AI reviewer. It runs inside the GitHub PR interface and posts its own read of the diff. It's a second AI opinion from a different vendor with a different training and a different rubric, sitting right where I'm already looking.

3. My own local AI review runner. This is the one I built. It runs an AI code review on my own hardware, under my existing CLI subscriptions, and posts its verdict as a PR comment. On high-risk changes it runs the review through two different model families, Codex and Claude, and synthesizes their findings into one verdict. Two independent models, two independent blind spots. I wrote a whole separate post on how this runner's transport works (it polls GitHub and treats labels as a durable queue rather than waiting for a webhook); if you want the plumbing, read Stop Receiving Webhooks, Start Polling. Here it's just one layer in the stack.

4. GitHub Actions CI gates. The automated required checks. Build succeeds, tests pass, coverage holds, formatting is clean, code quality thresholds are met. These are pass/fail facts rather than opinions, and a failing one blocks the merge outright. Where the AI reviewers say "this looks risky," the gates say "this is broken, full stop."

5. SonarQube. A static-analysis tool that scans the code without running it, hunting for bugs, code smells, security-sensitive patterns, and coverage gaps, then gates the PR on a quality threshold. It's the deterministic, rules-based counterweight to the four probabilistic AI opinions above it. SonarQube finds the same kind of issue the same way every single time, which is exactly what you want sitting next to a stack of models that each answer a little differently on every run.

Five layers, three flavors: AI reviewers reading intent (CodeRabbit, Copilot, my runner), hard pass/fail gates (Actions), and deterministic static analysis (SonarQube). A change has to satisfy all of the ones that apply to it before it merges.

Risk-Based Escalation, and Why This Is Affordable

A reasonable reaction here is that five reviewers on every pull request sounds slow and expensive. It would be, if every layer ran at full weight on every change. They don't.

The stack is risk-scored. Each change gets a rough risk assessment, and the most expensive layers escalate only for the riskiest changes. A one-line copy fix in a README doesn't earn a dual-model deep review. A change to authentication, a database migration, or a deploy pipeline does. The heavyweight pass, my local runner spending the time to run both Codex and Claude and reconcile them, kicks in where the cost of a missed bug is highest. That's a deliberate cost-and-coverage tradeoff: spend the expensive attention where a mistake actually hurts, and let the cheap layers carry the routine changes.

The economics work out in favor of layering, and that surprised me. Here's the shape of it for a solo dev:

CodeRabbit and Copilot review run on flat-rate subscriptions. Their cost is the same whether they review one PR a week or thirty.
The GitHub Actions gates run on CI minutes that, at my volume, sit comfortably inside the free allowance.
My local runner executes under CLI subscriptions I already pay for, on hardware I already own and leave running. Each review it performs adds no marginal token bill.
The risk scoring caps how often the genuinely expensive path runs at all.

Put those together and adding another reviewer to the gauntlet is mostly free at the margin. The fixed costs are paid; the per-PR cost of one more layer rounds to nothing. For a single operator, that's a rare situation where the safe choice and the cheap choice are the same choice. I'll take more independent eyes when more eyes are close to free.

Why So Many: The Thesis

The reason for all of this fits in one observation about probability.

A bug that one reviewer misses is common. Every reviewer, human or AI, has blind spots. A bug that two independent reviewers both miss is less common, because their blind spots rarely line up. A bug that survives an AI reviewer, a second AI reviewer from a different vendor, a dual-model local review, a battery of pass/fail gates, and a deterministic static analyzer is rare, because for that to happen, every one of those different rubrics has to fail in the same place at the same time. That's defense in depth: stack independent checks so that no single failure gets the whole way through.

This is exactly why the high-risk path runs two different model families instead of running one model twice. Two passes of the same model share the same blind spots; they tend to agree, including when they're both wrong. Two different models disagree productively. One flags something the other waved through. The disagreement is the value. So the principle I hold is that the riskiest changes always get two genuinely independent model perspectives, two different rubrics from two different vendors looking at the same diff.

And the human is still in this, just not where I used to be. I'm not reading every line as it's written anymore. I'm reading verdicts, resolving the cases where the layers disagree, and deciding what's actually true when CodeRabbit loves a change and SonarQube hates it. The judgment is still mine. It moved from the keyboard to the merge button.

I want to be honest that this is an opinionated setup built for one specific situation: a solo dev whose code is overwhelmingly AI-authored. A team with humans writing and reviewing code line by line already has a lot of this coverage built into how they work, and stacking five automated layers on top might be redundant for them. For me, where no human wrote the code in the first place, the verification layer is the only place human judgment touches the work at all. So it gets all of it.

The Close

When you stop writing the code, you don't stop being the engineer. The engineering just moves downstream, from authoring to specifying and verifying. The gauntlet is where I spend my judgment now, and I built it deep on purpose.

Let the cheap, fast layers catch the routine misses. Let two different models argue over the dangerous changes. Let the deterministic gates have the final, unarguable say. Write less code, verify it harder. That's the job now.

Discord as My Operator Pager: One Timeline for a Whole Studio

Tatted Dev — Sun, 07 Jun 2026 16:37:00 +0000

A deploy of mine broke, and I found out about it the way you never want to: days later, by stumbling onto it myself. The failure had been recorded. An email went out. A status flipped red in a dashboard somewhere. Every system did its job. I just never saw any of it, because the signal was scattered across so many places that none of them was the place I actually looked.

That's the failure mode of running a lot of automation alone. Under my repos there's a constant hum of machinery: deploys firing, CI pipelines passing and failing, scheduled jobs waking up to do work, secrets quietly aging toward expiry. When you're one person, the hard question stops being "can I build it" and becomes "do I know what it's doing right now." For a long time the honest answer was no.

The signal was everywhere and nowhere. GitHub notifications were supposed to be my feed, except they were buried under a huge issue backlog, so the inbox that should have told me a deploy broke was the same inbox screaming about forty open issues. Actions failures arrived as email, which I learned to skim past because most of them were noise. Some things only showed up if I went and looked: opening a dashboard, checking a deploy status, remembering to verify a job actually ran. There was no single place I could glance at and trust to tell me the truth. So I missed things. The information existed the whole time. It just had no home.

This post is about giving it one. I made Discord the place where everything my automation does reports in, and I gave that reporting a structure so the important events stay glanceable.

When the Signal Has No Home

The pattern was worse than any one missed alert.

A deploy would go out and I'd find out it worked by using the thing, not by being told. A CI run would fail on a repo I hadn't touched in a week, and the email telling me sat unread between two GitHub digest mails. A scheduled job would skip a night and I'd discover the gap days later. None of these are catastrophic on their own. The problem is the pattern: every kind of operational event lived in a different place, in a different format, with a different chance of me ever seeing it.

On a team, someone is usually watching the boards while someone else builds. Solo, the watching is also my job, layered on top of the building, and human attention does not scale across a dozen notification surfaces. I needed to collapse all of those surfaces into one.

The requirement was simple to state. I wanted a single timeline where, if something happened that I'd care about, it showed up, and where the things I'd care about most were easy to pick out from the things that are just routine chatter.

What a Webhook Is, and Why Discord

The mechanism underneath all of this is a webhook, and it's worth a plain definition because the whole design rests on it.

A Discord webhook is a URL you POST a message to. You send an HTTP request to that URL with some content, and the message appears in a Discord channel. That's the entire contract. There's no bot to host, no gateway connection to keep alive, no library to babysit. Any piece of automation that can make an HTTP request can speak into a channel, which means every part of my studio (a GitHub Action in the cloud, a script on a machine at home) can report in with the same trivial primitive.

Discord earns the role for a boring reason: I'm already in it, on my phone and my desktop, all day. The pager has to be somewhere I already look. Anywhere else just becomes one more dashboard I forget to open. Channels give me natural separation. Mentions give me a way to make the loud things loud. It was already running, so I made it load-bearing.

I'll borrow a word for the messages it carries: operator alerts. An operator alert is a message meant for me, the person running the studio, telling me something about the state of my own systems. A deploy finished. A pipeline failed. A secret is about to expire. The audience is exactly one person, and that fact ends up mattering a lot, which I'll get to.

The Taxonomy: Every Event Has a Known Home

A single channel with everything dumped into it would just be the email inbox again, reinvented. The structure is the point.

So I split operator alerts into channels by signal type. Each kind of event has a known home, and I know what each home means without reading closely. The split looks roughly like this (these are examples of the shape, not a literal channel list):

Deploys. Something went out, where it went, and whether it landed.
CI failures. A pipeline broke, on which repo, with a link to the run.
Security and credential events. A secret or credential did something I need to know about.
Rotation and escalation. A scheduled or sensitive job needs my attention now.

The reason this works is that the channel itself carries meaning before I read a word. A new message in the deploys channel is routine and I can let it scroll by. A new message in the security channel makes me stop. By routing each event type to its own home, the important signals stop competing with the routine ones for the same glance. Glanceability is a property of the layout, not of any single message.

A webhook emits a structured message into the right channel. The emitter knows what kind of event it's reporting, so it knows which channel URL to POST to. That routing decision is the taxonomy, encoded.

Two Stores, Because Alerts Come From Two Places

There's a credential wrinkle here that shaped the implementation, and it's a good illustration of how a small system grows real edges.

Those webhook URLs are secrets. Anyone holding one can post into your channel, so they have to be stored and handed to the emitters carefully. The catch is that my alerts originate from two very different places, and those two places have different ways of holding a secret.

Some alerts come from GitHub Actions, running in the cloud. Those read their webhook URLs from organization secrets, which is GitHub's built-in store for values that workflows are allowed to use. Other alerts come from a local automation worker running on my own hardware. That worker reads its webhook URLs from Key Vault, which is Azure's cloud secret store. Two execution contexts, two secret stores, the same destination channels on the other end.

I could have forced everything through one store, but the contexts genuinely live in different trust domains, and each already had a native, well-guarded place to keep a secret. So I let each emitter use the store that fits where it runs. The taxonomy is shared. The credential plumbing is local to the emitter.

Redaction Is Not Optional

There's one rule in this system I treat as absolute: secrets get redacted before anything is posted.

The reason is uncomfortable once you say it out loud. The whole point of a security and credential channel is to tell me when something is wrong with a secret. If the message announcing that a token is expiring includes the token, then my alerting surface just leaked a credential into a chat application. An alert that leaks the thing it's alerting about is its own incident, and a worse one than the event that triggered it.

So redaction is a property of the emitter, enforced before the POST, every time. The emitter's job is to describe an event in enough detail that I can act, and never enough detail to compromise anything. "A secret in this vault is expiring in three days" is the alert. The secret's value never goes near the channel. I'd rather an alert be slightly too vague than carry a payload I'd regret.

The Boundary: Operator Alerts and Customer Notifications Are Different Concerns

This is the part I hold most firmly, so I'll state it plainly as two separate things.

Operator alerts are signal for me, the person running the studio. The audience is one. The job is to tell me what my automation is doing so I can intervene when I need to. Discord is that pager, and this entire post is about it.

Customer-facing notifications are a product capability, the features that email or notify the people who use what I build. The audience is users. The job is reliable, durable delivery to people who are not me. That's a separate system entirely, with its own delivery guarantees, its own retries, its own failure handling, and its own place in the architecture.

These two have different audiences, different reliability needs, and different failure modes, so they live in different systems. If my operator pager misses a message, I notice the next time I glance and I go look. If a customer notification system misses a message, that's a product defect with someone else's expectations attached. Mixing them would drag the casual reliability of a personal pager into a place that demands real guarantees, or drag heavyweight delivery machinery into something that just needs to ping my phone. Keeping them apart lets each one be exactly as serious as it should be.

Discord is the operator pager. The customer notification product is its own thing, and it's a different post.

What Shipped, and What I Learned

The taxonomy is in place, both webhook stores are wired, redaction is enforced at the emitter, and the most recent piece to land was a credential pager: alerts specifically for credential and secret events. A secret nearing expiry, a rotation that needs attention, these now route to their own channel instead of dissolving into the general stream. The events that are easiest to forget and most painful to miss got the most deliberate home.

The thing I learned building this is that scattered signal gets solved by choosing one surface and committing to it, not by polishing the surfaces you already ignore. The technology here is almost embarrassingly simple. A webhook is a URL you POST to. All the real work lived in the taxonomy, the discipline of redaction, and the boundary that keeps my pager out of my product.

A solo operator can't watch a dozen places. So I stopped trying, and built the one place worth watching.

🍯 Announcing HoneyDrunk.Data: A Multi-Tenant Persistence Layer for Distributed .NET Applications

Tatted Dev — Tue, 06 Jan 2026 23:34:07 +0000

TL;DR: We just released HoneyDrunk.Data, a provider-agnostic persistence layer built for multi-tenant, distributed .NET 10 applications. It features automatic correlation tracking in SQL queries, tenant-aware repositories, and seamless integration with OpenTelemetry—all without coupling your domain logic to Entity Framework.

The Problem We're Solving

Building multi-tenant applications with proper observability is harder than it should be. You end up with:

Scattered tenant checks throughout your codebase
No correlation between your distributed traces and database queries
Tight coupling between your domain logic and EF Core
Test infrastructure that requires spinning up real databases

We built HoneyDrunk.Data to solve these problems as part of HoneyDrunk.OS—our distributed application framework for .NET.

Architecture: Layers That Actually Make Sense

┌─────────────────────────────────────┐
│   HoneyDrunk.Data.Abstractions      │  ← Zero EF Core dependencies
│   (IRepository, IUnitOfWork, etc.)  │
└─────────────────────────────────────┘
                  │
                  ▼
┌─────────────────────────────────────┐
│        HoneyDrunk.Data              │  ← Kernel integration, no EF Core
│   (Tenant accessor, telemetry)      │
└─────────────────────────────────────┘
                  │
                  ▼
┌─────────────────────────────────────┐
│  HoneyDrunk.Data.EntityFramework    │  ← EF Core implementation
│   (EfRepository, EfUnitOfWork)      │
└─────────────────────────────────────┘
                  │
                  ▼
┌─────────────────────────────────────┐
│    HoneyDrunk.Data.SqlServer        │  ← SQL Server specifics
│   (Retry, Azure SQL, datetime2)     │
└─────────────────────────────────────┘

Why this matters: Your domain projects reference only HoneyDrunk.Data.Abstractions. No EF Core leaking into your business logic. Swap providers without touching domain code.

Feature Highlight: Correlation Tracking in SQL

This is my favorite feature. Every SQL command is automatically tagged with the Grid correlation ID:

/* correlation:01JXY7ABC123DEF456 */
SELECT [o].[Id], [o].[CustomerId], [o].[Total]
FROM [Orders] AS [o]
WHERE [o].[TenantId] = @p0

Why it matters:

Find the exact query from a slow API response
Correlate database logs with distributed traces
Debug production issues without guessing

The implementation uses EF Core's DbCommandInterceptor:

public sealed class CorrelationCommandInterceptor : DbCommandInterceptor
{
    private readonly IDataDiagnosticsContext _diagnosticsContext;

    public override InterceptionResult<int> NonQueryExecuting(
        DbCommand command,
        CommandEventData eventData,
        InterceptionResult<int> result)
    {
        AddCorrelationComment(command);
        return base.NonQueryExecuting(command, eventData, result);
    }

    private void AddCorrelationComment(DbCommand command)
    {
        var correlationId = _diagnosticsContext.CorrelationId;
        if (string.IsNullOrEmpty(correlationId)) return;

        // SQL comments don't affect query plan caching
        command.CommandText = $"/* correlation:{correlationId} */\n{command.CommandText}";
    }
}

We use SQL comments specifically because they don't affect query plan caching—your cached plans stay cached.

Multi-Tenancy: From HTTP Header to Database Query

Tenant context flows automatically from the HTTP request through to database queries:

HTTP Request                 Kernel                    Data Layer
     │                         │                          │
X-Tenant-Id: acme  →  IOperationContext.TenantId  →  ITenantAccessor
     │                         │                          │
                                                   TenantId.FromString("acme")

The KernelTenantAccessor bridges our Kernel context system with the data layer:

public sealed class KernelTenantAccessor : ITenantAccessor
{
    private readonly IOperationContextAccessor _contextAccessor;

    public TenantId GetCurrentTenantId()
    {
        var tenantId = _contextAccessor.CurrentContext?.TenantId;
        return string.IsNullOrEmpty(tenantId) 
            ? default 
            : TenantId.FromString(tenantId);
    }
}

Your DbContext can then apply global query filters:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    // Every query automatically filters by tenant
    modelBuilder.Entity<Order>()
        .HasQueryFilter(o => o.TenantId == CurrentTenantId.Value);
}

No more "did we remember to filter by tenant?" code reviews.

The Repository Pattern, Done Right

I know, I know—"repository pattern is an anti-pattern with EF Core." Hear me out.

Our repositories aren't about abstracting EF Core. They're about:

Separating read from write concerns
Providing a testable boundary
Enabling future provider swaps (Dapper for hot paths, anyone?)

public interface IReadOnlyRepository<TEntity>
{
    ValueTask<TEntity?> FindByIdAsync(object id, CancellationToken ct = default);
    Task<IReadOnlyList<TEntity>> FindAsync(Expression<Func<TEntity, bool>> predicate, CancellationToken ct = default);
    Task<bool> ExistsAsync(Expression<Func<TEntity, bool>> predicate, CancellationToken ct = default);
}

public interface IRepository<TEntity> : IReadOnlyRepository<TEntity>
{
    Task AddAsync(TEntity entity, CancellationToken ct = default);
    void Update(TEntity entity);
    void Remove(TEntity entity);
}

The Unit of Work coordinates changes:

public async Task CheckoutAsync(Cart cart, CancellationToken ct)
{
    var orders = _unitOfWork.Repository<Order>();
    var inventory = _unitOfWork.Repository<InventoryItem>();

    var order = new Order { Items = cart.Items };
    await orders.AddAsync(order, ct);

    foreach (var item in cart.Items)
    {
        var inv = await inventory.FindByIdAsync(item.ProductId, ct);
        inv!.Quantity -= item.Quantity;
        inventory.Update(inv);
    }

    // Atomic save across all repositories
    await _unitOfWork.SaveChangesAsync(ct);
}

Testing Without Docker: SQLite In-Memory

Spinning up SQL Server containers for every test run is slow. We provide SQLite-based test infrastructure:

public class OrderRepositoryTests : IAsyncDisposable
{
    private readonly SqliteTestDbContextFactory<AppDbContext> _factory;
    private readonly AppDbContext _context;

    public OrderRepositoryTests()
    {
        _factory = new SqliteTestDbContextFactory<AppDbContext>(
            options => new AppDbContext(
                options,
                TestDoubles.CreateTenantAccessor("test-tenant"),
                TestDoubles.CreateDiagnosticsContext()));

        _context = _factory.Create();
    }

    [Fact]
    public async Task AddAsync_ShouldPersistOrder()
    {
        var repo = new EfRepository<Order, AppDbContext>(_context);
        var order = new Order { Id = Guid.NewGuid(), Total = 99.99m };

        await repo.AddAsync(order);
        await _context.SaveChangesAsync();

        var found = await repo.FindByIdAsync(order.Id);
        Assert.NotNull(found);
    }

    public async ValueTask DisposeAsync()
    {
        await _context.DisposeAsync();
        await _factory.DisposeAsync();
    }
}

Test doubles included for tenant and diagnostics contexts—no mocking frameworks required.

SQL Server Specifics: datetime2 and Retry Logic

The HoneyDrunk.Data.SqlServer package handles SQL Server-specific concerns:

builder.Services.AddHoneyDrunkDataSqlServer<AppDbContext>(options =>
{
    options.ConnectionString = config.GetConnectionString("Default");
    options.EnableRetryOnFailure = true;
    options.MaxRetryCount = 3;
});

// Or for Azure SQL with optimized settings
builder.Services.AddHoneyDrunkDataAzureSql<AppDbContext>(options =>
{
    options.ConnectionString = config.GetConnectionString("AzureSql");
});

Model conventions automatically apply SQL Server best practices:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder
        .UseDateTime2ForAllDateTimeProperties()  // No more datetime truncation
        .ConfigureDecimalPrecision(18, 4);       // Explicit money precision
}

Getting Started

# Full stack with SQL Server
dotnet add package HoneyDrunk.Data.SqlServer

# Or just EF Core (bring your own provider)
dotnet add package HoneyDrunk.Data.EntityFramework

# Or abstractions only (for domain libraries)
dotnet add package HoneyDrunk.Data.Abstractions

Minimal setup:

var builder = WebApplication.CreateBuilder(args);

// Register Kernel (required for context propagation)
builder.Services.AddHoneyDrunkGrid(options =>
{
    options.NodeId = "order-service";
    options.StudioId = "acme-corp";
});

// Register Data layer
builder.Services.AddHoneyDrunkData();
builder.Services.AddHoneyDrunkDataSqlServer<AppDbContext>(options =>
{
    options.ConnectionString = builder.Configuration.GetConnectionString("Default");
});

var app = builder.Build();

app.MapGet("/orders/{id}", async (Guid id, IUnitOfWork<AppDbContext> unitOfWork) =>
{
    var order = await unitOfWork.Repository<Order>().FindByIdAsync(id);
    return order is not null ? Results.Ok(order) : Results.NotFound();
});

app.Run();

What's Next?

This is v0.1.0—the foundation. On the roadmap:

PostgreSQL provider (HoneyDrunk.Data.PostgreSQL)
Read replica support for CQRS patterns
Outbox pattern integration for reliable messaging
Query profiling with automatic slow query detection

HoneyDrunk.Transport: A Transport Agnostic Messaging Framework for .NET

Tatted Dev — Mon, 08 Dec 2025 13:56:08 +0000

Distributed systems love to trap you in vendor gravity. One transport today becomes a rewrite tomorrow. When I started wiring together services for HoneyDrunk’s distributed grid, the usual messaging libraries all had the same problem: coupling. Everything leaked broker assumptions.

So I built HoneyDrunk.Transport to break that pattern.

What It Is

HoneyDrunk.Transport is a transport-agnostic messaging abstraction for .NET. Your code looks identical whether you're using Azure Service Bus, Azure Storage Queues, or the InMemory transport.

// This code works identically whether you're using
// Azure Service Bus, Storage Queues, or InMemory transport
public class OrderService(IMessagePublisher publisher, IGridContext gridContext)
{
    public async Task CreateOrderAsync(Order order, CancellationToken ct)
    {
        await publisher.PublishAsync(
            destination: "orders.created",
            message: new OrderCreated(order.Id, order.CustomerId),
            gridContext: gridContext,
            cancellationToken: ct);
    }
}

Your handlers stay the same too.

public class OrderCreatedHandler : IMessageHandler<OrderCreated>
{
    public async Task<MessageProcessingResult> HandleAsync(
        OrderCreated message,
        MessageContext context,
        CancellationToken ct)
    {
        var correlationId = context.GridContext?.CorrelationId;
        var tenantId = context.GridContext?.TenantId;

        await ProcessOrderAsync(message, ct);
        return MessageProcessingResult.Success;
    }
}

Why It Exists

1. Swap transports without rewriting code

// Development
services.AddHoneyDrunkTransportCore()
    .AddHoneyDrunkInMemoryTransport();

// Production
services.AddHoneyDrunkTransportCore()
    .AddHoneyDrunkServiceBusTransport(options => 
    {
        options.FullyQualifiedNamespace = "mynamespace.servicebus.windows.net";
        options.Address = "orders-queue";
    });

2. Distributed context propagation

Node A (Order Service)                    Node B (Payment Service)
┌─────────────────────┐                   ┌─────────────────────┐
│ CorrelationId: abc  │ ──── Queue ────▶  │ CorrelationId: abc  │
│ TenantId: tenant-1  │                   │ TenantId: tenant-1  │
│ ProjectId: proj-1   │                   │ ProjectId: proj-1   │
└─────────────────────┘                   └─────────────────────┘

3. Middleware pipeline

services.AddHoneyDrunkTransportCore(options =>
{
    options.EnableTelemetry = true;   // OpenTelemetry spans
    options.EnableLogging = true;     // Structured logging
    options.EnableCorrelation = true; // Grid context propagation
});

// Add custom middleware
services.AddMessageMiddleware<TenantResolutionMiddleware>();

4. Configurable error handling

var strategy = new ConfigurableErrorHandlingStrategy(maxDeliveryCount: 5)
    .RetryOn<TimeoutException>(TimeSpan.FromSeconds(5))
    .RetryOn<HttpRequestException>(TimeSpan.FromSeconds(10))
    .DeadLetterOn<ValidationException>()
    .DeadLetterOn<ArgumentNullException>();

services.AddSingleton<IErrorHandlingStrategy>(strategy);

Architecture at a Glance

┌─────────────────────────────────────────────────────────────────┐
│                     Your Application                            │
│  ┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐ │
│  │ OrderService    │  │ PaymentHandler  │  │ Custom          │ │
│  │ (IMessagePub)   │  │ (IMessageHandler)│ │ Middleware      │ │
│  └────────┬────────┘  └────────┬────────┘  └────────┬────────┘ │
└───────────┼─────────────────────┼─────────────────────┼─────────┘
            │                     │                     │
┌───────────▼─────────────────────▼─────────────────────▼─────────┐
│                   HoneyDrunk.Transport                          │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐          │
│  │ Abstractions │  │   Pipeline   │  │ Configuration│          │
│  │ IMessagePub  │  │  Middleware  │  │ ErrorStrategy│          │
│  │ IMessageHdlr │  │  Telemetry   │  │ RetryOptions │          │
│  └──────────────┘  └──────────────┘  └──────────────┘          │
└─────────────────────────────┬───────────────────────────────────┘
                              │
        ┌─────────────────────┼─────────────────────┐
        ▼                     ▼                     ▼
┌───────────────┐    ┌───────────────┐    ┌───────────────┐
│ ServiceBus    │    │ StorageQueue  │    │   InMemory    │
│   Transport   │    │   Transport   │    │   Transport   │
└───────────────┘    └───────────────┘    └───────────────┘

Transport Adapters

Azure Service Bus

services.AddHoneyDrunkServiceBusTransport(options =>
{
    options.FullyQualifiedNamespace = "mynamespace.servicebus.windows.net";
    options.EntityType = ServiceBusEntityType.Topic;
    options.Address = "orders-topic";
    options.SubscriptionName = "order-processor";
    options.MaxConcurrency = 10;

    // Blob fallback for large messages
    options.BlobFallback.Enabled = true;
    options.BlobFallback.AccountUrl = "https://myaccount.blob.core.windows.net";
});

Azure Storage Queue

services.AddHoneyDrunkStorageQueueTransport(options =>
{
    options.ConnectionString = "...";
    options.QueueName = "notifications";
    options.MaxConcurrency = 10;
    options.BatchProcessingConcurrency = 4;  // 40 total concurrent
});

InMemory Transport

services.AddHoneyDrunkTransportCore()
    .AddHoneyDrunkInMemoryTransport();

Try It Out

dotnet add package HoneyDrunk.Transport
dotnet add package HoneyDrunk.Transport.AzureServiceBus
dotnet add package HoneyDrunk.Transport.StorageQueue
dotnet add package HoneyDrunk.Transport.InMemory

Final Notes

HoneyDrunk.Transport exists because messaging shouldn’t require allegiance to a single broker. If you want clean abstractions, portable handlers, built-in telemetry, and automatic context propagation, it’s worth exploring.

If you try it, let me know how it fits into your stack.

Originally published on TattedDev.com

Honeypunk: A Semantic, Palette-Driven Theme Pipeline for Visual Studio 2026

Tatted Dev — Sun, 16 Nov 2025 20:43:39 +0000

Visual Studio 2026 shipped last week, and like a lot of devs, I installed it immediately. The new UI polish looked great. The editor surfaces felt modern. Then I opened a file and hit something familiar:

My favorite themes had not updated.

No previews. No experimental builds. No support for the new classification keys introduced in VS2026.

Instead of waiting, I built the update myself and, in the process, created a full semantic theme pipeline.

Honeypunk is a palette-driven, YAML-based system that lets you define color intent once and generate a complete Visual Studio theme automatically. No hex hunting. No drift. No fragile edits.

Repository: https://github.com/tatteddev/Honeypunk

Why Manual Theme Editing Fails

Visual Studio theming is powerful but tedious. Updating themes manually is slow and error prone, especially when a major version adds new editor surfaces.

Common issues include:

Hex values scattered across huge JSON theme files
Small tweaks creating near-duplicate colors
New VS releases breaking old themes
One color change often requiring 20 or more key edits
No auditing for unused or duplicate colors
Experimentation requiring too much overhead

Honeypunk introduces a semantic, declarative approach that avoids all of this.

The Pipeline Model

Honeypunk follows a predictable, declarative flow:

Palette → Roles → Mappings → Build → VSIX

Palette

The palette is the root of the system. All colors are centralized into a single file with:

Human-readable names
Contrast rules
Usage intent (foreground, accent, diagnostic, background)
Structure that allows global shifts with a single edit

Roles

Roles describe what a token represents, not what color it uses. Examples:

function
variable
type
interface
keyword
comment
string
operator

Roles point to palette entries, never hex values.

Mappings

Mappings connect semantic roles to actual Visual Studio classification keys. This file handles:

VS2022 through VS2026 classifications
ReSharper keys
Background and foreground tokens
New surfaces introduced by 2026

Build Scripts

The Python tooling:

Loads palette, roles, mappings
Resolves semantic intent to actual colors
Validates for errors, typos, unmapped items
Preserves flags like transparency
Generates a deterministic theme file

VSIX

The final packaging step creates a distributable Visual Studio extension supporting:

VS2022
VS2025
VS2026

The entire pipeline allows rebuilds in seconds.

Core Files

Honeypunk.yaml

Defines high-level theme structure:

Editor
Chrome and toolbars
Tool windows
Accent states
Debugging and caret surfaces
Selection and inlay hints

palette.md

A complete list of named colors with:

Hex values
Usage recommendations
Contrast notes
Accessibility considerations

roles.yaml

Maps semantic intent to palette names, for example:

functions: NeonYellow

variables: ChromeTeal

comments: SlateGray

mappings.yaml

Links roles to actual Visual Studio classification keys.

apply_palette.py

Reads all YAML files, applies semantic roles, enforces safety checks, and produces the resolved theme.

build_vsix.py

Packages the final theme into a VSIX with the necessary manifest metadata.

Palette Philosophy

The Honeypunk palette is intentionally structured for clarity and reduced fatigue.

Background tier

Deep gunmetal and charcoal tones that minimize glare.

Text tier

Neutral off-white and slate values optimized for long reading sessions.

Accent tier

Electric blues, neon yellows, and magentas used sparingly and intentionally.

Diagnostic triad

Orange for warnings
Magenta for attention
Green for success

The palette supports fast code scanning and visual consistency across large files.

Updating for Visual Studio 2026

VS2026 introduced new:

Classification keys
Chrome surfaces
Editor states
Accent highlights

A manual update would require reviewing every affected surface.

Honeypunk reduced this to a few mapping adjustments and a single rebuild.

Extending the System

Honeypunk was built for growth.

Adding a new role

Add to roles.yaml and map in mappings.yaml.

Adding a new color

Add to palette.md and reference it in roles.

Multiple theme variants

Create separate YAML build configurations sharing the same palette.

Coming soon

Accessibility variants
JSON diff reports
Live preview experiments
CI checks for color drift

Troubleshooting

Common fixes:

Theme not showing: verify VSIX manifest GUID.
Odd colors: check palette name for typos.
Build failure: YAML indentation error.
Missing token updates: mapping entry missing.

Try It Yourself

Clone the repo and modify a single role.

Rebuild the VSIX.

Install and restart Visual Studio.

You will immediately see how semantic theming makes iteration effortless.

Repository: https://github.com/tatteddev/Honeypunk

Originally published at:

https://tatteddev.com/blog/honeypunk-semantic-theme-pipeline-vs2026/

Building a Zero-Configuration .NET Standards Package

Tatted Dev — Mon, 03 Nov 2025 21:58:37 +0000

Posted by TattedDev

The Problem With Code Standards

Every .NET organization eventually fights the same battle: keeping code quality consistent across dozens of solutions. You copy .editorconfig files, manually add analyzers, and hope developers remember to fix warnings. Over time, configurations drift, rules diverge, and build quality becomes uneven.

HoneyDrunk.Standards solves this by turning code quality into infrastructure. It’s a single NuGet package that enforces conventions, analyzers, and build configurations automatically across every project in your ecosystem.

How It Works

1. Build-Transitive Package Design

The package uses MSBuild’s buildTransitive feature, which allows its build logic to propagate to all downstream projects that reference it.

Unlike normal runtime packages, this one operates entirely at build time.

When referenced, it automatically:

Enables StyleCop.Analyzers and Microsoft.CodeAnalysis.NetAnalyzers
Enforces nullable reference types
Treats warnings as errors in CI environments
Enables deterministic builds
Locks C# language version to latest

You don’t modify your .csproj. You don’t merge .editorconfig. It’s zero-configuration by design.

2. Continuous Integration Awareness

The package detects CI systems (like GitHub Actions or Azure Pipelines) through environment variables and automatically enables ContinuousIntegrationBuild=true.

This provides two distinct build profiles:

Local development: fast incremental builds with absolute source paths for debugging
CI builds: deterministic, reproducible outputs with embedded source paths for traceability

The result is parity between developer machines and build servers without requiring conditional logic in your projects.

3. Opt-Out Instead of Opt-In

Every enforcement feature is enabled by default.

Developers can selectively disable rules via MSBuild properties, but the baseline assumes quality enforcement. This approach prevents “silent drift” where one repository quietly stops following standards.

Opt-out defaults ensure consistency across all solutions while maintaining flexibility for legitimate edge cases.

Why This Approach Works

Consistent Code Quality

StyleCop.Analyzers enforces over 100 naming, spacing, and ordering rules
Microsoft.CodeAnalysis.NetAnalyzers enforces performance, security, and reliability best practices
Violations fail CI builds automatically, maintaining organizational quality thresholds

Configuration Centralization

One version bump updates analyzers, language rules, and conventions across every project.

No more synchronizing .editorconfig files or manually aligning rule sets across repositories.

Faster Onboarding

New developers get immediate feedback inside Visual Studio or Rider.

Standards become visible and actionable in the IDE instead of hidden in documentation.

Deterministic and Auditable Builds

Every project builds reproducibly, producing identical binaries for the same source inputs.

That’s essential for compliance, debugging, and verifying production deployments.

Common Gotchas and Solutions

1. Large Warning Backlogs

Adding the package to a legacy project often triggers hundreds of analyzer warnings.

Use incremental adoption:

<NoWarn>$(NoWarn);SA*</NoWarn>

Then remove suppression rules as you clean up the codebase.

2. Missing `PrivateAssets="all"`

Omitting this property allows analyzers to flow transitively into your consumers, which is rarely desirable.

Always declare:

<PackageReference Include="HoneyDrunk.Standards" PrivateAssets="all" />

This prevents analyzer propagation and keeps the standards internal to your organization.

3. Test Method Naming (CA1707)

Unit test naming conventions like MethodName_Condition_ExpectedResult conflict with CA1707.

The package pre-suppresses this rule, prioritizing readability and established testing patterns.

4. Overuse of the Null-Forgiving Operator (`!`)

The null-forgiving operator should be reserved for proven non-null scenarios.

Document any usage with an inline comment explaining why null cannot occur.

5. Local vs CI Output Differences

When running locally, builds embed absolute file paths.

In CI mode, paths are normalized for reproducibility.

To simulate CI locally:

dotnet build /p:ContinuousIntegrationBuild=true

6. Team Preference Conflicts

Different teams sometimes prefer conflicting style rules (for example, requiring or omitting this. prefixes).

The package allows per-project overrides in .editorconfig, and StyleCop can be disabled completely if needed:

<PropertyGroup>
  <EnableStyleCopAnalyzers>false</EnableStyleCopAnalyzers>
</PropertyGroup>

Implementation Best Practices

Start with a sample project. The included Consumer.Sample demonstrates compliant patterns and deliberate violations.
Document your rationale. The CONVENTIONS.md file explains why specific rules exist.
Use versioning semantics.
- Minor version → new rules or non-breaking changes
- Major version → breaking rule severity or enforcement changes

Treat standards packages as infrastructure, not libraries. They’re a versioned part of your build system.

Key Takeaways

Build-transitive packages are the cleanest way to enforce organization-wide build and analyzer standards.
Default-on enforcement guarantees consistency.
Gradual adoption keeps legacy code manageable.
Documentation matters as much as enforcement.
PrivateAssets="all" prevents downstream dependency pollution.

Try It Yourself

<PackageReference Include="HoneyDrunk.Standards" PrivateAssets="all" />

That single line brings your organization in line with modern, deterministic .NET build standards.

Repository: github.com/HoneyDrunkStudios/HoneyDrunk.Standards

Docs: Conventions guide, naming policies, nullable handling, and migration strategies.

Have you implemented your own internal standards package? What challenges did you hit during rollout? Share them below — the goal is a future where “code style review” isn’t a recurring meeting topic.

🟡 Written by TattedDev — building the HoneyDrunk ecosystem, one node at a time.

HoneyDrunk.Pipelines — Treat Your CI/CD as Infrastructure

Tatted Dev — Sat, 11 Oct 2025 21:02:40 +0000

When you’re a small team—or even a solo dev—the friction of managing CI/CD pipelines across multiple repos adds up fast.

A missing permission, a stale PAT, or a malformed GUID can break your release.

That’s what pushed me to think differently: treat pipeline configuration like infrastructure you version, maintain, and compose.

In this post, I’ll walk through how I built HoneyDrunk.Pipelines, a centralized, reusable template system for Azure DevOps, and the lessons that came out of it.

🧠 The Problem: Pipeline Sprawl & Runtime Breakage

Before building a unified system, here’s what I was dealing with:

Every repo had its own azure-pipelines.yml, each slightly different
Copy-pasted feed GUIDs, mismatched naming, and inconsistent versioning
Permission and service connection issues that only surfaced at runtime
Changing SDK versions or build logic meant updating several repos manually

A single pipeline failure captured the pain perfectly:

The build service identity didn’t have Contributor on the feed
The service connection used a stale PAT
The feed URL (with GUID) was mis-typed

Each of these were independent problems that only appeared after I pushed.

That’s when I decided: pipelines can’t be snowflakes anymore.

⚙️ The Vision: Pipelines as Reusable Infrastructure

I wrote down a few core principles before rebuilding:

Single source of truth. One repo for templates, many consumers
Versioned logic. Pipeline changes are reviewed and auditable
Composable building blocks. Stages, jobs, and steps can be mixed and matched
Separation of concerns. Projects define what to build; templates define how to build

🗂️ Repository Layout (Simplified)

HoneyDrunk.Pipelines/
├── stages/
├── jobs/
├── steps/
└── README.md

ConsumerRepo/
└── azure-pipelines.yml # references templates from HoneyDrunk.Pipelines

Consumer repos reference the template repo via Azure DevOps resources:

resources:
  repositories:
    - repository: pipelines
      type: git
      name: HoneyDrunk/HoneyDrunk.Pipelines
      ref: refs/heads/main

stages:
  - template: stages/pr-validation.stage.yaml@pipelines
    parameters:
      projectPath: 'src/MyLib/MyLib.csproj'
      runTests: true

  - template: stages/dotnet-publish.stage.yaml@pipelines
    parameters:
      dependsOn: PR_Validation
      condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
      packagePath: '$(Build.ArtifactStagingDirectory)/**/*.nupkg'
      feedName: 'HoneyDrunk-Internal'


That’s about 10 lines of YAML per project — the rest lives in the infrastructure layer.

🧩 Core Template Mechanics
PR Validation Stage
parameters:
  - name: projectPath
    type: string
  - name: configuration
    type: string
    default: 'Release'
  - name: runTests
    type: boolean
    default: true
  - name: dotnetVersion
    type: string
    default: '9.x'

stages:
  - stage: PR_Validation
    displayName: 'Build, Test, Validate'
    jobs:
      - job: Build
        pool:
          vmImage: 'ubuntu-latest'
        steps:
          - template: ../steps/install-dotnet-sdk.step.yaml
            parameters:
              dotnetVersion: ${{ parameters.dotnetVersion }}
          - template: ../steps/dotnet-restore-build.step.yaml
          - template: ../steps/dotnet-build.step.yaml
            parameters:
              projectPath: ${{ parameters.projectPath }}
              configuration: ${{ parameters.configuration }}
          - ${{ if eq(parameters.runTests, true) }}:
            - template: ../steps/dotnet-test.step.yaml
          - template: ../steps/dotnet-pack.step.yaml
            parameters:
              projectPath: ${{ parameters.projectPath }}
              configuration: ${{ parameters.configuration }}

Each step is modular, reusable, and easy to evolve.

Package Publish Step
parameters:
  - name: packagePath
    type: string
  - name: feedName
    type: string
  - name: serviceConnection
    type: string
    default: 'HoneyDrunk-AzureDevOps'

steps:
  - task: NuGetAuthenticate@1
    displayName: 'Authenticate with Azure Artifacts'
    inputs:
      nuGetServiceConnections: ${{ parameters.serviceConnection }}

  - task: DotNetCoreCLI@2
    displayName: 'Push to ${{ parameters.feedName }}'
    inputs:
      command: 'push'
      packagesToPush: ${{ parameters.packagePath }}
      nuGetFeedType: 'internal'
      publishVstsFeed: 'HoneyDrunk/${{ parameters.feedName }}'
      allowPackageConflicts: false

And to avoid brittle GUIDs, this script dynamically builds the feed URL:

- script: |
    FEED_URL="https://pkgs.dev.azure.com/$(System.TeamFoundationCollectionUri | sed 's|https://dev.azure.com/||')/_packaging/${{ parameters.feedName }}/nuget/v3/index.json"
    echo "##vso[task.setvariable variable=FeedUrl]$FEED_URL"
  displayName: 'Compute Feed URL'

No more copy-paste errors, no more mismatched feed identifiers.

🧰 Troubleshooting & Lessons Learned
Permission Setup

Ensure your Azure Pipelines build identity (Project Build Service) has Contributor access to the feed.
Without it, pushes will silently fail.

Service Connections

Use NuGetAuthenticate@1 instead of personal PATs wherever possible — it leverages the build service identity.

Parameterization

Anything that can change — paths, feed names, versions — should be a parameter.
Hardcoded values are time bombs.

🚀 The Impact

✅ Shared templates mean all projects follow the same structure
✅ Versioning and naming stay consistent
✅ Permission errors are practically gone
✅ Onboarding a new project takes minutes

⚖️ Before vs After

Before

Copy-paste massive YAML files

Search & replace project names

Debug GUIDs and PATs by trial and error

After

Reference templates

Set parameters

Push → it just works

🐝 Why It Matters for Small Teams

For indie devs or small studios like mine:

Time is precious. Every failed build costs momentum

Context switching is brutal. You shouldn’t be debugging YAML daily

Future-you will forget. Document it once, reuse forever

Treating pipelines as infrastructure is how you scale solo work.

🔮 Next Steps

Auto-generate release notes from commits

Add semantic versioning via conventional commits

Extend templates to handle multiple languages and deployment targets

Build once. Reuse forever.
That’s how HoneyDrunk Studios automates the grid.

🧱 Originally published on TattedDev.com

DEV Community: Tatted Dev

Building HoneyDrunk.Lore: My LLM Wiki and Daily News Blast

The Shape of Lore

The Daily Blast

Why I Wanted This

The Part That Feels Different

Two Terminals, One Screen: Building an Agent Cockpit That Tells the Truth About Cost

What HoneyHub Is

The Problem: Two Tools, Two Definitions of "Cost"

The Solution: Fidelity Is a First-Class Field

Claude: take the number, don't touch it

Codex: exact tokens, dollars only if I asked for them

The Centerpiece: The Two-Way Usage Table

The Headline Number Sums Only What It Can Measure

What I Learned

Next Steps

Stop Receiving Webhooks, Start Polling: Rebuilding the Grid Review Runner

The Old Shape: Inbound Webhook Over a Tunnel

Why It Failed

The Pivot: Push Becomes Pull

The Worker (and Why the Scheduler Is Boring on Purpose)

What I Learned

Next Steps

Treating Azure Infrastructure Like a Pull Request: Bicep and what-if

The Problem: I Provisioned From Memory

What Bicep Is (and What It Buys a Solo Dev)

Infra as a Diff You Review Before It Lands

The Payoff

What's Left to Codify

A Field Guide to Hand-Provisioning Azure Functions and Container Apps

Gotcha 1: az functionapp show returns null on Flex Consumption

Gotcha 2: the hostname you expect returns HTTP 000

Gotcha 3: the official deploy GitHub Action was blocked

Gotcha 4: Container Apps probes defaulted to port 80, my app listens on 8080

Gotcha 5: role assignments threw MissingSubscription, so I used az rest

What I Took From All of It

Four Reviewers and a Gauntlet: Verifying AI-Authored Code

What "AI Writes the Code" Means Here

The Layers

Risk-Based Escalation, and Why This Is Affordable

Why So Many: The Thesis

The Close

Discord as My Operator Pager: One Timeline for a Whole Studio

When the Signal Has No Home

What a Webhook Is, and Why Discord

The Taxonomy: Every Event Has a Known Home

Two Stores, Because Alerts Come From Two Places

Redaction Is Not Optional

The Boundary: Operator Alerts and Customer Notifications Are Different Concerns

What Shipped, and What I Learned

🍯 Announcing HoneyDrunk.Data: A Multi-Tenant Persistence Layer for Distributed .NET Applications

The Problem We're Solving

Architecture: Layers That Actually Make Sense

Feature Highlight: Correlation Tracking in SQL

Multi-Tenancy: From HTTP Header to Database Query

The Repository Pattern, Done Right

Testing Without Docker: SQLite In-Memory

SQL Server Specifics: datetime2 and Retry Logic

Getting Started

What's Next?

Links

HoneyDrunk.Transport: A Transport Agnostic Messaging Framework for .NET

What It Is

Why It Exists

1. Swap transports without rewriting code

2. Distributed context propagation

3. Middleware pipeline

4. Configurable error handling

Architecture at a Glance

Transport Adapters

Azure Service Bus

Azure Storage Queue

InMemory Transport

Try It Out

Final Notes

Honeypunk: A Semantic, Palette-Driven Theme Pipeline for Visual Studio 2026

Why Manual Theme Editing Fails

The Pipeline Model

Palette

Roles

Gotcha 1: `az functionapp show` returns null on Flex Consumption

2. Missing `PrivateAssets="all"`

4. Overuse of the Null-Forgiving Operator (`!`)