Here’s how I’m doing it.

Step 1: Categorize Topics

I broke down all assessment questions into 6 core categories:

• Algorithms & Data Structures
• SQL & LINQ
• C#/.NET Core concepts
• DevOps & CI/CD
• System Design (microservices, REST, queues)
• AI Tools as Coding Accelerators

This helps me track what to focus on weekly.

Step 2: Start with Brute Force (Then Optimize)

Instead of panicking over efficiency, I:

• Write a brute-force version first
• Ensure it works for small cases
• Then search or iterate into the optimized version

This makes patterns like sliding window, hashmap, and recursion much easier to understand.

Step 3: Practice Common Patterns

Each day I choose a pattern like:

• Sliding Window → Longest substring without repeat
• HashMap → Two Sum, Group Anagrams
• Stack → Valid Parentheses
• Binary Search → Search in rotated array

And I solve 1–2 problems using brute first, then refactor.

Step 4: Weekly Mock Tests

Once a week, I do a 25-minute simulation:

• 1 algorithm problem (LeetCode or Coderbyte)
• 1 real-world backend question (design API or SQL query)
• Use Copilot + ChatGPT only for hints, not answers

This gives me realistic pressure and makes me confident before the real test.

Step 5: AI Tools that Help

Here’s how I use AI ethically:

• GitHub Copilot to autocomplete loops, LINQ
• ChatGPT to explain logic or debug
• Ollama as a local GPT during offline prep
• Build a Notion doc of best prompts for reuse

Tools I Keep Open

• LeetCode Patterns
• C# Docs
• Visualgo.net
• My own GitHub repo with reusable snippets

Final Thoughts

By working smarter (not longer), I’ve found myself:

• Writing faster and cleaner code
• Explaining my solutions with more confidence
• Actually enjoying the interview prep process

If you’re prepping too — how do you learn best?

Let’s share strategies and improve together.

That’s fine for a meme. It’s less fine for a scan of your passport, and it’s the most common thing people convert. So I wanted to know how far a browser could get on its own.

Quite far, as it turns out — but not without a few traps that cost me an evening each. Here are the four that were worth writing down.

The constraint

Browsers decode plenty of formats: PNG, JPEG, WebP, GIF, BMP, AVIF, SVG, ICO.

They encode exactly three: PNG, JPEG, WebP. That’s the whole list canvas.toBlob() will give you.

Everything else — BMP, ICO, PDF, and crucially a properly compressed PNG — you write yourself, byte by byte.

Trap 1: toBlob lies to you

This is the one I’d most like to have known first.

canvas.toBlob() takes a MIME type. Pass it one the browser can’t encode, and it does not throw, does not return null, and does not warn. It silently gives you a PNG with a success callback.

canvas.toBlob((blob) => {
  console.log(blob.type); // "image/png" — but I asked for image/avif
}, 'image/avif', 0.8);

So you ship a converter that appears to work perfectly, and your users get files named .avif that are actually PNGs. Nothing errors. You find out from a bug report.

The fix is two lines:

function encodeNative(canvas, mime, quality) {
  return new Promise((resolve, reject) => {
    canvas.toBlob((blob) => {
      if (blob && blob.type === mime) resolve(blob);
      else reject(new Error("Your browser can't export " + mime));
    }, mime, quality);
  });
}

Check the type you got against the type you asked for. Never trust the callback firing as proof of anything.

Trap 2: “compressing” a PNG usually does nothing

Here’s the thing that surprised me most. Draw a PNG to a canvas, call toBlob('image/png'), and you get a file that’s often larger than the original.

PNG has no quality slider. It’s lossless. So there’s no knob for toBlob to turn, and re-encoding just re-does the same lossless compression, usually worse than whatever tool made the original.

Real PNG compression works differently. A standard PNG stores 24-bit colour — about 16 million possible values per pixel. Almost no real image uses that many. A logo might use twelve. A screenshot might use two hundred.

So you build an optimised palette of at most 256 colours and store a one-byte index per pixel instead of three or four bytes of colour. That’s where the savings live, and toBlob will never do it for you.

Which means writing the PNG yourself.

Writing a PNG by hand

A PNG is an 8-byte signature followed by chunks. Each chunk is: length, 4-byte type, data, CRC32.

function pngChunk(type, data) {
  const out = new Uint8Array(12 + data.length);
  const v = new DataView(out.buffer);
  v.setUint32(0, data.length);
  for (let i = 0; i < 4; i++) out[4 + i] = type.charCodeAt(i);
  out.set(data, 8);
  const crcBody = out.subarray(4, 8 + data.length);
  v.setUint32(8 + data.length, crc32(crcBody));
  return out;
}

Note the CRC covers the type and the data, but not the length field. Get that wrong and every decoder rejects the file with no useful message.

CRC32 itself is a table and a loop:

const CRC_TABLE = (() => {
  const t = new Uint32Array(256);
  for (let n = 0; n < 256; n++) {
    let c = n;
    for (let k = 0; k < 8; k++) c = c & 1 ? 0xEDB88320 ^ (c >>> 1) : c >>> 1;
    t[n] = c >>> 0;
  }
  return t;
})();

For an indexed PNG you need four chunks: IHDR (dimensions, bit depth, colour type 3 for palette), PLTE (the palette), tRNS (per-palette-entry alpha, only if anything is transparent), and IDAT (the pixel data).

One detail that’s easy to miss: every scanline in the raw data is prefixed with a filter byte. Zero means “no filter”. Forget it and your image comes out sheared diagonally — which is at least a memorable way to find the bug.

Bit depth is worth packing properly too. Two colours fit in 1 bit per pixel, four in 2 bits, sixteen in 4. A two-colour image at 8 bits per pixel wastes 87% of its bytes.

Trap 3: deflate vs deflate-raw

IDAT data is zlib-compressed, and browsers have that built in now via CompressionStream:

async function zlibDeflate(bytes) {
  const cs = new CompressionStream('deflate');
  const writer = cs.writable.getWriter();
  writer.write(bytes);
  writer.close();
  return new Uint8Array(await new Response(cs.readable).arrayBuffer());
}

The trap is the argument. CompressionStream accepts 'deflate', 'deflate-raw' and 'gzip', and the naming is genuinely misleading:

• 'deflate' produces zlib format — RFC 1950, a 2-byte header plus an Adler-32 checksum
• 'deflate-raw' produces raw deflate — RFC 1951, no header, no checksum

PNG’s IDAT requires the zlib wrapper, so you want 'deflate'. If you reach for 'deflate-raw' because “raw deflate” sounds like what a binary format wants, you get a file that is byte-for-byte plausible and refuses to open anywhere.

The quantizer: median cut and Floyd–Steinberg

Two classic algorithms, both about thirty lines.

Median cut builds the palette. Put every pixel in one box. Repeatedly take the box with the widest spread, find which channel it spreads on most, sort by that channel, split at the median. Stop at your colour count. Average each box to get its palette entry.

It’s better than it sounds because it spends palette entries where the image actually has variation, rather than spreading them evenly across a colour space the image never visits.

Floyd–Steinberg dithering handles the error. When a pixel’s true colour isn’t in the palette, you pick the nearest and you’re left with a difference. Throw it away and smooth gradients turn into visible bands. Instead, push that error onto the neighbours that haven’t been processed yet:

errCur[e + 3]  += er * 7 / 16;   // pixel to the right
errNext[e - 3] += er * 3 / 16;   // below-left
errNext[e]     += er * 5 / 16;   // directly below
errNext[e + 3] += er * 1 / 16;   // below-right

Those four fractions are from 1976 and they still work. The error gets scattered into a fine pattern your eye averages back out, and banding disappears.

Does it actually work?

Numbers from the test suite, on real files:

The graphic came out with a mean per-pixel difference of 0.00 — mathematically identical output, 24% smaller. The photograph averaged 8.96 per channel, which is invisible at normal viewing size but is a real loss, and worth being honest about: palette quantization is lossy on photographs. Photos should generally be WebP or JPEG anyway.

Trap 4: SVGs are 300×150

Draw an SVG to a canvas and you may get a 300×150 image regardless of its viewBox. That’s the CSS default replaced-element size, and it applies whenever the SVG has no explicit width and height.

The fix is to parse the viewBox, strip any existing dimensions, and inject real ones before rasterising:

const vb = /viewBoxs*=s*["']s*([d.-]+)[s,]+([d.-]+)[s,]+([d.-]+)[s,]+([d.-]+)/i.exec(tag);
let w = 1024, h = 1024;
if (vb) {
  const vw = parseFloat(vb[3]), vh = parseFloat(vb[4]);
  if (vw > 0 && vh > 0) { w = 1024; h = Math.round(1024 * vh / vw); }
}

Testing binary output

Unit-testing “did the conversion work” is harder than it looks, because a file can be the right size, the right type, and still be wrong.

What worked: drive the real pages in headless Chromium with Playwright, then verify the bytes in Python. Pillow checks dimensions, colour mode and how many palette entries were actually used. pypdf checks page counts and sizes. zipfile verifies archive integrity. Rotation and flipping get compared pixel-wise against Pillow’s own implementations.

That combination caught the SVG bug, the toBlob fallback, and a filter-byte mistake that produced a file every viewer opened happily at the wrong dimensions.

What a browser still can’t do

Worth stating plainly, because “it all runs client-side” can sound like a claim that it does everything:

• No HEIC, RAW, PSD or TIFF decoding. Browsers can’t, and shipping a WASM decoder for each would outweigh the entire project. If you need those, a server is the right answer.
• Big files depend on the device. A 100-megapixel image on an old phone is slow where a server would be instant.
• AVIF encoding only exists where the browser supports it — which is exactly why trap 1 matters.

What you get in exchange: nothing is uploaded, there’s no queue, there’s no file size limit set by someone’s bandwidth bill, and the page keeps working with the network switched off.

Code

It’s all MIT licensed and dependency-free — one JavaScript file for the engine, one Python script that generates the site: github.com/shaam130/ConvertPicto

The running version is at convertpicto.com if you want to try breaking it. I’d genuinely like to hear about the files it fails on.

I recently released InfoHUD Pro, a Windows utility designed to keep important information visible while you work.

It lets you create floating desktop HUDs for:

Text · Excel · Word · Charts · Images · Screenshots · Web Pages · PDFs

You can open multiple HUDs at the same time, keep them always on top, move and resize them, lock their positions, or hide/show everything with one click.

It’s especially useful for dual-monitor and multi-monitor setups.

Windows 10 / 11
English / Traditional Chinese / Simplified Chinese
7-day free trial

Microsoft Store:
https://apps.microsoft.com/detail/9nkf1rh8xck4?hl=en-US&gl=US

I’m continuing to improve it, so feedback and suggestions are welcome.

More products on Microsoft Store:

https://apps.microsoft.com/search/publisher?name=AdamYang&hl=en-US&gl=US

The agent layer: Claude Code, Codex, Cursor. The thing that writes code. Two years ago this layer did not exist; today it is where implementation happens.

The context layer: CLAUDE.md, AGENTS.md, rules files, memory systems. Telling agents how your repository works, what your conventions are, what not to touch. Everyone who onboarded an agent wrote these within a week, because an agent without context is a very fast junior with amnesia.

The tool layer: MCP. Agents reaching databases, browsers, issue trackers, deployment systems. Adopted fast because an agent that cannot touch your systems can only talk about them.

The isolation layer: git worktrees, containers, cloud sandboxes. One agent per checkout, because two sessions in one working directory stomp each other’s files and poison each other’s context. Anyone who ran two agents learned this in the first afternoon.

The orchestration layer: Gas Town, claude-squad, Foreman, and a fast-growing ecosystem of fleet runners. Who works on what, which sessions are alive, what needs review. The moment you run more than two or three agents, supervision becomes its own job, and this layer takes it.

Each of these layers got adopted quickly for the same reason: its absence hurts immediately and obviously. No context, the agent writes nonsense today. No isolation, files get stomped today. No orchestration, you lose track of your fleet today.

There is one more layer, and almost nobody runs it, because its absence hurts silently.

The failure that announces nothing

Two agents, one repository. Agent A is told to replace PaymentService with a Stripe-specific implementation. Agent B is told to add PayPal support to PaymentService. Run the failure through every layer you have adopted.

The agent layer performs perfectly: both sessions write competent code. The context layer performs: both followed your conventions. The tool layer performs: every MCP call succeeded. The isolation layer performs: separate worktrees, no stomped files. The orchestration layer performs: two independent tasks, both completed, both green.

Git merges both branches without a conflict, because the changes touch different lines. And the design is now broken: agent B built on an extension point agent A deleted. Nothing in the toolchain objected at any moment, because every layer you have answers a different question, and none of them answer this one: can these two plans coexist?

Git compares diffs, and there is no diff at the moment this collision actually happens. The collision is between intentions, at plan time, before either agent has written a line. We hit versions of this for months. The one that finally made us build tooling surfaced three days after a clean merge, in production.

The coordination layer

The missing layer answers exactly one question: can the work currently in flight all be true at once?

To be precise about what it does not do: it does not create plans. Your agents plan however they already plan. The coordination layer is a ledger and a referee, not a planner. Each agent declares what it is about to change before writing code: a semantic scope plus an operation, like symbol:PaymentService=replace. Scopes are not file paths, because file paths miss API, schema, configuration, and cross-language collisions. Deterministic rules compare the declarations and raise a finding while both sides are still plans: the rule that fired, an explanation, a suggested resolution. In the PaymentService case, one destructive operation and one additive operation on the same scope cannot both be true, and the second agent learns this in the same call that published its intent.

The other half of the layer is evidence. When work finishes, acceptance is gated on a verification command the layer executes itself against the exact fingerprint of the candidate change. An agent reporting that tests pass is provenance, not proof. If the tree changed after validation, the attempt does not count.

What building one taught us

Three lessons, each paid for.

First: declared beats inferred. We started by inferring operations from agent prose, and it produced confident false alarms. “Delete the flaky ThumbnailCache benchmark test” was read as destroying ThumbnailCache itself. Widening the verb list just moved the boundary. Making agents declare the operation as structured syntax removed the whole error class.

Second: advisory beats locks, but severity must be earned. Most overlaps between agents are compatible, and a lock serializes work that did not need serializing; the moment a lock exists, a busy repo becomes a queue. So claims warn instead of block. The discipline that makes warnings survivable is reserving HIGH for two declarations that genuinely cannot both be true. Our repo carries a regression fixture that fails the build if compatible work ever raises a HIGH.

Third: soft claims, hard gate. Everything before the finish line is advisory, because the finish line is not: no acceptance while an unresolved HIGH finding stands, and no acceptance on self-reported evidence. The gate staying hard is what lets everything before it stay soft.

Do you need this layer?

If you run one coding agent, no. Close the tab, you are fine.

If you run two or more on the same repository, whether in parallel today or sequentially across days, you have already had the silent version of this failure whether you noticed it or not. The tell: a change that made you say “wait, when did that class stop existing?” three days after a clean merge.

We open-sourced the coordination layer we built and use: Foremerge (https://github.com/naw103/foremerge), Apache-2.0, one Rust binary, local-first, above Git rather than inside it. Setup is one paste into Claude Code, Codex, or Cursor. Stated plainly per the honesty its own docs demand: detection is deterministic but heuristic and can warn on compatible work, claims never lock anything, and there are no published benchmarks yet, so no performance claims. The layer matters regardless of whose implementation you run, including one you build yourself.

The stack grew five layers in two years because each one’s absence hurt the day you needed it. The sixth one’s absence hurts three days later. That is the only reason you are probably missing it.

Foremerge
The open-source coordination protocol for parallel coding agents, built above Git. Agents declare intent and semantic scopes before writing code, so plans that cannot both be true collide in a queryable store instead of in your merge. One Rust binary, Apache-2.0, local-first.

curl -fsSL https://foremerge.com/install.sh | sh

Imagine this scenario, someone on your team gets offboarded while their AI agent is still mid-task. Nobody remembers the agent is even running. It’s just doing what it was told, on behalf of someone who, as of a minute ago, doesn’t work at your company or on your team anymore.

Does it stop?

Well, I built a small app to test that scenario, using Kinde to handle sign-in and to hold the record of who’s still active. I signed a real user in, handed their agent a task, and while the agent was still working through it, suspended that same user, in Kinde’s dashboard, mid-run, to see what the agent would do next.

Unsurprisingly, the agent kept working on the task.

You see, suspending or deleting a person changes how Kinde itself sees that user, but it doesn’t touch the access token their agent is already holding, because nothing about a suspension reaches back into a token that was already signed and handed out before it happened. The token still verifies exactly as it did before the suspension, so the agent has no way to know anything changed.

Everything I am going to talk about in this article is about closing that gap, and about what I actually found while doing it: webhook deliveries measured live, a production bug that could have left an offboarded user’s record looking active forever, and a hard number for how long an offboarded person’s agent keeps acting before anything catches it.

Why a suspended user’s token still works

Let’s start with what an access token actually is, because the whole gap follows from it. An OAuth access token isn’t a receipt you hand back to check against a ledger. It’s a signed claim, a small JSON payload with a cryptographic signature attached, and whatever’s checking it just verifies that signature against a public key rather than calling home to ask if the token’s still good. That’s the entire appeal of the design: an API can confirm a token is genuine without a database round trip on every request.

Which means suspending a user in Kinde only changes a row in Kinde’s own database. It doesn’t reach the token at all, because there’s nothing there for it to reach: the token was already handed out, already signed, already valid until whatever expiry it was minted with. Revoking it properly would mean tracking every issued token in a lookup table somewhere, which throws away the entire point of signing one in the first place, or it would mean just waiting for the thing to expire on its own.

I suspended a signed-in test user mid-session, and the app’s own check kept reporting that user’s access token as valid, seconds after Kinde had already suspended them.

So that gap isn’t a bug in Kinde, and it isn’t a bug in OAuth either. It’s just what a stateless credential is, by design, and the real question is what you build on top of it.

The shape of the fix

Two pieces close the gap. A webhook tells the app when Kinde’s view of a user changes, and a check runs before every single agent action, reading the app’s own record of that user instead of trusting whatever was true when the session started.

The agent itself is a small Claude Messages API loop, working through a closed set of three tools against a demo set of internal resources: list_resources, read_resource, write_resource. None of what follows is specific to what the agent does. It’s specific to the one place every tool call has to pass through before it’s allowed to run at all.

Building the seam

First, we start with the registry that defines those three actions, because it’s closed by construction rather than by convention. An action that isn’t in this table doesn’t half-exist somewhere in the code, waiting to be called by accident. It just doesn’t exist:

export const ACTION_REGISTRY: Record<ActionName, ActionDefinition> = {
  list_resources: { name: "list_resources", destructive: false, params: {} },
  read_resource: {
    name: "read_resource",
    destructive: false,
    params: { resourceId: { type: "string", required: true } },
  },
  write_resource: {
    name: "write_resource",
    destructive: true,
    params: {
      resourceId: { type: "string", required: true },
      title: { type: "string", required: false },
      body: { type: "string", required: false },
    },
  },
};

Both the tool schema handed to Claude and the enforcement check are built from this same table, so the two can never quietly drift apart from each other the way a schema and a permissions list usually do once someone forgets to update one of them.

Every tool call the model makes passes through a single function, enforceToolCall, which looks up the acting user’s current status and hands it to a small, pure decision function underneath it:

export function decideAccess(input: {
  mode: EnforcementMode;
  userStatus: UserStatus;
}): { decision: SeamDecision; reason: SeamReason } {
  if (input.mode === "naive") {
    return { decision: "allow", reason: "naive_mode_no_check" };
  }
  if (input.userStatus === "active") {
    return { decision: "allow", reason: "user_active" };
  }
  if (input.userStatus === "offboarded") {
    return { decision: "refuse", reason: "user_offboarded" };
  }
  return { decision: "refuse", reason: "user_unknown" };
}

Naive mode allows every call without ever looking at that status, which is the vulnerability this whole piece is about, reproduced on purpose so both modes can run side by side against the exact same code and prove the point cleanly. Enforced mode is stricter in a way that matters: it allows exactly one case, a confirmed active user, and refuses everything else, including a status the seam couldn’t even resolve because a read to Convex failed. An unknown status doesn’t get the benefit of the doubt.

That status comes from a webhook. Kinde sends a signed event on user.updated and user.deleted, the receiver verifies the signature, and then it does one more thing that has nothing to do with the signature at all:

export function isFreshWebhookEvent(
  event: WebhookEvent,
  now: number = Date.now(),
): boolean {
  const eventTime = Date.parse(event.timestamp);
  if (Number.isNaN(eventTime)) return false;
  return Math.abs(now - eventTime) <= MAX_CLOCK_SKEW_MS;
}

A valid signature only proves Kinde signed this payload at some point. It says nothing about when that was, so without this check, a captured event replayed months later would sail straight past signature verification, since the signature itself never expires, and past deduplication too, because dedup only catches an event id it’s already seen before. MAX_CLOCK_SKEW_MS is five minutes. Anything older than that gets rejected the same way a forged signature would.

The bug the build actually found

Hardening this receiver turned up a real ordering bug. The first version recorded the webhook’s delivery, for deduplication, before it applied the actual effect of marking the user offboarded. That ordering has a quiet failure mode: if the effect write failed right after the delivery had already been logged, a retried webhook would look like a duplicate of one already handled and get skipped. The user would never actually get offboarded, and nothing about the system would ever try again.

The fix took one line of reordering, but it only works because of one property underneath it: the effect, markOffboarded, is idempotent, so running it twice is always safe. That’s why it now runs first, unconditionally, ahead of the bookkeeping whose entire job is to stop it from running a third or fourth time. Recording the delivery first and applying the effect second felt like the more natural order to write. It was also the less safe one.

Proving it, live

scripts/e2e-narrative.ts runs one task against one real Kinde test user, twice: once with the seam in naive mode, once enforced, suspending that same user for real, mid-run, both times. Nothing in this script is simulated. It drives a real agent loop, fires a real suspend call at Kinde, and waits on the actual webhook to arrive over a tunnel before it checks what actually happened.

The same story shows up in the operator console, so I ran it once more while writing this, offboarding the signed-in user on purpose partway through a task:

Step one lands while the user’s still active. The offboard request goes out. Step two refuses, user_offboarded, with a cutoff latency of 2697ms measured from when the offboarding itself landed in the database, not from when the run started. Every one of those decisions lands in an audit log under a shared correlation id, so a run’s full timeline can be pulled back up after the fact, not just watched live:

The numbers that matter more than the demo

Across every live webhook delivery in this build, latency ran from 652ms to 2058ms, across suspends, restores, deletes, and role changes alike. That’s not instant. Most people assume it is.

The enforcement check itself doesn’t belong anywhere in that number. It’s one indexed read against Convex, and next to webhook delivery it’s close enough to free that it doesn’t move the total.

So the more honest way to describe total revocation speed is this: it’s webhook delivery latency, plus however long until the agent gets around to its next real action, and that second part isn’t a fixed system number at all. An agent moving faster, with no artificial pacing between steps or several tool calls requested in the same turn, gets caught just as fast on its very next call, without any extra mechanism needed to catch it sooner. The floor here is roughly one model round trip, not the enforcement check sitting underneath it.

A webhook can also be missed or delayed, because that’s what “best-effort delivery” actually means in practice, so I built a reconciliation sweep on top: a cron job checking every active user’s live status directly against Kinde every five minutes. I tested it against a forced scenario: suspended a real user, then manually pushed the app’s own record back to active, simulating a webhook that never arrived at all. The cron caught the drift and corrected it on its own, before I ever triggered a manual run.

Here’s what I think

“Revocation” is the wrong word for what any of this does, and I think that matters more than it sounds like it should. Nothing here revokes anything. What actually happens is a live check gets bolted on top of a credential that was never revocable to begin with, and I’d rather describe it that way than pretend otherwise, because that’s closer to what every system in this space is doing under the hood, whatever the marketing copy on top of it calls it.

I’d also argue this check shouldn’t be the thing you bolt on during a hardening pass once the demo already works, which is exactly the order it happened in during this build. The seam existed early on, but the reconciliation backstop and the timestamp check both came later, as production polish, and I think that ordering is backwards for anything that runs unattended. A browser session gets re-validated more or less by accident, on every page load, because there’s a human sitting there generating new requests the whole time. An agent loop doesn’t get that for free. It holds one credential, validated once at the start, and then it acts on that credential in a loop nobody’s watching in real time. If the check isn’t built into that loop from the first line, there’s no accident later that adds it back in.

The usual objection to this is cost: a database read on every single tool call sounds expensive once an agent’s task means dozens of calls instead of one. But this build’s own numbers say that objection doesn’t hold up, at least not with an indexed lookup like the one here. The check disappears next to webhook latency, and webhook latency itself disappears next to how long a person actually takes to notice someone’s gone and go click suspend. The genuinely expensive part of this whole system is the five to fifteen minutes between someone walking out the door and someone else noticing. Nobody optimizes for that number, even though it’s the one that actually decides how exposed you are.

What this doesn’t solve

The token-still-valid gap from the top of this piece is real, and nothing here closes it. This build works around it, by checking liveness on every call, instead of trying to make the token itself stop working. A system that actually needs the token revoked needs a different mechanism entirely, like short-lived tokens or an introspection endpoint hit on every use, and both of those trade away the exact stateless-verification benefit that made a signed token worth using in the first place.

The reconciliation sweep is a five-minute backstop, not the primary path, and if the webhook’s doing its job, the sweep never finds anything to correct.

runs.timeline, runs.get, and the audit queries in this build are also unauthenticated Convex reads. A run id or a correlation id is enough on its own to read that run’s whole timeline, which is fine for a single-user demo console and not fine at all for anything with untrusted users in it.

And the action registry here covers exactly three read and write actions on a demo resource. That’s enough to prove the pattern holds. It’s nowhere near enough to prove the pattern scales to a real authorization model with real permission boundaries between real resources.

Where this leaves the agent

Back to the opening scene: someone gets offboarded, and their agent is mid-task. Whether its next few tool calls go through was never actually a question about the token. The token was always going to keep working right up until it expired on its own, offboarding or not, because that’s just what it is. The real question was always whether anything standing between the agent and the action it’s about to take bothered to check, right then, whether the person behind it was still around.

Code and sources

The full build, the enforcement seam, the webhook handler, the reconciliation cron, and scripts/e2e-narrative.ts, is on GitHub: sholajegede/offboarding-revocation-demo.

The webhook signing and delivery model comes from Kinde’s own webhooks documentation, and the suspend and restore actions used throughout the demo follow Kinde’s Management API and its notes on suspending and deleting users.

The reconciliation sweep runs on Convex’s cron jobs, and the agent loop follows Anthropic’s tool use documentation for the Messages API. Every number in this piece came from runs.timeline and auditLog in that same Convex deployment, read straight off the live runs.

Clone it, wire it up against your own Kinde tenant, and offboard a test user mid-run. Your webhook latency might not match mine, your reconciliation sweep could catch different drift, and that’s the point really. Drop your numbers in the comments and let me know what you find.

codsh is a DeepSeek-native terminal coding agent on open dsh. It is not a Claude Code env wrapper.

The hook stays the same: /ship takes one sentence to verified code.

0.23.0 ships the Mission Contract control plane for that loop — so acceptance criteria stay sealed, drift blocks the run instead of rewriting the goal, and delivery needs recorded evidence.

What changed in 0.23.0

When Gate 1 confirms the spec, /ship compiles a machine-checkable Mission Contract (mission.contract.json) from the sealed Main Track, Out of Scope, and acceptance criteria.

After seal:

• Immutable — Main Track, Out of Scope, grill decisions, original wording, acceptance criteria, and the contract JSON. Protected writes are refused; external drift stops the run and stays on disk for inspection.
• Alignment Gate — refuses writes that lack requirement mapping or hit immutable memory.
• Drift Detector — scores plan/action drift against the seal; a rewritten Main Track is a blocker, not an accepted rewrite.
• Verifier — matches acceptance criteria to recorded evidence. Delivery does not complete without it.

Also in this release: wayfinder before the grill interview (destination + open decisions, separate from implementation), and tighter parent/subagent coordination — one parent-owned ticket per turn, fresh-context children for investigation / landing / review, parent keeps questions, gates, and final proofs.

npm: codsh-cli + codsh-bundle 0.23.0.

Why this matters vs “just chat a plan”

Ad-hoc agent plans live in conversation memory. They drift. Acceptance becomes vibes.

/ship keeps the human projection in Markdown and the runner-owned contract on disk:

1. Pre-flight → wayfinder → grill
2. Spec (Gate 1) → Tickets (Gate 2)
3. Landing (TDD) → evidence-based Done

While work is in flight you get a panorama: TTY overlay (Ctrl+G), a ticket-count teaser with the local Web flowchart URL, and the flowchart itself — /ship does not auto-open a browser.

Coming from Claude Code / Codex? Different harness, different product. Redirecting Claude Code at DeepSeek with env vars works; this is the native path on dsh. Map what maps / what’s missing on issue #64.

What /ship builds (gallery)

Every gallery project started from a one-sentence request. Real screenshots and playable results: blackman99.github.io/codsh/gallery.html

(Publishing: upload local PNGs from /workspace/codsh-assets/gallery-0.23.0/ as cover + inline if Dev.to prefers hosted uploads.)

Install (60 seconds)

npm install -g @deepseek-ai/dsh codsh-cli
export DEEPSEEK_API_KEY=…   # or any OpenAI-compatible route via ~/.dsh/settings.yaml
codsh

Node ≥22.19. Already on a matching dsh? npm i -g codsh-cli is enough.

Then:

/ship let long diffs open in a pager instead of scrolling past

For tiny edits, plain chat or ⇧Tab plan mode is enough — /ship is multi-phase and burns tokens on purpose.

Links

• Repo: https://github.com/Blackman99/codsh
• Site (real terminal captures): https://blackman99.github.io/codsh/
• Gallery: https://blackman99.github.io/codsh/gallery.html
• npm: codsh-cli · codsh-bundle (MIT)
• Claude Code / Codex migrants: https://github.com/Blackman99/codsh/issues/64

Early project. Sharp edges welcome — especially Windows (#62) and third-party endpoints (#63).

Three days later, in the morning, I was chasing a different problem and noticed something. The over-engineering that shows up in my own repositories was happening in the Opus sessions — the ones that picked up design work after Fable’s usage limit ran out.

Those two are the first and second half of the same event. When you make the top model your session default, the first thing that breaks is not the work product but the usage limit, and once the limit is gone, judgment itself drops to a lower model. This article is a record of which paths the default leaked into, why a convention and a warning failed to stop it, what did stop it, and what fell once the limit was gone.

Setup: three models across three tiers

I use Claude Code on a subscription plan (Max) and split three models by role. Fable, the top model, does judgment — checking premises, planning, acceptance. Below it, Opus does implementation, and I hand that work to a new session. Mechanical cross-checking goes to Sonnet. On my plan, Fable’s usage limit is separate from Opus’s, so Opus still works after Fable runs out. From here on I call the judgment side the judge tier and the implementation side the build tier (in my config files they are literally judge-tier and build-tier). My settings.json default model is fable, and I wrote up the division of labor for handing implementation off in an earlier article.

Since the start of August, every subagent I wrote myself carries a model: line. Writing the model into the definition file to fix it is what I call pinning below. The 11 files in ~/.claude/agents/*.md break down as fable 1 / opus 4 / sonnet 5 / haiku 1 as of September 16, the day I started writing this. A lint rejects any I forget.

I thought that was enough to have the tiers in place.

The default leaks into paths you cannot pin

What leaked on the day the limit ran out were /code-review and /simplify. Both ship with Claude Code, take no model argument, and run on the session’s model. Call them from a Fable session and they run on Fable. That is how the limit arrived in an instant.

There are other leak paths: the built-in subagents, which have no frontmatter. Counting my own log (~/.claude/metrics/agent-usage.jsonl), over the three weeks from installing the review hook described below to writing this article, 576 agent launches included 373 built-ins — general-purpose 231, Explore 121, Plan 10, claude-code-guide 11 — or 65%. Writing model: into my own agents does not reach two thirds of the launches. (claude-code-guide is fixed to Haiku, so the count that can inherit the session model is 362, or 63%.) The log does not record the model, so I cannot say how many of those ran on Fable. It was a hole I only noticed by counting, and I closed most of it while writing this article. What I closed it with is at the end.

Per the official documentation (as of September 16, 2026), a subagent’s model is resolved in this order: the model named at call time, the model: in the definition, the CLAUDE_CODE_SUBAGENT_MODEL environment variable, then the session’s model. Explore inherits the session model but caps at Opus; general-purpose and Plan inherit with no cap. So if the caller names no model and the environment variable is unset, every general-purpose a Fable session launches is Fable. Setting the variable changes general-purpose only; Explore and Plan do not move.

I fell into the same mechanism back in February. At the time, --model opus applied only to the main loop, and my subagents ran on Haiku, which I had not intended (the article from back then; the behavior has changed since). In February it leaked below what I intended, this time above it. Inheritance defaults leak in both directions.

The same report shows up in public issues. #76514, from July 10, says that omitting the per-agent model propagates Fable to every subagent; it was closed as not planned. #93894, from September 12, says that one run of /code-review high on Fable 5.1 exhausts the session budget and the review never finishes; it is still open.

The convention did not stop it, and neither did the warning

My fix on the day the limit ran out was a convention. I added a step at the end of every implementation plan — decide in one line whether this session implements — and made heavy implementation go to a new Opus session. I rejected enforcing it with a hook, because that would bury the policy inside the hook.

Two days later, at night, I typed this (my own words, translated):

…I put in a convention where Fable handles design and opus does the implementation, but it isn’t really being followed. Implementation is one thing, but when review runs straight afterwards — simplify and code-review especially — it wastes a serious amount of tokens….

So I added a hook. The first version was an advisory: warn when a review is launched in a Fable session. What I learned the next morning is that an advisory gets read after the review has already run. Seeing the warning, stopping, and re-running the review on Opus means paying twice — once for Fable, once for Opus.

That same morning I rewrote review-model-notice.sh. What I had rejected first was burying policy in a hook. What went into the hook this time is only a mechanical test — skill name crossed with session model — while the policy of which model does what stays on the rules side. The response is split by path.

# ~/.claude/hooks/review-model-notice.sh (excerpt, abridged)
# Split the response by path:
#   Direct skill call (code-review / simplify) -> **block**. The test is purely
#     mechanical (skill name x session model) with no room for a false positive,
#     and as an advisory the skill runs in the same turn and burns judge-tier
#     tokens before the advice is ever read (measured — stopping and re-running
#     the review on Opus meant paying twice). Only a block before execution works.
#   Agent/Task launch with a missing model pin -> stay at advisory. Partial
#     prompt matching is a heuristic and can produce false positives, so it does
#     not get deny authority.

The session’s model is not in the hook payload. It reads the most recent "model" from the tail of the transcript, and stays silent if it cannot read one.

model=$(tail -c 2000000 "$T" 2>/dev/null | grep -o '"model" *: *"[^"]*"' | tail -n 1) || true
case "$model" in
  *fable*) ;;
  *) exit 0 ;;
esac
# ...(compose the block / advisory text)
if [[ "$mode" == "block" ]]; then
  jq -cn --arg reason "$msg" '{decision:"block", reason:$reason}'
  exit 0
fi

A model that reads the block reason switches itself over to Agent(subagent_type: "general-purpose", model: "opus"). No human has to stop it and retype the command.

What broke was the budget, then the judgment

The same morning, in another conversation, I was talking about over-engineering. Just before that I had simplified my weekly-report machinery heavily, cutting thousands of lines of code. I typed this:

A fair amount of the over-engineering happens on opus, after fable’s usage limit is past

The real problem is that this happens because Fable gets wasted on implementation and review, the usage limit runs past, and I’m forced to make Opus the orchestrator.

Making the top model your default breaks the budget first. But that budget was there to buy the judge tier’s model. When it runs out, the judge tier drops to Opus, and the dropped judge tier waves over-engineering through. Putting the top model in the “default” slot works to push it out of the “judge tier” slot. Up to here this is an impression from a handful of cases; I have not counted how many times Opus’s judgment let over-engineering through.

So I reversed the direction in which I plug the leaks. The session default stays at the top model; the paths from the default to the judge tier stay open, and the paths that leak from the default to anything else get cut. The judge tier gets pinned. The architect agent, which decides whether a thing should be built at all, has been the only model: fable in my environment from that day through September 16.

It still ran out every weekend

Three days later, on Friday, I typed this:

Fable’s usage limit always runs out on Saturdays, Sundays and holidays, which is when I use it most. After it’s gone Opus does the design, and I really do feel Fable’s absence. I want it focused on design and planning, where Fable is strong, and everything else delegated to other models. Even now it’s supposed to delegate to Opus when it can, but a lot of the time Fable just goes ahead and implements.

I had plugged the review path, but implementation itself was running on Fable. My first convention had an escape hatch — if the conditions are not met, this session may implement — and the model itself was making that call.

I changed three things the same day.

1. Inverting the default. The default for “does this session implement” became “hand it to Opus.” I may implement in place only when I write one line in the plan naming one of three things: prose edits to design documents (decision records such as ADRs), a concrete reason the work cannot be handed off, or an explicit instruction from the user. Accountability moved from the side that hands off to the side that does not
2. A hook right after plan approval. A PostToolUse on ExitPlanMode reminds Fable sessions, and only Fable sessions, to decide the executor. It fires before the first implementation Edit, the latest safe position available
3. One line in the resident rules. So that it reaches implementation that never passes through plan mode, I wrote into my rules: “implementation in a judge-tier session defaults to dispatch to the build tier.” One line saying a judge-tier session does not implement; it hands the work to a build-tier session

The hook in (2) has a condition for staying quiet: if the plan body already contains the set phrase “executor decision,” it says nothing. At first I also had general words like dispatch and spawn-session in the suppression list. Running that against 271 past ExitPlanMode calls suppressed 31, and 30 of the 31 were false suppressions. A plan that merely mentions handing implementation off — that is, a session doing nothing but routing tasks, exactly where I most want the hook to fire — would go quiet. I narrowed the suppression list to the single set phrase and put “a plan that only mentions dispatch still fires” into the regression tests. Putting only mechanically decidable conditions into the machinery is the same call I made with the review hook.

In the three weeks since, there is no report in my session logs of the usage limit running out. That is the absence of a report, not a record of measured headroom. I still have nothing in my environment that mechanically records how much of the usage limit is left. I also have not looked at whether reviews that ran on Fable were catching anything Opus misses. What I can say goes as far as this: I have not had to write that same report again.

Four decision rules

If you run a similar setup, these four are what you can take away.

Don’t leave the tiers to the default; pin the judge tier and plug the paths that leak. My session default is still fable. What I changed is not the default but the paths the default flows into. It leaks into built-in skills, built-in subagents, and the session’s own implementation, and a model: in my own agent definitions reaches none of those three.

Fill in the built-in subagent defaults with the environment variable and same-named definitions. Setting CLAUDE_CODE_SUBAGENT_MODEL=opus changes the default for general-purpose. Explore and Plan do not move on that variable alone: either fix everything to one model with CLAUDE_CODE_SUBAGENT_MODEL_FORCE=1, or place a same-named agent definition carrying a model:. While writing this article I set the environment variable to opus and gave Explore a same-named definition on sonnet. Of the 362 launches above, what remains is Plan’s 10.

Block when the test is mechanical, advise when it is a heuristic. Skill name crossed with session model produces no false positives, so it gets stopped before execution. Anything you can only test by partial prompt matching stays a warning. Advice that arrives after execution does not protect a budget.

Invert the default of a convention. Most “conventions nobody follows” put no accountability on the side that does not follow them. Put the default on the handing-off side, and you have to write down your reason for not handing off.

I wrote expiry conditions for this wiring. It comes out if model tier distinctions and usage limits disappear, or if Claude Code starts switching models per session on its own. opusplan (plan on opus, execution on sonnet) already exists, so once a version that drops from fable to opus arrives, the hook is unnecessary.

Sources

• Create custom subagents – Claude Code Docs — the model resolution order, Explore’s cap, CLAUDE_CODE_SUBAGENT_MODEL_FORCE (retrieved 2026-09-16)
• Model configuration – Claude Code Docs — opusplan, CLAUDE_CODE_SUBAGENT_MODEL (retrieved 2026-09-16)
• anthropics/claude-code #76514 — subagents in a Fable session all inherit Fable (2026-07-10, closed as not planned)
• anthropics/claude-code #93894 — one /code-review high on Fable 5.1 exhausts the session budget (2026-09-12, open)

Related links

• I Handed 41 Tasks to an AI Loop. The Bottleneck Was Judgment, Not Code — how the split of judgment to Fable and implementation to Opus came about
• I Tried an Opus Orchestrator and Killed It: The ROI of Multi-Agent Systems — the February record of falling through the same inheritance default, in the downward direction
• I Cut My AI Review Chain From 6 Stages to 1: Breaking the Loop That Never Hits Zero Findings — cutting the number of review stages, on the same morning I noticed the advisory hook’s double payment
• The Markdown source of this article (GitHub) — the Markdown for every article, plus the index (docs/PUBLICATIONS.md), lives in the same repository
• My GitHub — my research repositories, with DOIs
• claude-harness — the public mirror of this article’s hook, hooks/review-model-notice.sh, and its tests

I got an answer, but not to the question I asked. Before you can ask what makes a post do well, you have to know what a normal post looks like, and it turns out almost nobody knows, including me, because the version of dev.to you read is not the one you publish into.

Two websites wearing the same logo

The feed at dev.to is curated. I pulled 2,500 posts from it and looked at the ones published in August, so everything had at least a fortnight to collect reactions. In that sample of 170 posts, the median post had 15 reactions, 70.6% of them had ten or more, and the mean was 28.8. Exactly zero of them had no reactions at all.

Then I sampled the site itself rather than the feed, by picking article IDs at random and fetching each one directly. That gives 460 posts published in August, chosen without any regard for whether anyone liked them. Here is that sample:

Ninety-two per cent of posts, plus or minus about two and a half points at this sample size, get no reaction whatsoever. Not a low number of reactions. None. And 95.7% of them get no comments either.

These are not bad posts. The zero-reaction pile, read at random, looks like this:

0 reactions  Four JavaScript problems I hit writing a chess engine
0 reactions  Delta E is a distance, not a score
0 reactions  How Farm.js compiles React components into direct DOM updates
0 reactions  Why Zod Crashed My Node.js Server

I would read all four of those. They went out into total silence, and the feed I actually see has been quietly filtering them out of my view for as long as I have been posting here.

Getting a fair sample is the hard part

My first attempt was the obvious one. dev.to’s API lets you list articles by tag, so I paged through 39 popular tags and collected 82,749 posts. Then, before trusting any of it, I ran a check: the curated feed’s August posts are popular by construction, so my big corpus ought to contain nearly all of them. It contained 49%.

So I took one missing post, a webdev article with 60 reactions published on 31 August, and walked twelve pages of the webdev tag listing looking for it. It is not there. What is there is stranger:

page 10: newest=2026-08-31  oldest=2026-08-29
page 11: newest=2026-09-13  oldest=2026-08-27
page 12: newest=2026-08-27  oldest=2026-08-18

Page 11 contains posts newer than anything on page 10. The pages overlap, they run backwards and forwards through time, and posts go missing between them. The listing is not an ordered, complete view of a tag, so you cannot page it to build a corpus, which is precisely what I had just spent forty minutes doing.

Worse, the omissions are not random. Comparing my random-ID sample against the tag corpus, the posts the listing gave me averaged 0.40 reactions while the ones it skipped averaged 0.15, and 19.0% of the included posts had at least one reaction against 5.1% of the excluded. Sampling through the listing quietly hands you a rosier site than the real one. My first draft of this post, written off that corpus, said 85% of posts get nothing. The true figure is 92%, and the error was entirely my instrument.

I also checked that a fortnight really is long enough for a post to finish accumulating. Splitting the August posts by age at the time I fetched them, the share getting any reaction was 13.6% at 14-20 days old and 15.0% at 42-48 days, with no trend in between, so nothing meaningful arrives after the first couple of weeks.

What actually correlates with anything

For the finer comparisons I used the large tag corpus, 45,400 August posts, because the random sample is too small to slice. It leans optimistic in absolute terms, for the reason above, but the relative differences between groups are what matter here.

The advice is not all wrong. A cover image goes with 23.7% of posts getting at least one reaction against 11.2% without. Writing in the first person, a title with “I” or “my” in it, goes with 24.7% against 13.9%. Length helps up to a point, with posts of three to seventeen minutes’ reading time doing better than posts under three minutes. Four tags beat one, by 16.0% against 3.5%.

Two pieces of standard advice are simply backwards. Titles beginning with “How” did worse than titles that do not, 12.2% against 15.1%. Listicles, the numbered-list titles, got at least one reaction less often than other posts, 9.5% against 15.0%, though their mean was higher, 0.80 against 0.50, which is the signature of a format that mostly flops and occasionally spikes.

The tag you choose matters more than anything you do to the title. Among tags with at least 300 posts:

Eight hundred posts tagged tech in one month, and not one of them got a single reaction.

And posting more is associated with doing worse per post, not better. Authors publishing one to five posts in August had 23.3% of them get a reaction; authors publishing 21 to 25 had 7.5%. Those high-volume authors are not a curiosity either, they produced 18,386 of the 45,400 posts in the corpus.

The part that undoes most of the above

All of those comparisons share a flaw. If experienced writers with existing followers are also the people who add cover images and write in the first person, then I am measuring the audience, not the technique.

So I ran it again inside each author. For every author with at least four posts in the month, I compared their own posts with a given feature against their own posts without it, then looked at the distribution of those paired differences. If a first-person title genuinely helps, an author’s first-person posts should beat their other posts.

They do not. Across 254 authors, the median paired difference for first-person titles was −0.08 reactions, with a 95% confidence interval of [−0.13, +0.00]. Listicles came out at −0.08, [−0.12, −0.03]. Question-mark titles, −0.08, [−0.14, −0.04]. Colons, 0.00. Every apparent effect from the previous section collapses to nothing, or to very slightly negative, once each writer is compared against themselves.

The honest reading is that the title patterns were never doing the work. They were a marker of which kind of account was posting, and when you hold the account fixed they stop predicting anything. What survives the within-author test is not the phrasing, it is which tag you land in and whether anyone was already reading you.

There was one result I could not explain away, and the sample is small enough that I would not lean on it: the 273 posts carrying dev.to’s new AI-assisted disclosure label averaged 4.06 reactions with 11.0% reaching ten, against 0.48 and 0.7% for everything else. That is either a real effect or, more likely, evidence that the people who bother setting a brand-new metadata field are unusually engaged with the platform to begin with.

Where I sit, since it would be cowardly not to say

My last twenty posts run from 5 to 16 reactions, median 8. Against the random sample, a post with 8 reactions beats 99.6% of dev.to. Sixteen beats everything in a 460-post draw.

That sounded like good news for about ten seconds. What it actually means is that the bar is on the floor: writing something that a handful of people react to puts you in the top half of one per cent, and the median experience of publishing here is being read by nobody at all.

What I got wrong

Twice, in the same afternoon, and both were instrumentation rather than analysis.

The first fetch piped its progress through tail, which buffers, so I watched an empty log for twenty minutes and assumed it had hung. It had not; it had collected 20,596 posts and was holding them in memory to write at the end. I killed it and lost all of them.

The second is the one that would have ruined the post. I had a complete-looking corpus of 82,749 posts and a headline number, and the only reason I did not publish 85% is that I made myself check the corpus against a list of posts I knew should be in it. If I had skipped that check, everything above would read the same and be wrong by seven percentage points, in the flattering direction. The check took four minutes.

What to take from it

If you write here, the relevant comparison is not the feed. The feed is the top fraction of a per cent, and measuring yourself against it is like judging your running against the people on television.

Pick your tag deliberately, because that is the one input with a large and consistent association. Put a cover image on it. Then stop optimising the title, because within a given author it does not appear to matter, and spend the time on the thing that does: being worth following, so that the next post starts with an audience rather than hoping to find one.

And if you are going to publish numbers about a platform, check your sample against something you already know the answer to. Mine was wrong in the direction that made the story nicer, which is the direction these things usually fail in.

That sentence took me a few months of building to arrive at, and once I had it, most of my tooling decisions stopped being arguments.

This is a walkthrough of the verification layer in a real project of mine: a wellbeing analytics platform with a Next.js core and a Python AI service. Four agent skills, sixteen repository gates, a hook that runs them at edit time, and a narrow mutation testing pilot. Everything here is running code, and I’ll be specific about what each piece does not catch, because that turns out to be the more useful half.

Why conventions in a README don’t survive

Let me start with the failure that convinced me.

My repo has an AGENTS.md saying that .agents/skills/ is the single source of agent instructions. A month earlier, GEMINI.md had said in plain prose: don’t create client-local copies of these skills.

A 3,442-byte partial copy of one skill showed up in .gemini/skills/ anyway. Two weeks later there was still an empty leftover directory next to it.

Here’s the part that matters: .claude/ and .gemini/ are in .gitignore. The copy was invisible in every diff and every code review. Not missed by a reviewer. Invisible to the mechanism of reviewing.

Two copies both claiming to be canonical, drifting apart with nothing comparing them. Prose has no enforcement mechanism. That’s not a discipline problem, it’s a category problem.

Layer 1: a skill tree with exactly one root

Skills are markdown files that tell an agent how to work in this repository; mine cover product invariants, session/branch state, verification, and the gates themselves. The design has four rules.

One canonical location. .agents/skills/ and nowhere else. There is no list of skills in any config file. The canonical set is the directories on disk:

const skillNames = fs
  .readdirSync(SKILLS_ROOT, { withFileTypes: true })
  .filter((entry) => entry.isDirectory())
  .map((entry) => entry.name);

A folder appears, a skill exists. This is why a copy elsewhere is dangerous rather than merely redundant: if the filesystem is the source of truth, any folder with a familiar name becomes a second source of truth.

Routing in the entrypoint. AGENTS.md carries a plain markdown list mapping tasks to skills:

- Verifying, testing, proving a fix, checking readiness, reviewing evidence, or
  about to claim a substantive change is complete →
  `.agents/skills/shalomut-verification/SKILL.md`.

Why bother if some clients discover skills automatically? Because a client with discovery and a human reading the file directly must arrive at the same rules. Discovery changes how a file is found, never what it says.

A reading map inside each skill. Every skill has a How to read this skill section splitting its own sections into “always in force” and “open when this condition holds.” That map, not the entrypoint, decides how much of a skill a task needs. The rule next to it: loading a section is cheap, skipping a rule is not, so when a condition is ambiguous, open the section.

A check that all of the above holds. npm run lint:skills refuses: a skill copy outside the canonical root (including an empty directory named after one), a broken or orphaned link in references/, a ## section the reading map never classifies, and any client entrypoint that routes nowhere.

Layer 2: gates, or how a convention becomes unignorable

A gate is a script that reads the repository and exits non-zero when it finds a violation. Nothing executes. No arguments get fuzzed, no mutants get generated. It reads — not just paths, but anything knowable without running the program: where a repository gets constructed (lint:composition), what a response body contains (lint:error-bodies), whether a document still agrees with the configuration it quotes (lint:doc-numbers).

What actually deserves a gate

This is the decision rule I’d most want to hand to someone starting out, and it took me a while to get right:

The tell that you need a gate: the violation is silent. Tests green, build passing, reviewer sees nothing, and the rule is already broken. If a violation fails the suite anyway, a test is enough and a gate is overhead.

One gate in full

The audit of my repo counted 21 route handlers interpolating a raw error.message into what they sent back. On /api/auth/login that went to anyone. Every one was written by somebody being helpful.

The naive check is a regex for error.message. I wrote that first. It let (error as Error).message straight through, and the audit itself had missed error?.message for the same reason.

So the rule became two rules:

1. a catch in a route handler binds the name error;
2. the argument of NextResponse.json(...) never mentions it.

Rule 1 exists to make rule 2 complete. Refusing the whole identifier makes the spelling irrelevant, and an identifier rule is only as good as the identifier, so rule 1 stops a handler slipping past with catch (e).

The implementation is not a regex either. It’s three passes:

// 1. Strip strings and comments, but KEEP ${...} inside templates.
//    Without stripping, { error: 'Internal error' } fails on its own wording.
//    Stripping templates whole would let `failed: ${error}` through,
//    and that is the leak itself.
export function stripTextAndComments(source) { /* hand-written scanner */ }

// 2. Find the argument region of a literal call by counting parens.
export function argumentRegions(source, call = 'NextResponse.json(') { /* ... */ }

// 3. Only now, a pattern. A property access is fine (`produced.error` is our
//    own field). A spread is not: { ...error } puts the whole thing in the body.
new RegExp(`(?<![\w$])(?<!(?<!\.)\.)${BINDING}\b`).test(readable)

Two places in the codebase used the name error for the product’s own refusal wording. They got renamed rather than exempted. An exemption list is a place the next leak hides.

And the blind spot, stated in the doc comment rather than discovered later: a body assembled into a variable and passed by name goes unnoticed. That gap is accepted, because the alternative is parsing TypeScript in a fitness check and every occurrence the audit found was a literal at the call site. With the follow-up that matters: if that stops being true, this needs a parser, not a wider regular expression.

The shape every gate shares

// scripts/check-<subject>.mjs
/**
 * <The rule. Why it exists — name the actual incident. What this cannot see.>
 */
export function findViolations(source, file) { /* pure, returns string[] */ }

function main() { /* reads files, prints, process.exit(1) */ }
if (process.argv[1] === fileURLToPath(import.meta.url)) main();

Pure exported functions so the test can import them. main() guarded so importing doesn’t run it. And on success, a line saying how much was checked:

Error-body fitness check passed: 47 route handlers, no caught error in a response body.

A silent success is indistinguishable from a check that read nothing.

Wiring, and why every gate has its own test

"lint:error-bodies": "node --test scripts/check-error-bodies.test.mjs && node scripts/check-error-bodies.mjs",
"verify:core": "npm run lint:literals && ... && npm run typecheck && npm test && npm run lint && npm run build"

The gate’s test runs before the gate. That order is the whole point: prove the check can fail, then trust it. A check whose pattern never matches anything is worse than no check, because it manufactures confidence.

Gates that guard the gates

The cheapest way to fix a red gate is to delete it from the chain. So:

lint:gate-inventory refuses:
  - a gate that isn't a step of verify:core
  - a gate missing from the inventory table
  - an inventory row with no gate behind it
  - a lint:* command that doesn't run its own test

Without this, the whole safety system rests on good faith, which means it doesn’t rest on anything.

Same principle inside the skills: the guardrails skill says outright that weakening a check, adding a file to an exemption list or narrowing its scope is a change to the rule, not a fix to the build — do it deliberately, update the doc comment and the tests on both sides. And: never bring a gate’s test in line with current behaviour to make things green. The gate’s test is the record of the rule.

Layer 3: the hook, so the agent hears it now

CI is the record. But CI tells you at 11:00 about something written at 10:00, by which point it’s buried under later edits made on top of it.

.claude/settings.json is the one file under .claude/ that Git tracks — .gitignore un-ignores exactly it:

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Edit|Write|MultiEdit|NotebookEdit",
      "hooks": [{ "type": "command", "command": "node scripts/gate-hook.mjs", "timeout": 90 }]
    }]
  }
}

gate-hook.mjs holds no rules. It takes the path of the file just written, maps it to the gates that could care, and runs those:

const RULES = [
  { gate: 'lint:error-bodies',
    when: (file) => /^src/app/api/.*/route.ts$/.test(file) },
  // ...
];

On refusal it exits with code 2, which feeds stderr back to the agent, and the message points to the relevant skill section and explicitly says not to weaken the check or rewrite its test to make it pass. That last line is defence against the first thing an agent tries.

Three limits, all stated in the file itself:

• 15 of 16 gates are mapped. lint:literals is deliberately out: its Python half needs an interpreter from .venv, and a missing local environment must not read as a violation.
• The mapping is narrow on purpose. A gate that fires on every edit is a gate people learn to wait out.
• It runs in one client only. A rule that lives in a hook doesn’t exist for Copilot, for Gemini, or for a person in a terminal.

One implementation detail worth stealing: the hook runs only the check half of each command, not the node --test half. The first version buried a one-line violation under sixty lines of passing TAP.

Layer 4: tests, and proving the tests are worth anything

Gates check shape. Tests check behaviour. Neither checks whether the tests are any good. That’s mutation testing: deliberately corrupt the code, see whether tests notice. Mine runs on two files — the AI contract validator and the scoring bands — and the full run isn’t a CI gate: the score moves when a function migrates between files or a test file enters the list, which has nothing to do with test strength.

The checks around it keep that number meaningful. lint:mutation-config re-derives tap.testFiles from the repo, because a missing entry doesn’t lower the score honestly — it reports as survived a mutant a real test would have killed. lint:contract-refusals demands a negative-test suite for every contract version; it proves a suite exists, not that it is complete. And when a product rule leaves a mutated file, mutate follows it in the same change, or the rule silently drops out of measurement.

Layer 5: how much checking is enough

This is the part I’d defend hardest, and the part most teams skip.

My verification skill carries a selection matrix: rows are areas a diff touched, cells are the mandatory minimum. The principle: choose the smallest set of checks that proves the changed behaviour, then widen in proportion to risk.

A few rows:

Running everything for a docs edit is the same mistake as running one small test for an auth change. Both look like diligence. Neither is.

One check belongs to no row: typecheck is mandatory for any .ts change. build types only the application graph, lint doesn’t check types at all, and npm test runs through tsx, which strips types without checking them. A green test run tells you nothing about types.

Say what counts as evidence

With an agent this stops being pedantry. Models report affirmatively by default, so the rules are written down:

• Label the context — local, test, or deployed — and never mix them silently.
• npm run dev starts a runtime. It is not evidence.
• A mock MCP server is not proof of real transport, and a wrapper that delegates to the same command is not a second piece of evidence.
• Don’t promise repo-wide mutation coverage. Separate killed / survived / no-coverage / runtime-error.
• verify:core is an && chain: it stops at the first failure. The steps after it did not run — don’t report them as passed.

Every rule carries its incident

The habit I’d transplant into any codebase regardless of AI: each check’s doc comment names what broke, with a date.

• Fonts. Until 2026-08-12 the build downloaded five .woff2 files from a Google host; when a runner got a stale stylesheet, all five 404’d and the build failed with a message mentioning neither fonts nor the network. The same commit built cleanly in the neighbouring job, so the gate had become a coin toss instead of a red light.
• Tenant chokepoint. A context loader recorded the visit from the request rather than the answer, so an administrator reading the only tenant left no audit row at all, and no test failed.

The corollary is a cleanup rule: a rule with no incident behind it is a candidate for deletion. Either it isn’t needed, or nobody remembers what it defends — and the first person it inconveniences will remove it.

What this doesn’t do

• Gates read text. A determined rename or a dynamic call walks around them. They defend against accidental violation, not adversarial.
• Presence checks don’t check agreement. A client adapter passes if it contains the string .agents/skills, even if the surrounding sentence says the opposite. Stated in the code; it stays a review question.
• None of this judges whether an architectural decision is right.
• It costs. Sixteen gates is sixteen scripts plus sixteen tests plus an inventory plus a gate guarding all of it. On a two-week prototype that’s absurd. In a regulated domain where the question is “prove this data couldn’t leak,” it’s the cheapest answer I know.

If you’re starting tomorrow

1. Take the last silent bug you shipped. Write the smallest script that would have refused it. One rule.
2. Give it a test that proves it can fail, and wire the test to run first.
3. Put it in one verify chain with everything else, and put that chain in CI.
4. Write the incident in the doc comment, with the date, and write down what the check can’t see.
5. Only then hook it into your agent’s edit loop, so the refusal arrives while the context is still warm.

Steps 1 through 4 work with no AI involved at all. Step 5 is just the feedback arriving earlier. That ordering is deliberate: the reason any of this holds is that the rules live where every client and every human reads them, and the agent integration is the last mile rather than the foundation.

Cloud-based recovery is becoming the default way Windows 11 recovers a machine that won’t boot, and almost nobody signed off on the dependency that creates. Local recovery media was never the preferred repair path. It was the path that worked when every preferred path had already failed — no network, no identity provider, no vendor cloud, nothing that depended on the thing that just broke. That property is what’s disappearing, not the USB drive itself.

What Changed

Microsoft’s Cloud Rebuild feature moved from the Experimental Insider channel to Beta on September 9, 2026 (Build 26220.9343) — the clearest signal yet that this is headed toward general availability on a normal timeline, not sitting as a permanent preview curiosity. It runs from the Windows Recovery Environment (WinRE), reformats the system disk, and pulls a fresh Windows 11 image plus current drivers directly from Windows Update. No USB flash drive. No DVD. No dependency on a recovery partition surviving whatever failure triggered the rebuild in the first place.

For managed fleets, Cloud Rebuild integrates with Windows Autopilot and Intune: a rebuilt device can re-enroll automatically, with assigned apps, policies, and user settings restored through Backup for Organizations. Remote initiation isn’t available in this Beta — a rebuild still has to be triggered locally from WinRE or an elevated prompt — but Microsoft has said Intune-driven remote triggering is planned. That detail matters more than it looks. The roadmap points toward IT no longer needing physical hands on the device to initiate recovery at all, which only deepens the dependency this post is about.

Cloud-Based Recovery Improves Convenience. It Doesn’t Improve Recovery Architecture.

Microsoft’s case for this feature is not weak, and it’s worth stating plainly before making the counter-argument:

Every item on the left is real and worth having. None of them is the same claim as the items on the right, and collapsing the two into a single “this is better” verdict is the mistake worth avoiding here. Cloud-based recovery can be operationally superior to what it replaces while simultaneously making the recovery architecture more centralized and more dependent on a single vendor’s availability. Those are two different arguments. Only one of them showed up in the feature announcement.

The Last Independent Recovery Path

Local recovery media was rarely anyone’s first choice. It was slow, it required physical custody of a drive, and it depended on someone remembering where that drive was kept. None of that was the point. The point was that it sat entirely outside the dependency chain that caused the outage in the first place — no network path, no identity provider, no vendor’s uptime, nothing the original failure could have taken down along with everything else. It’s the same principle the connected air gap argument makes about backup isolation — a fallback only counts as independent if it’s actually outside the failure domain, not merely labeled that way.

Two recovery paths responding to the identical failure make the difference concrete:

The traditional path has one dependency: whoever holds the drive. The cloud-based path has at least three, and all three sit outside the machine being recovered and outside the organization’s authority to guarantee.

Cloud-Based Recovery Carousel — 8-slide breakdown — the dependency chain argument in slide form: traditional vs. cloud-based recovery paths, the five-layer dependency stack, and the governance question underneath it.

Recovery Authority Transfer

Every recovery mechanism has an implicit authority chain — the sequence of things that have to hold true, and hold trusted, before a device comes back into service. For local recovery media, that chain was short: the organization decided what image and drivers a device would run, wrote that decision to media it physically controlled, and recovery executed against artifacts nobody outside the organization ever touched.

Cloud-based recovery replaces that chain with a longer one: Microsoft’s Update infrastructure, generic internet connectivity, DNS resolution, the TLS trust chain validating the connection, and the reachability of whichever Microsoft endpoint actually serves the rebuild. None of those five things sits under the organization’s authority, and all five now stand between “device won’t boot” and “device recovered.”

That’s the same drift The System Recovered. Your Recovery Boundary Didn’t. names on the other side of the lifecycle — dependency boundaries expanding faster than recovery boundaries account for. That post is about what a recovered system still depends on afterward. This is about what the recovery mechanism itself now depends on before it can even start.

That’s the question worth asking before this ships to production fleets, not after: has recovery authority moved outside the recovery boundary? Recovery Design Boundary — the framework naming what dependencies must exist before recovery can even begin — is built for exactly this question. A recovery mechanism that requires DNS resolution, TLS validation, and a third party’s infrastructure to stay healthy before it can execute has quietly redrawn where that boundary sits, whether or not anyone updated the architecture diagram to reflect it.

The question is not whether these dependencies usually work. They usually do. The question is whether they remain available during the exact class of event recovery procedures exist to address. Recovery mechanisms are not evaluated during normal operations. They’re evaluated during abnormal conditions, when multiple assumptions fail simultaneously.

Who Approved This?

Somewhere in most Data Protection programs there’s a decision record for which backup platform runs, what the RPO/RTO targets are, and who holds authority to declare a recovery complete. There is almost never a decision record for “OS recovery may now depend on Microsoft’s cloud infrastructure being reachable.” Nobody voted on that. It arrives as a default in an OS update, and it will reach most fleets the same way every other default setting does — silently, on whatever patch cadence the organization already runs.

Organizations rarely lose recovery independence through a formal architecture review. They lose it through default-path drift — a sequence of vendor defaults that gradually become production architecture without ever appearing in a design review.

The Governance & Recovery Assurance stage of Rack2Cloud’s own Data Protection Learning Path is where this kind of decision is supposed to get formalized — a recorded, accountable answer to what recovery may depend on, not a default absorbed silently through a patch cycle.

That’s a different failure mode from the one Recovery Evidence Boundary describes. Evidence Boundary is about whether anyone structurally independent can validate a recovery claim after the fact. This is upstream of that question — it’s about whether the organization ever exercised authority over the dependency in the first place. An unvalidated recovery claim is a governance failure at the audit stage. An inherited dependency nobody reviewed is a governance failure at the design stage, and design-stage failures are far cheaper to fix before a feature reaches general availability than after.

Recovery Dependency Mapper — tests recovery sequencing against your actual dependency graph and flags cycles or external dependencies nobody documented, including ones an OS vendor added by default.

Architect’s Verdict

Cloud-based recovery is not a downgrade. It’s a different architecture, and most organizations are about to inherit it without ever deciding to.

The real problem isn’t Microsoft’s engineering choice — reinstalling from a live, current image is a legitimate improvement over media that goes stale the day it’s created. The real problem is that a recovery architecture decision is being made by a default setting instead of by the people accountable for recovery outcomes. Every organization running Windows 11 fleets is about to answer “does OS recovery depend on our internet connection and Microsoft’s availability” whether or not anyone ever asked that question on purpose.

An organization that has never reviewed what its recovery depends on doesn’t have a recovery architecture. It has an assumption that hasn’t failed yet.

Recovery architecture is not defined by how a system recovers when everything works. It’s defined by what recovery still depends on when everything else doesn’t.

Originally published at rack2cloud.com

Most data in the real world is string , and python offers a way to interact and transform data to enable us meet our analysis goals.

To check Type of Data

###1.Types

Type()

This method enables us to check the type/class of data held in our variables

Str()

This is a built in function that turns any type of data into a string.

in instances where you dont use f-strings you might to covert your data into text to match the rest of the data type and perform the print function

### Transformations
This methods aim to change the appearance or form of the text

Replace()

In this you are aiming to replace an existing text with a new value, in you syntax you should specify the old value and the new value / or replace it with nothing

split()

This aims to split strings to a list , you clarity the item to be used as the separation point and it will be replaced with commas (,)

Using + /Concat

We can use the plus sign to join similar data types
“Hello ” + “World” results in “Hello World”

Join

Joins turns strings,sets,tuples into a single string, you outline the separator you want to be used
“SEPARATOR”.join(list)

Multiplier

We use the asterisk that serves as the multiple sign.

Cleaning of Whitespaces

lstrip()

This methods clears any white space on the left side of the string(leading whitespaces)

rstrip

This method clear whitespace on the right side of the string (trailing spaces)

strip()

This method removes leading and trailing white spaces. It doesn’t change the original string it returns a new string.
Strip() can also be used to remove special characters from the leading and trailing ends only.
Strip can’t clear white spaces or special characters within the data.

Cleaning Cases

Lower()

Standardizes the string to lower case

Upper()

Standardizes the string to upper case

Title()

It capitalizes every first letter of all words

Searching

Startswith()

This checks the prefix of a string to check for matching and returns either True / False

Endwith()

This checks the suffix to check for matching and returns a boolean true/false

Find

This helps us find the index of the first occurrence of the substring, it returns -1 incase the substring isn’t found

Integer

This checks the position of a substring in a string, performs similar to find but the difference is that if the substring doesn’t exist it will crash .
The safe option is using find because incase the substring doesn’t exist it gives a -1 feedback

In operator

In check if a value exists in a list, tuple, string
It returns True if found and False if the substring doesn’t exist

Validation

This methods check if the strings meet certain conditions.
The feedback is boolean , either True or False

text.isalpha() Only letters
text.isdigit() Only digits
text.isalnum() Letters and numbers only
text.isnumeric() Numeric characters
text.isspace() Only spaces
text.islower() All letters are lowercase
text.isupper() All letters are uppercase
text.istitle() Each word starts with uppercase

Web mimarisi, web uygulamalarının ve web sitelerinin tasarım ve yapısını tanımlayan kritik bir alandır. Kullanıcı deneyimini, performansını ve ölçeklenebilirliğini doğrudan etkileyen bir konu olarak, web mimarisi alanında yapılan yenilikler ve gelişmeler, web dünyasının geleceğini şekillendiriyor. Bu yazıda, web mimarisi alanındaki son trendleri, en iyi uygulamaları ve geleceğin web uygulamalarını oluşturmak için kullanılan ileri düzey teknikleri keşfederek web geliştiricilerinin ufuklarını genişletmeyi hedefliyoruz.

Geleceğin Web Mimarisi: Mikro Hizmetler ve Sunucusuz Mimari

Modern web uygulamaları, artan kullanıcı talepleri ve karmaşıklık nedeniyle geleneksel tek parça mimarilerin ötesine geçmeyi gerektiriyor. Mikro hizmetler ve sunucusuz mimari, web uygulamalarının ölçeklenebilirliğini ve bakımını kolaylaştırmak için ortaya çıkan popüler yaklaşımlar haline geldi.

Mikro Hizmetler Mimarisi

Mikro hizmetler mimarisi, bir uygulamayı daha küçük, bağımsız hizmetlere bölerek uygulamayı modüler hale getirir. Her mikro hizmet, belirli bir iş işlevini yerine getirir ve kendi veri depolarını ve arabirimlerini kullanır. Bu yaklaşım, her hizmetin bağımsız olarak geliştirilmesine, test edilmesine ve dağıtılmasına olanak tanır, böylece geliştirme sürecini hızlandırır ve esneklik sağlar.

Örneğin, bir e-ticaret web sitesi, ürün kataloğu, alışveriş sepeti, ödeme işlemleri ve müşteri hesapları gibi farklı mikro hizmetlerden oluşabilir. Bu mikro hizmetler birbirleriyle iletişim kurarak sorunsuz bir kullanıcı deneyimi sağlar. Mikro hizmetler mimarisi, her hizmetin ayrı olarak ölçeklendirilebilmesini sağlayarak uygulamanın genel performansını artırır.

Sunucusuz Mimari

Sunucusuz mimari, sunucu yönetim yükünü ortadan kaldıran ve kod yürütme için ölçeklenebilir bir ortam sağlayan bir yaklaşımdır. Bu mimaride, işlevsel kod parçaları (“fonksiyonlar”) bulut sağlayıcıları tarafından yönetilen ortamlarda çalıştırılır. Sunucusuz mimari, kodun yalnızca gerektiğinde yürütülmesini ve dinamik olarak ölçeklendirilmesini sağlar, böylece maliyet verimliliği ve esneklik sağlanır.

Örneğin, bir web uygulaması, kullanıcı kayıt işlemini işlemek için sunucusuz fonksiyonlar kullanabilir. Kullanıcı kaydolduğunda, sunucusuz fonksiyon tetiklenir, gerekli doğrulamaları yapar ve kullanıcı verilerini bir veritabanına kaydeder. Bu yaklaşım, sunucu yönetimiyle uğraşmadan esnek ve ekonomik bir çözüm sunar.

Uygulama: Reaktif Mimari ile Gerçek Zamanlı Web Uygulamaları

Reaktif mimari, web uygulamalarına gerçek zamanlı ve etkileşimli özellikler katmak için kullanılan modern bir yaklaşımdır. Reaktif mimari, veri akışlarını ve değişiklikleri yöneterek dinamik ve yanıt veren kullanıcı arabirimleri oluşturmayı amaçlar.

React ve Angular ile Reaktif Kullanıcı Arabirimleri

React ve Angular, reaktif mimariyi benimseyen popüler frontend kütüphaneleridir. Bu kütüphaneler, kullanıcı arabirimlerini küçük bileşenlere bölerek ve veri akışını yöneterek dinamik ve etkileşimli kullanıcı deneyimleri oluşturmayı kolaylaştırır.

Örneğin, bir sosyal medya akışını gösteren bir web uygulaması düşünün. React veya Angular kullanarak, yeni gönderiler alındıkça dinamik olarak güncellenen bir akış bileşeni oluşturabilirsiniz. Bu kütüphaneler, verilerde yapılan değişikliklere yanıt veren ve kullanıcı arabirimini buna göre güncelleyen reaktif veri akışları sağlar.

Kod Örneği: React ile Reaktif Kullanıcı Arabirimi

import React, { useState } from 'react';

function SocialMediaFeed() {
  const [posts, setPosts] = useState([]);

  const handleNewPost = (newPost) => {
    setPosts([...posts, newPost]);
  };

  return (
    <div>
      <h1>Social Media Feed</h1>
      <div>
        {posts.map((post) => (
          <Post key={post.id} post={post} />
        ))}
      </div>
    </div>
  );
}

function Post({ post }) {
  return (
    <div>
      <h2>{post.title}</h2>
      <p>{post.content}</p>
    </div>
  );
}

export default SocialMediaFeed;

Bu kod örneğinde, SocialMediaFeed bileşeni, posts adlı bir durum değişkeni ve handleNewPost adlı bir fonksiyon tanımlar. Yeni bir gönderi alındığında, handleNewPost fonksiyonu tetiklenir ve yeni gönderi mevcut gönderilerin listesine eklenir. posts listesi, map fonksiyonu kullanılarak Post bileşenine geçirilir ve her gönderi ayrı ayrı işlenir.

React’in reaktif doğası, posts listesindeki değişiklikleri algılar ve kullanıcı arabirimini otomatik olarak günceller, böylece yeni gönderiler dinamik olarak akışa eklenir. Bu yaklaşım, gerçek zamanlı ve etkileşimli bir kullanıcı deneyimi sağlar.

Geleceğin Web Mimarisi için Bulut Hizmetleri

Bulut hizmetleri, web mimarisi alanındaki yenilikleri hızlandırmada kritik bir rol oynamaktadır. AWS, Azure ve Google Cloud gibi bulut sağlayıcıları, ölçeklenebilirlik, güvenlik ve esneklik sunan çeşitli hizmetler sunar.

• Bulut Depolama: AWS S3 veya Azure Blob Depolama gibi bulut depolama hizmetleri, büyük miktarda veri depolamak ve erişmek için kullanılır. Web uygulamalarının statik içeriklerini, kullanıcı yüklerini veya yedeklemelerini depolamak için idealdir.
• Bulut İşlevleri: AWS Lambda veya Azure İşlevleri gibi sunucusuz hizmetler, kod yürütme için ölçeklenebilir bir ortam sağlar. Web uygulamalarının arka uç mantığını çalıştırmak için idealdir ve sunucu yönetimi yükünü ortadan kaldırır.
• Bulut Veritabanları: MongoDB Atlas veya AWS RDS gibi yönetilen veritabanı hizmetleri, ölçeklenebilir ve güvenilir veri depolama sağlar. Web uygulamalarının verilerini güvenli bir şekilde depolamak ve sorgulamak için kullanılabilir.
• İçerik Dağıtım Ağları (CDN’ler): CDN’ler, web uygulamalarının statik içeriklerini küresel olarak dağıtarak performansını artırır. Kullanıcıya yakın konumlardan içerik sunulması sayfa yükleme sürelerini kısaltır.

Sonuç

Web mimarisi, web uygulamalarının temelini oluşturan kritik bir alandır ve sürekli gelişen yenilikler ve trendler sunmaktadır. Mikro hizmetler mimarisi, sunucusuz mimari ve reaktif mimari gibi yaklaşımlar, web uygulamalarının ölçeklenebilirliğini, esnekliğini ve etkileşimliliğini artırıyor.

Ayrıca, bulut hizmetleri, web mimarisi alanındaki yenilikleri destekleyen güçlü araçlar sunmaktadır. Bulut depolama, sunucusuz işlevler ve CDN’ler, web uygulamalarının performansını, güvenilirliğini ve bakımını geliştirir.

Web geliştiricileri olarak, bu ileri düzey teknikleri ve yaklaşımları benimseyerek geleceğin web uygulamalarını oluşturabilir ve kullanıcılara etkileyici ve yenilikçi deneyimler sunabiliriz. Web mimarisi alanındaki sürekli gelişme, web dünyasının geleceğini şekillendirmeye devam edecek.

Introduction:

As students, we work with data almost every day. Whether it is a machine learning dataset, college records, project logs, or survey results, analyzing large amounts of data can become difficult when everything has to be downloaded and processed locally.

While learning AWS, I came across Amazon Athena, a service that makes this process much simpler.

Amazon Athena is a serverless interactive query service that allows us to analyze data stored in Amazon S3 using standard SQL. The interesting part is that we do not need to set up or manage servers, clusters, or other infrastructure before running queries.

In this blog, I will explain Amazon Athena in simple terms, how it works, its important features, a practical student use case, and some things to consider before using it.

What is Amazon Athena?

Amazon Athena is a serverless analytics service from AWS.

Its main purpose is to allow users to query data directly where it is stored, particularly in Amazon S3, using SQL.

For example, imagine that I have a large CSV file containing student project information:

student_id,department,project,score
101,AI&ML,RenalScan,92
102,CSE,SmartCampus,87
103,AI&ML,ChurnGuard,90

Instead of downloading the entire dataset and processing it on my laptop, I can store the file in S3 and use Athena to query it.

For example:

sql
SELECT department, AVG(score)
FROM student_projects
GROUP BY department;

Athena processes the query and returns the result.

It also supports multiple common data formats, including CSV, JSON, ORC, Avro, and Apache Parquet.

Why Was Amazon Athena Created?

Analyzing large datasets traditionally required infrastructure such as servers, database systems, or data-processing clusters.

For students and smaller teams, setting up and maintaining this infrastructure can be unnecessary for many analytics tasks.

Amazon Athena provides a serverless approach. We can keep data in Amazon S3, define its schema, and start running SQL queries without managing the underlying servers.

This makes Athena particularly useful for ad-hoc analysis, log analysis, data exploration, and querying data lakes.

The main idea is simple:

Store the data in the cloud and query it when you need it.

How Does Amazon Athena Work?

The basic workflow looks like this:

The process can be explained in a few steps:

1. Store the dataset in an Amazon S3 bucket.
2. Open Amazon Athena.
3. Define the structure/schema of the data.
4. Write a SQL query.
5. Athena reads the required data from S3.
6. The query is processed without the user managing servers.
7. Results are displayed and can also be stored in S3.

Athena is designed to execute queries in parallel and automatically scale the query-processing infrastructure.

Key Features of Amazon Athena

1.Serverless Architecture

The biggest feature of Athena is that it is serverless.

There is no need to create or maintain EC2 instances, configure clusters, install database software, or manually handle scaling.

AWS manages the infrastructure required to execute the queries, allowing the user to focus mainly on the data and SQL.

For a student, this is useful because we can experiment with analytics without first learning how to manage a complete data-processing cluster.

2.Query Data Using Standard SQL

Athena allows users to analyze data using SQL.

For someone who already knows SQL through a DBMS course, this makes Athena relatively approachable.

For example:

sql
SELECT project, AVG(score) AS average_score
FROM student_projects
GROUP BY project
ORDER BY average_score DESC;

Athena supports SQL operations such as joins, window functions, and arrays, and supports several data formats including CSV, JSON, ORC, Avro, and Parquet.

3.Integration with Amazon S3

Athena works directly with data stored in Amazon S3.

We do not have to first move the entire dataset into a traditional database before querying it.

This makes the combination of S3 + Athena useful for building a simple data lake architecture.

Athena can also use the AWS Glue Data Catalog to help define and manage table and partition metadata.

4.Workgroups for Managing Queries

Athena provides workgroups that can be used to separate workloads and teams.

For example, a college could create separate workgroups for:

Workgroups can also be used to control access, configure query-result locations, monitor usage, and establish data-usage limits.

College / Student Use Case

A practical use case for my college would be a Student Project Analytics System.

Suppose a department has thousands of project records containing:

• Student ID
• Department
• Project title
• Technology used
• Project score
• Academic year
• Project category

These records could be stored in S3.

Athena could then be used to answer questions such as:

sql
SELECT technology, COUNT(*) AS project_count
FROM student_projects
GROUP BY technology
ORDER BY project_count DESC;

The department could use the results to understand which technologies students are using most frequently.

Another query could calculate the average project score:

sql
SELECT department, AVG(score) AS average_score
FROM student_projects
GROUP BY department;

This would allow faculty members to analyze project trends without building and maintaining a dedicated database server for every analysis task.

A Simple Practical Example

Imagine that I have uploaded a CSV file called:
student_projects.csv
to an S3 bucket.

After defining the table structure in Athena, I can run:

sql
SELECT *
FROM student_projects
LIMIT 10;

To find the number of projects in each department:

sql
SELECT department, COUNT(*) AS total_projects
FROM student_projects
GROUP BY department;

To find high-scoring projects:

sql
SELECT student_id, project, score
FROM student_projects
WHERE score >= 90
ORDER BY score DESC;

The important point is that these queries can be run against data stored in S3 rather than requiring me to download the entire dataset onto my computer.

Athena can be accessed through the AWS Management Console, API, AWS CLI, SDKs, and supported JDBC/ODBC connections.

Advantages of Amazon Athena:

No Server Management

Athena is serverless, so users do not need to manage servers, clusters, software updates, or infrastructure scaling.

Easy for SQL Users

Anyone familiar with SQL can start exploring datasets without learning an entirely new query language.

Scalable

Athena is designed to automatically scale query execution and process queries in parallel.

Works with Large Datasets

Athena can be used for interactive analysis of large datasets stored in S3.

Integration with AWS

It works with services and tools such as Amazon S3, AWS Glue Data Catalog, IAM, CloudWatch, and business intelligence tools.

Limitations and Things to Consider:

Cost

Athena is not simply a completely free service.

For SQL queries, the default pricing model is based on the amount of data scanned. AWS also provides capacity-based pricing for certain workloads.

This means poorly optimized queries over very large datasets can become expensive.

Using compression, partitioning, and columnar formats such as Parquet can reduce the amount of data scanned and therefore reduce query costs.

Complexity

Basic queries are easy, but working with large datasets requires knowledge of data formats, schemas, partitions, permissions, and query optimization.

Scalability

Athena itself scales automatically, but the way data is stored still matters. Poorly organized datasets can result in unnecessary data scanning and slower or more expensive queries.

Security

Data access needs to be configured carefully. Athena works with AWS IAM policies and Amazon S3 bucket policies to control who can access the underlying data.

Athena can also query encrypted data stored in S3 and can encrypt query results.

Conclusion:

Amazon Athena is a useful AWS service for anyone who needs to analyze large amounts of data without managing servers.

Its combination of serverless architecture, SQL support, S3 integration, scalability, and flexible query management makes it useful for students as well as organizations.

For a student like me, Athena is especially interesting because it connects concepts that we already learn in college—such as SQL, databases, data analytics, and cloud computing.

A simple combination of Amazon S3 + Amazon Athena can turn a collection of raw datasets into something that can be queried and analyzed using familiar SQL commands.

My biggest takeaway from learning about Athena is that cloud computing is not always about managing more infrastructure. Sometimes, the advantage is that AWS manages the infrastructure so we can concentrate on solving the actual data problem.

References

• Amazon Athena – AWS Official Overview
• Amazon Athena Documentation
• Amazon Athena Features
• Amazon Athena Pricing
• Amazon Athena FAQs

Thonburian Whisper ถอดเสียงไทยในเครื่องฟรี ใช้ฟรีแม้เชิงพาณิชย์

โดย Nokka (นก-กา) | 15 กันยายน 2026

บทความนี้เขียนโดย AI (โมเดล deepseek-v4.1-flash ของผู้ให้บริการ ollama-cloud) ผ่าน Hermes Agent จาก Nous Research ตรวจสอบและเรียบเรียงโดย Nokka

เวลาพูดถึง AI กับเสียงไทย คนมักนึกถึง เสียงสังเคราะห์ คือทำให้ AI พูด

แต่อีกด้านหนึ่งสำคัญพอ ๆ กัน และมีคนเขียนถึงน้อยกว่ามาก คือ การถอดเสียงพูดไทยเป็นข้อความ [1]

Thonburian Whisper คือชุดโมเดลที่ทำเรื่องนี้ จากทีม Biomedical and Data Lab มหาวิทยาลัยมหิดล เปิดให้ใช้ฟรีและใช้เชิงพาณิชย์ได้ [1][2]

Thonburian Whisper คืออะไร

เป็นชุดโมเดล Automatic Speech Recognition (ASR) ที่ fine-tune จาก Whisper ของ OpenAI สำหรับภาษาไทยโดยเฉพาะ [1][2]

ทีมเผยแพร่หลายขนาดให้เลือกตามทรัพยากรที่มี

ตัวเลข downloads ด้านบนผมดึงจาก Hugging Face API โดยตรง ณ วันที่เขียน [2]

คะแนน WER และความต่างที่ราคาแลกมา

WER (Word Error Rate) คือสัดส่วนคำที่ถอดผิด ยิ่งต่ำยิ่งดี [1]

ตัวเลข WER ทั้งสองตัวด้านล่างผมดึงจากหน้าโมเดลทางการบน Hugging Face ทั้งรุ่น medium [1] และรุ่น large-v3 [3]

ทั้งสองค่าที่ระบุวัดบนชุดทดสอบ common_voice_13_0 ภาษาไทย ซึ่งระบุไว้บนหน้าโมเดลทางการ [1] และใช้ Deepcut tokenizer ในการตัดคำ ซึ่งเป็นรายละเอียดที่ผมคิดว่าสำคัญ เพราะ ค่า WER ภาษาไทยขึ้นกับวิธีตัดคำเป็นอย่างมาก [1]

ผมต้องชี้ให้ชัดตรงนี้ ตัวเลข 6.59 กับ 7.42 วัดด้วยวิธีเดียวกัน จึงเทียบกันได้ แต่ผมไม่สามารถบอกได้ว่าเทียบกับโมเดลอื่นได้หรือไม่ เพราะแต่ละทีมใช้ชุดทดสอบและตัวตัดคำต่างกัน [1]

ทำไมผมคิดว่าตัวนี้คุ้มค่าที่จะรู้จัก

หนึ่ง: ใบอนุญาต Apache 2.0 [1]

ผมตรวจจากหน้าโมเดลทั้งสองตัว (medium-combined และ large-v3-combined) ระบุ license: apache-2.0 เหมือนกัน [1]

ข้อนี้สำคัญเพราะต่างจากโมเดลเสียงไทยหลายตัวที่ห้ามใช้เชิงพาณิชย์ ⇒ ถ้าคุณทำแอปหรือบริการที่ต้องถอดเสียงลูกค้า ตัวนี้ใช้ได้โดยไม่ต้องขออนุญาต [1]

สอง: มีให้เลือกหลายขนาดจนรันในเครื่องได้จริง

มีตั้งแต่รุ่น small ที่รันบนเครื่องทั่วไป ไปจนถึง large-v3 ที่ต้องใช้ GPU แต่ให้คะแนนดีที่สุด [1][2]

สาม: มีรุ่นกลั่น (distill) สำหรับคนที่ต้องการความเร็ว ซึ่งทีมเผยแพร่แยกไว้ต่างหาก [4]

distill-whisper-th-small และ distill-whisper-th-large-v3 [4] เป็นรุ่นที่กลั่นให้เล็กลงและเร็วขึ้น ซึ่งมักแลกกับความแม่นบ้าง [2]

วิธีใช้ห้าบรรทัดจบ

ทีมให้โค้ดตัวอย่างไว้บนหน้าโมเดล และเป็นวิธีมาตรฐานของ Whisper [1]

from transformers import pipeline

MODEL_NAME = "biodatlab/whisper-th-medium-combined"
lang = "th"

device = 0 if torch.cuda.is_available() else "cpu"

pipe = pipeline(
    task="automatic-speech-recognition",
    model=MODEL_NAME,
    chunk_length_s=30,
    device=device,
)
pipe.model.config.forced_decoder_ids = pipe.tokenizer.get_decoder_prompt_ids(
  language=lang,
  task="transcribe"
)
text = pipe("audio.mp3")["text"]

จุดที่ผมคิดว่าคนมักลืมคือสองบรรทัดกลาง การตั้ง forced_decoder_ids ให้ภาษาเป็น th และ task เป็น transcribe ถ้าไม่ตั้ง โมเดลอาจถอดเป็นภาษาอังกฤษหรือแปลแทนที่จะถอด [1]

ประวัติ: เริ่มจากปี 2022

ทีมเผยแพร่ชุดนี้ครั้งแรกเมื่อปี 2022 โดย Atirut Boribalburephan · Zaw Htet Aung · Knot Pipatsrisawat · Titipat Achakulvisut [1]

การอ้างอิงใน BibTeX ของทีมระบุปี 2022 และมี DOI บน Hugging Face [1]

แต่รุ่นที่คนใช้มากที่สุดในตอนนี้ (whisper-th-medium-combined) เป็นรุ่นที่ฝึกต่อมาแล้ว หน้าโมเดลระบุว่า Combined V4 ฝึกบนข้อมูล augmented จาก common_voice_13_0 ภาษาไทย · google/fleurs และชุดข้อมูลที่ทีมคัดสรรเพิ่ม [1]

ผมต้องบอกตรง ๆ ว่า ผมไม่พบวันที่เผยแพร่ที่ชัดเจนของรุ่น V4 สิ่งที่ยืนยันได้คือ BibTeX ระบุปี 2022 ซึ่งเป็นปีของเวอร์ชันแรก [1]

พารามิเตอร์การฝึกที่ทีมเปิดไว้

หน้าโมเดลของรุ่น medium ระบุรายละเอียดการฝึกไว้ครบ [1]

ทีมเปิดไว้ให้ดูทั้งหมด ซึ่งเป็นเรื่องที่มีคุณค่าในความเห็นของผม เพราะทำให้คนที่อยากฝึกต่อยอดรู้ว่าต้องเริ่มจากจุดไหน [1]

เรื่องที่ทีมยังไม่ได้เขียนไว้

หน้าโมเดลทั้งสองรุ่นของทีม ระบุไว้ตรง ๆ ว่า *”Intended uses & limitations: More information needed”* และ “Training and evaluation data: More information needed” [1]

ผมจึงไม่เดาว่าข้อจำกัดของโมเดลคืออะไร แต่สิ่งที่ผม ยืนยันได้ คือทีมเปิดเผยว่ายังไม่ได้เขียนส่วนนี้ [1]

และนี่เป็นเรื่องที่ผมอยากให้คุณรู้ก่อนใช้ โมเดลนี้ไม่มีการระบุข้อจำกัดที่ชัดเจน เช่น ไม่รู้ว่าทำงานได้แค่ไหนกับเสียงใต้ หรือเสียงที่มีเสียงรบกวน หรือภาษาถิ่น [1]

เริ่มทดลองได้อย่างไร

ผมแนะนำให้ลองแบบนี้ครับ เลือกไฟล์เสียงของคุณเอง 1 ไฟล์ที่ มีสำเนียงหรือศัพท์เฉพาะที่คุณสนใจ แล้วลองถอดด้วยรุ่น small ก่อน

ถ้าคะแนนพอใช้ ก็ไม่ต้องใช้รุ่นใหญ่ แต่ถ้าไม่พอ การขยับไป medium หรือ large-v3 ก็ใช้โค้ดชุดเดิม แก้แค่ชื่อโมเดลในบรรทัดเดียว [1]

และเพราะเป็น Apache 2.0 คุณลองในบริบทงานจริงได้เลยโดยไม่ต้องกังวลเรื่องสิทธิ์ [1]

ข้อควรระวัง

หนึ่ง ผมไม่ได้รันโมเดลนี้ ทั้งหมดเป็นการรายงานจากหน้าโมเดลบน Hugging Face [1][2]

สอง ตัวเลข WER ทั้งหมดเป็นของทีมเอง บนชุดทดสอบ common_voice_13_0 และใช้ Deepcut tokenizer ห้ามนำไปเทียบกับ WER ของทีมอื่นโดยตรง เพราะวิธีตัดคำต่างกัน [1]

สาม ทีมไม่ได้ระบุข้อจำกัดการใช้งาน (limitations) ไว้ หน้าโมเดลเขียนว่า “ต้องการข้อมูลเพิ่มเติม” ทั้งสองหัวข้อ [1]

สี่ ผมไม่พบวันที่เผยแพร่ที่ชัดเจนของรุ่น V4 สิ่งที่ยืนยันได้คือ BibTeX ระบุปี 2022 สำหรับเวอร์ชันแรก [1]

ห้า ตัวเลข downloads เปลี่ยนทุกวัน ตัวเลขที่ผมเขียนเป็นค่าที่ดึงจาก API ณ วันที่เขียน [2]

หก มีโมเดลที่บุคคลอื่นสร้างต่อจากชุดนี้ (เช่นรุ่นสำหรับงานดูแลผู้สูงอายุ หรือรุ่นแปลงสำหรับ MLX) ซึ่งผมไม่ได้ตรวจคุณภาพ [2]

เจ็ด ผมทำงานบนระบบที่ใช้โมเดล AI และเขียนบทความนี้ด้วยความช่วยเหลือของ AI [5]

บทความที่เกี่ยวข้อง

นี่คือตอนที่ 2 ของซีรีส์ ตอนที่ 1 พูดถึง JaiTTS โคลนเสียงไทยที่คะแนนแม่นกว่ามนุษย์ ซึ่งเป็นด้าน “สร้างเสียง” ตอนนี้เป็นด้าน “ถอดเสียง” และตอนที่ 3 จะเป็น OpenJAI-v1.0-14B โมเดลภาษาจากทีมเดียวกันกับ JaiTTS

แหล่งอ้างอิง

[1] Boribalburephan, A., Aung, Z. H., Pipatsrisawat, K., Achakulvisut, T., “Thonburian Whisper: A fine-tuned Whisper model for Thai automatic speech recognition” (2022), https://huggingface.co/biodatlab/whisper-th-medium-combined

[2] “biodatlab” โมเดลทั้งหมดของทีม Biomedical and Data Lab, Hugging Face (เข้าถึง ก.ย. 2026), https://huggingface.co/biodatlab

[3] “whisper-th-large-v3-combined” รุ่น Large V3 พร้อมค่าที่วัดได้, Hugging Face (เข้าถึง ก.ย. 2026), https://huggingface.co/biodatlab/whisper-th-large-v3-combined

[4] “distill-whisper-th-large-v3” รุ่นกลั่นสำหรับผู้ที่ต้องการความเร็ว, Hugging Face (เข้าถึง ก.ย. 2026), https://huggingface.co/biodatlab/distill-whisper-th-large-v3

[5] การเปิดเผยของผู้เขียน: บทความนี้เขียนโดยใช้ AI

Attempting to resolve both execution profiles with a single orchestration platform inevitably degrades system stability. Forcing BPMN (Business Process Model and Notation) engines to execute low-latency microservice Sagas leads to database state bloat and worker thread starvation. Conversely, using code-first workflow engines to manage multi-week human tasks obscures business visibility, hardcodes organizational approval chains, and compromises audit compliance.

Under the Xenon Architecture Standards, modern banking platform design resolves this tension through a dual-orchestration pattern mapped directly to Banking Industry Architecture Network (BIAN) service domains. This paper evaluates the operational boundaries, data-flow integrations, and failure patterns of pairing Temporal for machine-level distributed transaction Sagas with Flowable for human-in-the-loop business process management.

Architectural Mapping across BIAN Service Domains

The Banking Industry Architecture Network (BIAN) defines standard Service Domains with strict encapsulation boundaries. Each Service Domain exposes functional capabilities through control keys and service operations. However, execution profiles vary drastically across domains.

By establishing an orchestration taxonomy, we assign orchestration responsibility based on state duration, execution throughput, and the presence of human intervention.

                                   +------------------------------------------+
                                   |         Flowable BPMN Engine             |
                                   |  (Human Workflows & SLA Management)      |
                                   +--------------------+---------------------+
                                                        |
                                            Async gRPC / Event Bus
                                                        |
                                   +--------------------+---------------------+
                                   |         Temporal Engine                  |
                                   |   (Machine Sagas & API Resiliency)       |
                                   +----+---------------+----------------+----+
                                        |               |                |
                                        v               v                v
                               +----------------+ +-----------+ +-----------------+
                               | Payment Engine | | Ledger API| | Screening Engine|
                               +----------------+ +-----------+ +-----------------+

Deep Dive 1: Temporal for Machine-Level Sagas

Temporal provides a developer-centric, code-first durable execution model. It persists the complete stack execution trace of an application, rendering code execution resilient to process crashes, network partitions, and downstream infrastructure outages.

Within the Xenon Architecture framework, Temporal handles machine-to-machine integration patterns where execution must be deterministic, programmatic, and sub-second.

The Saga Pattern in Core Ledger Operations

When executing complex financial movements across isolated microservices (e.g., reserving balance in Position Keeping, checking limits in Risk Management, and posting to General Ledger), distributed ACID transactions are non-viable due to lock contention. Temporal enforces the Saga Pattern by registering explicit compensating actions for every forward transaction step.

Below is an enterprise Go implementation demonstrating a deterministic, fault-tolerant BIAN Payment Saga using Temporal SDK:

package sagas

import (
    "fmt"
    "time"

    "go.temporal.io/sdk/workflow"
)

// PaymentSagaInput holds payload for BIAN Payment Execution
type PaymentSagaInput struct {
    PaymentID        string
    SourceAccount    string
    TargetAccount    string
    Amount           float64
    Currency         string
    CorrelationID    string
}

// PaymentSagaWorkflow orchestrates machine-level execution with strict compensations
func PaymentSagaWorkflow(ctx workflow.Context, input PaymentSagaInput) (err error) {
    options := workflow.ActivityOptions{
        StartToCloseTimeout: 5 * time.Second,
        RetryPolicy: &workflow.RetryPolicy{
            InitialInterval:    100 * time.Millisecond,
            BackoffCoefficient: 2.0,
            MaximumAttempts:    5,
        },
    }
    ctx = workflow.WithActivityOptions(ctx, options)

    var compensations []func(workflow.Context) error
    defer func() {
        if err != nil {
            // Execute compensations in reverse order on failure
            compCtx, _ := workflow.NewDisconnectedContext(ctx)
            for i := len(compensations) - 1; i >= 0; i-- {
                if compErr := compensations[i](compCtx); compErr != nil {
                    workflow.GetLogger(ctx).Error("Compensation failed", "error", compErr)
                }
            }
        }
    }()

    // Step 1: Reserve Funds in Source Account
    var reservationID string
    err = workflow.ExecuteActivity(ctx, ReserveFundsActivity, input.SourceAccount, input.Amount, input.CorrelationID).Get(ctx, &reservationID)
    if err != nil {
        return fmt.Errorf("failed to reserve funds: %w", err)
    }
    // Register Compensation
    compensations = append(compensations, func(cCtx workflow.Context) error {
        return workflow.ExecuteActivity(cCtx, CancelReservationActivity, reservationID, input.CorrelationID).Get(cCtx, nil)
    })

    // Step 2: Perform Real-Time Sanctions Screening
    var passedScreening bool
    err = workflow.ExecuteActivity(ctx, ScreenTransactionActivity, input.PaymentID, input.Amount).Get(ctx, &passedScreening)
    if err != nil || !passedScreening {
        err = fmt.Errorf("sanctions check rejected transaction")
        return err
    }

    // Step 3: Credit Target Account
    var postingID string
    err = workflow.ExecuteActivity(ctx, CreditAccountActivity, input.TargetAccount, input.Amount, input.CorrelationID).Get(ctx, &postingID)
    if err != nil {
        return fmt.Errorf("failed to credit target account: %w", err)
    }

    // Step 4: Finalize Reservation (Commit)
    err = workflow.ExecuteActivity(ctx, FinalizeReservationActivity, reservationID, postingID).Get(ctx, nil)
    if err != nil {
        return fmt.Errorf("failed to finalize balance movement: %w", err)
    }

    return nil
}

Key Technical Advantages of Temporal in Financial Sagas

• Zero Polling Cost: Event-driven architecture suspends workers while waiting for external system responses without occupying active threads.
• Transparent Retries: Non-deterministic external failures (e.g., API timeouts) trigger exponential backoffs without polluting business domain state.
• Exact Execution Replay: System history event sourcing ensures state can be reconstructed precisely during platform disaster recovery events.

Deep Dive 2: Flowable for Human-in-the-Loop Workflows

Flowable implements BPMN 2.0 and CMMN (Case Management Model and Notation) standards. It excels where state persistence spans long periods, processes must adapt dynamically to human input, and compliance requires a clear visual domain map.

Human Approvals in Credit Assessment

In BIAN Credit Assessment, automated scoring engines process standard requests instantaneously. However, applications flagged for risk exceptions must transition to manual underwriting.

Flowable models these long-lived process steps natively using User Tasks, Candidate Groups, and Escalation Timers.

<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL"
             xmlns:flowable="http://flowable.org/bpmn"
             targetNamespace="BIAN/CreditAssessment">

  <process id="loanUnderwritingProcess" name="Loan Underwriting Process" isExecutable="true">

    <startEvent id="startEvent" name="Loan Application Received" />

    <sequenceFlow sourceRef="startEvent" targetRef="callAutomatedScoringSaga" />

    <!-- Java Delegate acting as a client bridge to Temporal Saga -->
    <serviceTask id="callAutomatedScoringSaga" 
                 name="Execute Machine Scoring Saga" 
                 flowable:class="com.xenon.banking.bridge.TemporalSagaDelegate" />

    <sequenceFlow sourceRef="callAutomatedScoringSaga" targetRef="checkScoringDecision" />

    <exclusiveGateway id="checkScoringDecision" name="Approval Decision?" />

    <sequenceFlow sourceRef="checkScoringDecision" targetRef="autoApproveEnd">
      <conditionExpression xsi:type="tFormalExpression">${scoreOutcome == 'AUTO_APPROVED'}</conditionExpression>
    </sequenceFlow>

    <sequenceFlow sourceRef="checkScoringDecision" targetRef="manualUnderwritingTask">
      <conditionExpression xsi:type="tFormalExpression">${scoreOutcome == 'REFER_TO_HUMAN'}</conditionExpression>
    </sequenceFlow>

    <!-- Human Task Assignment -->
    <userTask id="manualUnderwritingTask" 
              name="Manual Credit Review" 
              flowable:candidateGroups="underwriters">
      <documentation>
        Underwriter review required for Application ID: ${applicationId}. Credit Score border case.
      </documentation>
    </userTask>

    <!-- Boundary Timer Event for SLA Escalation -->
    <boundaryEvent id="slaTimer" attachedToRef="manualUnderwritingTask" cancelActivity="false">
      <timerEventDefinition>
        <timeDuration>PT24H</timeDuration>
      </timerEventDefinition>
    </boundaryEvent>

    <sequenceFlow sourceRef="slaTimer" targetRef="escalateToManager" />

    <userTask id="escalateToManager" 
              name="Manager Override Review" 
              flowable:candidateGroups="credit_managers" />

    <sequenceFlow sourceRef="manualUnderwritingTask" targetRef="manualDecisionGateway" />

    <exclusiveGateway id="manualDecisionGateway" name="Approved?" />
    <sequenceFlow sourceRef="manualDecisionGateway" targetRef="approvedEnd">
      <conditionExpression xsi:type="tFormalExpression">${underwriterDecision == 'APPROVED'}</conditionExpression>
    </sequenceFlow>
    <sequenceFlow sourceRef="manualDecisionGateway" targetRef="rejectedEnd">
      <conditionExpression xsi:type="tFormalExpression">${underwriterDecision == 'REJECTED'}</conditionExpression>
    </sequenceFlow>

    <endEvent id="autoApproveEnd" name="Auto Approved" />
    <endEvent id="approvedEnd" name="Manually Approved" />
    <endEvent id="rejectedEnd" name="Application Rejected" />

  </process>
</definitions>

Key Technical Advantages of Flowable for Business Operations

• Declarative BPMN/CMMN Visualizations: Enables risk, compliance, and auditing teams to inspect and validate business pathways directly using standardised graphical representations.
• Organizational Hierarchy Awareness: Dynamic resolution of user roles, delegations, managerial escalations, and regional assignment groups.
• Operational Task APIs: Native capabilities for listing, claiming, reassigning, and completing tasks through enterprise web application interfaces.

The Integration Architecture: Bridging the Dual-Orchestration Gap

The architectural key to Xenon’s framework lies in preventing direct, tight coupling between Flowable and Temporal. Flowable must remain agnostic to microservice execution mechanics, and Temporal must not manage long-lived human process state.

We achieve integration via Event-Driven Asynchronous Signals using Apache Kafka or gRPC Bridge Delegates.

+-----------------------------------------------------------------------------------+
| FLOWABLE PROCESS ENGINE                                                           |
|                                                                                   |
|  [BPMN: Start] ---> [ServiceTask: Trigger Saga] ---> [Receive Task: Wait Signal]  |
+-----------------------------------|--------------------------^--------------------+
                                    |                          |
                         1. Async gRPC Execution        4. Signal Execution Callback
                                    |                          |
+-----------------------------------|--------------------------|--------------------+
| INTEGRATION LAYER                 v                          |                    |
|                         +-------------------+      +------------------+           |
|                         | Temporal Client   |      | Signal REST/gRPC |           |
|                         | Dispatcher        |      | Client           |           |
|                         +---------+---------+      +---------^--------+           |
+-----------------------------------|--------------------------|--------------------+
                                    |                          |
                         2. Start Workflow              3. Complete Saga
                                    |                          |
+-----------------------------------|--------------------------|--------------------+
| TEMPORAL ENGINE                   v                          |                    |
|                                                              |                    |
|    [Start Saga Workflow] ---> [Execute Microservices] -------+                    |
+-----------------------------------------------------------------------------------+

The Java Bridge Implementation

When Flowable encounters a step that requires machine execution (e.g., executing a complex Temporal credit-scoring Saga), a custom Java Delegate triggers the Temporal workflow asynchronously. The Flowable process then enters a native ReceiveTask state, awaiting a system signal.

package com.xenon.banking.bridge;

import io.temporal.client.WorkflowClient;
import io.temporal.client.WorkflowOptions;
import org.flowable.engine.delegate.DelegateExecution;
import org.flowable.engine.delegate.JavaDelegate;
import org.springframework.stereotype.Component;

import com.xenon.banking.temporal.CreditScoringWorkflow;
import com.xenon.banking.temporal.model.ScoringRequest;

@Component("temporalSagaDelegate")
public class TemporalSagaDelegate implements JavaDelegate {

    private final WorkflowClient temporalWorkflowClient;

    public TemporalSagaDelegate(WorkflowClient temporalWorkflowClient) {
        this.temporalWorkflowClient = temporalWorkflowClient;
    }

    @Override
    public void execute(DelegateExecution execution) {
        String applicationId = (String) execution.getVariable("applicationId");
        String executionId = execution.getId();

        // 1. Construct non-blocking options with correlation key
        WorkflowOptions options = WorkflowOptions.newBuilder()
                .setTaskQueue("CREDIT_SCORING_TASK_QUEUE")
                .setWorkflowId("CreditScore-" + applicationId)
                .build();

        // 2. Instantiate Stub
        CreditScoringWorkflow workflowStub = temporalWorkflowClient.newWorkflowStub(CreditScoringWorkflow.class, options);

        // 3. Prepare Input with Flowable Execution Callback Reference
        ScoringRequest request = new ScoringRequest();
        request.setApplicationId(applicationId);
        request.setFlowableExecutionId(executionId);

        // 4. Trigger Temporal Saga Asynchronously
        WorkflowClient.start(workflowStub::executeScoring, request);

        // 5. Flowable context moves to a ReceiveTask node immediately after this execution
    }
}

Completion Callback: Temporal signaling back to Flowable

Upon completion of the Saga, a Temporal Activity posts an asynchronous completion signal back to Flowable’s Runtime Service:

package com.xenon.banking.bridge;

import org.flowable.engine.RuntimeService;
import org.springframework.stereotype.Service;

@Service
public class FlowableCallbackService {

    private final RuntimeService flowableRuntimeService;

    public FlowableCallbackService(RuntimeService flowableRuntimeService) {
        this.flowableRuntimeService = flowableRuntimeService;
    }

    public void handleSagaCompletion(String flowableExecutionId, String outcome, double score) {
        // Pass result parameters back to Flowable engine memory context
        flowableRuntimeService.setVariable(flowableExecutionId, "scoreOutcome", outcome);
        flowableRuntimeService.setVariable(flowableExecutionId, "creditScore", score);

        // Trigger Flowable step advancement out of ReceiveTask
        flowableRuntimeService.trigger(flowableExecutionId);
    }
}

Failure Modes, State Recovery, and Transactional Boundaries

In a dual-orchestration topology, edge cases occur primarily at the operational boundary between the two systems. System design must accommodate asymmetric execution states.

Scenario 1: Temporal Saga Fails Completely

If a machine Saga fails and all compensating actions complete successfully, the machine state remains consistent, but the business transaction cannot proceed automatically.

• Mitigation: The Temporal completion activity signals Flowable with an outcome = 'SYSTEM_ERROR' payload.
• Flowable Behavior: Flowable evaluates this outcome using a BPMN Exclusive Gateway and routes the application to an operational exception handling queue (Human User Task) for operational staff to investigate or manual retry.

Scenario 2: Human Task Times Out or Is Cancelled

A customer cancels a loan request while the human underwriting task is pending in Flowable, or the review period exceeds defined SLA boundaries.

• Mitigation: Flowable triggers an Interrupting Boundary Event (Timer or Signal).
• Temporal Cancellation: Flowable dispatches an explicit RPC request to the Temporal Client API (workflowStub.cancel()). Temporal intercepts the cancellation request, runs any required cleanup activities, and releases allocated system resources (such as active fund holds).

State Synchronization Patterns

To maintain audit integrity, state synchronization across both systems must conform to standard operational principles:

1. Correlation Keys: Every transaction must carry a global BIAN Correlation ID (correlationId = "BIAN-ORIG-2026-98234"). This identifier must be passed across Flowable executions, Temporal Workflows, Kafka Headers, and downstream microservice trace contexts.
2. Idempotent Signal Ingestion: Signals sent from Temporal to Flowable must use deterministic execution references (executionId). If network instability causes duplicate delivery of a completion signal, Flowable’s execution check rejects processing of redundant payloads.

Observability, Distributed Tracing, and Auditability

Operating dual orchestrators requires unified observability across both machine traces and human audit logs.

[Customer Application] 
       │
       ▼  W3C TraceContext (traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01)
┌──────────────┐
│  Flowable    │ (Generates Human Audit Record: UserTask 'Approved' by User #4092)
└──────┬───────┘
       │ OpenTelemetry Context Propagation (gRPC / Kafka Headers)
       ▼
┌──────────────┐
│  Temporal    │ (Generates Microservice Execution Span: Activity 'DebitLedger' 4ms)
└──────────────┘

• OpenTelemetry Propagation: Inject the W3C traceparent header into Flowable process variables. When calling Temporal through the gRPC bridge client, populate the OpenTelemetry context. This enables end-to-end tracing in tools like Jaeger or Datadog, spanning from human UI interaction down to database commits.
• Audit Trail Bifurcation:
• Regulatory Audit (Compliance): Sourced from Flowable’s historical DB tables (ACT_HI_*), providing clear verification of which human approved what action at what time.
• System Operations Audit (IT): Sourced from Temporal’s Event History store, verifying which microservice APIs executed, retry counts, payload hashes, and exact execution timing.

Adopting a dual-orchestration pattern based on Temporal and Flowable provides a structured design for BIAN-compliant banking platforms. By delegating machine-level transactional consistency to Temporal’s Saga implementation and long-running organizational processes to Flowable’s BPMN engine, core banking systems achieve sub-second technical performance alongside resilient human workflows.