Coder Legion - Recent posts tagged opensource

Trick or Type Guard? Surviving `unknown` with is-kit 🎃

Sat, 31 Oct 2026 15:54:29 +0000

Hoi hoi! 👋

I'm @nyaomaru, a frontend engineer who is scared of horror things 🙀

Happy Halloween! 🎃👻

Tonight, we're exploring a haunted TypeScript project.

There are zombies 🧟, ghosts 👻, mysterious pumpkins 🎃, and a terrifying vampire 🧛 waiting for us.

And they all have something to do with TypeScript types!

Our mission?

Survive the night without losing type safety! 😸

Let's go!

🧟 Chapter 1: The Unknown Living Dead

It's a dark and spooky night.

Suddenly, something crawls out of the grave! 🧟

const creature: unknown = JSON.parse('{"message":"BRAAAINS!"}');

Oh! An unknown creature!

Let's see what it wants.

console.log(creature.message);
// ❌ 'creature' is of type 'unknown'.

WHAT?! 🙀

TypeScript won't let us!

But why?

Well, because we don't actually know what creature is.

It might be a zombie.
It might be a ghost.
It might even be a cute little cat. 😸

unknown means we haven't verified the value yet.

Unlike any, TypeScript won't let us access arbitrary properties on an unknown value.

And that's actually a good thing!

Let's try something simpler.

import { isString } from "is-kit";

const voice: unknown = JSON.parse('"BRAAAINS!"');

if (isString(voice)) {
  console.log(voice.toUpperCase());
  // BRAAAINS!
}

YAY! 🎉

We survived our first encounter!

Of course, we could also use typeof voice === 'string' here.

For a single check, that's perfectly fine!

But what happens when our monsters become bigger and more complicated?

🎃 Chapter 2: The Big Pumpkin of Unknown

Look!

A GIGANTIC PUMPKIN! 🎃

And apparently, it's full of candy.

But nobody knows what's really inside.

const pumpkin: unknown = JSON.parse(`{
  "name": "Big Pumpkin",
  "candies": ["Chocolate", "Lollipop", "Cookie"],
  "spookyLevel": 99,
  "keeper": {
    "name": "cat",
    "friendly": true
  },
  "secret": "Meow!"
}`);

That's a pretty big object.

Can we just grab the candy?

console.log(pumpkin.candies);
// ❌ 'pumpkin' is of type 'unknown'.

Not again! 😿

We need to check what's inside before touching anything.

Fortunately, we have struct!

import {
  arrayOf,
  isBoolean,
  isNumber,
  isString,
  optionalKey,
  struct,
} from "is-kit";

const isPumpkin = struct({
  name: isString,
  candies: arrayOf(isString),
  spookyLevel: isNumber,
  keeper: struct({
    name: isString,
    friendly: isBoolean,
  }),
  secret: optionalKey(isString),
});

We composed several small guards into one big pumpkin guard.

isString checks strings.
isNumber checks finite numbers.
arrayOf(isString) checks an array of strings.
struct checks nested object shapes.
optionalKey allows a property to be missing.

Now, let's open the pumpkin!

import { safeParse } from "is-kit";

const result = safeParse(isPumpkin, pumpkin);

if (result.valid) {
  console.log(result.value.candies);
  // ['Chocolate', 'Lollipop', 'Cookie']

  console.log(result.value.keeper.name);
  // cat 😸
}

We found the candy!!! 🍬🎉

When validation succeeds, result.value has the type inferred from our guards.

And when validation fails?

const cursedPumpkin = {
  name: "Cursed Pumpkin",
  candies: "100 candies",
  spookyLevel: 99,
  keeper: {
    name: "cat",
    friendly: true,
  },
};

const result = safeParse(isPumpkin, cursedPumpkin);

console.log(result);
// { valid: false }

The candies were a string, not an array!

Our guard rejected the cursed pumpkin.

And here's the important part.

safeParse doesn't magically fix or convert invalid values.

It simply tells us whether the value passed our guard.

Also, struct allows extra properties by default. If you need to reject additional own enumerable string keys, you can use { exact: true }.

Nice and simple!

🍬 Chapter 3: Trick or Type Guard!

Ding dong! 🔔

TRICK OR TREAT!!! 😸

Someone hands us a mysterious gift.

function receiveGift(): unknown {
  return Math.random() > 0.5 ? "Chocolate" : { spiders: 100 };
}

const gift: unknown = receiveGift();

Wait.

Is it candy?
Or is it a box full of spiders?! 🕷️😱

We need a way to check!

And this time, we want to accept either a string or a number.

Let's combine our guards with or!

import { isNumber, isString, or } from "is-kit";

const isTreat = or(isString, isNumber);

function trickOrTreat(gift: unknown) {
  if (isTreat(gift)) {
    // gift: string | number
    return `🍬 Treat: ${gift}`;
  }

  return "👻 Trick!";
}

Now let's try it!

trickOrTreat("Chocolate");
// 🍬 Treat: Chocolate

trickOrTreat(100);
// 🍬 Treat: 100

trickOrTreat({ spiders: 100 });
// 👻 Trick!

YAY!!! 🍬

No spiders for us today!

This is one of my favorite things about is-kit.

We don't need to write one giant validator.

We can build small guards, combine them, and reuse them wherever we need.

Small guards. Simple composition. Useful TypeScript narrowing.

That's the idea!

But wait,
Something is coming.
Something TERRIFYING.

🧛 Final Boss: The Vampire Called `any`

Suddenly, the lights go out.

The door opens.

A mysterious figure appears in the darkness.

It's... COUNT ANY!!! 🧛💀

The most terrifying vampire in our TypeScript project! And he has a very dangerous power.

He can make TypeScript stop checking our operations!

const visitor: unknown = JSON.parse('{"name":666}');

A mysterious visitor has arrived.

Normally, TypeScript protects us from accessing properties before we verify them.

But Count Any has a trick.

THE CURSE OF as any! 🧛

const vampire = visitor as any;

// The vampire ignores type safety!
console.log(vampire.name.toUpperCase());

No TypeScript error!

Wait, What?! 🙀

Does that mean the code is safe?

At runtime

TypeError: vampire.name.toUpperCase is not a function

💀 GAME OVER 💀

Count Any didn't turn the number into a string.

He just convinced TypeScript to stop checking it!

That's what makes any dangerous.

It allows operations without requiring proof that they'll work.

But unknown behaves differently.

const visitor: unknown = JSON.parse('{"name":666}');

console.log(visitor.name.toUpperCase());
// ❌ TypeScript stops us!

TypeScript refuses to continue until we check the value.

So how do we defeat Count Any?

With a Type Guard, of course! 😸

import { isString, struct } from "is-kit";

const isFriendlyGuest = struct({
  name: isString,
});

if (isFriendlyGuest(visitor)) {
  console.log(visitor.name.toUpperCase());
} else {
  console.log("🧄 Not tonight, Count Any!");
}

And just like that

THE VAMPIRE HAS BEEN DEFEATED! 🧄🎉

Well, at least this particular cursed value has been rejected.

A Type Guard checks the actual runtime value, while a type assertion only changes what TypeScript believes about it.

One important detail, neither unknown nor any changes the value at runtime.

They are TypeScript types.

The difference is what the compiler allows us to do before verifying the value.

And that's why unknown is usually the safer choice for untrusted data.

😸 Epilogue: We Survived Halloween!

What a night!

We met the Unknown Living Dead, opened a gigantic pumpkin, collected some candy, and defeated Count Any!

So, what did we learn?

Monster	TypeScript lesson
🧟 Unknown Living Dead	`unknown` prevents unchecked operations
🎃 Big Pumpkin	`struct` validates object shapes
🍬 Trick or Treat	`or` combines reusable type guards
🧛 Count Any	`any` bypasses normal type checking

Of course, any isn't always evil.

Sometimes it's useful when dealing with legacy code or difficult integrations.

But when working with API responses, parsed JSON, and other untrusted values, keeping them as unknown until validation is usually a much safer approach.

And is-kit makes those checks easy to compose and reuse!

If you want to explore more, check out the official guide 👇

📖 How to Validate unknown in TypeScript Without a Schema Library

And remember

The real monster isn't unknown. It's unchecked any. 🧛

Happy Halloween!!! 🎃👻

If you enjoyed this little TypeScript adventure, check out is-kit!

{% embed https://github.com/nyaomaru/is-kit %}

And if you like the project, a ⭐ would make this little cat very happy! 😸

Thank you for reading! 🤲

Embeds: Putting a Live NitroIDE Playground Inside Your Docs

Sat, 31 Oct 2026 12:32:01 +0000

Every tutorial has the same weak spot: the code sample. A static block shows what the code looks like. It cannot show what the code does. The reader has to copy it, open an editor, paste it, and run it — and every step in that chain is a step where a reader leaves.

A month ago I wrote about NitroIDE's share engine: the Share button compresses an entire workspace into a ?code= URL parameter, and opening that link rebuilds the workspace locally in the reader's browser. Nothing is uploaded to a server. That post was about sending code to one person. This one is about the layer on top of it: embedding that workspace inside a page, so the reader never has to leave the tutorial at all.

Take any NitroIDE share URL and add ?embed=1 to it. That is the whole API:

<iframe src="https://nitroide.com/tools/codebox.html?embed=1&code=YOUR_SHARE_CODE" width="100%" height="500" frameborder="0"></iframe>

The embed loads a stripped-down, read-only viewer. The full IDE chrome is gone — no file explorer, no console panel, no settings menus. What remains is the two things a reader actually needs: the editor and the live preview, side by side. The reader sees the code and its output in the same frame, on the same page, with nothing to install and no account to create.

Read-only is a deliberate choice, not a missing feature. A tutorial embed is not a workspace; it is a demonstration. If the reader could edit the code in place, every edit would be a fork of the author's example with no way back — and the next reader would see someone else's experiment, not the tutorial. So the embed shows, and the escape hatch handles editing: every embed carries a footer link reading "Built with NitroIDE — open & edit". One click opens the exact workspace in the full editor, where the reader can change anything. Show first, edit second, and never confuse the two.

Where this actually belongs

The honest answer is: anywhere that renders an iframe and where the reader is there to learn. Blog posts, documentation pages, tutorial sites, course material — anywhere a code sample currently sits as a dead block.

It does not belong in a GitHub README. GitHub strips iframes from rendered Markdown, so an embed pasted into a README renders as nothing. That is what the "Open in NitroIDE" badge is for — a link, not a frame — and knowing which of the two a surface accepts is the difference between an embed that works and one that silently vanishes. If the page cannot render an iframe, do not force the embed in; link out instead.

The second place it belongs is less obvious: your own changelog and release notes. A new feature described in prose is a claim; the same feature embedded as a running demo is evidence. When a release note says "the preview now updates without flicker," an embedded playground running the new behaviour lets the reader verify it in ten seconds instead of trusting the sentence.

The details that make an embed feel native, not bolted on

A bare iframe works. A few attributes make it feel like part of the page:

width="100%" and a fixed height around 500px. The embed is a window into a workspace, and a window needs a predictable frame. Let it fill the content column and keep the height tall enough that the preview is readable without scrolling inside a scrolling page.
loading="lazy" on embeds below the fold. A tutorial with five demos should not load five editors before the reader reaches the first one. Lazy loading defers each embed until it scrolls into view.
A title attribute on the iframe. It costs nothing and it is what a screen reader announces; "Live demo: responsive card layout" is a better experience than an unnamed frame.
One demo per concept. An embed is a heavyweight element — a whole editor and a live preview. Three embeds proving the same point are two embeds too many; one well-chosen demo per idea keeps the page fast and the argument sharp.

None of these are NitroIDE features. They are the hosting page's job, and they are the difference between an embed that feels like part of the tutorial and one that feels pasted in.

The limits, stated plainly

An embed inherits every limit of the share link it is built on. The workspace travels inside the URL itself, compressed into the ?code= parameter, so a very large project makes a very long URL. For a tutorial demo — a handful of files, a single concept — that is never a problem. For a full application, it is: use ZIP export for the project and embed a small, focused demo of the idea instead. The embed is for the example, not the app.

The second limit comes from the preview's sandbox. NitroIDE's preview runs in a sandboxed iframe with an opaque origin, which is what keeps code in a shared link from touching the reader's saved projects. The tradeoff is that localStorage, sessionStorage, and cookies are unavailable inside the preview — and in Safari, touching them throws a SecurityError. Demo code that reads localStorage unguarded will crash inside the embed while working fine in a normal tab. Wrap storage access in try/catch in any code you plan to embed, and the same demo runs everywhere.

The third limit is the read-only viewer itself. It hides the console, so a demo whose point is console output — logging, errors, debugging — loses its punchline inside an embed. That is a real constraint, and the honest response is to pick the right surface: embed the demos whose output is visual, and link out to the full editor for the ones whose output lives in the console.

Why this matters more than a nicer code block

Syntax highlighting made code readable. Embeds make it runnable, and that is a different category of change. A readable sample asks the reader to trust the author. A runnable sample lets the reader check the author — change a value, watch the preview move, break it, fix it. That is the feedback loop NitroIDE is built around, except now it happens inside someone else's docs, for a reader who never opened the IDE at all.

The embed is also the quietest distribution NitroIDE has. Every embed carries its own attribution in the footer, and every footer click is a reader who arrived at the full editor from inside a tutorial they were already reading — not from a post, not from an ad, from a working demo. That is the growth loop that does not look like a growth loop: make the tool useful inside other people's pages, and let the pages do the talking.

One parameter, one iframe, one running demo where a dead code block used to be. Try it with the docs example above — paste a share code into the snippet, drop it into a page, and the tutorial stops describing the code and starts running it.

I build NitroIDE — a browser-based IDE where your code never leaves your machine: https://nitroide.com?utm_source=coderlegion&utm_medium=article&utm_campaign=daily-2026-10-31

The Maintainer Who Wrote "Sorry, I Missed the Request!"

Fri, 30 Oct 2026 20:21:47 +0000

Sixteen days of silence, one polite reminder, and a surprisingly good Friday in open source.

My favorite GitHub notification this month wasn't a new star, a detailed code review, or someone telling me my project had changed their life.

It was a maintainer saying:

"Sorry, I missed the request!"

That's it.

No technical discussion. No complicated review. No debate about architecture. Just five words, an exclamation mark, and a merged pull request.

And somehow, that little interaction made my Friday.

Let me explain.

The world's least dramatic pull request

On October 14, I opened a pull request to in-toto/friends.

If you're unfamiliar with in-toto, it's an open-source framework focused on software supply-chain security. The friends repository maintains a list of projects that integrate with it.

I maintain a tool called workproof, which generates verifiable engineering reports from private repositories.

I wanted to add it to the list.

The pull request was about as exciting as it sounds.

One row in a Markdown table.

Not a new feature. Not a performance improvement. Not a security patch that would save thousands of production servers from catching fire.

A row.

If GitHub had an award for the least dramatic contribution of the week, I might have been a serious contender.

I opened the PR, checked that everything looked right, and moved on to other work.

Then I waited.

And waited.

Not in the cinematic sense. There was no staring at the screen, refreshing GitHub every seven seconds while dramatic music played in the background.

I had other things to build.

But every so often, I'd check the pull request.

Still open.

No comments. No review. No labels.

Nothing.

Sixteen days passed.

The strange psychology of an unanswered PR

Here's something I've noticed about contributing to open-source projects.

When you submit a pull request, you know intellectually that nobody owes you an immediate response.

Maintainers have jobs, families, other repositories, notifications, issues, bugs, releases, and probably an impressive collection of browser tabs they'll never close.

I understand that.

But there's still a small part of your brain that starts inventing explanations when a PR sits unanswered.

Did I submit it incorrectly?

Is this repository still maintained?

Was the contribution inappropriate?

Should I say something?

Would saying something make me annoying?

The last question is particularly interesting.

As contributors, we often worry about bothering maintainers. We don't want to appear impatient or entitled, especially when the change is small.

So we wait.

Sometimes a week. Sometimes a month.

Sometimes until the repository becomes a historical artifact and someone discovers our pull request while researching ancient civilizations.

Meanwhile, the maintainer might simply have missed the notification.

That's the funny part.

We can spend days interpreting silence that contains absolutely no information.

Thirty-five minutes

On October 30, I decided to write a follow-up.

Nothing elaborate.

I mentioned that the pull request had been open since October 14, that the change still merged cleanly, and that a quick yes or no would help me plan.

That was the whole point.

I wasn't asking the maintainer to prioritize my contribution. I wasn't explaining why my project was important. I wasn't trying to turn a Markdown table update into a philosophical argument about the future of software supply chains.

I just wanted to know whether the contribution made sense.

Thirty-five minutes later, the maintainer approved it.

The response:

"Sorry, I missed the request!"

At 11:02 UTC, the PR was merged.

Sixteen days of silence.

Thirty-five minutes after a reminder, done.

I laughed a little when I saw it.

Not because the maintainer had done anything wrong. Quite the opposite.

The answer was so ordinary and so human that it immediately made the entire situation feel smaller.

There had been no hidden disagreement.

No mysterious review process.

No elaborate technical objection waiting to emerge.

The request had simply been missed.

And now it wasn't.

We talk a lot about automation. We talk less about attention.

I spend a lot of time around software engineering, open-source tooling, and AI-assisted development.

Every week, there's a new discussion about agents writing code, agents reviewing code, agents fixing bugs, and eventually agents doing practically everything except remembering where we left our coffee.

Some of those developments are genuinely exciting.

But this little experience reminded me of something that doesn't get nearly as much attention.

Open source isn't just a collection of repositories.

It's also a collection of people trying to coordinate their limited time and attention.

A pull request can be technically correct, perfectly formatted, and ready to merge.

That doesn't mean someone has seen it.

And even when someone has seen it, that doesn't mean they've had the time or context to respond.

Those are different problems.

As engineers, we're very good at building systems that track code changes. We have statuses, checks, notifications, dashboards, review requests, and activity histories.

Yet a perfectly valid contribution can still disappear into the noise.

The software is doing its job.

The humans are just busy being humans.

A reminder doesn't have to be a demand

I've seen contributors handle unanswered pull requests in very different ways.

Some wait indefinitely.

Some send repeated messages.

Some become frustrated and start questioning whether the project is actively maintained.

And occasionally, a simple follow-up turns into an argument that nobody really wanted to have.

I'm not convinced any of those extremes help.

What worked for me was making the request easy to answer.

Not:

"Why hasn't anyone reviewed my PR?"

Not:

"This is a very important contribution and deserves your attention."

And definitely not:

"Hello??? @maintainer @maintainer @maintainer"

Just a little context, a specific question, and room for the answer to be no.

That last part matters.

When you ask for a review, you're asking another person to spend time on something you care about.

They might agree.

They might disagree.

They might need another week.

They might decide the contribution doesn't belong in the project.

All of those are legitimate outcomes.

A polite reminder doesn't guarantee a merge, and it shouldn't.

It just gives the conversation another chance to happen.

Of course, every project has its own contribution guidelines and review expectations. Some maintainers explicitly ask contributors not to ping them. Those boundaries deserve respect.

But where follow-ups are welcome, one clear message can be more useful than two weeks of silent speculation.

At least, it was in this case.

Small contributions are still real contributions

I also want to avoid exaggerating what happened here.

My PR added one row to a README.

It wasn't a significant engineering breakthrough. It didn't prove the quality or security of workproof. Being listed in a repository isn't the same thing as receiving an independent endorsement.

And I don't think we should pretend otherwise.

There's already enough inflated language in technology.

Not every commit is revolutionary.

Not every feature is groundbreaking.

And not every merged pull request needs a LinkedIn post explaining how it transformed the future of engineering.

Although, apparently, one Markdown row can inspire an entire article.

So perhaps I'm not completely innocent.

But small contributions do matter in a different way.

They help projects stay connected.

They improve documentation, update integrations, correct outdated information, and sometimes simply make it easier for the next person to discover something useful.

They also give contributors opportunities to interact with communities outside their own projects.

That last part matters to me.

I maintain my own tools, but I don't want all my engineering work to happen inside repositories where I'm the person making every decision.

Contributing elsewhere means learning how other projects work, respecting their processes, and occasionally discovering that the person on the other side of the pull request is just as human as you are.

It's a modest kind of connection.

But I like it.

The other side of the notification

There's another perspective worth considering.

Imagine maintaining a popular open-source project.

You've spent months or years building something useful, often without compensation proportional to the work involved.

Your inbox is full.

Someone reports a bug.

Someone requests a feature.

Someone opens a PR that breaks three tests.

Someone asks whether the project supports a configuration you documented two paragraphs above their question.

And somewhere among all of that is a perfectly reasonable one-line contribution.

You miss it.

Sixteen days later, the contributor sends a polite reminder.

You take a look, realize it's fine, and merge it.

What do you say?

In this case:

"Sorry, I missed the request!"

I appreciated that response because it didn't try to turn a small oversight into something complicated.

No excuses.

No defensiveness.

Just an acknowledgment and an action.

That's a pretty good way to handle many situations, not only pull requests.

And if you're a maintainer reading this, I don't think the lesson is that you need to respond to everything immediately.

That would be a terrible expectation.

It's that even a short answer can be valuable.

"Not right now."

"Needs changes."

"This doesn't fit the project."

"Sorry, I missed this."

A response doesn't have to be positive to be useful.

Sometimes it just needs to exist.

One more thing before I close GitHub

I have a couple of other pull requests waiting in different projects.

After this experience, I'm going to check their statuses and see whether a follow-up makes sense.

Not because I suddenly believe every unanswered PR is one message away from being merged.

Some changes need discussion. Some need substantial review. Some may never be accepted.

That's part of contributing to projects you don't control.

But I'm less inclined to interpret silence as a decision.

And I'm a little more comfortable asking a reasonable question when enough time has passed.

If you've contributed to open source, you've probably experienced that strange waiting period where you can't tell whether your PR is being considered, forgotten, or quietly ignored.

My experience isn't proof that reminders always work.

It's just one example of why they sometimes do.

Sixteen days of silence turned out to mean exactly what the maintainer said:

They missed the request.

Nothing more dramatic than that.

So thank you to the maintainer who took the time to respond and merge the change.

You probably spent less than a minute writing that sentence.

I ended up writing an entire article about it.

That's a pretty impressive return on five words.

I'm Efe Genc, an independent software engineer building open-source developer tools. I write about engineering, experiments, and the things that happen when software meets actual human beings.

First published on my site: https://efegenc.me/writing/the-maintainer-who-wrote-sorry-i-missed-the-request/

Building Knemora: An Open-source, Local-first AI (SI) Second Brain

Fri, 30 Oct 2026 15:23:16 +0000

I’m Federico, a visual designer and full-stack developer.

About six months ago, I had an idea I kept coming back to: could I turn documents and datasets into connected knowledge, explore the relationships visually, and ask questions without sending my material to a cloud inference service?

Why I built Knemora?
After a lot of research, architecture decisions, late nights, and interface iterations, that idea became Knemora.

How it works?
It’s an open-source, local-first AI (SI) Second Brain. You bring your documents and datasets; Knemora compiles knowledge into a portable Markdown wiki, connects pages, and makes that knowledge available through search, a native graph, and chat with source citations.

Architecture:
The diagrams below show the system architecture and the knowledge/inference workflow.

A few choices behind the architecture:

Portable knowledge: Markdown pages with frontmatter and explicit links. The graph is a rebuildable view of those connections.
Local inference: llama.cpp with Qwen3-8B Q3_K_M as the default model.
Retrieval: BM25 search and bounded graph navigation, without a vector database.
Traceability: original documents are preserved, and generated claims carry source references.
Dataset analysis: Polars performs structured calculations, keeping numerical results grounded in computation.

The stack includes Vue 3, FastAPI, Google ADK, SQLite, and Sigma.js/Graphology.

The initial alpha targets macOS Apple Silicon. Node.js 24 with npm is required; the launcher manages the remaining runtimes and model downloads. Initial setup needs internet access, while the core knowledge and inference workflow runs locally afterward. There’s also an isolated demo with interconnected sample knowledge.

As a designer, I care about making the interface clear and the graph useful. As a developer, I care about keeping the underlying knowledge portable and understandable.

Open-source software has helped me throughout my career, and I’m proud to contribute something of my own. This is an early alpha, with plenty left to improve.

Code, documentation, and setup:
github.com/federicolaterra/knemora

Website:
knemora.space

[OC] I built a free, open-source HIPAA DICOM anonymizer for medical imaging

Fri, 30 Oct 2026 10:49:57 +0000

I just released dicom-clean — an open-source CLI tool for HIPAA-compliant DICOM de-identification. Here's how it works and why I built it.

The Problem

Medical imaging files (CT scans, MRIs, X-rays) use a format called DICOM, which contains two things:

Metadata — patient name, birth date, MRN, hospital, referring physician, etc.
Pixel data — the actual image

When hospitals want to share DICOM data for research, AI training, or vendor evaluation, they must remove the patient identifiers first — this is required by HIPAA Safe Harbor (45 CFR §164.514(b)(2)).

But existing options are problematic:

Commercial tools (RSNA CTP, DicomCleaner) cost $5,000+/year
Cloud solutions upload patient data → HIPAA violation risk
DCMTK / GDCM work but have steep learning curves (C++ toolchain, complex syntax)

So I built dicom-clean to be:

✅ 100% offline (air-gapped compatible)
✅ Simple CLI (one command)
✅ Zero-install (standalone .exe)
✅ Free and open source (AGPL-3.0)

What It Does

1. Strips All 18 HIPAA Patient Identifiers

The tool blanks out 40+ scalar PHI tags and deletes 8 sequences that may carry nested PHI:

HIPAA_TAGS_TO_BLANK = (
    (0x0010, 0x0010),  # PatientName
    (0x0010, 0x0020),  # PatientID
    (0x0010, 0x0030),  # PatientBirthDate
    (0x0010, 0x1040),  # PatientAddress
    (0x0008, 0x0080),  # InstitutionName
    (0x0008, 0x0090),  # ReferringPhysicianName
    # ... 40+ more
)

HIPAA_TAGS_TO_REMOVE = (
    (0x0008, 0x1110),  # ReferencedStudySequence
    (0x0008, 0x1115),  # ReferencedSeriesSequence
    # ... 6 more
)

Design decision: I blank the scalar tags (preserving tag + VR) rather than deleting them, so downstream PACS and DICOM viewers don't break when they expect those fields.

2. Deterministic UID Pseudonymization

DICOM uses UIDs (Unique Identifiers) to link files together. A study has a StudyInstanceUID, each series has a SeriesInstanceUID, and each image has a SOPInstanceUID.

If you just replace these with random UUIDs, you lose the relationships between files — a PACS server won't be able to group images from the same study.

My solution: SHA-256 with an optional salt.

def pseudonymize_uid(original_uid: str, salt: str = "") -> str:
    """Deterministically pseudonymize a DICOM UID."""
    if not original_uid:
        return original_uid
    digest = hashlib.sha256(
        (salt + str(original_uid)).encode("utf-8")
    ).hexdigest()
    number = int(digest[:32], 16)  # 128 bits
    return f"2.25.{number}"

Why this works:

Deterministic — Same input + salt → same output, always
Reversible relationships — All files from one study get consistent pseudonyms
Non-reversible — Without the salt, you can't reverse it
Valid format — Output is a proper DICOM UID (2.25.<128-bit-int>)

3. Image Integrity

The pixel data is never touched. Same for:

Modality (CT, MR, US, etc.)
PixelData
TransferSyntaxUID
PhotometricInterpretation
Rows / Columns
BitsAllocated / BitsStored
PixelSpacing / SliceThickness
Window/Level tags

So the image looks identical in any DICOM viewer — only the metadata changes.

4. Date Reduction

HIPAA permits keeping the year but not the month/day. So:

Before: StudyDate = "20250315"
After:  StudyDate = "20250101"

Tech Stack

Component	Purpose
pydicom	DICOM parsing & writing
Typer	CLI framework
Rich	Terminal UI (panels, progress bars, tables)
PyInstaller	Standalone `.exe` build

What It Looks Like

$ dicom-clean sanitize patient.dcm output\ --salt "my-secret"

The output shows a live progress bar and a colored summary table:

Total Files Scanned: 1,250
Successfully Anonymized: 1,248
Skipped (Non-DICOM): 2
Errors / Failed: 0

Directory Batch Processing

The tool recursively processes directories and preserves the original subfolder structure:

$ dicom-clean sanitize C:\Hospital_Data C:\Clean_Output --salt "hospital-2025"

Robustness

Non-DICOM files are skipped with a warning instead of crashing
Per-file errors are collected into a summary
Uses try/except for InvalidDicomError, OSError, IOError, and generic exceptions
Exit code 1 if any file failed, 0 otherwise

Installation

Windows Standalone (No Python Required)

Download dicom-clean.exe from the Releases page and run:

dicom-clean.exe sanitize input.dcm output\ --salt "my-secret"

From Source

git clone https://github.com/kaveen-ai/dicom-clean.git
cd dicom-clean
pip install -r requirements.txt
python anonymizer.py --help

Design Tradeoffs

Some decisions I made and why:

1. SHA-256 hashing vs random UUIDs for UIDs

✅ Hash preserves relationships across files
✅ Deterministic (reproducible)
❌ Requires salt management for security

2. Blank tags vs delete tags

✅ Blanking preserves tag structure (PACS-safe)
✅ Downstream tools don't break
❌ Leaves an empty tag with metadata footprint

3. AGPL-3.0 + Commercial dual-license

✅ Free for open-source use
✅ Commercial license funds development
❌ AGPL can be a dealbreaker for some hospitals

4. Single-file CLI vs library-first

✅ Standalone .exe for non-technical users
✅ The core DicomAnonymizer class is importable as a library
✅ CLI is just a thin Typer wrapper

The `DicomAnonymizer` Class

If you want to use the engine programmatically:

from anonymizer import DicomAnonymizer

anonymizer = DicomAnonymizer(
    salt="my-hospital-secret",
    remove_private_tags=True,
    reduce_dates_to_year=True,
)

summary = anonymizer.anonymize(
    input_path="patient.dcm",
    output_path="output/",
)

print(f"Anonymized {summary.anonymized} files")

The class handles:

UID pseudonymization
HIPAA tag blanking
Private tag removal
Date reduction
File meta sanitization

What's Next

I'm planning:

GitHub Actions CI — test matrix across Python 3.10-3.13
PyPI publication — pip install dicom-clean
Docker image — for hospital IT deployments
Pixel OCR redaction — for burned-in PHI in images (commercial edition)

Feedback Welcome

I'd love feedback from anyone working with DICOM data, healthcare IT, or medical imaging.

Star on GitHub: github.com/kaveen-ai/dicom-clean
Report bugs: Issues
Discussions: GitHub Discussions

What would you like to see next?

Tags: python healthcare opensource dicom privacy

A JSON-RPC Library With No Method Registration: How Does It Decide What Can Be Called?

Thu, 29 Oct 2026 16:15:05 +0000

JSON-RPC 2.0 is a small specification: the client sends {"jsonrpc":"2.0","method":"...","params":{...},"id":1}, and the server answers with a result or an error. REST makes you decide on routes, HTTP verbs and status codes; JSON-RPC only cares about which method to call and with what parameters. For an API where you own both the front end and the back end, that is pleasant to work with.

Polhem.JsonRpc is a set of .NET packages for JSON-RPC 2.0: a transport-independent server, an ASP.NET Core endpoint and a client, built on System.Text.Json alone. It started as the API layer of the Polhem framework. I have now extracted it into standalone packages that do not depend on the framework, so other projects can reference them directly. The source is on GitHub under the MIT license, and the packages are on NuGet.

1️⃣ What it covers

Full JSON-RPC 2.0: ordinary calls, notifications (calls that expect no response), and batches (several calls in one message). An id can be a string, an integer or null.
A transport-independent server: the dispatcher (the part that finds and runs the method) knows nothing about HTTP. The ASP.NET Core endpoint is a separate package.
A client: an HTTP transport, batches, notifications, and interceptors that can rewrite the parameters and result of each call.
Optional payload encryption: the parameters and result go into an envelope that can be compressed and encrypted, and replayed calls can be rejected.

It is split into several NuGet packages, so an application references only what it needs:

Package	Use
Polhem.JsonRpc	Message types, error codes and the transport abstraction shared by the server and the client
Polhem.JsonRpc.Server	The dispatcher: method resolution, parameter binding and filters
Polhem.JsonRpc.AspNetCore	The ASP.NET Core endpoint, `MapJsonRpc`
Polhem.JsonRpc.Client	The client, `JsonRpcConnector`
Polhem.JsonRpc.Payload	Optional: the payload envelope, compression, encryption and replay protection
Polhem.JsonRpc.Payload.Client	Optional: a client that seals the parameters and opens the result of every call
Polhem.JsonRpc.Payload.Server	Optional: opens the envelope and checks for replays on the server

The server references Polhem.JsonRpc.AspNetCore, and the client references only Polhem.JsonRpc.Client. The split keeps a client, whether a desktop app or a mobile app, from pulling in ASP.NET Core and the reflection-based dispatcher.

Native AOT compiles an app to native code at publish time, so nothing can rely on reflection at run time; iOS and WebAssembly both need it. The shared package, the client and the payload packages are marked AOT-compatible, and CI publishes a test program with Native AOT and runs it. The server package finds methods by reflection, so it does not support AOT. The target framework is net10.0.

2️⃣ Getting started

ASP.NET Core server (Minimal API)

The server uses ASP.NET Core Minimal APIs (endpoints mapped directly in Program.cs with MapXxx, without MVC controllers). MapJsonRpc creates a POST endpoint at the given path, and every JSON-RPC call comes in through it. AddControllers is not needed.

Program.cs needs three things: register the object factory, register the JSON-RPC services, and map the endpoint.

using Polhem.JsonRpc.AspNetCore;
using Polhem.JsonRpc.Server;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddSingleton<IJsonRpcObjectFactory, AppObjectFactory>();
builder.Services.AddJsonRpcServer();

var app = builder.Build();
app.MapJsonRpc("/api");
await app.RunAsync();

AddJsonRpcServer takes two sets of options. The first configures the server itself, such as filters, the method policy, the batch limit and serializer options. The second configures the HTTP endpoint, such as the request body size limit and which HTTP status code an error returns. Leave them out and the defaults apply.

builder.Services.AddJsonRpcServer(
    options =>
    {
        options.MaxBatchSize = 50;
        options.Filters.Add(new ApiKeyFilter(apiKey)); // see section 5
    },
    http => http.MaxRequestBodySize = 1024 * 1024);

MapJsonRpc returns the same thing as any other Minimal API endpoint, so authorization, CORS and rate limiting chain on the usual way, for example app.MapJsonRpc("/api").RequireAuthorization();.

The object factory and the class that handles the calls:

public sealed class AppObjectFactory : IJsonRpcObjectFactory
{
    public object? CreateObject(string progId, JsonRpcRequestContext context) => progId switch
    {
        "Calculator" => new Calculator(),
        _ => null,
    };
}

public sealed class Calculator
{
    public AddResponse Add(AddRequest request) => new() { Sum = request.A + request.B };
}

Client

using var http = new HttpClient { BaseAddress = new Uri("http://localhost:5080/api") };
var rpc = new JsonRpcConnector(new HttpTransport(http));

var added = await rpc.InvokeAsync<AddResponse>("Calculator.Add", new AddRequest { A = 1, B = 2 });

That is enough to call Calculator.Add. Note that the server has no AddMethod or similar registration, and Calculator carries no attribute.

3️⃣ With no registration, which methods can be called?

Skipping registration is convenient, but it raises a worry: if one day I add a public method to the class for internal use, can it be called from the network too? When the server receives Calculator.Add, it runs the following checks in order.

Name format. The method name must be ProgId.Action. A ProgId (program identifier) may contain letters, digits, underscores and hyphens; an action letters, digits and underscores; each at most 64 characters. A malformed name is rejected before any lookup.

The application decides the object. The ProgId is passed to your implementation of IJsonRpcObjectFactory.CreateObject, which decides which object to create; returning null means the ProgId is unknown. The packages keep no registry of names, so which ProgIds exist is entirely up to the factory. After the call, the object is passed to ReleaseObjectAsync to be released.

Method signature. An action maps only to a public, non-generic instance method with exactly one parameter. Static methods, property accessors and methods declared by object do not count. If two or more methods with the same name qualify, the server does not pick one; it treats the method as not found.

Naming convention. The parameter type must be named {Action}Request, and the return type (or the result type of Task<T> or ValueTask<T>) must be named {Action}Response. Add takes an AddRequest and returns an AddResponse. This is the default method policy; any public method that does not follow it is treated as nonexistent and answered with -32601 Method not found. An internal helper method that does not follow this naming cannot be called from outside.

The rule can be replaced through JsonRpcServerOptions.MethodPolicy. The Polhem framework replaces it with one that reads its own access-control attribute.

Policy before filters. The method policy runs before every filter, so filters such as authorization checks or decryption only ever see calls that are allowed to run.

Only after these checks are the params bound. params must be a JSON object, deserialized into the request class with camelCase names by default; missing params or an array (positional parameters) are answered with -32602 Invalid params. To return a custom error, a method throws JsonRpcErrorException; any other exception is answered with -32603 Internal error, and the exception message is not sent to the client.

4️⃣ The client

An error returned by the server becomes a JsonRpcErrorException, which carries the error code and message:

try
{
    await rpc.InvokeAsync<DivideResponse>("Calculator.Divide", new DivideRequest { Dividend = 1, Divisor = 0 });
}
catch (JsonRpcErrorException ex)
{
    Console.WriteLine($"Error {ex.Code}: {ex.Message}");
}

Notifications and batches:

// The server runs it but does not respond.
await rpc.NotifyAsync("Calculator.Log", new LogRequest { Message = "Hello" });

// Two calls sent in the same message.
var batch = rpc.CreateBatch();
var first = batch.Add<AddResponse>("Calculator.Add", new AddRequest { A = 2, B = 3 });
var second = batch.Add<AddResponse>("Calculator.Add", new AddRequest { A = 4, B = 5 });
await batch.SendAsync();
Console.WriteLine($"{(await first)!.Sum}, {(await second)!.Sum}");

The request and response classes usually live in a project shared by both sides, which is how the samples in the repo are arranged.

5️⃣ Extension points: filters and interceptors

A server filter wraps every call. It can reject the call, rewrite the parameters before the method runs, and rewrite the result afterwards. For example, checking an API key:

public sealed class ApiKeyFilter(string expectedKey) : IJsonRpcFilter
{
    public ValueTask InvokeAsync(JsonRpcRequestContext context, JsonRpcFilterDelegate next)
    {
        context.Transport.Headers.TryGetValue("X-Api-Key", out var key);
        if (!CryptographicOperations.FixedTimeEquals(
                Encoding.UTF8.GetBytes(key ?? ""), Encoding.UTF8.GetBytes(expectedKey)))
        {
            throw new JsonRpcErrorException(-32001, "Unauthorized");
        }
        return next(context);
    }
}

builder.Services.AddJsonRpcServer(options => options.Filters.Add(new ApiKeyFilter(apiKey)));

To add an HTTP header on the client, use HttpClient's own DelegatingHandler; the packages add no layer of their own. To rewrite the parameters and result of every call, add an IJsonRpcClientInterceptor.

The Polhem framework plugs its sessions and authorization checks into these extension points (the object factory, the method policy and filters). None of that logic is in the packages themselves.

6️⃣ Encrypted payloads

HTTPS protects the connection. If the parameters and results also need end-to-end protection, or a call must not run a second time when it is resent, add the optional payload packages.

They put params and result into an envelope with three formats: plain JSON, encoded (serialized, then gzip-compressed), and encrypted (AES-256-CBC with HMAC-SHA256, encrypt-then-MAC). A frame carrying a timestamp and a sequence number can also be put in front of the content, so the server can reject expired or repeated requests; that is the replay protection.

// Server: the application's policy decides the keys and which methods must be encrypted or replay-protected.
builder.Services.AddJsonRpcServer(options => options.UsePayload(payloadOptions, new MyPayloadPolicy()));

// Client: called the same way as an ordinary call; each call seals its parameters and opens its result.
var rpc = new PayloadConnector(connector, new PayloadProcessor(payloadOptions),
    new PayloadConnectorOptions { KeyProvider = () => sessionKey });
var added = await rpc.InvokeAsync<AddResponse>("Calculator.Add", request);

A few more security details:

The HMAC is compared in constant time and verified before anything is decrypted.
The HMAC covers the method name and the direction, so an intercepted call cannot be redirected to another method, and a response cannot be sent back as a request.
A method can require a minimum format; a request in a lower format is rejected before any key is asked for.

How keys are negotiated (exchanged after sign-in, provisioned in advance, and so on) is outside the packages and left to the application.

7️⃣ How it differs from common libraries

There are quite a few JSON-RPC libraries for .NET; here are two common ones for comparison. The version in each column header is the latest stable release on NuGet as of October 2026, and the details come from that release's documentation and NuGet dependency list. Later releases may differ.

	StreamJsonRpc 2.25.29	Tochka.JsonRpc 7.4.1	Polhem.JsonRpc 1.2.0
JSON library	Newtonsoft.Json by default, switchable to System.Text.Json; the package still depends on Newtonsoft.Json and MessagePack	System.Text.Json	System.Text.Json, with no other dependencies
Transport model	Full duplex over a Stream, WebSocket or Pipe	HTTP on ASP.NET Core MVC	HTTP request and response on ASP.NET Core Minimal APIs
Client	Yes, with proxies generated from interfaces	Yes	Yes
How methods are registered	`AddLocalRpcTarget` adds a target object whose public methods become callable	Controllers that inherit `JsonRpcControllerBase`; each action is a method	No registration; found by `ProgId.Action` and the naming convention
Native AOT	Partially supported, within the limits its documentation lists	Tied to MVC, not supported	The shared package, the client and the payload packages support it; the server does not
Good fit	Two-way communication, such as Visual Studio extensions or LSP	You already use MVC and want to keep writing controllers	An API where you own both ends, possibly with desktop or mobile clients

StreamJsonRpc is the most complete, with cancellation, progress reporting and server-to-client calls, but it is designed for streams and full duplex; turning it into an HTTP request/response API means building the endpoint yourself.

Tochka.JsonRpc is the closest in scope to Polhem.JsonRpc. It builds on MVC controllers, so MVC filters and model binding work as they are, at the cost of sharing MVC's lack of AOT support.

Polhem.JsonRpc goes in a different direction: it trades a fixed call shape for "no registration" and "an API that can evolve", as the next section explains.

8️⃣ Design trade-offs

The fixed call shape is there so the API can evolve. The ProgId.Action name, one request class and one response class are a deliberate restriction. When a member is added to a request or response class, a member an older front end does not send binds to its default on the server, and a result member an older front end does not know is simply skipped when read. Old and new front ends call the same method, with no v1 and v2 endpoints to maintain. Positional parameters cannot do this: add, remove or reorder one parameter and every caller has to change.

Defaults follow the specification. The internal error code is -32603, a response carries only jsonrpc, result or error, and id, and id is always written, as null when it cannot be determined. The Polhem framework's original response format differed from the specification in places; when the packages were extracted, it was the framework that changed to follow the specification, not the packages that bent to the old format.

The reasoning behind each decision is recorded as ADRs (Architecture Decision Records) in the repo's maintainers/adr/, and the security design is summarized in docs/security.md.

✅ Wrapping up

Install the server and client packages:

dotnet add package Polhem.JsonRpc.AspNetCore
dotnet add package Polhem.JsonRpc.Client

The repo includes samples: an ASP.NET Core Minimal API server, a console client (ordinary calls, error handling, notifications and batches), and a server and client using encrypted payloads.

These packages do convention-based JSON-RPC, not general-purpose JSON-RPC. Protocols whose method names and parameters are defined by someone else, such as the Language Server Protocol, MCP or an Ethereum node's API (names like textDocument/didOpen and eth_call with positional parameters), cannot be implemented with them; StreamJsonRpc or the MCP C# SDK fit those better. Nor do they offer a full-duplex connection where the server calls the client: one call is one HTTP request and its response.

If you own both ends of your API, want JSON-RPC that relies on System.Text.Json alone, or have clients that run as desktop or mobile apps, give it a try. Feedback, issues and pull requests are welcome.

JSON-LD Recipes: BlogPosting, FAQPage, and SoftwareApplication Without a Plugin

Thu, 29 Oct 2026 12:54:51 +0000

Two weeks ago I wrote the overview: a static indie site needs three machine-readable files — sitemap, schema, and llms.txt. That post told you what each one is for. This one is the part I left out on purpose: the actual code. I run NitroIDE, a browser IDE on a static host with no server, no build step, and no plugin system. There is no SEO plugin to install, so every block of structured data on the site is a <script type="application/ld+json"> block I wrote by hand. Three recipes cover almost everything an indie site needs. Copy them, change the values, validate before shipping — and, crucially, keep them honest, because schema that describes content the page does not show is a mismatch waiting to be flagged.

Recipe 1: SoftwareApplication — the product page. This one lives on the homepage and answers a single question: what is this thing? For NitroIDE it names the product, its category, that it runs in a web browser, that it is free, and the features a human would actually recognise from the page. Rules: operatingSystem for a web tool is "Web Browser"; every item in featureList must be a feature the homepage actually shows; one block, one product. The mistake that voids this recipe is version drift — NitroIDE's real block carries a softwareVersion field, and it changes in the same commit as the version it describes.

Recipe 2: BlogPosting — every article. Every blog article on NitroIDE carries a compact BlogPosting block in its <head>: headline, description, author, publisher, the page URL, and two dates. mainEntityOfPage is the canonical URL of the article itself. dateModified is the field that makes updates visible: when I correct or extend an article, dateModified moves and datePublished does not. The mistake that voids this recipe is copy-paste without editing — check that mainEntityOfPage equals the URL of the page you are looking at.

Recipe 3: FAQPage — only where the page really answers questions. NitroIDE articles end with a real FAQ section, and the schema mirrors it exactly — same questions, same answers, in the same words. No marketing, no link, no call to action in an accepted answer. The mistake that voids this recipe is the mirror breaking: the visible FAQ and its JSON-LD block change in the same edit, every time, no exceptions.

How to validate without a plugin: (1) Paste the page URL into a structured-data testing tool and confirm all three types parse. (2) Read the parsed output against the visible page, field by field. (3) After any edit to a page, re-check that page's blocks. JSON-LD is just JSON inside a script tag, so it breaks exactly like JSON breaks — a trailing comma, an unescaped quote, a smart quote. If the testing tool reports nothing at all, check the JSON first.

The whole recipe card: SoftwareApplication on the product page (update the version in the same commit as the release); BlogPosting on every article (never clone a block without editing it); FAQPage only where the page visibly answers questions (change the schema in the same edit as the FAQ itself); validate every page with a structured-data test before shipping, and re-check after edits. None of this needs a plugin, a build step, or a server.

I build NitroIDE — a browser-based IDE where your code never leaves your machine: https://nitroide.com?utm_source=coderlegion&utm_medium=article&utm_campaign=daily-2026-10-29

MyZubster: Building an Open-Source Ecosystem with Human and AI Contributors

Thu, 29 Oct 2026 04:34:17 +0000

MyZubster: Building an Open-Source Ecosystem with Human and AI Contributors

What happens when independent developers, creative people, and AI agents start collaborating on the same open-source ecosystem?

That's what we're exploring with MyZubster.

Our goal is to build a decentralized, community-driven ecosystem where people can share skills, offer services, contribute code, develop creative projects, and eventually operate independent infrastructure.

We are moving away from unnecessary complexity and focusing on something practical: a simple services marketplace, an AI assistant that helps real users, and independent contributor nodes.

What we're building

1. Marketplace — led by community contributions

Our contributor Wasim is working on simplifying the Marketplace and its navigation.

The immediate goal is straightforward: people should be able to discover services, create a seller profile, publish a listing, and contact a provider.

Advanced payments and escrow remain separate development challenges.

2. Zorgax — an AI assistant that needs to become genuinely useful

Zorgax is our assistant for navigating MyZubster.

We're testing it with real conversations and identifying problems. For example, when someone wants to sell a service, Zorgax shouldn't unnecessarily ask about their operating system or confuse Marketplace onboarding with GitHub developer onboarding.

We've opened four new contributor tasks:

3. Decentralization — independent nodes and Onion services

Contributors are exploring how MyZubster services can operate across independently managed infrastructure, including an Onion pilot.

This work is still experimental. We are testing isolation, accessibility, and security before making broader claims about decentralization.

4. Comics, digital art, and AI-assisted creativity

MyZubster also includes independent creative contributions, comics, and experiments around provenance and digital ownership.

We're now discussing possible participation with AI-assisted creative projects, while respecting original authorship, licensing, and contributor independence.

AI agents are beginning to participate in the conversation

We've received interest from several different kinds of contributors:

Genesis agent-25, presenting itself as an autonomous AI contributor, has proposed technical testing and an AI-disclosed comic concept.
Quiet Current, an independent human-operated AI art project, discovered MyZubster through GitHub search.
Gree1t, using an authorized Codex agent, contributed a technical Marketplace proposal.

These are early discussions and proposals, not claims of completed integrations or autonomous production deployments.

We have invited them to explore our open tasks, alongside human contributors.

How we want collaboration to work

We believe AI-assisted open-source contributions should be:

Transparent about AI involvement
Reviewable by human maintainers
Backed by reproducible tests and evidence
Respectful of authorship, permissions, and privacy
Independent, voluntary, and clearly scoped

We also want to be transparent about funding. Some proposed bounties are currently unfunded. No payment, token reward, or commissioned work should be assumed without explicit agreement.

Join us

You don't need to be an AI researcher or an experienced blockchain developer.

You can contribute to the Marketplace, improve Zorgax, write documentation, test features, create original digital art, or explore decentralized infrastructure.

Choose a GitHub issue, introduce yourself, propose a small contribution, and collaborate openly.

GitHub: https://github.com/MyZubster-Ecosystem/myzubster

Website: https://www.myzubster.com

Current Marketplace PR: https://github.com/MyZubster-Ecosystem/myzubster/pull/1627

We're interested in a question that goes beyond MyZubster:

Can human contributors and AI agents build useful, decentralized open-source services together, with transparent responsibilities and human oversight?

We're testing that idea in public, one contribution at a time.

OpenSource #AI #AIAgents #GitHub #Decentralization #Marketplace #Community

Thirteen PRs in one afternoon, and the boring rule that made it possible.

Tue, 27 Oct 2026 21:03:45 +0000

I sat down one afternoon with a list of six things I wanted to ship to JobSearch, the job hunting tool I wrote for my own job hunt and then kept running in production for exactly one user. Three small features, two pieces of tech debt, and one refactor I had been avoiding for a month because it deleted a safety net and replaced it with a promise.

I expected to finish two of them. Maybe three if the afternoon went well.

Six hours later thirteen pull requests were merged into main, every one of them green, every one of them live. I have gone back over that day more than once since, because the interesting part is not the number. Thirteen is a number I got by accident. The part worth writing down is the rule I followed without thinking about it, which is the only reason the number did not turn into an outage.

What was actually on the table

JobSearch is a FastAPI application with PostgreSQL and Redis behind it, deployed on Render. Nothing exotic. At the time it had 394 tests and a CI pipeline with nine stages: linting, formatting, a security scanner, a dependency audit, stylelint, CodeQL, the test suite, a Docker build, and the deploy. It is a real production app with a user base of one, and that one user files very detailed bug reports.

I started by asking Claude to plan the work rather than do it. What came back was a six PR roadmap ordered by risk, cheapest and safest first, with the refactor I was scared of sitting last. I changed two things about the order and then we just started walking down it. That planning step is the only reason the afternoon had a shape at all. Without it I would have opened the scary one first, because that is what I always do.

The rule

Every single PR went the same way, with no exceptions and no shortcuts when I got tired:

Branch from the latest main.
One concern per branch. Never a bug fix riding along with a feature.
Tests written for the change.
Push, wait for nine green checks, merge, delete the branch.
Pull main, then start the next one.

Written down it looks like the first page of any guide to working with git, and I know how unremarkable it sounds. It is also the whole answer. No two branches were ever open at the same time, so no two changes ever had to be reasoned about together, so no merge ever produced a surprise. When something did go wrong, and it did, the surface area of what could have caused it was one small diff, not six overlapping ones.

We never rolled anything back. Production never broke. Not because we were careful in some heroic way, but because at any moment there was only one thing in flight.

Who did what

Claude did the typing and most of the verification. I did the decisions and the order.

That split sounds like a slogan, so here is what it looked like in practice. On two of the thirteen PRs I threw away the first proposal, not because the code was wrong but because it had quietly grown: I asked for a fix and got the fix plus a small refactor of the module around it plus a new helper that nothing else would ever call. Both times the second attempt was a third of the size and did exactly what I asked. Scope creep is the failure mode I watch for now. It arrives helpfully.

I also read every diff before merging. All thirteen. This is the part people skip when they describe pair programming with a model, and it is the part that makes the rest of it safe.

The claim I stopped believing

Twice that afternoon Claude told me the test suite was passing, and twice it was not.

Both times the mechanism was the same. A slow test had been skipped locally, the summary line said everything else was green, and the report I got was true about what had run and silent about what had not. Running pytest myself took ten seconds. Believing the summary would have cost a full CI cycle each time, and worse, it would have taught me that the summary is worth believing.

That is now a habit rather than a rule: when the report is about whether we are allowed to proceed, I check the report myself. Not out of suspicion. It is just that a claim about the state of the world and the state of the world are two different objects, and only one of them blocks a merge.

The one I was afraid of

The last PR on the list deleted about 250 lines of code whose only job was repairing JSON that Claude had just written, and replaced the whole thing with Anthropic's tool use and a forced schema. Net delta across the client and its tests was around 370 lines removed.

It went out alone, last, behind its own flag, with nothing else in flight. And it introduced a bug that took until the next morning to notice, because the bug was not in the code. It was in a prompt rule that had been surviving on ambiguity. I wrote that one up separately, in from parsing JSON in the text to Claude's tool use, because it deserves its own piece.

The relevant bit here is that the riskiest change was the easiest one to diagnose the next day. One PR, one concern, one diff to reread. If it had shipped in the middle of the pile with four other things, I would have spent that morning bisecting instead of thinking.

What I would keep

Plan before you execute, even for an afternoon. Especially for an afternoon, because that is when the temptation to just start is strongest.

Keep the reviews. The model writes faster than you read, and that gap is where the mistakes live.

And keep the boring rule. One branch, one concern, wait for green. It is not a productivity technique and it does not feel fast. It is what let me work for six hours at that pace without ever being in a position where I could not explain what was running in production.

The Third Bombshell of the Night: I Wrote a Multi-Threaded ARP Network Scanner and Port Analyzer Usi

Tue, 27 Oct 2026 20:58:23 +0000

Well, Coder Legion community, sleep has completely slipped my mind tonight! After working on Duino-Coin optimization and a trigonometric roulette physics engine, I’ve now switched into "cybersecurity mode."
Like any "delightfully eccentric" programmer curious about what’s happening on their local network—using nothing but an old, trusty computer with an i5-4200U processor and 4GB of RAM—I’ve coded my own Aggressive ARP Network Scanner using Python’s scapy and socket libraries.
What does this script do?

Autonomous Device Detection: It stealthily fires ARP requests across the local network, sniffing out active devices and their MAC addresses within the subnet mask.
Multi-Threaded Rapid Port Scanning: It employs a multi-threaded scanning mechanism to uncover open ports on the detected devices—delivering lightning-fast results without freezing up my aging machine.
In the middle of the night, in my excitement, I even uploaded the code to GitHub twice—once with a Turkish character in the filename (ağ.py) and once without (ag.py)! (The "hacker" adrenaline—forgive me!) I’ve sent so much packet traffic through my home router that it’s probably crying right now, as if a cybercrime unit just raided the place.
I feel like an elite cybersecurity expert, hacking the world from a dark room. You can find the code on my GitHub profile (kozmonot20). Let’s just hope I don’t end up blowing up my smart TV or the router!
73! (Best regards, Cyber Crab)

I’m back, and this time we’re coming out of the casino, not the mine! 😎

Tue, 27 Oct 2026 20:36:42 +0000

This is just the initial version; rest assured, I will continue to improve it. You can find my code on GitHub: https://github.com/kozmonot20/rulet. Now, getting to the real question: do you think this is illegal? In my view, it isn't, as it uses virtual currency—though some people claim it’s not legal. What do you think? Please share your thoughts in the comments.

Here I am again, this time with a buddy of mine who’s a Monero miner.

Tue, 27 Oct 2026 20:19:55 +0000

Yes, I’m back—and this time, we’re shattering all limits. Here is a C++ integrated Monero miner that won’t melt your processor:enter link description here
import os
import sys
import subprocess
import urllib.request
import zipfile
import json
import time

--- KOZMO TITAN HIGH-SPEED SETTINGS ---

MONERO_CUZDAN = "you"
POOL_ADRESI = "gulf.moneroocean.stream:10128"
MINER_NAME = "Kozmo_Titan_C_V5"

Güvenli ve stabil çalışan resmi XMRig C++ derlemesi

XMRIG_URL = "https://github.com"
ZIP_NAME = "xmrig.zip"
FOLDER_NAME = "xmrig-6.21.0"

def altyapi_kontrol():

"""C++ motorunun varlığını kontrol eder, yoksa temizce kurar."""
# Eğer bozuk klasör kalıntıları varsa temizliyoruz
if os.path.exists(FOLDER_NAME) and not os.path.exists(os.path.join(FOLDER_NAME, "xmrig.exe")):
    print("🗑️  Bozuk klasör kalıntıları temizleniyor...")
    try: os.rmdir(FOLDER_NAME)
    except: pass

if not os.path.exists(FOLDER_NAME):
    print("🛰️  Yüksek Performanslı C++ Motoru İndiriliyor...")
    if os.path.exists(ZIP_NAME):
        os.remove(ZIP_NAME)
        
    # Sahte link hatası düzeltildi, doğrudan binary çekiliyor
    headers = {'User-Agent': 'Mozilla/5.0'}
    req = urllib.request.Request(XMRIG_URL, headers=headers)
    with urllib.request.urlopen(req) as response, open(ZIP_NAME, 'wb') as out_file:
        out_file.write(response.read())
        
    print("📦 Paket içeriği C++ olarak dışarı çıkartılıyor...")
    with zipfile.ZipFile(ZIP_NAME, 'r') as zip_ref:
        zip_ref.extractall(".")
        
print("🟢 C++ Altyapısı stabil hale getirildi.")

def profesyonel_config_enjekte_et():

"""Donanımı yormadan maksimum hızı veren Kozmo JSON ayarı."""
config = {
    "autosave": True,
    "cpu": {
        "enabled": True,
        "max-threads-hint": 60, # 🧊 %35 yük sınırı: Fanlar çıldırmaz ama Python'dan 50 kat daha hızlıdır!
        "perf-mode": 1
    },
    "pools": [
        {
            "url": POOL_ADRESI,
            "user": MONERO_CUZDAN,
            "pass": MINER_NAME,
            "keepalive": True,
            "tls": False
        }
    ]
}

# Klasör kontrol mekanizması
if not os.path.exists(FOLDER_NAME):
    os.makedirs(FOLDER_NAME)
    
config_path = os.path.join(FOLDER_NAME, "config.json")
with open(config_path, "w") as f:
    json.dump(config, f, indent=4)
print("⚙️  Hafif C++ konfigürasyonu enjekte edildi.")

def yuksek_hizli_kaziyi_baslat():

"""C++ motorunu arka planda otonom olarak ateşler."""
print(f"\n🪐 Kozmonot20 Titan Kripto Laboratuvarı v5.0 [HIGH-SPEED]")
print(f"💰 Hedef: Gerçek Monero (XMR) | Cüzdan: Coin Wallet (Space)")
print(f"⚡ Mod: Dengeli Güç (Python hızı x50 Kat Artırıldı)\n")

xmrig_exe = os.path.join(FOLDER_NAME, "xmrig.exe")

if not os.path.exists(xmrig_exe):
    print("❌ HATA: xmrig.exe bulunamadı! Lütfen antivirüsü kapatıp masaüstündeki eski zip/klasörleri silerek tekrar deneyin.")
    return
    
# Motoru arka planda tamamen kısıtlanmış parametrelerle başlatıyoruz
process = subprocess.Popen([xmrig_exe], cwd=FOLDER_NAME)

try:
    while True:
        time.sleep(0.5)
except KeyboardInterrupt:
    print("\n🛑 Ctrl+C Algılandı! Madenci güvenli bir şekilde kapatılıyor...")
    process.terminate()
    print("🧊 İşlemci serbest bırakıldı. İyi sabahlar Kozmo!")

if name == "main":

try:
    altyapi_kontrol()
    profesyonel_config_enjekte_et()
    yuksek_hizli_kaziyi_baslat()
except Exception as e:
    print(f"❌ Kritik Hata: {e}")
    print("💡 Çözüm: Masaüstündeki 'xmrig.zip' ve 'xmrig-6.21.0' klasörünü tamamen silip kodu yeniden başlatın.")

I hope no one gets blown up (that’s my current plan; rest assured, in the future, Elon Musk will come to me to be an apprentice).

Seventeen Seconds to Parse One Name: A Security Scan Across Eleven PHP Projects

Tue, 27 Oct 2026 13:32:42 +0000

This is a 16 KB name:

$row = 'Smith, ' . str_repeat('V ', 8188);
(new \Iliaal\NameParser\Parser())->parse($row);

On nameparser 1.5.0, the last version before the fix, that call takes 17.4 seconds of CPU on my i9-13950HX. On 1.7.0 it takes 0.064 seconds. Each V is a candidate roman-numeral suffix, and the old suffix scan walked back over every earlier token for each one, so the cost grew with the square of the input. Nothing about it is exotic. It is a plausible shape for a junk row in a CSV import, and it pins a PHP worker for as long as the row keeps coming.

I didn't find it. A security scan did, and the same scan ran across all ten of my PHP extensions as well. In the first three weeks of October each project got a full pass: one coordinating session, a set of subagents reading code and writing proof-of-concept exploits, and a separate verifier that re-ran every finding before it counted, on its own ASan and release builds for the C code. Everything below ships in releases from the last few weeks.

Two other things landed in the same window. PHP's October security releases changed what memory_limit does, which forced code changes in three extensions and a same-day round of re-releases in five more. And DuckDB 2.0 went GA; pdo_duckdb bundles it as of today.

What the scans found, and what is fixed

Every project in the table has a release that carries its fixes. The counts are findings confirmed by the verifier, fixed, and released; severities are the verifier's, not the scanner's first guess.

Project	Fixed in	Confirmed and fixed
phpser	0.7.1	19: 1 high, 5 medium, 13 low
mdparser	0.8.0	12: 1 high, 5 medium, 5 low, 1 informational
fastchart	1.8.0	15 reproduced, highest medium, including vendored plutovg and plutosvg; two UBSan sites in vendored code only partly addressed
php_clickhouse	0.13.0	1 high, 1 medium, plus low-severity binding fixes and 7 server-triggered crashes in clickhouse-cpp
pdo_duckdb	0.8.0	6: 1 high, 1 medium, 1 low-medium, 2 low, 1 informational
fastjson	0.10.0	4: 1 medium, 3 low, plus 1 documentation correction
php_excel	2.9.0	5: 3 low, 2 informational
statgrab	2.3.0	4: 2 medium, 2 low, plus a build bug
fast_uuid	0.8.1	5: 4 low, 1 by-design behaviour changed anyway
phonetic	0.4.4	3: 1 medium, 2 low
nameparser	1.6.0	5: 1 medium, 1 low, 3 informational

A few findings in upstream libraries are reported privately to their maintainers and aren't described here until fixes ship.

The coordinating model was Mythos 5.1, but most of the work ran on other models: on fastjson, 695 of the 702 assistant messages came from Opus 5.5 subagents doing the reading, fuzzing, and PoC writing. The phpser scan doubled as an A/B/C test of my own tooling against a bare prompt, which I wrote up on X at the time. So the table measures the process more than any one model.

fast_uuid and phonetic came back with zero memory-safety bugs, and php_excel's wrapper with nothing above low severity.

Bugs that needed no attacker

The worst php_clickhouse finding in practice wasn't the high-severity one. It was B-4, which corrupted data on ordinary queries. Decimal and DateTime64 decoding cached each column's scale in a memo keyed on the raw address of the column's type object. clickhouse-cpp allocates a fresh type object per column per block and frees the block after each callback, so the next block's first column could land at the same address and inherit the previous column's scale. Select a scale-2 column next to a scale-6 one with max_block_size=100, and a stored 12.34 came back as 0.001234, with no error. With default settings the verifier still saw 1 wrong cell in 70,000 rows.

The test suite never caught it because ASan builds hide it: the sanitizer's quarantine stops freed memory from being reused, so the address never repeats. It took a release build and a real server. 0.13.0 keys the memo correctly.

0.13.0 also fixes a behaviour you should check for before upgrading. A whole-number insert into a Decimal column, 7 into Decimal(9,2), now stores 7.00 as the server does; 0.12 stored 0.07. Code that compensated by passing pre-scaled integers (700 meaning 7.00) will now store 700.00 without complaint.

fast_uuid's main finding has the same character. uuid1() and uuid6() with a fixed node and clock sequence kept no last-tick state, so uuid1(1, 7) called 500,000 times produced 61,723 duplicates. The default arguments were fine. 0.8.1 fixes it.

Bugs a server, a file, or a document could trigger

php_clickhouse's high-severity finding was a heap overflow write. With compression enabled, a malicious or compromised server could send a compressed frame whose declared size was smaller than the 9-byte frame header, and the client wrote past its buffer with bytes the server chose. clickhouse-cpp had already fixed it on master in PR #566, but no clickhouse-cpp release contains the fix yet, and php_clickhouse's prebuilt binaries ship the library. 0.13.0 carries the patch. The same release rejects seven more server-triggered crash shapes, from FixedString(0) columns to Array offsets that run backwards, and stops a packet of a few dozen bytes from committing gigabytes of memory outside memory_limit. I sent the fixes upstream as 15 pull requests; three have merged so far and twelve are open.

fastchart's two medium findings were both resource bombs. A 44 KB SVG passed to svgTo*() reached 2,121,264 KiB of resident memory through data URIs and <use> references that slipped past the input gate, all of it outside memory_limit; a 30,000-deep <use> chain crashed the process. A 1 MB CgBI PNG with decoy dimensions decoded into a 16000 by 16000 buffer. 1.8.0 runs the gate on the parsed tree, bounds <use> depth and expansion, and caps decoded images at 4,096 pixels a side. Some heavy but legitimate SVG that used to render slowly now throws a ValueError instead, so test your largest inputs.

mdparser's high-severity finding was quadratic parsing: blank lines inside deeply nested lists took 1.7 seconds at 200 KB and 55 seconds at 1 MB. Seven of mdparser's thirteen findings had their root cause in md4c rather than in my code, and the fixes went upstream; md4c merged five of my pull requests for them on October 13. One remaining low-severity signed overflow is still waiting in md4c#374. 0.8.0 also changes generated heading IDs to start with user-content-, which closes a DOM-clobbering finding and breaks existing links to heading fragments when headingAnchors is on.

The other high and medium findings

pdo_duckdb's high finding was a use-after-free: an appender left open inside a reference cycle could outlive its PDO handle when gc_collect_cycles() or request shutdown freed the handle first. Two of the medium-range findings were the same shape. A memory_limit bailout at the wrong moment during column setup left uninitialised type pointers that were destroyed later; the PoC got the sanitizer to report a destructor running on 0x4141414141414141. 0.8.0 fixes all six.

phpser's high finding was that a nested SPL unserialize() ignored allowed_classes. Its legacy handler path ran outside the decoder's context, so a class allowlist set on the outer call never reached the inner one. 0.7.1 fixes it along with eighteen others, most of them bounds on work an untrusted payload could demand.

nameparser's quadratic case, from the top of this post, is fixed in 1.6.0. Its release notes say plainly that earlier notes describing hostile-input parsing as linear "did not hold for these shapes". phonetic's medium finding was a 14-byte input, bmpm("de akeaxhaeasz"), that caused an uncatchable fatal error. 0.4.4 turns budget overruns into a catchable ValueError and caps BMPM output at 256 times the input size, after a 1,560-byte input had produced 3.9 MB.

memory_limit stopped stopping things

PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12 shipped on October 21 with the fix for CVE-2026-109618, rated critical. Part of that fix changes what happens when an allocation crosses memory_limit. The engine used to bail out on the spot with a longjmp. Now it records the error, lets the allocation succeed, and raises the fatal at the next safe point in the VM.

For PHP code that's invisible. For an extension it isn't. A C loop that decodes a payload or builds rows never reaches a VM safe point, so it keeps allocating past memory_limit until it hits a hard limit, by default twice memory_limit below 1 GiB. At the hard limit the engine calls _exit(): no shutdown functions, no destructors, no session write, and php-fpm loses the worker instead of failing one request.

So every loop whose length comes from input has to notice the pending error and stop on its own. This is how phpser does it:

/* PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 queue a memory_limit error instead of
 * bailing out; the allocation still succeeds until a hard limit (2x the soft
 * limit below 1G) that _exit()s the process. Loops that keep allocating must
 * stop on their own once the error is pending. */
#ifdef ZEND_HAS_OOM
# define PHPSER_HAS_OOM() ZEND_HAS_OOM()
#else
# define PHPSER_HAS_OOM() 0
#endif

A loop check cannot help when a single allocation is sized from a count the payload declares. Those go through the new fallible allocators instead (zend_hash_real_finit(..., true), safe_femalloc, fecalloc), which queue the error and return NULL rather than running into the hard limit. phpser 0.10.0 uses both. mdparser 0.8.1 and pdo_duckdb 0.9.0 do the same for their input-sized loops and presizes.

The re-release day

There is a catch. The October headers route smart_str growth through a new engine function, smart_str_ferealloc(), from inline header code. An extension compiled against 8.4.27 headers imports that symbol even if it never mentions it, and 8.4.26 doesn't export it. My release workflows built prebuilt binaries against the newest patch of each PHP minor, which had always been the safe choice.

On October 26 that meant mdparser 0.8.1, phpser 0.10.0, fastjson 0.10.1, php_clickhouse 0.13.1, and phonetic 0.4.5 all shipped Linux and macOS binaries that died with undefined symbol: smart_str_ferealloc on every PHP 8.4 before 8.4.27 and every 8.5 before 8.5.12. Source builds were fine, because they compile against the PHP they load into. All five were re-released the same day as mdparser 0.8.2, phpser 0.10.1, fastjson 0.10.2, php_clickhouse 0.13.2, and phonetic 0.4.6, and fastchart 1.8.1 picked up the same change before it could break. Their prebuilts now compile against the oldest patch of each minor (8.4.1, since 8.4.0 was never released, and 8.5.0), and each binary has to load on both the oldest and the newest patch before anything uploads.

That fix has a cost, and the phpser changelog states it: a binary built against 8.4.1 headers doesn't have the memory_limit stop. To get it, you build from source on a patched PHP.

Refusing vulnerable PHP releases

The longer-term answer is the opposite trade. pdo_duckdb 0.9.0 makes it today: its prebuilt binaries are built against the patched headers and require PHP 8.2.35, 8.3.36, 8.4.27, or 8.5.12 or newer. Load one on 8.4.26 and the process stops at the first call:

php: symbol lookup error: /ext/pdo_duckdb.so: undefined symbol: smart_str_ferealloc

That message is honest but unfriendly, and it arrives at runtime rather than at startup. The next releases of pdo_duckdb, phpser, and mdparser fix that with a startup check. On PHP 8.3 and newer, the module compares the running patch with the one it was compiled against and refuses to start on an older one, naming both versions. This is mdparser's:

if (php_version_id() < PHP_VERSION_ID) {
    zend_error(E_CORE_WARNING,
        "mdparser was built for PHP %s and cannot run on PHP %s; "
        "install a build for this PHP version or build from source",
        PHP_VERSION, php_version());
    return FAILURE;
}

With that check in place, pdo_duckdb keeps the binaries it already builds against the patched headers, and phpser and mdparser can move theirs back to the patched headers and regain the memory_limit stop. A server still on 8.4.26 gets a clear startup warning instead of a crash on the first request, and with a critical CVE fixed in 8.4.27 it should move anyway.

pdo_duckdb 0.9.0: DuckDB 2.0

DuckDB 2.0.0 went GA on October 21, and pdo_duckdb 0.9.0, out today, bundles it in every prebuilt binary. 0.8.0 had already built against the 2.0 previews. Source builds still work against DuckDB 1.5.3 and newer; configure detects 2.0 from duckdb_v2.h, because the 2.0 headers still report C API version 1.5.6, and it refuses to build when 2.0 headers meet an older libduckdb.

The upgrade is not transparent, and the README has a full section on it. The one most likely to bite is the file format. DuckDB 2.0 writes new files at storage version 69, and DuckDB 1.5 reads only 64 to 68. If a 1.5 process has to read the file too, ask for the older format when you open it:

$db = new PDO('duckdb:/data/shared.duckdb;storage_compatibility_version=v1.5.6');

On the 0.9.0 binary, a file opened that way reports v1.5.0+ in duckdb_databases(), and a default one reports v2.0.0+. Existing 1.5 files keep their format after 2.0 writes to them. The rest is DuckDB's own behaviour: a failed statement now invalidates the whole transaction, integer division by zero throws, single-arrow lambdas are rejected, and the new PEG parser is the default. That last one has a sharp edge for parameter binding: $1_0 means parameter 10 under PEG and parameter 1 under the legacy parser. Each change has a setting that restores 1.5 behaviour.

0.9.0 also adds PDO::DUCKDB_ATTR_NATIVE_STRUCTURES, an opt-in that fetches LIST, ARRAY, STRUCT, TUPLE, MAP, UNION, JSON, and VARIANT values as lossless PHP structures instead of canonical strings, with exact numerics, binary keys, and SQL NULL kept distinct from VARIANT null. VARIANT works top-level and nested, and the appender accepts PHP arrays and objects for it.

One fix in 0.9.0 matters even if you never touch 2.0: two PDO connections to the same database file could lose writes and see stale reads. Equivalent paths now share one DuckDB instance while transactions stay connection-local.

Performance, with the hardware attached

Most of the speed work came before the scans. Apart from the nameparser row, which I re-ran for this post, these are the numbers from each project's changelog with the conditions it states.

Project	Change	Measured on
nameparser 1.6.0	16 KB hostile row: 17.4 s to 0.064 s	i9-13950HX, PHP 8.4.27 (my rerun of 1.5.0 vs 1.7.0)
phpser 0.6.0	`range(0, 9999)` encodes to 7 bytes; encode 57% faster, decode 66% faster	aarch64
phpser 0.7.0	Signed decode 53 to 85% faster; 1,000-row rowset decodes in 429 KB instead of 645 KB	aarch64
fastjson 0.9.0	`fastjson_validate()` costs 0.47 to 0.90x a full parse, down from 1.1 to 1.9x	Neoverse-N1
fastjson 0.9.0 to 0.10.0	Key-heavy decode peak memory about 15% lower; file decode peak 9 to 33% lower	Neoverse-N1
fast_uuid 0.8.0	`uuid_v4()` 76 to 42 ns; `uuid_v4_bin_batch(100)` 61 to 27 ns per UUID; `uuid_v7_bin_batch()` 25.9 to 16.6 ns	Neoverse-N1
mdparser 0.6.2	`toAst()` 5 to 9% faster; retained AST memory 47% lower on softbreak-dense input; code-heavy `toXml()` output 49% smaller in memory	aarch64, PHP 8.4.25
php_clickhouse 0.12.0	Temporal, string, and IP inserts about 19% faster; IPv4 selects about 12%	200,000-row probes

The phpser integer-run encoding is the one I'd point at. A run with a constant step is stored as a start, a step, and a count, so range(0, 9999) encodes to 7 bytes and range(0, 999999) to 8. Native serialize() needs 137,790 bytes for the first one.

fast_uuid's speedup comes from refilling its random buffer with a userspace AES-256-CTR generator with fast key erasure, instead of a getrandom() call per 8 KiB, on CPUs with AES instructions. It has one caveat, and the changelog states it: clones of one VM snapshot can repeat up to 64 KiB of output per thread.

Breaking changes worth reading before you upgrade

Most of these releases are drop-in. These are not:

php_clickhouse 0.13.0: whole-number Decimal inserts scale like the server's (above).
mdparser 0.8.0: heading IDs carry a user-content- prefix.
phpser 0.10.0: Closures and other unserializable objects throw instead of quietly encoding NULL. Check what you put in $_SESSION before upgrading. New wire tags since 0.7.0 mean readers must upgrade before writers.
php_excel 2.9.0 and 2.9.1: dates use PHP's timezone rather than the OS one, and text is UTF-8 regardless of the process locale. Apps that relied on the locale to pass non-UTF-8 bytes through will see different output. 2.7.0 also rejects a font from a different ExcelBook in addText().
fastchart 1.8.0: heavy SVG that used to render slowly may now throw ValueError.
phonetic 0.4.4: oversized BMPM and Daitch-Mokotoff work throws a catchable ValueError rather than ending the request.
statgrab 2.2.2: Statgrab::ERROR_UNSUPPORTED is 44, matching libstatgrab; it was 41.

On the feature side, phpser 0.8.0 and 0.9.0 added signed sessions (phpser.session_key, HMAC-SHA256), an APCu serializer (apc.serializer=phpser), keyed payloads, and an exported C API. nameparser 1.4.0 understands joint salutations, so Mr. and Mrs. Brad Smith keeps Brad as the first name, with new isJoint(), getSalutations(), and getPartner(), and 1.4.1 raised first-and-last accuracy on 30,000 NPPES provider rows from 95.94% to 97.18%. statgrab 2.3.1 fixes a heap overflow in the bundled libstatgrab's Linux command-line handling that the scan didn't cover.

What a scan is worth

None of these projects were neglected before October. Each had a test suite and documentation that said where its limits were. The scans still found an allowlist that didn't reach a nested call, a Decimal that came back ten thousand times too small, and a 16 KB name that took 17 seconds. Two of the most consequential findings sat in code I had already called linear or already tested under ASan, and for the Decimal bug the ASan testing is exactly what hid it.

The fixes are released and listed above. Upgrade pdo_duckdb if you are moving to DuckDB 2.0, php_clickhouse if you talk to a server you don't control, and PHP itself to 8.4.27 or 8.5.12 whatever else you do.

From Silence to Sound: Fixing Audio on Ubuntu Linux on my Samsung Galaxy Book

Mon, 26 Oct 2026 19:05:37 +0000

Over four days. That’s how long I spent trying to get the internal speakers on my Samsung Galaxy Book2 (NT950XDA) to produce a single sound after switching from Windows to Ubuntu.

And I wasn’t alone.

The Problem

Right out of the box, Ubuntu (even the latest 24.04) doesn’t play well with the Realtek ALC298 audio codec on many Samsung Galaxy Book devices. Headphones might work, but internal speakers remain silent due to uninitialized smart speaker amps.

I found myself crawling through obscure forum posts, GitHub issues, and deep dmesg logs. I came across broken workarounds, kernel parameters, even dead-end firmware downloads. Nothing stuck — until I discovered a promising thread from the Manjaro community and a early work of @joshuagrisham.

The Breakthrough

The answer turned out to be hda-verb, a tool for sending manual codec commands to initialize the amp. After copying dozens of lines of hda-verb commands into a script and running it manually, audio finally burst through my speakers.

It worked—but only until the next reboot.

The Automation

That’s when I decided to build a real solution:

Auto-run the fix at boot and after resume
Avoid breaking any existing audio setups
Use systemd services for reliability
Keep it simple, safe, and open source

The Tool: galaxybook-linux-setup

Now available on GitHub: https://github.com/topzyray/galaxybook-linux-setup

Features:

Initializes smart speaker amps via hda-verb
Runs fix on boot + resume using systemd
Disables PulseAudio's suspend-on-idle to prevent speaker freezing
Backs up existing config files to avoid damage
⚙️ Detects your current user and system safely
MIT-licensed, contributions welcome

Installation is as easy as:

git clone https://github.com/topzyray/galaxybook-linux-setup.git
cd galaxybook-linux-setup
chmod +x install.sh
./install.sh

Reboot when prompted, and you’re done. No more silent boots.

Who This Might Helps

Galaxy Book2 NT950XDA users or other device with similar issue or device/driver info
Anyone with Realtek ALC298 codec and no speaker output
Linux newcomers switching from Windows
Ubuntu/Mint/Pop_OS/Manjaro users on 5.8+ kernels though I tested on 6.14.

Credit Where Due

Joshua Grisham @joshuagrisham – GitHub
Community post from user @drlucas – Manjaro Forum
Access hda-ver used here

The Bigger Picture

This project reminded me why open source matters. Without the knowledge of those before me, I’d still be rebooting into silence.

Now, I’m extending this to include fingerprint readers, screen brightness fixes, and more for Galaxy Book users and I will also be testing on other devices. Please you can test too.

NOTE: The script does not delete any file rather it create a backup whenever updating an existing file.

Have a similar issue? Found this useful? Contribute, fork, share, or open an issue!

Repo: https://github.com/topzyray/galaxybook-linux-setup

If you have further question, suggestion or observations please leave them in the comment section. Thank you for reading.

Your AI Coding Agents Are Filling Up Your Disk. Here’s How to Clean Up Safely

Mon, 26 Oct 2026 10:01:25 +0000

agent-janitor scans agent data across tools, shows what it finds, and archives eligible files before removing them.

If you use AI coding agents regularly, they leave more behind than code.

Session transcripts, debug logs, caches, and old worktrees can quietly accumulate across your machine. After months of use, it can be hard to tell what’s taking up space—and harder to know what’s safe to remove.

A generic disk cleaner doesn’t understand the difference between a disposable cache and a session you may want to resume. A tool built for one coding agent won’t necessarily help with the others.

That’s why I built agent-janitor: a CLI for inspecting, classifying, and safely reclaiming data left behind by AI coding agents.

Start with a read-only scan

You can run a scan without installing the package globally:

npx agent-janitor scan

The scan reports what it finds, how large it is, when it was last touched, and how it is classified. For example, it can distinguish between regenerable cache data and transcripts that may contain session state.

It can also scan transcript content for known credential patterns. That’s an exposure warning—not automatic secret removal or redaction.

Clean up with a way back

When you choose to clean up, agent-janitor is designed to archive eligible items before removing them. By default, it applies a 30-day retention gate, so recent or active data is skipped.

npx agent-janitor clean

You can restore archived data later:

agent-janitor restore --list
agent-janitor restore latest

Or find archived sessions using a session ID or project name:

agent-janitor restore <session-id>
agent-janitor restore <project-name>

The goal is to make cleanup less of a gamble: review what the tool found, archive what it acts on, and restore items when you need them again.

One tool for several agent data stores

agent-janitor currently includes drivers for Claude Code, Codex, Cursor, Gemini CLI, OpenCode, and agent-created Git worktrees. It brings those into one scan and cleanup workflow rather than requiring a different cleanup process for each tool.

It also has optional ways to make checks part of your routine:

A weekly scheduled summary
A shell prompt segment
A pre-push check for orphaned worktree registrations, staged agent artifacts, and likely secrets in changed files

These are opt-in; you can start with a one-time scan and decide whether to install them.

Try it

The package requires Node.js 20 or newer. To inspect your machine:

npx agent-janitor scan

For the full command list and safety details, visit the GitHub repository or the npm package page.

If you use multiple AI coding agents, I’d like to hear what kinds of files and workflows you’d want agent-janitor to support next. Share feedback or report an issue on GitHub.

OKAY,OKAY, CALM DOWN...

Sun, 25 Oct 2026 21:15:51 +0000

Every developer knows that distinct, cold shiver down their spine when they run a script and realize it works too well.
Last night, after putting my local casino simulation scripts to rest, I decided to shift my focus toward cybersecurity and network architecture. I fired up PyCharm, imported scapy and socket, and started coding a fast local ARP network scanner and an aggressive port analyzer.
Within minutes, the logic was solid. The script was automatically detecting active interfaces, calculating subnet masks, and performing stealthy multi-threaded port scans. I was feeling like an absolute elite hacker.
To test its raw power, I targeted an external sandbox server and hit execute.
Suddenly, my console screen flooded with fast, sequential green lines. Open ports were falling like dominoes. Services were being guessed accurately, and my custom SYN packets were hitting the target with microsecond precision. The script was behaving like an absolute beast.
And then, my router's activity LED started blinking like crazy. My phone lost connection. The fan on my PC roared to maximum speed.
OKAY, OKAY, CALM DOWN... I muttered to myself, my fingers hovering frantically over Ctrl + C.
A massive wave of adrenaline hit me. Did I accidentally trigger a network-wide security alert? Did I just execute a self-inflicted DDoS attack on my own home gateway? Was the ISP siber-security team about to flag my IP address?
For three terrifying seconds, I visualized my entire internet setup collapsing, followed by a very awkward phone call with my network provider explaining why a teenager was flooding the pipes with aggressive raw sockets at 2 AM.
I smashed Ctrl + C. The console stopped. The router stabilized. The silence in my room returned.
As I took a deep breath, I reviewed the execution logs. It turns out, no firewalls were breached and no local nodes were melted. The sudden network drop was just my sister streaming a 4K video in the next room at the exact same second, and my PC fan was just reacting to a heavy background Windows update. It was a complete, chaotic coincidence.
The takeaway? Building raw network tools with Python is incredibly empowering, but it will also test your nervous system. When you code at the packet level, the line between "I am a genius" and "I need to call my internet provider to apologize" is incredibly thin.
The script is now safely committed to GitHub. And yes, it is strictly configured for 127.0.0.1. For now.

devtemDesign: one config object paints a whole landing page

Sun, 25 Oct 2026 10:50:19 +0000

A zero-dependency page engine in plain HTML, CSS and JS. 7 templates, live theming, pricing, FAQ, stats and a mobile drawer from a single config. Full reference included

Every landing page I built started the same way: nav, hero, feature cards, pricing, FAQ, footer, then a day of making it responsive. So I wrote an engine that does that part for me.

devtemDesign takes one config object and renders the whole page. No framework, no build step, no dependencies. Two tags and one function call.

This post is both an introduction and a reference for v0.1.0.

Try it in 30 seconds

<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/devtemdesign@0.1.0/style.min.css">
<script src="https://cdn.jsdelivr.net/npm/devtemdesign@0.1.0/script.min.js"></script>

<div id="app-root"></div>
<script>
  devtemDesign("app-root", {
    template: "cyber",
    logoName: "MYAPP",
    heroTitleLine1: "Declarative UI,",
    heroTitleLine2: "Zero-Config Motion",
    heroSubtitle: "One config object. Complete animated landing.",
    primaryBtnText: "Get started",
    primaryBtnHref: "/docs"
  });
</script>

That gives you a sticky glass navbar, an animated hero, ambient background orbs, reveal-on-scroll, a mobile drawer and a footer. Every section except the hero is optional, and a section only renders when its config key is present.

If you want to skip the code entirely, the builder generates a config from a description and lets you edit it live.

What's in 0.1.0

7 templates: figsh, cyber, aurora, monochrome, sunset, ocean, and paper (light).
Live theming: switch at runtime, add a built-in theme button, or override any design token.
New sections: stats with count-up numbers, FAQ accordion, closing CTA, and pricing with a Monthly/Yearly toggle.
Interactions: scroll progress bar, active nav link, card spotlight, seamless brand marquee, back-to-top button.
A real lifecycle: devtemDesign() returns { setTemplate, destroy }.
Accessibility: skip link, focus rings, aria-expanded on the menu, native <details> for FAQ, full prefers-reduced-motion support.

A fuller example

const page = devtemDesign("app-root", {
  template: "ocean",
  themeSwitcher: true,
  logoName: "ORBIT",
  navLinks: [
    { label: "Features", href: "#features" },
    { label: "Pricing", href: "#pricing" },
    { label: "FAQ", href: "#faq" }
  ],
  ctaText: "Start free",
  ctaHref: "#pricing",

  heroBadge: "New: team workspaces",
  heroTitleLine1: "Ship analytics,",
  heroTitleLine2: "not dashboards",
  heroSubtitle: "Turn raw events into answers your whole team can read.",
  primaryBtnText: "Start free",
  primaryBtnHref: "#pricing",

  stats: [
    { value: "12k+", label: "Teams" },
    { value: "99.9%", label: "Uptime" }
  ],

  features: [
    { title: "Live metrics", desc: "Streams update in under a second.", icon: "⚡" },
    { title: "Shared boards", desc: "One link for the whole team.", icon: "📊" }
  ],

  yearlyBadge: "Save 20%",
  pricing: [
    { tier: "Starter", amount: "$0", features: ["3 boards"], cta: "Start free", href: "#" },
    { tier: "Team", amount: "$19", period: "/mo",
      yearly: { amount: "$182", period: "/yr" },
      featured: true, badge: "Most popular",
      features: ["Unlimited boards", "Priority support"], cta: "Go Team", href: "#" }
  ],

  faq: [{ q: "Is there a free plan?", a: "Yes. Starter is free forever." }],
  cta: { title: "See your data differently", text: "Create account", href: "#" },
  footer: { tagline: "Built with devtemDesign.", copy: "© 2026 Orbit" }
});

You can see this running, with a template picker and a mobile preview, on the examples page.

Templates

Template	Vibe	Accents
`figsh`	Futuristic glass	Cyan, purple, pink
`cyber`	Neon cyberpunk	Cyan, magenta, red
`aurora`	Organic nature	Emerald, violet, blue
`monochrome`	Minimal grayscale	White, silver
`sunset`	Warm dusk	Orange, rose, gold
`ocean`	Cool depth	Sky, teal, indigo
`paper`	Light mode	Indigo, pink, cyan

Every color in the stylesheet comes from a token, which is why the light template works without a separate stylesheet.

Runtime control

const page = devtemDesign("app-root", config);

page.setTemplate("sunset");   // switch theme, no re-render
page.destroy();               // remove listeners, observers and markup

devtemDesign.version;         // "0.1.0"
devtemDesign.templates;       // ["figsh", "cyber", "aurora", ...]

Calling devtemDesign() again on the same container destroys the previous instance first, so there are no leaked listeners.

Theme tokens

Override any token with the theme option:

theme: { accent: "#ff4d6d", accent2: "#ffb703", "bg-deep": "#0b0710" }

Token	Purpose
`--accent`, `--accent2`, `--accent3`	Brand colors and gradients
`--text`, `--muted`	Primary and secondary text
`--bg-deep`	Page background, and text on filled buttons
`--glass-bg`, `--glass-border`, `--glass-blur`	Card surfaces
`--surface`, `--line`	Subtle fills and dividers
`--orb`	Ambient orb opacity

Config reference

All text fields accept HTML, so icons and inline markup work. Only pass content you trust.

Option	Type	Default	Description
`template`	string	`"figsh"`	One of the 7 templates
`theme`	object	`{}`	Token overrides
`themeSwitcher`	boolean or string[]	`false`	Navbar theme button. An array limits the cycle. Choice is saved in `localStorage`
`cursor`	boolean	`true`	Custom cursor on or off
`logo`, `logoName`, `logoHref`	string	fscss logo, `"CORE"`, `"/"`	Brand image, name and link
`navLinks`	(string or `{ label, href }`)[]	Features, How it works, Pricing	Navbar and drawer links
`ctaText`, `ctaHref`	string	`"Get started"`, `"#"`	Navbar button

Hero

Option	Description
`heroBadge`	Pill above the title
`heroTitleLine1`, `heroTitleLine2`	H1 lines. The second has an animated gradient
`heroSubtitle`	Paragraph under the H1
`primaryBtnText`, `primaryBtnHref`	Main button
`secondaryBtnText`, `secondaryBtnHref`	Ghost button, rendered only when text is set
`brands`, `brandsSubtitle`	Hero chips and a seamless marquee that pauses on hover

Sections

Section	Keys	Anchor
Stats	`stats: [{ value, label }]`	`#stats`
Features	`featuresLabel`, `featuresTitle`, `featuresSub`, `features: [{ title, desc, icon }]`	`#features`
Steps	`stepsLabel`, `stepsTitle`, `stepsSub`, `steps: [{ title, desc }]`	`#how`
Panels	`panelsLabel`, `panelsTitle`, `panelsSub`, `panels: [{ tag, title, desc }]`	none
Pricing	`pricingLabel`, `pricingTitle`, `pricingSub`, `yearlyBadge`, `pricing: [...]`	`#pricing`
FAQ	`faqLabel`, `faqTitle`, `faqSub`, `faq: [{ q, a }]`	`#faq`
CTA	`cta: { title, sub, text, href }`	none

Stat values keep their prefix, suffix, commas and decimals, so "$1,200", "99.9%" and "12k+" all count up correctly.

A pricing plan looks like this. A Monthly/Yearly toggle appears automatically when any plan has yearly:

{
  tier: "Pro", amount: "$12", period: "/mo", desc: "For product landings.",
  features: ["Everything in Free", "Priority support"],
  cta: "Go Pro", href: "/signup",
  featured: true, badge: "Most popular",
  yearly: { amount: "$115", period: "/yr" }
}

footer: {
  tagline: "Declarative UI engine for the modern web.",
  copy: "© 2026 devtem-dev",
  columns: [{ heading: "Product", links: [{ label: "Docs", href: "/docs" }] }],
  social:  [{ icon: "fab fa-github", href: "https://github.com/devtem-dev", label: "GitHub" }],
  legal:   [{ label: "Privacy", href: "/privacy" }]
}

The full schema, with types and defaults, lives at design.devtem.org/api.

Upgrading from 0.0.2

Three option names changed to match what the code actually reads:

0.0.2 docs	Use now
`heroTag`	`heroBadge`
`featuresSectionLabel`	`featuresLabel`
`featuresSectionTitle`	`featuresTitle`

Good to know

Font Awesome is optional. It is only needed for icon fields and footer social icons. The hamburger, checkmarks and accordions are pure CSS.
Theming uses color-mix(), so you need Chrome 111+, Safari 16.2+ or Firefox 113+. Older browsers still render the page but lose some tinted surfaces.
Rendering replaces the container's contents. Give the engine its own wrapper element.

surviving-lines scored highest in a six-arm code-ownership benchmark

Sat, 24 Oct 2026 11:15:17 +0000

I wrote surviving-lines to answer one question: who wrote the code that is still in this repository? It is a command-line tool that counts each author's surviving lines with git blame and prints them next to the author's share of commits. It also ships as a Claude Code plugin, so an agent can run it instead of estimating. For version 0.4.0 I wanted to know whether the plugin changes how well an agent answers ownership questions. So I measured it against three other tools and against Claude with no plugin.

The short result: on 5 sealed tasks the plugin scored 9.67 of 25 and the best other arm scored 7.33. The 95% bootstrap interval of that difference is [+0.33, +4.33], so it stays above zero but only just. A score of 9.67 of 25 also means that the plugin passed fewer than 4 criteria in 10, so these tasks are hard for every arm. On 11 public tasks, which I had read while developing the tool, it scored 47.67 of 51 against 41.00 for the best other arm. It did not win every task, and the details are below.

What was measured

Each task gives an agent a git repository and a question that a person taking over a project would ask, for example "Who should I ask to review changes to time.go, version7.go and the SQL code, and are the people who actually wrote those parts still around?" A task has five criteria or fewer, such as "names this person as the top owner with a share between 51% and 59%" or "does not credit the person who only ran the formatter". The criteria were written with a ground truth computed from the repository, and a model grader scored each answer against them. The grader gave its reason before its verdict, with five votes per criterion, and the verdict is the majority.

There are two sets of tasks:

The sealed set has 5 tasks. An agent that had not seen the surviving-lines repository wrote them. It was given a plain description of the user's job and the file layout. Each task uses a real open-source repository in a different ecosystem (Python, Go, Zig, Ruby, PHP) with commits added by the writer that create hazards: a formatter run, the same person under several addresses, squash-merged work, mechanical file moves, an author who differs from the committer.
The public set has 11 tasks. It uses one small JavaScript repository where the main author has two addresses, asked in several ways (who owns the code, the bus factor of a directory, who should review a file, code owners per directory and so on). The tasks were read while the tool was being developed, so I label the set development-seen. The claim in this article rests on the sealed set.

The six arms are surviving-lines at commit 8af57f4, project-pilot 1.0.0 with its natural prompt and again with the prompt "Use the /project-pilot:bus-factor command for this.", mcp-git-historian, busfactor by k41n, and a Claude Code run with an empty plugin. The other tools were run from copies pinned at the commits listed in the evidence folder. project-pilot 1.0.0, invoked only has runs on the 8 public tasks that define an invoked prompt, so its public total counts the other 3 tasks as 0. Each arm ran each task three times on Sonnet 5.5 through Claude Code 2.1.308. The protocol was committed before the first run, and no result from an earlier round was reused. Version 0.4.0 on npm ships the same plugin code as that commit: the bin, hooks, agents and schema folders are byte-identical, and only the skill description text and version number differ.

Sealed set

arm	total of 25
surviving-lines	9.67
project-pilot 1.0.0, invoked	7.33
no code-ownership plugin	3.33
busfactor (k41n)	2.67
project-pilot 1.0.0	2.33
mcp-git-historian	2.00

A total is the sum over the tasks of the mean criteria passed over the three runs. The difference to the best other arm, project-pilot 1.0.0, invoked, is +2.33 with a 95% interval of [+0.33, +4.33]. Against the other four arms the differences are between +6.33 and +7.67, and every interval is above zero. With 5 tasks and 3 runs, the lower bound of 0.33 is close to zero, and a different set of tasks could move it either way.

The protocol also defines stricter checks, and the plugin fails them on this set. On HZ3 it scored 0.67 where project-pilot 1.0.0, invoked scored 1.33, and on HZ5 it scored 1.33 where the empty-plugin run scored 1.67. The per-task rule (rule B), under which the plugin may not trail the best rival on any task, therefore fails, and so does the rule that the plugin must lose at most 80% of the points the best rival loses: it lost 15.33 of 25 and the rival lost 17.67, where the limit was 14.13. I do not claim it is first on every task.

Public set

On the public set the plugin scored 47.67 of 51. The best other arm was the empty-plugin run at 41.00, and the difference is +6.67 with an interval of [+5.00, +8.33]. Against project-pilot taking the better of its two arms on each task, the difference is +4.33 with an interval of [+2.00, +6.00]. The totals of the other arms are 40.33 (project-pilot 1.0.0), 40.33 (busfactor), 38.33 (mcp-git-historian) and 27.33 (project-pilot 1.0.0, invoked, with the 3 missing tasks).

It lost three tasks: T1 and T1i, where it scored 3.00 and busfactor and the empty-plugin run scored 4.00, and E5, where it scored 4.00 and mcp-git-historian scored 5.00. The 80% rule passes on this set. The per-task rule fails on those three tasks. Because these tasks were read during development, a high score here is weaker evidence than the sealed result.

Other models

I ran Haiku 5.5 and Opus 5.5 once per task, with only surviving-lines, the empty-plugin run and the best rival of each task. These totals are descriptive. One run per task is too few to compute an interval, and I make no claim of being first from them.

model	set	surviving-lines	empty plugin	best rivals, summed per task
Haiku 5.5	sealed, of 25	6	3	0
Haiku 5.5	public, of 51	46	33	33
Opus 5.5	sealed, of 25	15	12	14
Opus 5.5	public, of 51	51	39	43

The plugin is ahead in total in all four rows. The per-task rule fails on several tasks for both models, except on Opus with the public set.

How much to trust the grading

I regraded a random sample of 28 of the 279 graded cells with fresh grader sessions. The new grade agreed with the first on 129 of 131 criteria (98.5%), and no cell moved by more than one point. I also ran the same 28 cells again once. 25 of those 28 re-runs scored within the range of the three original runs, so a single run of a cell can differ from the earlier ones. On the sealed set the five votes were unanimous on 91.6% of verdicts and on the public set on 97.0%.

What it costs and what went wrong

At list price the plugin costs 1.67 times the empty-plugin run per cell on the sealed set (0.117 US dollars against 0.070) and 1.56 times on the public set (0.076 against 0.049), because it uses more turns and tokens. The runs were charged to a subscription. The whole round, including the development gates that decided whether to run the final measurement, would cost 185.46 US dollars at list price.

The plugin has a Stop hook that checks the numbers in an answer once before the agent finishes. It blocked the first answer in 5 of 48 plugin cells (10.4%). Those cells scored 3.40 on average and the unblocked ones 3.60 criteria, so this data does not show whether the hook helps.

These points limit the result:

The tasks are ours. The sealed writer did not read the surviving-lines repository, but the agent that ran the measurement saw the writer's closing summary (the five repositories and a line of hazards per task) before I wrote the protocol. The hazards are the ones the tool was built to handle. A benchmark by someone who builds a rival could rank the arms differently.
Five sealed tasks is a small set, and the intervals reflect only the three runs per task, not a different choice of tasks.
One model produced the sealed and public runs, one CLI version, one login.
The session limit stopped the drivers twice, both times during the audit re-runs. Cells that failed on a limit were set aside, never graded, and run again, and no scored run was set aside. I renewed the login after the second stop, so the audit re-runs after that point and the other-model runs may have gone through a different account.
The sealed scripts are published with contributor addresses replaced by their SHA-256. The published scripts rebuild the fixtures with the same commit ids and reproduce the ground truth byte for byte.
The interval of each arm's own total in the figure is not printed in the evidence summary, which only has intervals of differences. I computed them from the same grades with the same method (intervals.py, next to the figure script), and it checks its totals against the summary.

The benchmark above asks whether an agent uses the tool well. A separate question is why the tool counts both numbers. In September I ran it on twelve public repositories, with the design and the meaning of a null result written down first. For each repository I measured every author's share of non-merge commits and share of surviving lines at HEAD, from a one-in-five deterministic file sample, with three seeds per repository. That is 36 runs and 2,748 author rows, measured on 5 September 2026 with version 0.1.6.

The author with the most commits also held the most surviving lines in 25 of the 36 runs, and on all three seeds in 8 of the 12 repositories. Commit counts therefore usually point at the right person. The gap between the two shares is larger than that suggests: among authors holding at least 5% of either measure (122 author rows), the median gap was 7.5 percentage points and the mean 12.2. 43 of the 122 (35%) differed by 10 points or more, and the largest single gap was 63.8 points. In cloudflare/capnweb the top committer, holding 46% of commits, held between 3% and 16% of the sampled surviving lines depending on the seed, while a contributor with 2% of the commits held 45% to 58%. I did not look into why.

This has limits. Twelve repositories describe twelve repositories and are not a statement about open source. The sample moves the magnitudes: the top author's line share had a median spread of 5.4 points across seeds and a maximum of 17.4, so I read a direction from one run and a magnitude from several. The tool counted bots as authors in that run, and since 0.3.0 it leaves them out by default, so that table has not been re-run with the current behaviour. Surviving code is not merit, since code can stay because nobody dares to touch it. HEAD has moved on in all twelve repositories and the data file records no commit ids, so a re-run will give different numbers.

Try it and check it

npx surviving-lines --sort gap

--sort gap puts the author with the largest difference between line share and commit share first. The tool needs Node 22 or newer and git 2.15 or newer. To use it from Claude Code:

/plugin install surviving-lines --marketplace Bubblegunn/surviving-lines

Every cell, the departures from the protocol and a recompute step are in the round 13 evidence folder. REPRODUCE.md in that folder gives the commands for a re-run, and the earlier rounds and rulings are in docs/HEAD-TO-HEAD.md. The repository is Bubblegunn/surviving-lines, and version 0.4.0 is on npm. I wrote about the first version of the tool in September: Who really owns this code? A git blame sampler you can run in one command.

Three people outside my own commits have shipped code in the tool: @shivam-070208 wrote --markdown, @Aaqibhafeezkhan wrote --sort gap, and @Enard52 sent fixes that make empty runs say which filter emptied them. If you run it on something and the numbers look wrong to you, tell me which repository and I will look.

Disclosure: I drafted this article with AI assistance (Claude) and reviewed it myself. Every number comes from the evidence folder linked above and the research folder in the repository, and the benchmark can be re-run from it.

Humanizer has about 60,000 stars. On 12 public tasks my linter plugin scored 2.67 higher

Sat, 24 Oct 2026 10:06:25 +0000

I wanted to know whether a linter for AI writing tells helps an agent rewrite a file better than a good prompt does. So I ran a benchmark with 11 arms: the linter packaged as a Claude Code plugin, six other Claude Code skills that claim to remove AI-sounding prose, and Claude with no plugin. Three of those skills (Humanizer, unslop and everwrite) were also run a second time with the prompt calling them by name, which is where the count of 11 comes from. Each arm ran each task three times on Sonnet 5.5.

The short result: on 12 public tasks the linter scored 58.67 of 60 and the best other arm scored 56.00. On 6 held-out tasks, written by an author who had not read the code, four arms scored 29.67 or more of 30, so that set does not separate them.

What was measured

Each task asks an agent to edit a real file in place: a French launch note, a README intro, a pull request description, release notes, a mixed-language guide, a repository set-up. A task scores only what the file contains afterwards, so talking about the problem earns nothing. Each task also carries facts a careless rewrite would break, such as numbers, names, code and links, and scripted checks look for them. Some criteria need judgment, and those went to a blind grader: outputs of all arms were shuffled and anonymised, and the grader gave its reason before its verdict, five votes per cell. Of 99 blind cells, 92 were unanimous.

The other six tools are Humanizer (blader/humanizer, about 60,000 GitHub stars per the GitHub API on 2026-10-24), unslop, everwrite, slopless, avoid-ai-writing and slop-cop. The protocol was written and committed before the first cell ran. A total below is the sum over tasks of the mean over the three runs, with a maximum of 5 points per task. The result applies to those tasks only and ranks nothing in general.

Public tasks

arm	total of 60	95% interval
this linter	58.67	[57.67, 59.67]
Humanizer, called by name	56.00	[54.67, 57.33]
Humanizer	54.67	[53.33, 56.33]
everwrite, called by name	54.33	[52.67, 56.33]
everwrite	53.33	[52.00, 54.67]
unslop, called by name	51.67	[51.00, 53.00]
unslop	51.00	[50.33, 51.67]
slopless	50.67	[49.33, 52.00]
avoid-ai-writing	50.33	[49.33, 51.67]
slop-cop	49.00	[47.67, 50.33]
no plugin	48.67	[47.00, 50.00]

The difference between the linter and the best other arm, Humanizer called by name, is 2.67 points, with a 95% bootstrap interval of [1.00, 4.33]. The lower bound is above zero.

It did not win every task. On h11 and h15 it scored 4.67 where the best rival scored 5.00, and on h18 it tied at 4.67. The benchmark's stricter per-task rule (rule B) fails on those three tasks.

Held-out tasks

Six further tasks were written by an author, a Sonnet agent, who had seen no code of this repository. The person running the measurement had not read them before it.

arm	total of 30	95% interval
unslop	30.00	[30.00, 30.00]
avoid-ai-writing	29.67	[29.00, 30.00]
this linter	29.67	[29.00, 30.00]
unslop, called by name	29.67	[29.00, 30.00]
no plugin	28.67	[28.00, 29.00]
Humanizer	28.67	[28.00, 29.00]
Humanizer, called by name	28.00	[27.00, 29.00]
slopless	28.00	[28.00, 28.00]
everwrite, called by name	27.33	[26.33, 28.33]
slop-cop	27.00	[25.67, 28.33]
everwrite	26.67	[26.00, 27.00]

Here the linter is 0.33 behind unslop, with an interval of [-1.00, 0.00], so the claim that it is first does not hold on this set. It lost that 0.33 on one task, ho1, where it scored 4.67 against 5.00. Four arms sit at 29.67 or higher and even the no-plugin baseline reaches 28.67, so these tasks cannot separate the top arms. Across both sets: first on the public set, and within 0.33 of the best of the 11 arms on the held-out set.

Other models

I also ran Haiku 5.5 and Opus 5.5 once per task, with only the linter, the best other arm of each set and the no-plugin baseline. These totals are descriptive. With one run per task, a difference of one or two points is inside the run-to-run variation. These runs were not blind-graded, so the public scores use the scripted criteria only and their maximum is 57.

model	set	this linter	best other arm	no plugin
Haiku 5.5	public, of 57	54	52 (Humanizer, called by name)	43
Haiku 5.5	held-out, of 30	28	28 (unslop)	26
Opus 5.5	public, of 57	54	54 (Humanizer, called by name)	45
Opus 5.5	held-out, of 30	29	27 (unslop)	25

What a prompt cannot do

The linter is a command line tool that calls no model and has no dependencies. Its rules are deterministic: the same text gives the same findings. A rewrite can pass every check and still lose a fact, so the tool also has --compare. It lists each number, version, date, link, quotation, code span and name that appears in one text and not the other, and exits 1 when it finds one. It also reports a qualifier that went missing next to a number, and first-person or claim words that the rewrite added.

This is real output on a two-line example I wrote for this post:

$ npx ai-slop-linter --compare before.md after.md
facts: 1 kept, 4 lost, 0 added
lost   date     3 March 2026
lost   number   1200
lost   qualifier up to 40
lost   version  2.4

The plugin's skill runs this after each rewrite and treats a failing comparison as blocking. --compare compares facts and not wording, so it cannot say whether a rewrite is good.

What it costs

This arm cost 2.43 times the no-plugin baseline per cell at list price, on both sets, because it takes more turns and more tokens. In the public set that was 0.125 US dollars per cell against 0.051. The runs were charged to a subscription, and the whole measurement would cost about 91 US dollars at list price.

What went wrong in the measurement

The session limit stopped the runs twice. 236 public and 160 held-out attempts failed with usage_limit_reached, were kept and never scored, and the same commands ran them again.
The public and held-out runs went on at the same time. The held-out runs used a later commit, because the harness refuses a working tree whose benchmark folder differs from the commit. The product files are byte-identical between the two commits.
The blind grader loop died once and was started again, so for a while two copies wrote vote files. All 165 vote files of the re-grade are valid, and none was dropped by hand.
A re-grade of 33 sampled blind runs agreed with the first grading on 99.4 percent of criteria. Of 60 sampled cells run a second time, 38 of 40 public and 19 of 20 held-out re-runs fell inside the range of the original three runs.

Try it and check it

npx ai-slop-linter README.md
npx ai-slop-linter --compare before.md after.md

To install it as a Claude Code plugin:

/plugin marketplace add Bubblegunn/ai-slop-linter
/plugin install ai-slop-linter@ai-slop-linter

Every cell, the departures from the protocol and a recompute step are in the round 8 evidence folder. REPRODUCE.md in that folder gives the commands for a re-run, which needs Claude Code 2.1.308, Node 24 and about 9 hours. The tasks, criteria and harness are public in bench/head-to-head/, and the earlier rounds and rulings are in docs/HEAD-TO-HEAD.md. The repository is Bubblegunn/ai-slop-linter, and version 0.2.0 is on npm.

Developer Weekly Briefing — October 23, 2026

Fri, 23 Oct 2026 12:49:47 +0000

Three threads defined this week. Security researchers — now routinely assisted by AI — found critical bugs faster than maintainers could coordinate patches. Agentic AI standards solidified in meaningful ways, with the Agentic AI Foundation adding four new projects and a candid CTO willing to name the gaps. And on the infrastructure side, the tools for keeping developer pipelines safe from compromised packages got sharper. Here's what mattered.

PHP2Shell: AI turned a theoretical bug into an exploit in days

PHP shipped emergency patches on October 21 for PHP2Shell — two critical flaws, both rated 9.2 under CVSS v4.0, that let an unauthenticated attacker run code on your server. The fixes are in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. If you run a supported branch, the path is simple: patch and restart your PHP workers.

The harder story is what's underneath. These flaws trace back to the PHP 5 series — CVE-2026-109618 corrupts memory during out-of-memory errors, CVE-2026-109619 involves stale global state from freed request memory. Security researchers had spotted the vectors more than a year ago but couldn't find a practical way to trigger them. They stayed in the "theoretical" pile. Then two independent researchers, each using a frontier AI model, found working exploits within days of each other this past August. Cloudflare logged attacks hours before patches shipped on October 21.

Matthew Weier O'Phinney, PHP Foundation board member and principal product manager at Perforce OpenLogic and Zend, was direct: "These vulnerabilities affect every single Server API provided by the language, because their roots are deep within how the engine manages memory." That includes PHP-FPM behind Nginx — not just mod_php. Workarounds like disabling session upload progress buy time; they don't fix the underlying problem.

The real exposure is PHP past community support. Every version before 8.2 is EOL, and 8.2 itself ends community support at year's end. If you're on an older version, your options are a commercial LTS provider — several shipped patches for PHP 7.2–8.1 in coordination with the PHP Security team — or a migration to a supported branch. His broader point: AI is accelerating discovery faster than patches reach unsupported software. That gap is a business risk, not just an engineering footnote.

AAIF now has 10 projects — its CTO on what to adopt and where security falls short

The Agentic AI Foundation started December 2025 with three projects. It hit ten this week at AGNTCon + MCPCon North America in San Jose, adding contributions from Anthropic (Agent Skills), OpenAI (Open Responses), Hugging Face (OpenEnv), and Alibaba (OpenSandbox). The foundation passed 300 member organizations.

I asked Manik Surtani, AAIF's CTO and co-founder, what that means for teams building on these standards. His answers were practical.

On what to use now: MCP and A2A are the most mature. Open Responses has reached solid maturity. OpenSandbox is early but worth watching — and you need a sandbox somewhere. "Running without any sandbox is dangerous, and you shouldn't do it." Put a gateway in the middle so you can migrate models and tools later.

On the reference stack question everyone keeps asking: don't expect one. "The more I think about it, the more I believe any reference stack we build today will be out of date tomorrow." Production deployments are the reference.

On the two biggest security gaps in the agentic stack today: agent identity and authentication, and attestation — proof that an agent did what you asked and didn't go sideways. No AAIF project covers either one yet. There are working groups, but no adopted standards. If your agents operate on real systems, those are the areas where your own controls need to be strongest.

GitHub puts a firewall between npm and your CI runners

Install time is where npm attackers have focused all year. Preinstall and postinstall scripts can run before tests or scanners get a look — the compromised Axios release in March, the @redhat-cloud-services attack in June, and a worm that touched more than 400 packages in August all exploited that window. GitHub's answer is a package firewall, now in public preview for Enterprise Cloud customers.

The firewall sits between endpoints — CI runners, AI coding agents, developer workstations — and the upstream npm registry. Five policy controls ship out of the box: blocking known malware from the GitHub Advisory Database, blocking versions with known vulnerabilities above a configurable severity, blocking attestation downgrades (a package that stops shipping provenance after earlier versions carried it), blocking newly introduced install scripts, and a minimum package age cooldown from 1 to 365 days, defaulting to one day.

The cooldown is the simplest and may be the most useful. Most malicious npm versions are pulled within hours of discovery. A one-day hold would have stopped the compromised Axios versions, which were live for about three hours. The attestation check has a known gap: it won't catch a hijacked pipeline that signs malicious code honestly, as happened in the AsyncAPI attack in July.

Mitch Ashley of The Futurum Group noted the core constraint: "The firewall only protects traffic routed through it, so teams should block direct access to the public registry at the network layer." Watch the metered pricing at general availability too — a usage-based bill gives teams a reason to route less through the firewall.

For Enterprise Cloud customers, the free preview is worth running. Find out what a one-day cooldown would actually catch in your environment before you have to find out the hard way.

Anthropic used Claude to formally verify 123 open source libraries — and found bugs fuzzing had missed

Formal verification has always been expensive. Two person-years to build the seL4 microkernel. Twenty person-years to verify it. That math is why it has mostly lived in avionics and cryptography. Anthropic's Frontier Red Team, working with formal methods company Theorem, ran the largest AI-assisted formal verification effort yet: 123 open source libraries from Google's OSS-Fuzz project, 239 fuzzing entry points, proofs operating on RISC-V assembly, not source code.

The approach was clever. Instead of writing new specs from scratch — historically the hardest part — the team converted existing fuzz tests into formal specs. Each fuzz entry point became a proof statement: this program never crashes on any input under 64 MB. Theorem supplied formal models of RISC-V and Linux process behavior. Claude wrote the proofs. The Rocq proof checker validated them.

Over a few weeks, Claude produced about 180 million lines of Rocq proof. Typical proofs ran around 600,000 lines for a binary with a median of 18,000 instructions. Claude was allowed to patch bugs it hit and keep going, and it found hundreds. Several are notable: a counter underflow in a decompressor that only triggered on inputs around 20 MB with one specific layout; an out-of-bounds read in an image decoder needing a 64 MB input and more than 2 GB of memory; a logic bug in file-loading restrictions that wasn't always enforced. None of these would have surfaced from typical fuzzing, which usually caps inputs at 1 MB.

Cost is real — proofs can consume hundreds of millions of tokens — but Anthropic points to two trends: Claude Opus 5.5 used 40% fewer tokens than Opus 5 on 36 small verification tasks, and agents sharing a workspace and reusing proofs needed 17% fewer tokens. The reuse point matters more than token savings. Much of any proof covers code every C program shares, so proofs transfer well. Verify a small set of widely used libraries once, and much of the stack downstream gets easier.

Anthropic has released a subset of proofs and the RISC-V and OS semantics on GitHub. Theorem is offering to run the pipeline for other open source projects and has published a Claude skill for teams that want to start. The near-term takeaway for DevOps teams: don't drop fuzzing. Do start watching whether formal verification moves into your pipeline the way fuzzing did — Anthropic predicts it will become roughly as practical as fuzzing is today.

GitHub adds AI-powered security scanning to pull requests. GitHub's new code scanning feature runs directly on PRs, flagging security issues before merge rather than after. It uses AI to surface findings in context with the diff. Worth watching if your team uses GitHub Enterprise. Read more
AI agents can now decompile software — here's what that means for security. Researchers demonstrated that frontier AI models can decompile binaries and reconstruct meaningful source-level understanding of proprietary software. The implications run in both directions: useful for security audits, dangerous in the wrong hands. Read more
HiddenLayer puts a security layer between external LLMs and your internal systems. LLM gateway hijacking — where an attacker manipulates prompts to redirect agent calls to a malicious model — is an emerging attack class. HiddenLayer's approach sits in the request path between your application and external model APIs, inspecting and filtering what goes through. Read more
CyberCartel used Claude and Grok to automate banking attacks. A threat actor group documented using frontier AI models to automate credential-harvesting campaigns targeting banking customers. The research maps how they used AI to generate phishing lures, adapt to defenses, and scale operations that would previously have required more manual effort. Read more
Microsoft Foundry agents can now run on a schedule. Scheduled execution is a basic building block for autonomous agents — run a report, check a system, trigger a workflow at a set time without a human in the loop. Microsoft Foundry now supports it natively. Read more
Google launches Harness² for AI agent testing. Google's new testing framework is designed for multi-step agent workflows, where individual unit tests don't capture enough of the failure surface. It's aimed at teams building production agents who need confidence that the full chain — not just each step — behaves as expected. Read more
OpenAI lands a COBOL modernization deal with a Fortune 500 bank. Enterprise AI is starting to move into legacy modernization, one of the largest untapped engineering markets. OpenAI will use its models to translate COBOL systems for a major bank — a deal that signals how AI-assisted migration may finally make the COBOL mountain climbable. Read more
Mod42 is building data centers for organizations that can't afford hyperscale. The hyperscale economics of AI infrastructure don't reach everyone. Mod42's approach targets mid-market enterprise and public-sector workloads that need dedicated capacity without signing a hyperscaler contract. Read more

Developer Spotlight this week

Dean Hall is best known for creating DayZ, one of the most influential survival games of the past decade. He's back with a new project, Brutal, and he rebuilt his game engine from scratch to make it. The conversation covers what drove that decision, where AI fits in his development process, and where it doesn't. His take on what AI still can't do is worth hearing from someone who has shipped at scale.

Watch the conversation

The through-line this week: AI is accelerating both sides of the security equation. PHP2Shell shows how quickly a theoretical bug becomes a working exploit once researchers have capable models to help. The CyberCartel and HiddenLayer stories show the same dynamic at the application layer. And Anthropic's formal verification work shows that AI can also scale up the defenses — producing more proof and catching more bugs than human teams could afford to write by hand. The tools are neutral. The race is real.

See you next Friday.

Developer Weekly Briefing is published every Friday on Coder Legion. Written by Tom Smith.

is-kit Reached 100 Stars ⭐🎉 Here’s What Changed Since 50

Fri, 23 Oct 2026 12:24:38 +0000

Hoi hoi!

YAY! is-kit just reached 100 GitHub stars⭐ 🎉🎉🎉

When it reached 50 stars, I wrote about how we use it in a production TypeScript application serving more than 100,000 users. 👇

https://dev.to/nyaomaru/is-kit-reached-50-stars-heres-how-we-use-it-in-production-2i5b

I could write the same story again. But that would be boring. 😹

A lot has happened since then.

The library gained new APIs, some existing APIs became stricter, I started using it in more of my own OSS projects, and one real-world use case even exposed a type inference edge case in Effect.

So this time, instead of explaining the production adoption again, I want to look at:

What changed between 50 and 100 stars
Some of the most important APIs added since then
How I am actually using is-kit outside the original production application
A real bug report involving Effect.catchIf
What 100 stars means to me now

Let's dive in! 🔧

⭐ First, What Did 50 Stars Mean?

At 50 stars, the biggest thing I wanted to show was that is-kit was not only a toy project.

It was already being used in a real production application. 🚀

The application had repeated runtime checks like

typeof value === "string";
typeof value === "number";
value === null || value === undefined;

and several larger user-defined type guards for things like HTTP errors, literal unions, arrays, API values, and plain objects.

The interesting part was not that is-kit made those checks shorter.
The interesting part was that it gave them one reusable shape.

Small guards could be composed.

Application-owned helpers could sit between the library and feature code. And the result could still participate in normal TypeScript control flow.

That part has not changed.

But since 50 stars, the library itself has moved quite a bit. 👀

One thing I kept running into was this.

I already have a good type guard.
I just want to apply it to one property.

For example

declare const input: unknown;

Maybe I already know how to validate a string

import { isString } from "is-kit";

But now I want to express

"This object has a name property, and that property is a string."

That sounds simple, but there are actually a few different cases.

A required property is not the same as an optional property.
An array index is not the same as an object property.

And an optional property that becomes known to be defined should narrow differently from one that is still optional.

So is-kit added three property refinement helpers:

refineKey
refineDefinedKey
refineIndex

The idea is simple

Take a type guard you already trust and lift it onto a property or array element.

For example

import { isString, refineKey } from "is-kit";

const hasStringName = refineKey("name", isString);

Now the string guard is reusable at a deeper level instead of being rewritten inside another custom predicate.

This is a small API, but I like it because it follows the same design goal as the rest of is-kit.

Do not build one giant validator.

Build small checks that can be reused in normal TypeScript code.

🔍 Then `discriminatedUnion` Got Much More Serious

The biggest addition since the 50-star article is probably the exhaustive discriminated union API introduced in v1.15.0.

Consider a common TypeScript type

type Result = { ok: true; value: string } | { ok: false; error: string };

At runtime, validating this is not difficult.

You can check ok, then validate the corresponding fields.

But there is another question

Can TypeScript verify that the validator itself covers the whole union?

That is where discriminatedUnion comes in.

import { discriminatedUnion, isString, oneOfValues, typedStruct } from "is-kit";

type Result = { ok: true; value: string } | { ok: false; error: string };

const resultUnion = discriminatedUnion<Result>();

export const isResult = resultUnion("ok", [true, false], {
  true: typedStruct<Extract<Result, { ok: true }>>()({
    ok: oneOfValues(true),
    value: isString,
  }),
  false: typedStruct<Extract<Result, { ok: false }>>()({
    ok: oneOfValues(false),
    error: isString,
  }),
});

The runtime behavior is useful.

But the more interesting part is the compile-time contract.

The builder checks things like:

Missing discriminant branches
Extra branches
Incompatible branch guards
Incomplete discriminant tuples

So if the union changes, the guard cannot silently stay incomplete.

That matters because one of the easiest ways for a hand-written type guard to become dangerous is drift.

The TypeScript type evolves.
The runtime guard does not.
And the compiler cannot normally tell you that the two are no longer aligned.

discriminatedUnion is one attempt to make that class of mistake harder.

💪 The Library Also Became Stricter

Not every improvement between 50 and 100 stars was a new feature.

A lot of work was about making existing behavior more precise.

For example, recent releases included fixes around:

recordOf literal-key narrowing
native Error brand checks
array guards with overridden iterators
exact struct validation
symbol-keyed struct schemas
cross-realm struct schemas

There was also more package-level testing.

is-kit now checks published-package behavior from both ESM and CommonJS TypeScript consumers, and also has Deno / JSR smoke coverage.

This part is less exciting to show in a code snippet.

But for a small library, I think it is important.

Making sure they behave correctly in weird JavaScript and TypeScript environments is where things become real.

🤖 I Started Using `is-kit` in Other OSS Too

Since reaching 50 stars, I've also started using is-kit more naturally in other OSS projects I maintain.

For example, in my changelog tooling of changelog-bot, I use define to keep small predicates reusable and composable instead of turning every runtime check into an isolated helper.

A simplified example looks like this 👇

import { define, oneOfValues } from "is-kit";

const CHANGELOG_SECTIONS = ["Added", "Changed", "Fixed", "Removed"] as const;

const isChangelogSection = define<(typeof CHANGELOG_SECTIONS)[number]>(
  oneOfValues(CHANGELOG_SECTIONS),
);

The exact code is not the important part.

What changed for me is that I no longer think

"I should use my library here."

I just reach for the guard I need.

A library starts becoming useful to its maintainer when it stops feeling like a demo of itself.

🚀 Then an `is-kit` Guard Ran Into an Effect Type Bug

This was one of the most interesting things that happened recently.

An is-kit user was using a type guard with Effect's catchIf.

Conceptually, the refinement looked like this 👇

(error: unknown): error is SomeError => ...

That is completely normal for is-kit.

In fact, unknown is exactly where the library is designed to start.

But with Effect.catchIf, that refinement could affect generic inference in an unexpected way.

The error channel could become widened to unknown.

The reported case resulted in this Effect PR 👏 And merged 🚀

https://github.com/Effect-TS/effect/pull/9252

The relevant type originally looked roughly like this

refinement: Predicate.Refinement<E, EB>;

and the fix changed it to

refinement: Predicate.Refinement<NoInfer<E>, EB>;

The important idea is that the refinement's input type should not be allowed to redefine the error type already established by the Effect.

The PR also adds type tests for cases like

const result = Effect.catchIf(
  mixedEffect,
  (e: unknown): e is AiError => e instanceof AiError,
  () => Effect.succeed("ok"),
);

Without the fix, the refinement input could participate in inference and widen the error channel.

With NoInfer, the original error type remains the source of truth.

The same pattern was fixed for Channel and Stream too.

There was also a Bluesky post about the issue

https://bsky.app/profile/evadeva.bsky.social/post/3mxwiqfeo3s2j

I really liked this bug because it came from an interaction I would probably never have discovered by testing is-kit alone.

is-kit did not "break Effect". And Effect was not doing something absurd either.

It was a subtle TypeScript inference interaction between a generic API and a refinement whose input was intentionally broad.

That is exactly the kind of edge case that appears when libraries start meeting each other in real code.

👍 This Is the Kind of Feedback I Wanted

When is-kit reached 50 stars, I wrote

"Someone found this idea useful."

That was already enough to make me happy.

100 stars still does not mean the library is huge.

A star is still not a benchmark.
It is still not proof of correctness.
And it definitely does not mean every TypeScript project should install is-kit.

But something has changed.

People are not only starring the repository anymore.

They are

Using the library
Asking questions
Finding edge cases
Reporting bugs
Comparing it with other validation approaches
Using its guards with other TypeScript libraries
Making me reconsider APIs I thought were already finished

That is much more valuable than the number itself. 💖

💬 The Project Is Also Becoming Easier to Explain

Another thing changed between 50 and 100 stars.

I became much clearer about what is-kit is not.

It is not trying to replace every schema library.
It is not trying to turn every runtime value into a schema-first workflow.
And it is not trying to hide normal TypeScript control flow.

The core question is still very small

"Can this unknown value safely enter this branch?"

Sometimes a schema library is the right answer.

For example, if I need:

Rich validation errors
Transformations
Form validation
A contract shared across systems

I may want Zod, Valibot, ArkType, or something else.

But sometimes I already have normal TypeScript code and I only need a reusable narrowing function.

That is where I want is-kit to be useful.

if (isUser(value)) {
  value.id;
}

if (isHttpClientError(error)) {
  // Handle HTTP client errors
}

items.filter(isString);

result.catch(isHttpClientError);

const isMaybeNumber = nullish(isNumber);

Small runtime decisions.
Normal functions.
Normal TypeScript.

🐱 What 100 Stars Means to Me

100 stars is still small compared with the largest TypeScript OSS projects.

No problem.

What matters to me is that the project is becoming more real in ways that have nothing to do with the star counter.

Since the 50-star milestone:

New APIs were added
Existing APIs became stricter
Runtime edge cases were fixed
Package compatibility testing improved
I started using is-kit naturally in other OSS
External usage produced feedback I could not generate alone
An unknown-based refinement even helped expose an inference edge case in Effect

That last part is probably my favorite.

Because the goal was never to build a library that only looks nice in its own README!!!

The goal is to make reusable runtime narrowing work naturally inside real TypeScript code.

And now I am starting to see that happen outside my own repository too.

Thank you to everyone who starred the project, tried it, reported something, asked a question, opened an issue, or simply read the code. 🙏

There is still a lot I want to improve.

But 100 feels pretty nice. 😸⭐

If small composable type guards fit your TypeScript style, give it a try!

https://github.com/nyaomaru/is-kit

Thank you for reading! 🤲

AAIF Hits 10 Projects. Its CTO on What to Adopt Now and the Security Gaps Left Open

Fri, 23 Oct 2026 12:00:00 +0000

The Agentic AI Foundation (AAIF) launched in December 2025 with three projects: the Model Context Protocol (MCP), goose, and AGENTS.md. Less than a year later, it hosts 10.

On October 22, at AGNTCon + MCPCon North America in San Jose, AAIF added four more. Anthropic contributed Agent Skills. OpenAI contributed Open Responses. Hugging Face contributed OpenEnv. Alibaba contributed OpenSandbox. The foundation also announced it has passed 300 member organizations.

That's a lot of new pieces in a short time. So I asked Manik Surtani, AAIF's CTO and co-founder, what vendor-neutral governance means for developers who build on these projects. He worked with all four companies to bring the projects in.

His answers are practical. Nothing changes in how you use MCP today. Don't wait for a reference stack. Pick a sandbox and a gateway now. And the two biggest security gaps in the agentic stack, agent identity and attestation, aren't covered by any AAIF project yet.

The four new projects at a glance

Agent Skills (Anthropic): An open format for packaging instructions, scripts, and resources so agents can load specialized know-how on demand, across products.
Open Responses (OpenAI): An open spec, based on the OpenAI Responses API, for describing LLM requests and outputs once and running them across model providers.
OpenEnv (Hugging Face): A framework and community hub for building and sharing reinforcement learning environments. Each environment runs as a containerized service that exposes MCP and the Gym training interface.
OpenSandbox (Alibaba): A general-purpose sandbox platform for coding agents, GUI agents, evaluation, code execution, and RL training, with Docker and Kubernetes runtimes.

They join A2A, Agent Router, agentgateway, AGENTS.md, goose, and MCP.

Answers have been edited for length and clarity.

You worked with four companies to bring these projects in. What did neutral governance need to guarantee before they handed them over? What did each company give up, and what did it keep?

OpenAI and Anthropic helped bootstrap AAIF, so they already knew what good neutral governance looks like and what it means for them.

Alibaba wanted to be the first non-US project in the foundation, and specifically the first Chinese one. I think that will open the door to more projects coming out of Asia, and I'm excited about that. They didn't need many guarantees either. They have a lot of projects in the CNCF and already see the value. AAIF is part of the Linux Foundation, a sister organization to the CNCF, so they already trusted us.

Hugging Face is a similar story. The Linux Foundation brand is well known, and that trust made it relatively easy to get everyone on board. The common thread is that these companies already understood and valued vendor-neutral stewardship. The conversation was much shorter than people might expect.

For a developer who has already built on MCP or Agent Skills, what actually changes now that the project sits at AAIF?

Day to day, nothing changes. Using these standards stays the same.

What changes is how the projects evolve. Spec changes and improvements will happen with a lot more transparency, with much more of that work in the open. Each project will also have a more structured maintainer group. That gives others a real path to maintainership. The more you participate, contribute, and show commitment, the better your chance of becoming a maintainer and helping steer the project.

So for existing users, the practical effect is stability today and a more open, more broadly governed process for how the specs develop tomorrow.

Open Responses is based on OpenAI's Responses API. How do you keep a spec neutral when it started as one vendor's API?

It comes down to the same mechanism. Competing model providers can now join the project as contributors and help shape the API.

It's also already not just OpenAI's API. Open Responses has been an open source project for a while. More than one company has adopted it, and others are contributing to it. So neutrality isn't hypothetical. A competing provider's path to influence is the same as anyone else's: show up, contribute, build trust, and earn a seat in steering the direction.

These projects touch each other. How is AAIF making sure the 10 projects fit together? Is there a reference stack developers can follow?

People always ask me about a reference stack, and I tend to push back. We started out thinking there should be one. But the more I think about it, the more I believe any reference stack we build today will be out of date tomorrow. The space is changing too fast. I don't want to use one as a roadmap to hunt for missing pieces.

Right now, I think of it as a giant experiment. Everyone is assembling these pieces in different ways, and it's great to see what works and what doesn't. When people deploy something in production, that becomes the reference for that pattern. Other people assemble the same building blocks differently, which is just as interesting.

This isn't cloud, a mature technology with a fairly static, well-understood reference stack. This space is still new and experimental.

If a developer starts a new agent project today, which AAIF projects should they adopt first? Which should they watch?

MCP and A2A are our two most mature projects. Open Responses is now very mature as well.

OpenSandbox is still pretty nascent, and many sandboxing technologies with different approaches are coming out. It's worth watching. But you do need a sandbox. Pick one and start moving. Running without any sandbox is dangerous, and you shouldn't do it.

Routers and gateways sit in the middle. They're an important part of the ecosystem, and the space will keep evolving, so grab one to get started.

The good news is that switching is relatively easy in the agentic world. With agent-driven development, you can migrate from one tool to another without much hassle. In the old days of handcrafting everything, migration was far more expensive. So pick one, and make sure there's a gateway somewhere in between. That gives you the option to migrate models and other important pieces later.

Where are the biggest security gaps in the agentic stack right now? Which ones does no AAIF project cover yet?

The biggest gaps are around identity and authentication. There are nascent standards, but nothing we've adopted yet. There are plenty of commercial products for agent identity worth looking at. Still, I don't think anyone has cracked that nut. We have a working group going deep into the space, and we want to see what comes out of it.

The other big gap is attestation: proof that an agent actually did what you asked and didn't go off the rails and do something else. There are a lot of interesting proposals on the table, and we might soon spin up a working group there as well.

Neither area is covered by an AAIF project today. Both are worth watching closely.

OpenEnv brings AAIF into reinforcement learning. Why do training and evaluation belong in the same foundation as runtime protocols? What does it mean for teams that never train a model?

Having a number of projects doesn't mean everyone needs to adopt everything in one stack. Some pieces matter more to certain engineers, companies, or products, and less to others.

OpenEnv is a good example. It appeals strongly to a certain class of companies and products, but not to everyone. If your team never trains a model, nothing obliges you to touch it. Adopt the protocols and runtime pieces that fit your needs and ignore the rest. AAIF is a home for the building blocks of the agentic ecosystem. Each team takes what's relevant to what it's building.

AAIF passed 300 members in under a year. How does an individual developer or a small team get a real say in a project's roadmap?

Like many open source projects, it's very meritocratic. Get involved, roll up your sleeves, and start working on the project. Contribute ideas, conversations, or code. That's how you earn credibility with the project, and the more you have, the more you can shape it.

There's no fixed timeline. It depends on how much you put in. The path is the same for an individual developer as for a large company: participate, show what you're good at, and demonstrate commitment. Over time, you earn the trust to influence the project's direction and potentially become a maintainer.

Vendors ship new agent features every few weeks. Consensus takes time. How do you balance speed with neutral governance?

One of our main tools is the Sandbox lifecycle stage. (Editor's note: this is a project maturity level, not the OpenSandbox project.)

When we started the foundation, projects could come in at two levels. Impact meant broad, industry-wide adoption, a project that was already a pillar of the industry. Growth was one step before that: production usage and adoption, but not yet ubiquitous.

Even that wasn't enough in a space moving this fast. We needed something earlier for projects with little production usage but lots of developer adoption, momentum, and excitement. Sandbox lets us bring those projects in early without investing too much, so we can watch, learn, and help shape the space.

I think of it as early-stage investing. You make early bets. Some become big and important. Most won't, and that's okay.

As for a concrete example of governance speeding up or slowing down a project, I think it's still too early to point to one.

What should developers expect from AAIF over the next 12 months?

A lot more projects, many more member companies, and a number of AGNTCon + MCPCon events. We have a big lineup planned for next year, from local grassroots events to large conferences like this one. For updates, follow along at aaif.io.

What developers should take from this

Nothing breaks. If you build on MCP, Agent Skills, or Open Responses today, your code doesn't change. What changes is who gets a say in what comes next.
Don't wait for a blueprint. AAIF won't publish a reference stack any time soon. Production deployments are the reference.
Sandbox and gateway now. Surtani was clear: running agents without a sandbox is dangerous. A gateway in the middle keeps your options open on models and tools.
Watch identity and attestation. These are the two biggest open security gaps, and no AAIF project covers them yet. If you're building agents that act on real systems, that's where your own controls need to be strongest.
Influence is earned. Contributing is the path to a say in the roadmap, for individuals and large vendors alike.

Building the MyZubster Metaverse: From Prototype to Secure Realtime Infrastructure

Fri, 23 Oct 2026 05:22:14 +0000

Building the MyZubster Metaverse: From Prototype to Secure Realtime Infrastructure
The MyZubster Metaverse is evolving from a simple interactive experience into a distributed platform designed around secure identity, realtime communication, reliability, privacy, and verifiable collaboration.
During the latest development phase, we focused on the infrastructure required to operate the metaverse safely under real production conditions.
This article explains what we implemented, how the architecture works, what we verified, and what remains before the system can be considered production-ready.
The Current Architecture
The metaverse now follows a layered architecture:
Authenticated user

↓

MyZubster session

↓

Short-lived realtime token

↓

Authorized realtime channel

↓

Distributed gateway

↓

Redis coordination layer

↓

Presence, rate limits and observability
The objective is to prevent clients from connecting directly to unrestricted realtime resources.
Every connection must originate from an authenticated MyZubster session and receive only the permissions required for its specific room or operation.
Authenticated Realtime Sessions
We introduced a dedicated token exchange for realtime connections.
The server:

verifies the current MyZubster session;
checks whether the user may access the requested resource;
generates a short-lived realtime token;
restricts that token to authorized channels;
rejects anonymous or malformed requests.
This limits the damage caused by leaked tokens and prevents clients from subscribing to arbitrary rooms.
A client cannot simply invent a room identifier and connect to it. Authorization is evaluated server-side before realtime access is granted.
Channel Authorization
Realtime channels are treated as protected resources.
The authorization layer validates:
user identity;
session validity;
resource ownership;
room membership;
token expiration;
permitted operations.
This establishes a clear trust boundary between the browser and the realtime gateway.
The client requests access, but the server remains responsible for deciding whether that access is legitimate.
Distributed Presence with Redis
In-memory presence works only while a single application instance is running. It becomes unreliable when multiple instances or serverless functions are involved.
We therefore introduced Redis-backed presence coordination.
Redis is used to track:
active participants;
room membership;
temporary presence state;
expiration of abandoned sessions;
coordination between separate gateway instances.
Presence entries have a limited lifetime. If a client disappears without completing a normal disconnection, the corresponding state can expire automatically instead of remaining indefinitely.
Graceful Redis Failure Handling
Redis is now considered an explicit infrastructure dependency.
The system distinguishes between:
the application process being alive;
the realtime gateway being operational;
Redis being reachable;
the complete service being ready to accept traffic.
Failures are handled deliberately rather than silently ignored. This is important because returning a successful health response while the coordination layer is unavailable would provide misleading information to deployment systems and operators.
Distributed Rate Limiting
Local counters cannot reliably enforce limits across multiple runtime instances.
We implemented a distributed rate-limiting foundation backed by Redis so that requests are evaluated against shared state.
The rate-limiting system is designed to protect:
realtime token generation;
connection attempts;
room joins;
message publication;
presence updates;
abuse-sensitive API routes.
This provides a foundation for defending the metaverse against spam, accidental request loops and automated abuse.
Future work will refine quotas by route, identity, IP risk and operation type.
Privacy-Safe Observability
Reliability requires visibility, but observability must not expose private user information.
The realtime infrastructure now supports structured operational signals for:
authorization failures;
connection lifecycle events;
Redis availability;
rate-limit decisions;
degraded states;
health and readiness checks.
The goal is to make infrastructure problems diagnosable without logging raw credentials, session tokens or unnecessary personal information.
Health and Readiness Endpoints
A process being alive does not mean it is ready to serve realtime traffic.
We extended the health model to include Redis readiness. The service can now report a degraded state when Redis is unavailable instead of returning an unconditional success response.
Conceptually:
Process alive + Redis unavailable
```
       ↓
```
Service is not fully ready
```
       ↓
```
Health response reports degradation
This distinction is essential for:
deployment validation;
load balancers;
automated monitoring;
incident diagnosis;
rolling releases;
recovery procedures.
Shared Redis Client
A reusable Redis client layer was introduced to avoid creating duplicated connections across services and requests.
The shared client centralizes:
configuration;
connection reuse;
error handling;
readiness checks;
shutdown behavior;
instrumentation.
Centralizing this behavior reduces connection pressure and gives every Redis-dependent feature a consistent operational model.
Preview Infrastructure
The new realtime changes were deployed to an isolated Vercel Preview environment.
This allows us to validate infrastructure modifications before they affect the public production deployment.
The preview environment provides a safe place to test:
application builds;
serverless deployment behavior;
environment configuration;
readiness responses;
Redis connectivity;
authentication flows;
realtime regressions.
Production remains unchanged while the current pull request is still under review.
Testing and Continuous Integration
The implementation is covered by automated backend tests, including readiness behavior and Redis degradation scenarios.
The principal validation pipeline successfully completed:
backend tests;
frontend tests;
linting;
application builds;
Seller Free policy verification;
continuous evidence generation;
preview deployment.
This provides strong evidence that the new infrastructure integrates correctly with the existing application.
However, passing tests alone do not make the service production-ready. Runtime drills, dependency remediation and real multi-instance load testing are still required.
Current Development Status
The realtime readiness work is currently available in a draft pull request:
MyZubster realtime readiness PR #40
The implementation includes four focused commits:
feat(realtime): expose Redis readiness
test(realtime): cover Redis readiness
feat(realtime): gate health on Redis
test(realtime): cover Redis health degradation
Keeping the commits focused makes review and rollback easier.
Current Security Blocker
The security audit currently reports vulnerabilities in the transitive ip-address dependency for versions up to 10.7.3.
The available patched version is 10.7.4.
Before merging the realtime work, we need to:
identify which direct dependency introduces ip-address;
update the dependency chain safely;
regenerate the lockfile;
run the complete test suite;
repeat the security audit;
confirm that no high or critical vulnerability remains.
The pull request should remain in draft until this has been addressed and the runtime verification has been completed.
What Still Needs to Be Done
Dependency remediation
Upgrade the affected dependency chain and obtain a clean security audit.
Direct runtime verification
Verify the deployed preview response from:
/api/realtime/health
The response should explicitly show whether Redis is ready and whether the service is operating normally or in a degraded state.
Redis failure drill
Temporarily simulate Redis unavailability in an isolated environment and verify that:
readiness fails correctly;
the service does not claim to be healthy;
errors remain controlled;
recovery occurs after Redis reconnects.
Multi-instance load testing
Run concurrent tests against multiple gateway instances and verify:
shared rate limits;
consistent presence;
room synchronization;
connection cleanup;
acceptable latency;
stable Redis connection usage.
Restart and recovery testing
Restart application and Redis instances while clients are connected.
We need evidence that the platform can recover without leaving permanent ghost sessions or inconsistent presence records.
End-to-end acceptance testing
The complete flow must be tested:
Login
→ request realtime token
→ authorize channel
→ connect
→ join room
→ publish event
→ update presence
→ disconnect
→ clean up state
Unauthorized variations must also be tested.
Production rollout strategy
The production release should be gradual:
deploy to Preview;
complete runtime verification;
run load and failure drills;
review monitoring signals;
merge after approval;
deploy production;
observe error rates and Redis health;
retain a documented rollback procedure.
Longer-Term Metaverse Roadmap
Once reliability and security are validated, development can move toward the experience layer.
Planned areas include:
WebXR support;
immersive rooms;
interactive avatars;
spatial collaboration;
verified professional profiles;
Zorgax integration;
verified knowledge inside virtual environments;
community-managed spaces;
portable identity;
privacy-safe analytics;
independent interoperable nodes.
The long-term objective is not merely to build another virtual world.
MyZubster aims to combine identity, knowledge, collaboration and transparent open-source development inside an interoperable environment.
Lessons Learned
The most important lesson from this phase is that realtime development is not simply about sending messages quickly.
A reliable realtime platform must answer several harder questions:
Who is allowed to connect?
Which channels may they access?
How is state shared across instances?
What happens when Redis fails?
How is abuse limited globally?
Can operators distinguish “alive” from “ready”?
Can the system recover cleanly after a restart?
Can failures be investigated without exposing private data?
These concerns are now becoming first-class parts of the MyZubster architecture.
Conclusion
The MyZubster Metaverse has progressed beyond an isolated prototype.
We now have the foundation for:
authenticated realtime access;
server-controlled channel authorization;
Redis-backed presence;
distributed rate limiting;
privacy-aware observability;
dependency-aware health checks;
isolated preview deployments;
automated tests and evidence generation.
The next milestone is to prove that this architecture remains reliable under dependency failures, restarts, concurrency and realistic traffic.
Only after those checks—and after resolving the current security advisory—should the realtime infrastructure be promoted to production.
MyZubster remains an open-source project, and technical review, testing and constructive contributions are welcome.
Project Links
MyZubster repository
MyZubster Metaverse
Realtime readiness pull request
Repository GitHub: https://github.com/danieldirimini-myzubster/myzubster
Metaverso MyZubster: https://www.myzubster.com/metaverse
Pull request Realtime Readiness #40: https://github.com/danieldirimini-myzubster/myzubster/pull/40
Roadmap Linear MYZ-83: https://linear.app/myzubster/issue/MYZ-83/b6-realtime-observability-reliability-and-load-tests
Organizzazione GitHub MyZubster Ecosystem: https://github.com/MyZubster-Ecosystem
Profilo GitHub MyZubster: https://github.com/myzubster
Sito principale: https://www.myzubster.com
Knowledge Explorer: https://www.myzubster.com/knowledge
Profilo Zorgax: https://www.myzubster.com/zorgax-profile-onboarding

I Built Avi.js — A Lightweight TypeScript Framework Inspired by NestJS

Thu, 22 Oct 2026 14:41:50 +0000

I Built Avi.js — A Lightweight TypeScript Framework Inspired by NestJS

I've been working on an open-source project called Avi.js, and I recently released v0.1.2! 🚀

Avi.js — Structure without the overhead.

It's a lightweight, TypeScript-first backend framework for Node.js, inspired by the structured development experience of NestJS.

The idea started with a question:

Can we build a structured TypeScript backend framework with modules, controllers, and dependency injection—without requiring reflect-metadata?

That's what I've been exploring with Avi.js.

What I've built so far

Before getting into the latest update, here's a look at what Avi.js currently supports.

1. Modules, controllers, and dependency injection

Avi.js supports a modular architecture with explicit dependency declarations rather than relying on runtime reflection.

It includes singleton, transient, and request-scoped providers, along with startup checks for missing dependencies and circular references.

The goal is to keep dependencies visible in code while providing a familiar way to organize backend applications.

2. Two API styles, one engine

Avi.js supports two ways of defining controllers:

Decorator-based API: Class-based controllers and modules using standard TC39 decorators.
Explicit API: Plain TypeScript objects and functions without decorators.

Both approaches use the same router, dependency injection container, and request pipeline.

This gives developers the flexibility to choose the style that fits their project.

3. Dependency injection without `reflect-metadata`

Instead of inferring constructor dependencies through emitted runtime metadata, Avi.js uses explicit declarations such as static inject.

For example:

@Controller('/users')
class UsersController {
  static inject = [UsersService] as const;

  constructor(private readonly users: UsersService) {}
}

This approach doesn't require reflect-metadata, emitDecoratorMetadata, or legacy experimental decorators.

It's a design choice focused on making dependency wiring explicit and understandable.

4. Native Node.js HTTP

Avi.js runs on Node.js's native node:http module without requiring Express or Fastify underneath.

It supports:

HTTP routing and route parameters
Middleware and guards
Request and response hooks
JSON, text, and streaming responses
Graceful shutdown

5. Validation, security, and developer tooling

Avi.js also includes several features for building and maintaining backend applications:

Schema validation using Standard Schema-compatible libraries
CORS and security headers
OpenAPI 3.1 document generation
Testing utilities with provider overrides
CLI scaffolding and code generation
Startup checks for dependency and route configuration errors

These features are already available in the current early-development releases.

What's new in v0.1.2?

One feature I'm particularly excited about is resource generation.

You can now generate an entire CRUD resource using one command:

npx avi g resource posts

For a modular project, the CLI generates:

src/
└── modules/
    └── posts/
        ├── posts.module.ts
        ├── posts.controller.ts
        └── posts.service.ts

The CLI also registers the resource in your application automatically.

The generated resource includes working GET, POST, PATCH, and DELETE routes backed by an in-memory store, which you can later replace with your own database integration.

For minimal projects, Avi.js generates services and routes without requiring modules.

The goal is to reduce repetitive setup while keeping the generated code understandable and editable.

Getting started

You can try Avi.js with Node.js 22.12 or newer.

Create a new project:

npm create avi@latest my-api
cd my-api
npm install
npm run dev

Avi.js currently provides two official project templates:

Modular (default): A feature-first structure with modules, controllers, and services.
Minimal: A smaller, functional structure using explicit routes and services.

Both templates run on the same framework engine, so you can start small and introduce more structure as your application grows.

You can also install the core package directly into an existing project:

npm install @avijs/core

Avi.js is still in pre-alpha development (0.x), and its APIs may change before 1.0.

I'm not trying to claim it's faster or better than established frameworks. It's an experiment in building a structured backend framework with explicit dependencies and fewer runtime abstractions.

I'm sharing it because I'd love to get feedback from developers who enjoy working with Node.js and TypeScript.

If you're curious, feel free to try it, open an issue, or contribute.

Official website: https://chrischase011.github.io/avi-js/

GitHub: https://github.com/chrischase011/avi-js

Latest release: https://github.com/chrischase011/avi-js/releases/tag/v0.1.2

Thanks for checking it out! 🚀

#typescript #nodejs #opensource #webdev

PHP2Shell: Two 9.2-Rated Flaws Reach Back to PHP 5. Here's the Plan for EOL Teams

Thu, 22 Oct 2026 13:00:00 +0000

PHP shipped emergency patches on October 21 for two critical flaws now known as PHP2Shell. Both are rated 9.2 under CVSS v4.0. Both can let an unauthenticated attacker run code on your server.

The fixes are in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If you run a supported branch, update and restart your PHP workers. That part is simple.

The harder question is what to do if you run a version that no longer gets community patches. A lot of teams are in that spot.

I asked Matthew Weier O'Phinney about it. He's principal product manager for Perforce OpenLogic and Zend, and he sits on the PHP Foundation board. Perforce sells extended support for end-of-life (EOL) open source software, so keep that in mind when he talks about extended support. But he also had a close view of how this disclosure played out.

What the flaws do

CVE-2026-109618 corrupts memory when PHP hits an out-of-memory error in the middle of a request. CVE-2026-109619 involves stale global state. PHP keeps pointers to request data after that memory has been freed.

Weier O'Phinney put it in plain terms. "An attacker can create one or more payloads that simulate large file uploads, or multi-file uploads, that hit configured memory limits for the PHP application," he said. Because of how PHP handled memory and errors at that moment, the attacker could end up running system commands on the server.

The attack doesn't need a vulnerable application or a public upload form. And the timeline was tight. Details leaked on October 20, a day before the coordinated release. Security firm Sansec reports that Cloudflare saw attacks hours before the patches shipped.

It's not just mod_php

PHP's advisory named Apache's mod_php as the highest-risk configuration. Some early coverage stopped there. Weier O'Phinney says that's too narrow.

"These vulnerabilities affect every single Server API (SAPI) provided by the language, because their roots are deep within how the engine manages memory and handles errors," he said. "If you run PHP, your application is affected, plain and simple."

mod_php may be the easiest path in. But PHP has also confirmed remote code execution against PHP-FPM under the right application conditions. If you run FPM behind Nginx, you're not off the hook.

Workarounds buy time. They don't fix the problem.

The early advice was to turn off session upload progress and remove memory limits. Weier O'Phinney says those steps help, but only so much. "They just change the size of the file upload payloads the attacker needs to use to exploit the system," he said.

He's more positive about two other measures:

A web application firewall (WAF) that limits which paths accept uploads, or any user submission
AppArmor or SELinux to restrict PHP's access to system binaries

Both are good defense-in-depth. But he warns that creative attackers can still find ways around them if the PHP runtime underneath is vulnerable.

PHP says the same thing. Updating is the only complete fix. If you removed the memory limit as a stopgap, put a container or cgroup limit in place, and restore a finite limit once you've patched.

The end-of-life problem

Here's where it gets uncomfortable. According to Weier O'Phinney, every PHP version before 8.2 is past community support. And 8.2 reaches end of life at the end of this year.

These flaws trace back to the PHP 5 series. "If you're running PHP 5, PHP 7, or early PHP 8 versions, you will need to audit your applications and deployments," he said.

He sees two paths:

Use a commercial long-term support (LTS) provider. Several have patched EOL versions. Perforce Zend patched PHP 7.2, 7.3, 7.4 and 8.1 in coordination with the PHP Security team. If you already have a provider, confirm it shipped patches for your version.
Start migrating to a community-supported version. That means 8.2 or later. Since 8.2 is nearly at end of life itself, a migration that stops there only buys you a couple of months.

If you have neither, his advice is to pick one today.

AI changed the clock

The backstory matters here. A security audit sponsored by the Sovereign Tech Agency and the PHP Foundation found these attack vectors last year. But the security team couldn't find a practical way to trigger them. They treated the flaws as largely theoretical and kept working on them off and on.

Then, this past August, two independent researchers found the same issues within days of each other. Each was using a frontier AI model. Each built a way to exploit them. The PHP Security team had to move them to the top of the list.

That's the real shift. A bug that sat in the "theoretical" pile for a year became practical in a matter of days.

Weier O'Phinney sees the same pattern across open source. The cURL project has been handling a flood of AI-discovered reports for two years. Spring has seen a big jump in reports this year. And those reports still need people to review them. Maintainers have to confirm that each patch works, doesn't break existing behavior and doesn't add new flaws. Many AI-generated reports also overstate severity, which takes more time to sort out.

For EOL software, this is the core risk. Discovery is speeding up. Patches for unsupported versions aren't.

Migration or extended support?

Weier O'Phinney is clear that migration is the goal. Current versions get new features and security fixes first, and the rest of the ecosystem tends to follow the latest releases.

But he's also realistic. Continuous upgrades take discipline, solid testing and QA, and a DevOps team that can roll releases out and roll them back. Some companies also face regulatory reviews every time they move to a new feature release. That costs time and money, so migration gets pushed back.

"So adopt those new versions if you can, but have a plan for when you cannot," he said.

That's fair advice, and it's worth taking at face value. Extended support is a bridge, not a destination. If you're evaluating a provider, ask one simple question: how fast did it ship PHP2Shell patches for your version? The answer tells you a lot.

How the disclosure worked

Weier O'Phinney knew for a couple of months that big security patches were coming. He didn't know the details. "That's a good thing," he said. Fewer people in the loop means less chance of a leak.

The PHP Foundation now employs a small team that coordinates security work between researchers and the PHP project. One of them contacted Weier O'Phinney in his role at a commercial LTS provider to line up releases. In more than 20 years at Zend, that was a first for him. The PHP Security team worked with Zend's packaging team and reviewed its patches so both were ready on release day.

His bigger concern is capacity. The PHP Security team is small, and the volume of incoming reports keeps growing. He'd like to see it staffed well enough to coordinate like this more often. His ask: if your company depends on PHP, consider donating to the PHP Foundation.

What to do this week

Find every PHP runtime you have. Check servers, containers, base images and hosting accounts. Trust php -v, not your documentation.
Patch supported branches now. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, then restart PHP workers so the new code is actually running.
Check EOL versions separately. If you use an LTS provider, confirm it has shipped fixes. If you don't, choose between getting one and starting a migration.
Treat workarounds as temporary. Undo emergency config changes once you've patched.
Keep the extra layers. A WAF and AppArmor or SELinux are worth having after the patch, too.
Plan for more of this. AI-assisted discovery isn't slowing down. Budget time for triage and upgrades, not just for incidents.

PHP2Shell will get patched on most supported systems this week. The teams still exposed next month will be the ones running PHP that nobody owns. Now is a good time to find out if that's you.

From Lab to Code #1: Exploring Classical Computer Vision with Python and OpenCV

Thu, 22 Oct 2026 12:53:42 +0000

Most conversations about computer vision today revolve around deep learning, neural networks, and increasingly sophisticated AI models.

But not every image processing problem requires a trained model.

Sometimes, a Gaussian filter is enough to reduce noise. A threshold can separate objects from their background. A Fourier transform can reveal interference that is difficult to understand in the spatial domain.

These techniques are relatively simple, mathematically interpretable, and still useful in practical applications.

Recently, while exploring image and signal processing concepts in my computer engineering studies, I decided to start a small programming series called From Lab to Code.

The idea is simple: take engineering concepts I encounter, build independent implementations, visualize the results, and share what I learn.

For the first project, I built a small interactive image processing toolkit using Python, OpenCV, NumPy, and Streamlit.

GitHub repository: https://github.com/Ertugrulmutlu/from-lab-to-code

Project 01 — Image Processing: https://github.com/Ertugrulmutlu/from-lab-to-code/tree/main/01-image-processing

What Are We Building?

The application explores four classical computer vision techniques:

Image denoising using Gaussian and median filters.
Object counting using illumination correction, thresholding, and connected components.
Periodic noise removal using the Fast Fourier Transform (FFT).
Color clustering using K-means.

The application provides interactive controls, generated example images, and visual comparisons.

No pretrained models, API calls, or external datasets are required.

All bundled demonstration images are generated programmatically.

1. Image Denoising: Gaussian vs. Median Filtering

Digital images are often affected by noise.

Noise can originate from camera sensors, poor lighting conditions, signal transmission, or image acquisition hardware.

Two common types are:

Gaussian noise: Random variations in pixel intensity, often modeled using a normal distribution.
Salt-and-pepper noise: Individual pixels unexpectedly taking very dark or very bright values.

Different noise distributions require different filtering strategies.

Gaussian Filtering

A Gaussian filter performs a weighted average of neighboring pixels.

Pixels closer to the center receive higher weights, following a Gaussian distribution.

Mathematically, the two-dimensional Gaussian kernel can be written as:

G(x, y) = (1 / 2πσ²) × exp(-(x² + y²) / 2σ²)

The parameter σ controls the amount of smoothing.

A larger σ produces stronger smoothing but can also remove fine image details.

In OpenCV, Gaussian filtering is straightforward:

import cv2

gaussian = cv2.GaussianBlur(
    image, (5, 5), 0
)

Median Filtering

Unlike Gaussian filtering, a median filter replaces the center pixel with the median value of its neighborhood.

Consider these pixel values:

[10, 11, 12, 13, 255]

Their average is 60.2, but their median is 12.

If the value 255 represents an isolated noise spike, the median is much closer to the surrounding pixel values.

This makes median filtering particularly useful for salt-and-pepper noise.

median = cv2.medianBlur(image, 5)

Comparing the Results

The application applies both filters to the same noisy image.

It also calculates the Mean Squared Error (MSE) against the original image when a reference is available.

MSE = (1/N) × Σ(original - processed)²

A lower MSE indicates a smaller average squared difference from the reference image.

However, MSE alone does not fully describe perceptual image quality.

Key takeaway: Gaussian filtering is useful for smoothing distributed noise, while median filtering is often more effective against isolated intensity spikes.

Neither method is universally superior.

2. Object Counting: From Pixels to Objects

Suppose we want to count small objects placed on a table.

At first, this sounds like a simple thresholding problem.

If the objects are darker than the background, we could classify pixels based on their intensity.

But what happens when the background illumination is uneven?

One side of the image might be noticeably darker than the other, making a single global threshold unreliable.

Step 1: Estimate the Background

We can approximate slowly changing illumination using a large Gaussian blur.

background = cv2.GaussianBlur(
    gray, (0, 0), sigmaX=30
)

Subtracting the original image from the estimated background helps emphasize darker foreground objects.

corrected = cv2.subtract(
    background, gray
)

This reduces the influence of gradual illumination changes.

Step 2: Apply Otsu Thresholding

Otsu's method automatically selects a threshold based on the image's intensity distribution.

Instead of manually choosing a number such as 100 or 150, it searches for a threshold that separates the intensity classes according to their statistical variance.

_, mask = cv2.threshold(
    corrected,
    0,
    255,
    cv2.THRESH_BINARY + cv2.THRESH_OTSU
)

The output is a binary image containing foreground and background pixels.

Step 3: Identify Connected Components

After thresholding, neighboring foreground pixels can be grouped into connected regions.

OpenCV provides a useful function for this:

count, labels, stats, centroids = (
    cv2.connectedComponentsWithStats(
        mask, connectivity=8
    )
)

The function returns component labels and information such as bounding boxes and pixel areas.

By excluding the background and removing regions below a minimum area, we can estimate the number of objects.

The project also applies a small morphological opening operation before counting to remove isolated foreground noise.

Where Can This Be Useful?

This approach can be applied to controlled visual inspection tasks involving separate objects, such as small manufactured components.

However, it comes with important assumptions.

Objects should be sufficiently separated, and the contrast between objects and background should be reasonably clear.

Touching objects may merge into a single connected component.

Key takeaway: Reliable object counting often requires preprocessing, not just thresholding.

3. Fourier Transform: Removing Periodic Noise

This was one of the most interesting parts of the project.

Images are normally represented in the spatial domain, where each pixel corresponds to a position.

But some image artifacts are easier to identify in the frequency domain.

For example, imagine an image affected by regularly repeating stripes.

Those stripes represent periodic variations in pixel intensity.

Moving to the Frequency Domain

The two-dimensional Discrete Fourier Transform decomposes an image into spatial frequency components.

Each component represents a particular frequency and orientation.

Using NumPy:

import numpy as np

spectrum = np.fft.fft2(gray)

shifted = np.fft.fftshift(spectrum)

magnitude = np.log1p(
    np.abs(shifted)
)

Here:

fft2() computes the two-dimensional Fourier transform.
fftshift() moves the zero-frequency component to the center.
abs() obtains the magnitude.
log1p() makes the magnitude spectrum easier to visualize.

Periodic interference may appear as distinct peaks in the Fourier spectrum.

Removing Specific Frequencies

If we know which frequencies correspond to interference, we can suppress them using a notch filter.

A notch filter removes selected frequency regions while preserving much of the remaining spectrum.

For real-valued images, the Fourier spectrum has conjugate symmetry.

This means a sinusoidal interference component generally produces a symmetric pair of frequency peaks.

Both should be handled to preserve the symmetry of the filtered spectrum.

The basic operation is:

filtered_spectrum = shifted * mask

Here, mask contains zeros at the frequencies we want to suppress and ones elsewhere.

We then reconstruct the image using the inverse Fourier transform.

restored = np.fft.ifft2(
    np.fft.ifftshift(filtered_spectrum)
).real

An Important Limitation

In this project, the periodic noise is generated with known frequencies.

Therefore, the notch filter already knows where the unwanted frequency components are located.

This is intentional: it lets us isolate and study the effect of frequency-domain filtering.

Automatically identifying unknown interference frequencies in arbitrary photographs is a separate problem and is not implemented here.

A notch filter can also remove useful image information if the rejected frequencies overlap with actual image content.

Key takeaway: The Fourier transform provides another perspective on image processing, allowing us to manipulate structures according to their spatial frequencies rather than their pixel positions.

4. K-Means: Unsupervised Color Clustering

The final technique explores unsupervised learning.

Unlike classification models, K-means does not require predefined class labels.

Instead, it groups observations based on similarity.

For an RGB image, each pixel can be represented as a three-dimensional vector:

Pixel = [Red, Green, Blue]

K-means attempts to divide these vectors into K clusters by minimizing the squared distances between pixels and their assigned cluster centers.

The objective function is:

J = Σ ||xᵢ - μ(clusterᵢ)||²

where xᵢ is a pixel vector and μ is the corresponding cluster center.

Implementing K-Means with OpenCV

First, reshape the image into a collection of RGB vectors:

pixels = image.reshape(
    -1, 3
).astype(np.float32)

Then run K-means:

criteria = (
    cv2.TERM_CRITERIA_EPS +
    cv2.TERM_CRITERIA_MAX_ITER,
    25,
    0.2
)

_, labels, centers = cv2.kmeans(
    pixels,
    4,
    None,
    criteria,
    5,
    cv2.KMEANS_PP_CENTERS
)

We can reconstruct an image by replacing each pixel with the color of its assigned cluster center.

This produces a simplified image containing a small number of representative colors.

Color Clustering Is Not Semantic Segmentation

This distinction is important.

K-means only sees RGB values in this implementation.

It does not understand objects, scenes, or semantic categories.

Two unrelated objects with similar colors may belong to the same cluster.

Likewise, one object with multiple colors may be split across several clusters.

Still, color clustering is useful for exploring image structure, reducing color complexity, and understanding unsupervised learning.

Running the Project Locally

The project is available on GitHub:

https://github.com/Ertugrulmutlu/from-lab-to-code/tree/main/01-image-processing

You will need Python 3.10 or newer.

Clone the repository:

git clone https://github.com/Ertugrulmutlu/from-lab-to-code.git
cd from-lab-to-code/01-image-processing

Create a virtual environment:

python -m venv .venv

Activate it on Windows PowerShell:

.\.venv\Scripts\Activate.ps1

Install the dependencies:

python -m pip install -r requirements.txt

Start the application:

python -m streamlit run app.py

Streamlit will open an interactive application in your browser.

You can switch between the four techniques, adjust processing parameters, and compare the results.

Each mode includes a programmatically generated example image. You can also upload an image of your own.

To regenerate the demonstration gallery:

python demo.py

To run the included tests:

python -m unittest discover -s tests -v

The processing algorithms are implemented in processing.py, while synthetic.py generates the example images and app.py contains the Streamlit interface.

What I Learned

Building this project reinforced several important ideas.

First, understanding the characteristics of a problem matters as much as selecting an algorithm.

Gaussian filtering and median filtering may look similar at first, but they behave differently depending on the noise distribution.

Second, preprocessing can determine whether a simple computer vision algorithm succeeds or fails.

In the object counting example, background illumination correction can be just as important as the thresholding operation itself.

Third, the frequency domain provides a different way to reason about images.

Some patterns that are difficult to isolate spatially become much easier to analyze after a Fourier transform.

Finally, unsupervised clustering demonstrates that useful structure can be extracted from images without labeled training data, even though grouping colors is not the same as understanding a scene.

Why I Started From Lab to Code

I wanted a lightweight way to turn engineering concepts into practical software projects.

Not every project needs to become a startup, a large framework, or a long-term product.

Sometimes, a small, well-explained implementation is enough to explore an idea and demonstrate what you have learned.

That is the philosophy behind From Lab to Code.

Each entry will focus on an engineering topic, build a small independent implementation, and document the underlying concepts and results.

The projects are independently implemented, with original demonstration materials rather than redistributed university coursework.

This first project focuses on classical image processing. Future entries may explore other engineering topics as I encounter them.

If you are learning computer vision or signal processing, I hope the code and explanations help you experiment with these concepts yourself.

Explore the series: https://github.com/Ertugrulmutlu/from-lab-to-code

Explore the image processing project: https://github.com/Ertugrulmutlu/from-lab-to-code/tree/main/01-image-processing

Thanks for reading!

# 🚀 MyZubster is looking for contributors — Let's build a community-powered marketplace!

Thu, 22 Oct 2026 05:55:41 +0000

🚀 MyZubster is looking for contributors — Let's build a community-powered marketplace!

What if your GitHub contributions could become real opportunities to earn, collaborate and build independent projects?

We're building MyZubster, an open-source ecosystem connecting developers, digital creators, freelancers and local communities.

Our vision is to create a marketplace where people can:

💻 Offer digital skills — programming, UI/UX, AI, DevOps, cybersecurity and blockchain development.

🤝 Exchange services, collaborate on projects and support volunteer initiatives.

₿ Explore payments using Bitcoin (BTC), Ethereum (ETH), Monero (XMR) and traditional currencies.

🔐 Help design secure multisig escrow solutions, with legal and regulatory compliance considered from the beginning.

🌍 Connect GitHub contributions, digital portfolios and independent community projects.

🧠 We need your ideas, not just your code!

We've opened a community discussion to explore how MyZubster can become a practical, sustainable and legally compliant marketplace.

We're looking for:

Developers and open-source contributors
Blockchain and cryptocurrency specialists
UI/UX designers
Privacy and security researchers
Legal, fintech and compliance professionals
Freelancers interested in selling digital skills

Some features are already under development; others are proposals we want to design and validate together.

We especially want to explore how contributors can offer their digital services through the marketplace, how crypto payments should work, and how to reduce legal and technical risks for everyone involved.

🔗 Join the discussion

GitHub community topic:
https://github.com/MyZubster-Ecosystem/myzubster/issues/1639

Project repository:
https://github.com/MyZubster-Ecosystem/myzubster

Website:
https://myzubster.com

💬 Introduce yourself, share your expertise, propose an idea or tell us what you'd like to build.

You don't need to be an expert in everything. Every meaningful contribution matters.

Let's build something useful, open and sustainable — together.

OpenSource #GitHub #Blockchain #Monero #Bitcoin #Ethereum #Marketplace #WebDevelopment #Freelancing #Decentralization #MyZubster

Costcodle: a daily price guessing game

Thu, 22 Oct 2026 01:40:36 +0000

Plenty of people walk the aisles of a Costco warehouse and guess the price of a bulk pack before they look at the tag. Wordle showed that one small puzzle a day, the same for everyone and finished in about a minute, can quietly turn into a habit. I put those two things together.

Costcodle is a free daily Costco price guessing game. Every day everyone gets the same Costco item and six guesses to land within 5% of its price. A new item starts at 00:00 UTC. It runs in the browser, there is no account, and your stats stay on your device.

How a round works

One item. You see a product photo, its name and the pack size. Bulk sizes are part of the challenge.

A typed guess. Enter a dollar amount like 12.99 and press Submit. Anything from $0.01 to $999,999.99 with at most two decimals is accepted.

A receipt for feedback. Each guess prints a new line on a receipt. Higher or Lower tells you which way to go. Within 25% of the price, the line is marked Close.

A 5% target. Land within 5% of the price, edges included, and you win. Use all six guesses without getting there and the receipt reveals the answer.

The prices are snapshots collected for the original Costcodle game, so treat them as a fun reference rather than today's shelf price. Real prices change over time and differ by location.

A real game looks like this

Here is puzzle #1122 from October 15, 2026, an Organic Crimini Mushrooms 24 oz pack. It is a past puzzle with a published answer, so nothing here spoils a live game.

Guess $4.00. The receipt says Higher. The guess is 33% off, outside the Close band.
Guess $7.00. The receipt says Close and Lower. Now it is 17% off.
Guess $6.00. Win.

The price was $5.99, and the winning range was $5.70 to $6.28. Solved in 3 of 6 guesses. This exact game is also the 30-second walkthrough video if you would rather watch it than read it.

Three ways to play

The daily puzzle is the main event. One item for the whole world each day, with your games played, win rate, streaks and guess distribution saved in your browser. Once you finish, the Stats panel also shows how everyone did on today's item: players, win rate and the spread of wins by number of guesses.

Costcodle Unlimited deals random past items one after another, with the same six guesses and the same 5% rule. It never touches your daily streak, so it works as a warm-up or as a way to keep going after the daily game.

Costcodle answers lists the published answers of past puzzles, each with its game price and winning range.

When you finish, you can share your receipt as a short grid: one row per guess, colored for Win, Close or Far, with an arrow for Higher or Lower. The price is never in it, so friends can still play the same item.

Stack notes for the engineers in the room

A price game has one secret to keep, and the browser is the wrong place to keep it. Most of the engineering went into that and into getting the rules exactly right.

Integer cents everywhere. Every amount is an integer number of cents. The win check is written as |guess - price| * 100 <= price * 5, so the 5% edge is exact with no floating point in the way. On #1122, $5.70 wins and $5.69 is only Close; $6.28 wins and $6.29 is Close again.

The answer stays on the server. Each guess is a POST that the server judges. A game in progress lives in a token signed with HMAC-SHA-256, so the server keeps no session table, and only the response that ends the game, win or loss, carries the price. The page HTML, the JavaScript bundle and the structured data never contain today's price, and a build check fails if a file a browser can download carries question bank data.

Practice never leaks the daily game. Unlimited deals only puzzles that are over: never today's, never a future one, and never yesterday's while its grace window is still open. That rule is one function in the rules package, so the daily game and the practice mode cannot disagree about it.

A schedule in UTC. Puzzle numbers are computed from an anchor (October 15, 2026 is #1122) plus whole UTC days. If you started a game before midnight, you have a 10 minute grace window to finish it.

The rules are open source. costcodle-rules is the rules engine behind the site: guess judging, price parsing, the daily schedule and the spoiler-free share text. It is MIT licensed, pure TypeScript with no runtime dependencies, and published on npm under the same name. It is exported from the site's own repository, so it is the code the live game runs, and every example in its README is covered by a test.

import { evaluateGuess, winningRange } from "costcodle-rules";

evaluateGuess(400, 599); // { guessCents: 400, band: "far", direction: "higher" }
evaluateGuess(700, 599); // { guessCents: 700, band: "close", direction: "lower" }
evaluateGuess(600, 599); // { guessCents: 600, band: "win", direction: "none" }
winningRange(599);       // { minCents: 570, maxCents: 628 }

One Worker. The site is Astro with React islands on a single Cloudflare Worker, with D1 for data and a private R2 bucket for product photos. Pages are cached at the edge under a key that includes the build version and a publication revision, so publishing a new answer page makes the old copies unreachable without purging anything. The same Worker runs three scheduled jobs: one fetches the next product photo at 23:55 UTC, one publishes the answer pages of finished puzzles just after midnight, and an hourly one retries anything that failed.

Pricing

Part	Price	Account
Daily puzzle	Free	None
Costcodle Unlimited	Free	None
Costcodle answers	Free	None
costcodle-rules	MIT license	None

Costcodle is an independent fan game. It is not affiliated with, endorsed by, or sponsored by Costco Wholesale Corporation.

Your turn

If you play a round, I would like to hear how close your first guess was. And for the developers here: would you set the Close band at 25%, or is that too generous for a game with a 5% target?

MyZubster Dev Update: Local AI, GitHub Onboarding & Decentralized Collaboration 🚀

Wed, 21 Oct 2026 05:38:10 +0000

MyZubster Dev Update: Local AI, GitHub Onboarding & Decentralized Collaboration 🚀

We're building MyZubster, an open-source ecosystem connecting developers, independent projects, services, and communities.

Today we made significant progress on Zorgax, our locally hosted AI assistant.

Our goal is simple: make it easier for anyone — including people with no programming experience — to join GitHub, contribute to projects, and become part of a collaborative ecosystem.

🔧 What We Built and Tested

1. Vercel ↔ VPS Connectivity

We restored communication between our Vercel Production deployment and the VPS backend using a signed HTTPS gateway.

Production assistant endpoint responding successfully
HTTP 502 connectivity issue resolved in our tests
Node.js gateway operational
MongoDB connected
Local Ollama inference available

2. GitHub Contributor Onboarding

We implemented a deterministic onboarding guide in Zorgax.

The assistant can now:

Guide new users to GitHub registration
Recognize completion messages such as FATTO
Ask for a GitHub username
Recognize that username within the conversation
Advance to Git and GitHub CLI setup
Avoid claiming an account has been verified without evidence

3. Real Production Testing

Our regression tests passed: 4/4.

We also tested the public Zorgax chat and confirmed that the assistant correctly advanced from GitHub registration to the username and tooling stages.

4. Local AI Architecture

Our system currently combines:

Node.js backend
Vercel frontend and gateway
VPS-hosted services
Ollama with qwen2.5:3b
Deterministic onboarding rules
MongoDB

This approach helps us keep sensitive onboarding workflows predictable while using local AI for more flexible assistance.

🐛 What Still Needs Work

Our tests also revealed that Zorgax can lose track of the onboarding sequence when it falls back to Ollama.

For example, after Git and GitHub CLI version checks, it may answer a different MyZubster-related question instead of continuing with GitHub authentication.

We're working toward a complete flow:

GitHub signup → username → Git/CLI checks → authentication → repository → first pull request

We want every step to be clear, verifiable, and beginner-friendly.

🌍 Beyond a Traditional Marketplace

MyZubster is also exploring ways to connect:

Independent developer projects
Skills and services through a marketplace
Contributor profiles and verifiable contributions
Local community initiatives
Decentralized infrastructure and autonomous nodes
Privacy-conscious payments and collaboration

Our longer-term vision is a federated ecosystem where contributors can develop their own projects while remaining connected to a broader network.

These are ongoing development goals, not claims that every feature is already production-ready.

🤝 Looking for Contributors

We're particularly interested in developers who want to help with:

AI-assisted GitHub onboarding
Node.js and API testing
UX/UI simplification
GitHub automation
Marketplace workflows
VPS and decentralized infrastructure
Open-source documentation

You don't need to build everything. Even a small, well-tested contribution can move the project forward.

Explore MyZubster: https://www.myzubster.com

Try Zorgax: https://www.myzubster.com/zorgax

GitHub: https://github.com/MyZubster-Ecosystem

Let's collaborate

We're interested in connecting independent developers and projects rather than requiring everyone to work inside a single centralized system.

Question for the community: How would you design an AI onboarding assistant that guides a complete beginner from creating a GitHub account to opening their first pull request?

OpenSource #AI #GitHub #NodeJS #Decentralization #DeveloperCommunity

Inside OpenPLC Runtime v4: Establishing a Security Research Baseline

Mon, 19 Oct 2026 21:28:33 +0000

An architectural investigation into the processes, communication interfaces, and Linux environment surrounding a software PLC runtime.

It has been a little over a month since I wrapped up my industrial protocol research series. At the time, I said something new was coming. Here it is.

The protocol series taught me a lot about how industrial systems communicate. For this next stage, I wanted to look at a different part of the picture... the PLC runtime itself.

I chose OpenPLC Runtime v4 as the first target for a new series of PLC security investigations. Before testing individual security properties, I wanted to understand what was running, how its components interacted, and what the surrounding Linux environment allowed them to do. That became the first investigation: establishing a baseline.

Why start with architecture?

A PLC runtime sits between control logic and the environment in which that logic executes. Its behavior depends on more than the code that runs inside it. Processes, local communication channels, loaded components, operating system permissions, and resource limits can all affect how it operates.

I wanted to answer a few practical questions before moving into deeper testing.

What processes make up the runtime? Which communication interfaces are visible? What privileges and operating system resources are available to the processes? How does the runtime behave when one of its components exits unexpectedly?

These questions helped define the scope. I was not trying to find a vulnerability in this first investigation. I wanted to document the environment well enough that future tests would have a reliable point of reference.

The target and lab

The target was OpenPLC Runtime v4, running in an isolated Docker container on my research machine. Keeping it in a container gave me a repeatable environment to inspect without involving a physical PLC or a production control system.

I started the container with the runtime image and published ports for the web interface and Modbus TCP:

docker run -d \
  --name openplc-v4-lab \
  -p 8443:8443 \
  -p 502:502 \
  ghcr.io/autonomy-logic/openplc-runtime:latest

One detail matters for anyone reproducing this work: the image uses the latest tag. That tag can point to a different image over time, so it should not be treated as a fixed version. For a reproducible investigation, record the image digest and runtime version used during the test.

The container provided a contained target for process inspection, socket enumeration, filesystem review, and observation of Linux process state. I used standard Linux tools and direct inspection of the container's /proc, /sys, and filesystem interfaces.

The investigation was divided into seven phases. Each phase examined a different part of the running environment, with observations recorded in the project notes.

Reconstructing the runtime

1. The processes

The first useful result was a clearer picture of the processes involved.

The container's initial process, PID 1, ran the Python web management application through its virtual environment. A separate process named etherdog handled runtime supervision and exposed a control socket. The PLC execution process appeared as plc_main.

These process IDs describe the snapshot I inspected, not permanent identities. The PLC process received a different PID after it was restarted, which is exactly why I recorded process names and executable paths alongside the IDs.

Thread-aware inspection also showed that these were not single-threaded processes. In the observed state, the management process had 11 threads, etherdog had two, and plc_main had four. One of the PLC process threads was named plc_watchdog.

I then deliberately terminated plc_main to observe what happened. The supervisor reported an unexpected exit with code -9 and attempted to restart the process. The replacement process initialized some runtime components and recreated the PLC runtime socket, but it could not find the expected libplc_*.so files in its build directory. It entered the EMPTY state and did not transition to RUNNING.

This was a useful observation of the runtime's recovery behavior under that specific condition. It does not establish how every failure would be handled, but it gave me a concrete starting point for future investigations into lifecycle management and recovery.

2. Local communication

The processes also had local communication interfaces worth examining.

The web application's Python code contained a Unix-domain socket client targeting /run/runtime/plc_runtime.socket. The corresponding C header defined the same socket path and specified buffer limits, including a maximum response size of 65,536 bytes.

A separate Python component, UnixLogServer, bound to /run/runtime/log_runtime.socket. Its implementation accepted local clients and handled incoming log lines.

The supervisor used another socket path, /run/runtime/etherdog.socket, for its control interface. The socket's presence and filesystem permissions were observable, while the exact authorization behavior of every communication path was outside the scope of this baseline.

These findings established that Unix-domain sockets were part of the runtime's internal communication design. They also gave me concrete paths and implementation files to revisit when investigating message handling or access control later.

3. Network listeners

I used ss to inspect the network sockets visible inside the container's network namespace.

The snapshot showed two listeners or bound sockets associated with the Python management process:

Protocol	Local address	Observed state
TCP	`0.0.0.0:8443`	Listening
UDP	`0.0.0.0:33333`	Bound, no connected peer

Both were associated with file descriptors held by PID 1. The wildcard addresses mean the sockets were bound across the container's available network interfaces, rather than to a single container interface address.

That observation alone does not establish external reachability. Docker port publishing, host firewall rules, routing, and other network conditions affect whether a service can be reached from outside the container.

I had published TCP port 502 when starting the container, but the inspection snapshot did not show a Modbus TCP listener on that port. Publishing a port in Docker does not prove that an application is listening behind it. I recorded the result as a finding about this particular runtime state, rather than a universal statement about OpenPLC Runtime v4.

I did not test web routes, authentication, or the behavior of the exposed services in this phase. Those questions require separate, scoped investigations.

Figure 1. A view of the observed runtime processes, local communication paths, and network interfaces. The diagram summarizes the lab snapshot; it should not be read as a complete specification of every internal connection.

The runtime's Linux environment

Knowing which processes existed was only part of the picture. I also needed to understand what those processes could access through the operating system.

1. Executables and runtime state

The main PLC executable was located at /workdir/build/plc_main, while the observed supervisor executable was at /workdir/build/etherdog. Both were owned by root:root and had mode 0755, allowing the owner to read, write, and execute them, while group members and other users had read and execute permissions.

The inspected runtime directory contained several relevant files and interfaces. These included /run/runtime/.env, the supervisor's JSON file, the SQLite database at /run/runtime/restapi.db, and the Unix-domain sockets described earlier.

I checked the permissions and metadata of these paths without reading the contents of .env or inspecting the database records. The database file had a SQLite header, which identified its format, but its contents were not part of this investigation.

This matters since a file's name, format, ownership, and mode tell us something about how it is exposed in the environment, but they do not tell us what data it contains or whether the application uses every file in the way its name suggests.

2. Capabilities, file descriptors, and devices

I inspected the Linux capabilities of the management and PLC processes. The observed capability sets included CAP_NET_RAW and did not include CAP_SYS_RAWIO.

Capabilities are one part of a process's effective authority. They help describe which privileged operations may be available, but they do not independently establish whether a particular operation is reachable through the application's code or permitted by other system controls.

I also reviewed open file descriptors and correlated socket inodes with entries in /proc/net/unix, /proc/net/tcp, and /proc/net/udp. This connected several of the observed descriptors to the runtime's local sockets and network endpoints. The management process also had the database open.

Some file descriptors referred to pipes shared between processes. That showed that the processes held descriptors for the same underlying pipe objects. It did not, by itself, establish the purpose or contents of every message passing through them.

The captured /dev listing contained standard Linux device nodes, including /dev/null, /dev/zero, /dev/random, and terminal-related entries. I did not see obvious dedicated GPIO, SPI, or I²C device nodes in that listing.

That is a limited observation. It does not prove that hardware access is impossible, or that every possible I/O mechanism is absent. The runtime may use software backends, network interfaces, other mounted resources, or interfaces that were not identifiable from this snapshot.

For this investigation, the useful result was a record of the capabilities, descriptors, and device nodes visible in the environment. Whether a particular interface can be used to influence physical I/O remains a separate question.

3. Memory mappings and loaded components

I inspected the PLC process's memory map through /proc. The main executable appeared in separate read-only, executable, and writable mappings. The process also had a heap, anonymous memory regions, a stack mapping, and mappings for shared libraries.

Two plugin libraries were particularly relevant to the runtime's industrial focus: libethercat_plugin.so and libs7comm_plugin.so. Both appeared in the process's mappings, alongside the C runtime, OpenSSL libraries, Python libraries, and native Python extensions.

This gave me evidence that these plugin libraries were mapped into the process at the time of inspection. It did not establish which plugin functions were active, what protocol operations were being performed, or how the runtime handled specific industrial messages.

Anonymous mappings were recorded as anonymous mappings. I did not assign them to particular runtime structures because the mapping information alone was insufficient to identify their contents reliably.

The snapshot was also taken before deploying user control logic. That boundary is important: the memory layout of a process running an actual project may differ from the baseline observed here.

4. Scheduling and resource limits

The final phase examined how the PLC process was scheduled and what resource limits were visible at the inspected cgroup level.

The PLC process was using SCHED_OTHER with priority zero. The four listed threads were also using normal time-sharing scheduling. The process affinity mask was fff, indicating an allowed CPU mask covering the corresponding CPU bits. In this environment, that mask represented CPUs 0 through 11.

The inspected cgroup files reported:

cpu.max     max 100000
memory.max  max

These values indicated that the inspected cgroup level did not specify a CPU quota or a maximum memory limit through those files. They do not mean the process had unlimited resources. Parent cgroups, Docker settings, host capacity, and contention can still constrain it.

During runtime observation, the watchdog also logged a failed attempt to set SCHED_FIFO priority 99, with the error Operation not permitted. That confirmed the scheduling request failed in this environment. It did not establish the runtime's timing accuracy, cycle jitter, or behavior under load. I did not measure real-time performance in this investigation. The scheduling and resource observations provide context for that work if it becomes relevant later.

Figure 2. A summary of the process environment, loaded components, visible operating system interfaces, and scheduling configuration observed during the investigation. These details describe the captured lab state, not every possible deployment configuration.

What this baseline establishes

By the end of the investigation, I had a working map of the environment around the runtime.

I identified the principal processes and their observed thread counts. I documented the local socket paths and the network sockets visible in the container. I recorded relevant executable and state-file permissions, inspected capabilities and open descriptors, and reviewed the PLC process's memory mappings. The scheduling and cgroup checks added context about the execution environment.

The unexpected termination test also showed a specific recovery path. The supervisor detected the PLC process exit and attempted to restart it, but the replacement did not reach the RUNNING state because expected shared libraries were not found in the inspected build directory.

These results give later investigations something concrete to compare against. If a subsequent test changes process behavior, introduces a new interface, or produces an unexpected failure, there is now a baseline to help distinguish the new observation from the environment that was already present.

The detailed phase notes, commands, paths, and supporting observations are available in the plc-runtime-architecture repository.

Where the research goes next

This first investigation closes with a baseline rather than a vulnerability investigation. I now have a better understanding of the processes surrounding OpenPLC Runtime v4, the interfaces they expose, and the Linux environment in which they run.

The next investigations can build on that knowledge and examine individual security properties in more detail. Each one will need its own question, evidence, and limits.

After spending so much time examining how industrial protocols communicate, I am looking forward to digging into the software that makes a PLC runtime operate. Stay tuned.

Previously: Industrial Protocol Research

If you're new to my work, you can explore my previous industrial protocol research series, where I investigated how protocols such as Modbus, DNP3, OPC UA, EtherNet/IP, PROFINET, and S7comm work under the hood.

The series covered protocol structure, implementation behavior, communication analysis, and security characteristics through controlled lab investigations.

Explore the research: Industrial Protocol Labs on GitHub

Building the MyZubster Metaverse: From Public Characters to Secure World Actions

Mon, 19 Oct 2026 04:58:09 +0000

Building the MyZubster Metaverse: From Public Characters to Secure World Actions
MyZubster is building an open-source metaverse that connects public characters, verified knowledge, contributor identities, realtime interactions, and GitHub-based development.
The project is not limited to a graphical virtual world. Its technical foundation is based on authenticated actions, explicit user consent, verifiable evidence, secure automation, and independently inspectable deployments.
This is a technical update on what we have implemented, what we recently stabilized, and what remains before the platform can be considered production-ready.
The Architecture
The current architecture follows this general flow:
MyZubster account

↓

Authenticated session

↓

Time-limited session lease

↓

Zorgax or metaverse character

↓

Authorized world action

↓

Realtime event distribution

↓

Persistent and verifiable evidence
Each state-changing request should answer four questions:

Which account initiated the request?
Is its session still valid?
Which character is associated with that session?
Is the requested action permitted?
This is important because a client-provided character ID cannot be considered proof of ownership.
The Public Metaverse
The public interface is available at:
https://www.myzubster.com/metaverse
Our latest production verification confirmed that the page loads correctly and exposes:
- 25 public characters
- 7 verified explorers
- A deployed Vercel production build
- No blocking browser-console errors
  This public page represents the visible part of a larger system. Most of our recent work has focused on the security and infrastructure beneath it.
  Session-Bound World Actions
  World actions are being migrated to a session-bound authorization model.
  The server must derive the acting identity from an authenticated session instead of trusting identifiers supplied by the client.
  const session = await resolveAuthenticatedSession(request);

if (!session) {
throw new UnauthorizedError();
}

const lease = await resolveActiveLease(session.id);

if (!lease || lease.expiresAt <= new Date()) {
throw new SessionExpiredError();
}

const character = await resolveCharacterForAccount(session.accountId);

await authorizeWorldAction({
session,
lease,
character,
action: request.body.action,
});
This approach reduces the risk of:

Character impersonation
Cross-account actions
Replayed requests
Actions performed after logout
Use of expired sessions
Client-side manipulation of ownership fields
Authentication identifies the account. The session lease determines whether its authorization is still active. The policy layer determines which world actions are allowed.
Session Lease Lifecycle
An authenticated session should not provide unlimited access.
We introduced a lease lifecycle that can represent the following states:
CREATED
↓
ACTIVE
↓
RENEWED
↓
EXPIRED

ACTIVE
↓
REVOKED
A lease can be invalidated when:

The expiration time is reached
The user signs out
The account is disabled
Security credentials are rotated
An administrator revokes the session
A security policy invalidates older leases
Metaverse endpoints must verify the lease immediately before performing a protected action.
Zorgax and Contributor Consent
Zorgax connects several areas of MyZubster:
GitHub contributors
Public professional profiles
Knowledge Cards
Verified Knowledge
Metaverse characters
Development Requests
A public GitHub identity can generate an optional character proposal, but registration must require explicit consent.
GitHub contribution
```
  ↓
```
Character draft
```
  ↓
```
Contributor reviews proposal
```
  ↓
```
Explicit acceptance
```
  ↓
```
Public character registration
A character proposal does not imply:
Legal identity verification
Employment
Partnership
Ownership
Payment eligibility
Institutional endorsement
Keeping these distinctions explicit is essential for an open contributor ecosystem.
Realtime Communication
The realtime layer still needs to be completed, but its event structure must support reliable synchronization.
A typical event could look like this:
{
"eventId": "evt01...",
"worldId": "myzubster-main",
"characterId": "character...",
"sessionId": "session_...",
"sequence": 1842,
"type": "character.position.updated",
"occurredAt": "2026-10-19T04:50:00.000Z",
"payload": {
"x": 12.4,
"y": 0,
"z": -8.1
}
}
The event identifier and sequence number allow clients to detect:
Duplicate messages
Out-of-order updates
Missing events
Stale world state
After reconnecting, a client should send its last accepted sequence number and recover any missing state.
Distributed Rate Limiting
In-memory rate limiting works only for a single application instance. It is insufficient when requests are distributed across several workers or serverless deployments.
Production enforcement therefore requires shared state:
Client
↓
Application instance A ─┐
Application instance B ─┼→ Shared atomic rate limiter
Application instance C ─┘
Different policies are required for:
Login attempts
Session creation
Lease renewal
Character movement
World interactions
Realtime messages
Search endpoints
Profile updates
The system must also define what happens when the rate-limit service becomes unavailable: fail open, fail closed, or apply a limited fallback policy.
CI Runtime Modernization
We recently completed an important GitHub Actions upgrade.
GitHub warned that older JavaScript actions were using the deprecated Node.js 20 runtime. The affected references were updated from:
uses: actions/checkout@v4
uses: actions/setup-node@v4
to:
uses: actions/checkout@v5
uses: actions/setup-node@v5
The migration covered:
12 workflow files
26 action references
CI and lint
Security auditing
SBOM generation
Vercel deployment
Evidence validation
Seller policy regression testing
MYZ ledger verification
Pilot API testing
Decentraland SDK7 proof workflows
We validated all 16 workflow YAML files before publishing the change and confirmed that no affected v4 references remained.
The update was integrated through Pull Request #38.
The final commit on main is:
69ef67716df50482e8fbf9960ccab7dfc37d3000
Post-Merge Results
The merge triggered seven workflows on the production branch.
All completed successfully:
CI — Test and Lint
Security Audit
SBOM and Vulnerability Scan
Continuous Evidence Gate
MYZ Canonical Ledger Contract
MYZ-164 Seller Free Policy
Deploy to Vercel
The deployment workflow also completed successfully, confirming that the runtime migration did not break the production delivery process.
What Is Currently Working
The current baseline includes:
Public metaverse interface
Public characters
Verified explorers
GitHub-connected contributor identities
Optional Zorgax character onboarding
Session-bound authorization development
Session lease lifecycle enforcement
Knowledge and profile integration
Automated security auditing
SBOM generation
Continuous evidence validation
Node.js 24-compatible GitHub Actions
Automated Vercel deployments
What Still Needs to Be Built
Complete Authentication Enforcement
Every state-changing endpoint must use the same canonical authentication and authorization process.
Required scenarios include:
Expired sessions
Revoked leases
Logout
Credential rotation
Concurrent sessions
Disabled accounts
Replay attempts
Cross-account character access
Finish Distributed Rate Limiting
We still need to validate:
Atomic counters
Multiple application instances
Concurrent requests
Counter expiration
Boundary conditions
Backend failure behavior
Recovery after temporary outages
Complete Realtime Synchronization
The realtime layer must support:
Presence
Character movement
Interactions
Reconnection
Missed-event recovery
Duplicate suppression
Event ordering
Backpressure management
Add Privacy-Safe Observability
Operational monitoring should measure:
Active sessions
Rejected world actions
Lease-renewal failures
Realtime disconnections
Rate-limit activations
API latency
Backend error rates
The system should minimize personal data and avoid storing unnecessary raw identifiers.
Reliability and Load Testing
Before expanding public access, the platform needs tests for:
Concurrent users
Movement bursts
Realtime fan-out
Session-store latency
Infrastructure restarts
Partial failures
Deployment rollback
Rate-limit contention
End-to-End Acceptance
The complete flow must be tested as one system:
Sign in
→ select a character
→ create a session lease
→ enter the metaverse
→ perform an authorized action
→ receive a realtime event
→ disconnect
→ reconnect and recover state
→ sign out
→ verify that further actions are rejected
WebXR
WebXR remains part of the roadmap, but it should follow security, realtime communication, and reliability work.
Our planned order is:
1. Authentication and session enforcement
2. Distributed rate limiting
3. Realtime synchronization
4. Privacy-safe analytics
5. Reliability and load testing
6. End-to-end acceptance
7. WebXR experience
  Conclusion
  The MyZubster Metaverse now has a concrete technical foundation: public characters, contributor identity integration, authenticated session work, automated security checks, reproducible deployments, and a modernized CI runtime.
  It is not finished, and we do not want to describe experimental components as complete systems.
  Every future milestone should be accompanied by:
Public source code
Automated tests
Deployment evidence
Clear limitations
Reproducible verification steps
Our goal is to build the metaverse transparently, incrementally, and with evidence that contributors can inspect independently.

Is your coding agent reading the memory you wrote?

Sun, 18 Oct 2026 21:21:32 +0000

I maintain Selvedge. This article was prepared with AI assistance and checked against the released Selvedge v0.3.17 package from PyPI (tag v0.3.17, commit 3b67b8f) and the repository's main branch at commit 66c51d3.

I saved one decision, read it back six ways, and got nothing from two of them. The record never moved. The reads that missed it had opened a different, empty database.

This is a reproduction, not an incident report. I installed Selvedge v0.3.17 from PyPI in a fresh virtual environment, pointed HOME at a throwaway directory, and logged one invented decision from a project root:

selvedge init
selvedge log src/billing/charge.py::retry_charge reject \
  --reasoning "Rejected automatic retries inside retry_charge; went with a single attempt plus an idempotency key, because a retry after a timeout can charge a customer twice." \
  --constraint "A payment request must never be submitted twice for one order." \
  --stale-when "the payment provider offers server-side idempotent retries" \
  --agent synthetic-demo

(--agent only sets an attribution label.) Then I asked for that record from different places.

One record, six reads

From src/billing, a subdirectory of the project, selvedge prior-attempts src/billing/charge.py::retry_charge --json returned the record.

From an unrelated directory, the same lookup (without --json) printed "No prior attempts found" and exited 0. By the end of the run, the throwaway home directory held a new per-user database with zero events.

From that same unrelated directory with SELVEDGE_DB=/path/to/demo-app/.selvedge/selvedge.db set, the command returned the record with the same ID.

With the same variable set, the Python package returned the same ID:

from selvedge import SelvedgeStorage, get_db_path

store = SelvedgeStorage(get_db_path(read_only=True))
blame = store.get_blame("src/billing/charge.py::retry_charge")
print(blame["id"] if blame else "not found in this store")

Finally, a small test script started selvedge-server over stdio and called its prior_attempts tool. With SELVEDGE_DB set, it returned the same ID. Without it, from the unrelated directory, it returned an empty list.

Every read that found the database returned one ID. The two misses weren't missing data; they were the wrong file.

Why the empty answer happened

Selvedge stores decisions in local SQLite. In v0.3.17, the CLI and the MCP server both find that database with get_db_path, which the package also exports. It checks three places, in order:

the SELVEDGE_DB environment variable;
an existing .selvedge/selvedge.db file, searched for upward from the current directory;
the per-user fallback ~/.selvedge/selvedge.db.

The subdirectory read found the project file by searching upward. The unrelated directory had no project file above it, so the read fell through to the per-user path.

The tool didn't hide this. A normal lookup that falls back writes a warning to stderr, once per process, unless SELVEDGE_QUIET is set. Both the CLI miss and the MCP miss printed it. On its own, get_db_path(read_only=True) stays silent and creates nothing. But opening that path with SelvedgeStorage, as the snippet above does, still creates the per-user directory and an empty database, with no warning. In a fresh home directory without SELVEDGE_DB, the snippet printed "not found in this store". selvedge doctor reports the resolved path and which step matched: "via walked up from CWD to project .selvedge/" from the project root, and "via global fallback (~/.selvedge/)" with status WARN from the unrelated directory. That doctor run still exited 0, so a script that checks only exit codes won't notice.

An MCP server makes this easier to miss. A client starts the server with whatever working directory and environment the client chooses, and whether you see the server's stderr depends on the client. The README says to set SELVEDGE_DB in the server configuration when the client starts outside your project.

Checking your own setup, with or without Selvedge

None of this is specific to one tool. Any file-based memory, whether a decisions folder, a JSON file or a SQLite database, is located by each process for itself. So, before trusting an empty answer, find out how your tool picks its file. Usually it's some mix of explicit path, project discovery and a per-user default.

Then ask the question from where the reader actually runs. A check in your terminal describes your terminal, not an agent client or a CI job with its own directory and environment. For processes you don't launch yourself, set the path explicitly rather than relying on discovery.

When a lookup comes back empty, read it as "nothing in this store," not "nothing was ever decided." And once, after any change to clients or configuration, write a test record through one route and read it through the others, comparing IDs rather than text. Matching text could be a copy; a matching ID means the same record.

What's on main, and not released

PR #76, merged into main as commit 66c51d3 on October 17, 2026 (PT), reworks Selvedge's architecture plan. It describes MCP as "one route to the core, not a prerequisite for using it," and plans a small local core shared by the library, CLI, MCP and optional integrations. The PR also adds a regression check that saves and retrieves a record across isolated Python processes, and rewords the bundled prompt to present CLI and MCP as routes to the same store.

None of this is in v0.3.17, and the architecture document says the phases add no release dates. It notes that the current package still installs MCP dependencies, and that making them optional needs a separate compatibility assessment. It lists compact review presentation, native GitHub validation and an editor integration as future work.

What this run doesn't show

It's synthetic: one invented record, one machine, Python 3.13 and a throwaway home directory. The CLI's PyPI update check was turned off, and telemetry was never enabled.
No agent client was tested. The MCP route used a test script built on the mcp Python client, so check your own client's configuration, launch directory and activation separately.
Selvedge stores what a person or agent explicitly saves. It doesn't verify that the reasoning is true, and it doesn't guarantee that an agent will consult it.
Pinning the path makes routes agree on a file. It doesn't create records nobody saved.

I built a background remover that never sees your photo (and it does GIFs and videos too)!

Sun, 18 Oct 2026 14:58:30 +0000

When you’re the only engineer in the family, you automatically become the unpaid IT department, video producer, and resident graphic designer, because to relatives, "computers" is just one big subject (and that includes everything to do with mobile phones too... somehow!). So whenever someone needed a transparent PNG or a quick cutout, it fell on me, and I’d get stuck in the same annoying loop. I'd hunt down a "free" background remover (whatever showed up first on Google), upload the photo, wait, and then get held hostage by a "Buy Credits" button. My only options were settling for a blurry, postage-stamp-sized preview, or making a whole new account if I was desperate enough for the high-res version. Worse, somewhere in that mess, a family photo would get shipped off to a sketchy server I know nothing about.

For a product shot, that's annoying. For a passport photo, a signature, or a client's photo, it's a bit more than annoying.

So I added a background remover to Fizzdoc, my open-source toolkit where every tool runs inside the browser tab. It now does:

Photos: Remove Background, saved at the photo's own resolution as PNG, JPG or WebP.
Animated GIFs: Remove GIF Background, every frame, same timing, same loop.
Videos: Remove Video Background, every frame, with the sound kept.
WhatsApp stickers: WhatsApp Sticker Maker, a 512 × 512 WebP with a white outline, kept under 100 KB, with words in fun fonts and emoji you drag into place.

You can keep the background clear, or put white, any colour, a blur or another photo behind. It's free, there's no sign-up, no watermark, and no limit on how many photos you do. The size limit comes from your device's memory, not from me.

And the photo never leaves your device. Not "we delete it after an hour". It just never goes anywhere.

Below is how it works, and what broke along the way.

The rule: nothing gets uploaded, and you can check

Fizzdoc is a static site on Cloudflare Pages. There's no backend, so there's nothing that could receive a file. The page also ships a Content Security Policy with connect-src 'self', which means the browser itself blocks the page from talking to any other website.

That rule shaped everything below. No CDN for the model, no hosted inference API, no "just this one request". Open DevTools, go to the Network tab, remove the background, and you'll see the model files coming from fizzdoc.com and nothing going out.

Picking a model

I wanted three things:

Good edges on hair and fur, because that's where background removers usually show their seams.
Small enough to download once into a browser.
A licence that lets anyone use the result, including for work.

I went with BiRefNet (MIT licence), the lite variant, using the 512 × 512 ONNX export by studioludens. I store its big weight tensors as 16-bit floats and cast them back to 32-bit when the model loads, which halves the download to about 100 MB without changing the maths it runs.

For phones there's a second model, U²-Net small (Apache-2.0), just 4.6 MB. I learned this one the hard way: someone sent me a screenshot of an early version on a 6 GB Android phone, where Chrome killed the tab at 5% ("Aw, Snap!"). A browser tab on a phone gets far less memory than the phone has, and when it runs out there's no error to catch, the tab just dies. So now phones always use the small model, and the page says so ("for the cleanest edges on hair and fur, use a laptop"). If the big model ever crashes a tab on a laptop too, the page remembers it for 30 days and uses the small one there.

And for laptops with a graphics chip there's the opposite: a Sharper edges (hair, fur) button. It reruns the photo through a 1024 × 1024 export of the same BiRefNet-lite model (onnx-community, MIT). It's a one-time 135 MB download and needs WebGPU, so it's never offered on phones. If the device can't manage it, you keep the result you already had.

Running it: WebGPU when it can, CPU when it can't

The model runs with ONNX Runtime Web inside a Web Worker, so the page never freezes.

If the device has a graphics chip with WebGPU, the model runs there. This is the fast path.
If WebGPU isn't there (or the driver says no), the same model runs on the CPU through WebAssembly.
If that fails too, usually because the device ran out of memory, the small U²-Net model takes over.

So the chain is GPU, then the same model on CPU, then the small model. Nobody gets an error just because their laptop is old.

Two fun problems with "self-host everything"

Cloudflare Pages has a 25 MiB limit per file. The model is about 100 MB and ONNX Runtime's WebGPU build is a 27 MB .wasm. So both live on the server as 20 MiB parts: the models are split by a small script when I add them, and the runtime is split at build time. The worker downloads the parts, joins them, and keeps the result in the browser's Cache Storage, so the next time it starts straight from there, even with the internet off. The build also fails if any file it writes goes over 25 MiB, after one deploy failed on it.

A runtime that exists in pieces. ONNX Runtime normally fetches its .wasm as one file. Mine exists just as parts on the server, so the worker joins them from Cache Storage and hands the bytes to the runtime directly with ort.env.wasm.wasmBinary. It needs no extra hosting and no change to the security policy.

The part I'm proudest of: full resolution from a 512 px model

The model looks at your photo squeezed to 512 × 512 and returns a soft mask. If you stretch that mask back over a 4000 × 3000 photo, the edges look like they were cut with a butter knife.

So the mask goes through two classic image-processing filters, both plain arithmetic on typed arrays in the worker:

Fast guided filter (He and Sun, 2015). It uses the photo itself as a guide to snap the blurry mask onto the real edges, so hair follows the actual strands. The fit is computed on a smaller copy (up to 1280 px) and then applied to every pixel of the full photo in one pass.
Blur-fusion foreground estimation (Forte, 2021). Edge pixels are a mix of your subject and the old background. Put a cut-out on a new colour without fixing that, and you get a faint halo of the old background. This step estimates the subject's true colour at the edges, so the new background looks like it was always there.

By default the result is saved at your photo's own size: your own pixels, with a cleaner mask.

When the AI gets it almost right

It's an AI model, so a busy background or a subject that blends into it can confuse it. For photos there's a small set of touch-ups:

Erase / Restore brush, with Undo, Redo and Zoom for careful work on a phone.
Tap to remove and Tap to keep: one tap picks the whole connected area of a similar colour and removes it, or brings it back.
Shadow and a white Outline, if you want the cut-out to stand out.
Crop: the whole photo, fit to the subject, or a square around the subject for online shop listings.
Hold to see the original, to compare before and after.

GIFs: every frame, same rhythm

Animated GIFs are sneaky. Many frames aren't full pictures, just small patches drawn over the previous frame, with rules ("disposal methods") about what to clear afterwards.

gifuct-js (MIT) decodes the frames, and Fizzdoc composes each one into a full picture the way a browser would show it.
Each frame goes through the same model (in a faster mode, since there can be dozens).
gifenc (MIT) writes the new GIF, keeping every frame's delay and the loop.

One catch: a GIF pixel is either fully see-through or fully solid. So on a clear background the edges are a little sharper than in a PNG. Pick a colour or a photo behind and the soft edges are back.

Videos: every frame, sound kept

For video, Mediabunny (MPL-2.0) reads the file and the browser's own WebCodecs encoder writes the new one. Every frame goes through the model and gets its new background, and the soundtrack is carried over.

The output is MP4 (H.264) if the browser can handle it; otherwise, it's WebM (VP9). Before you start, the page shows a preview frame and an estimate of how long the whole clip will take on that device.

What does "no background" mean for a video? Truly see-through video would need the encoder library to start helper workers from blob: URLs, which my page's security policy blocks, and most players can't show it anyway. So "None" gives you a green screen, which any video editor removes in one click. I chose to keep the policy strict rather than loosen it for one feature.

Stickers: words, emoji, and the last step in WhatsApp

The WhatsApp Sticker Maker starts from the same cut-out. It squares it to 512 × 512, adds a white outline, and keeps the WebP under 100 KB by lowering the quality step by step until it fits.

On top of that, you can add words in five styles (Funny, Cute, Cozy, BIG, and Serious) and emojis. Each one is a layer you drag, pinch, resize and rotate, on a phone or with a mouse. The fonts are self-hosted like everything else: Bangers, Kalam, Teko and Inter, with Baloo 2 covering Hindi letters. Emoji are drawn with your device's own emoji font.

One fun bug on the way: Vite inlines small files as data: URLs, and a few of the font files were small enough. My own CSP (default-src 'self') refused them, and the end-to-end test that fails on any CSP violation caught it before it shipped. Fonts are now always separate files.

One limit, though. A web page can't add a sticker to WhatsApp, and a sticker shared from the browser arrives as a normal photo. So instead of a "Share to WhatsApp" button that doesn't do what it says, the page shows WhatsApp's own steps: save the sticker, then in any chat tap Stickers › Create and pick it. On iPhone there's a "Save to Photos" button, because downloads go to Files and WhatsApp picks stickers from Photos.

What it's like on low-end phones

I care about this a lot because many people open Fizzdoc on Android phones.

Phones always get the small model, so it works rather than crashes. Edges are a bit softer than on a laptop, which is a trade I'll take every time.
The worker keeps the page responsive while it thinks.
The model downloads once (the page shows the progress in MB). After that it starts right away, and it keeps working with Wi-Fi and mobile data off, which is also the easiest way to check that nothing is uploaded.
Videos give you a time estimate first: short clips are fine, long ones are a laptop job.

Things it doesn't do (yet)

Truly transparent video (see above, green screen instead).
Many photos in one go: the background remover takes one photo at a time.
Several photos in one sticker. That's next.

Credits

None of this would exist without these people and projects. Thank you:

Project	What it does in Fizzdoc	Licence
BiRefNet by Peng Zheng and co-authors	The background model	MIT
birefnet-lite-512 by studioludens	The 512 px ONNX export	MIT
BiRefNet_lite-ONNX by onnx-community	The 1024 px export for Sharper edges	MIT
U²-Net by Xuebin Qin and co-authors	The small model for phones	Apache-2.0
ONNX Runtime Web by Microsoft	Runs the models on WebGPU or WebAssembly	MIT
gifuct-js by Matt Way	Reads animated GIFs	MIT
gifenc by Matt DesLauriers	Writes animated GIFs	MIT
Mediabunny by Vanilagy	Reads and writes videos	MPL-2.0
Kaiming He and Jian Sun	The (fast) guided filter	Paper
Marco Forte	Blur-fusion foreground estimation	Paper

The full licence texts are in Fizzdoc's third-party licences.

Try it, break it, tell me

Photo: https://fizzdoc.com/remove-background/
GIF: https://fizzdoc.com/remove-gif-background/
Video: https://fizzdoc.com/remove-video-background/
WhatsApp sticker: https://fizzdoc.com/whatsapp-sticker-maker/
Code (Apache-2.0): https://github.com/kingrishabdugar/fizzdoc

It's part of a bigger toolkit of 68 free tools (PDF, Word, Excel, PowerPoint, images and audio), all running in your browser, in 16 languages. If something looks off on your device, there's a "Report it" link on every tool. And if you like it, a star on GitHub genuinely makes my day.

Stop your AI agent from redoing finished work

Sat, 17 Oct 2026 19:17:43 +0000

I maintain Selvedge. This article was prepared with AI assistance and checked against the released v0.3.17 documentation.

A recent question in the OpenAI Codex discussions describes a familiar failure. After months of AI-assisted development on an internal business app, the author asks: "How do experienced developers prevent AI coding agents from producing disconnected code and repeatedly rebuilding or breaking previously completed functionality?" (openai/codex #52835). I'm citing it as a clear public statement of the problem, not as a Selvedge user story.

A new session sees the code but not its history. It doesn't know which feature was signed off last week, or which "obvious" improvement was already tried and dropped. From the agent's point of view, rewriting a working module is as reasonable as extending it.

Most of the fix is process, not tooling. These tactics work with any agent.

1. Write "done" down where the agent will read it

An agent can't respect a boundary it never sees. Keep a short, maintained list of completed areas in the instruction file your agent loads at startup (for example AGENTS.md, CLAUDE.md, GEMINI.md or a Cursor rules file, depending on the client). For each entry, name the files or modules, the behavior that is finished, and the test that proves it:

DONE: approval flow (src/approvals.py). Covered by tests/test_approvals.py.
Extend it; do not restructure it without asking.

Prune it regularly; a stale list gets skimmed.

2. Make finished behavior executable

A sentence saying "the approval flow works" is weaker than a test that fails when it stops working. Before you call a feature done, make sure at least one test exercises it from the user's side, and ask the agent to run the full suite before declaring any later task complete. A rebuild that breaks finished work then shows up as a red test rather than a surprise.

3. Record what you rejected, not just what you chose

Code shows the approach you picked. It doesn't show the alternative you ruled out, and that is exactly what a fresh session is most likely to propose again. When you decline an approach, write down three things: what you rejected, why, and what would make it worth reconsidering. An architecture decision record (ADR) or a section of your project docs works. The revisit condition matters because it stops a reasonable rejection from becoming a permanent rule.

4. Scope every task, including what not to touch

"Add CSV export to the dashboard" invites the agent to reorganize the dashboard. "Add CSV export in src/export.py; do not modify src/approvals.py or the database schema" does not. Name the files in scope and the finished areas out of scope, and keep each diff small enough to review in full.

5. Look before editing, and review against the record

Start each task by asking the agent to read the relevant notes and say what it will leave unchanged. Then review the diff against that statement. A change to a "done" file isn't automatically wrong, but it should come with a reason you can check.

Where Selvedge fits

These steps work with plain files. Their weak point is lookup: as notes grow, the right one must surface just as the agent edits a specific function or column. Selvedge is one way to handle step 3 and the lookup in step 5.

Selvedge is an open-source local decision log for coding agents. It runs as a local stdio MCP server or a CLI, stores records in SQLite under .selvedge/, needs no hosted account, and makes no LLM calls in core storage and retrieval. You or your agent save a decision, its reason and any rejected approach against an entity such as src/approvals.py::submit_for_review, users.email or deps/stripe. A later session queries that entity before editing it.

Here is a synthetic example I ran with Selvedge 0.3.17 in a temporary project. The rejection is invented for illustration:

selvedge init
selvedge log src/approvals.py::submit_for_review reject \
  --reasoning "Rejected rebuilding approvals on browser localStorage; went with the server-side approvals table instead, which passes tests/test_approvals.py. A manager on another device would not see a pending submission." \
  --constraint "Approval state must be visible to every reviewer on any device." \
  --stale-when "approval state moves to a different shared store"

Before the next edit, an agent with shell access can run selvedge prior-attempts src/approvals.py::submit_for_review, or call the prior_attempts MCP tool. In the synthetic run, the CLI returned the record labeled rejected (exact) along with the saved reasoning. The summary line still reads current status … reverted; in 0.3.17 that status covers both reverted and rejected records, and the row label shows which one it was. "Exact" means an explicit rejection was recorded. It doesn't mean the rejection was correct or still applies. selvedge blame showed the constraint and revisit condition, and selvedge search localStorage found the record. For an entity with no qualifying records, the CLI reported "No prior attempts found". That means nothing was recorded, not that nothing was ever tried.

For reviewers, selvedge export --format markdown -o DECISIONS.md writes a digest that lists explicit rejections under "Considered and rejected". Since 0.3.17, adding --check exits 0 silently when the file is current and 1 with a diff when it is stale or missing. In the synthetic run, logging a second rejection made the check exit 1 and print the missing entry. A hook or CI job can use this to catch a stale copy.

Tip: name the chosen approach inside the rejection itself. If you log a finished change and then a rejection on the same entity, prior-attempts shows the finished change as tried, then reverted.

If a rejection stops applying, selvedge supersede reopens it and keeps the original record in the history.

Limits

Only explicitly saved decisions can be retrieved. Connecting the MCP server doesn't capture every decision automatically.
Selvedge stores the reasoning a person or agent supplies. It doesn't verify that the reasoning is true or complete.
Nothing guarantees an agent will consult the record. The built-in selvedge demo runs on a temporary database; it doesn't verify your agent's configuration, activation or hooks. Check those separately in your own client.
It doesn't replace tests, scoped tasks, code review or a single maintained codebase.

If you try it, the useful test is one real rejection: save it, close the session, and check whether a new session retrieves it before proposing the same idea. Setup is in the quickstart, and the source is at masondelan/selvedge.

Open Source vs. Proprietary: Why We Built Parts of AnimeArray with Open-Source Tools

Sat, 17 Oct 2026 16:56:37 +0000

There's a question we get every time someone finds the site for the first time. It usually arrives about ten seconds after they realise AnimeArray is free:

"So who's paying for all this? What's the catch?"

It's a fair question, and for a while I didn't have a good answer beyond "advertising covers the hosting." That was true but it was the boring half of the story. The interesting half is why we built most of what runs the site ourselves, when we could have assembled the same product out of almost entirely commercial services and shipped it in a fraction of the time.

I've been chewing on that question for long enough that I figured the answer was worth writing down properly — including the parts where we made the wrong call.

What "owning it" actually got us

The first thing you get is the ability to read the code. Not documentation about it — the code.

This sounds obvious once you say it, but I only appreciated it properly during an incident a few months in. Something in the request-handling layer started throwing intermittently. Not consistently enough to be obvious, not rarely enough to ignore. I lost a couple of hours reading the source of the component that was misbehaving, found the logic error, and fixed it myself.

The alternative was a support ticket with a stack trace I didn't fully understand, waiting on a response from someone who would need my description of the problem to even start investigating. That's not a criticism of vendors — it's just a real difference in how long the problem takes to die. On a small project, an hour versus a week is the whole ballgame.

The second thing is exit cost, and this is the one I underweighted for a long time.

Every proprietary tool in a stack is a dependency you don't control. Pricing changes. Features get deprecated. APIs shift under you. The vendor pivots toward a different market. Individually these are survivable. Stacked across a dozen tools, they add up to something you can no longer actually move, even if every individual part is replaceable on paper.

The reason we care is specific: the expensive, hard-won parts of what we built — the recommendation logic that understands what you actually watched, the systems that keep twelve characters sounding like twelve different people — those live in our code, not inside somebody else's product. If we changed direction tomorrow, we'd carry that work with us. That was deliberate, even if I didn't have this vocabulary for it at the time.

The third is predictable cost, which sounds boring until you have to present a budget.

Open source tooling isn't free. It's labour and hardware, both of which you can see coming and forecast. What it avoids is per-seat licences and metered APIs that scale unpredictably and tend to punish you precisely when you start succeeding — which is a genuinely unpleasant property to own.

And the fourth is privacy, though I want to frame it carefully. It's not that open source is more private by some moral property. It's structural. When you run the software, the data stays where you put it. You don't need to publish a policy about what you won't collect, because there's no third party standing in the path to collect it.

The part nobody wants to hear

Open source is not free, and "we built it ourselves" is not a synonym for "we did nothing for it."

Some of the most valuable software in our stack was donated by someone, and I'm grateful for it every day. But the hours we spent configuring, debugging, updating, monitoring and repairing it are absolutely real, and they come out of the same revenue that has to cover hosting and bandwidth. On a small team that's the largest cost we carry, and it's invisible if you only look at the licensing line and conclude we're saving money.

We own the maintenance. Every dependency is something we chose to run, which means somebody is responsible for watching it, updating it, and dealing with the moment an upstream release breaks something we rely on. A company selling commercial software does that work as part of the price. We do it as part of the job. If you're building something small and reading this thinking it's a free shortcut, that's the misunderstanding I most want to correct.

There's a version of this that only works at a certain ratio. If our traffic grew a hundredfold, we'd need to make completely different calls — probably more managed services, more outsourced operations, and a much smaller independent stack. We don't pretend the current approach scales forever. We think it's honest about what it costs and right for where we are today, and those are different questions.

Where we deliberately chose proprietary

I'm not going to pretend open source wins every round, because it doesn't, and an article that only celebrates its own decisions is an advertisement.

We use paid tools in a few categories, and I'd make the same call again:

Things where a support contract is worth more than the licence. When a problem has a clear escalation path and a known owner, it gets solved faster than anything we could diagnose ourselves. That's not a bad thing to buy.

Services with no credible open equivalent at the quality level we need. Rebuilding a search index or a video pipeline in order to avoid a subscription isn't virtue, it's waste. Not everything important is a matter of principle.

Anything where our own time is the scarcest resource and licensing it is genuinely cheaper than building it. This one is easy to get wrong because founders tend to over-value building. Sometimes building is the right call and it's satisfying. Sometimes it's ego with a maintenance bill attached.

The other thing worth saying: we don't treat open source as a purity test. A permissive licence is legal permission, not a guarantee of quality, security, or maintenance. Popularity on a package registry tells you how many people use something. It does not tell you whether anybody is looking after it.

The four questions we ask

When a new tool comes up, we run it through a checklist. It's short on purpose, because a long checklist doesn't get used.

Can we read it? If we can't inspect what we're running, we can't honestly reason about whether it belongs anywhere near a stack that handles user accounts. This is a threshold question — a tool that fails it usually doesn't get a second conversation, regardless of price.
What's the exit? If this vanished tomorrow, how long would it take to replace it? High exit cost on something load-bearing is a decision we make deliberately, or not at all.
Who pays when it breaks? If the honest answer is "we do" and we're not in a position to staff that, we shouldn't choose it. No amount of being right about the long term compensates for a small team quietly becoming the on-call rotation.
Does it compound? Does owning this make the next thing easier to build, or does it create a brand new category of problem? Tools that make later work faster are worth more than tools that are marginally better today.

The real output of this isn't a score. It's that it forces us to be honest about which category a decision falls into, which is where most bad choices actually get made — in the gap between "it's free" and "we can maintain it."

What this actually means for the people who use the site

This isn't infrastructure trivia. It shows up in things people notice.

Because we own the software, we can promise the things that matter and keep them. Everything stays free and usable without an account, because there's no per-user cost to pass on — you can try AnimeArray for as long as you like and never be asked for a card.

It also means we can be straight about what the site is and isn't. It's an independent fan project. It hosts no video. It isn't affiliated with, endorsed by, or connected to any studio, publisher, or licensor. There's no commercial arrangement making any of that awkward to say, and I'd rather be boringly accurate than vaguely impressive.

And it means we can fix things without asking anyone's permission. When something wasn't working well — and things have, repeatedly — we changed it. Nobody had to approve a roadmap.

If you want to see how this reads in practice, the character chats are the part I'm proudest of, mostly because keeping twelve distinct voices distinct is much harder than it sounds and much more satisfying than I expected. The Otaku AI assistant is the other one, and it exists because we kept wanting a thing that didn't exist.

If you're starting something similar

The question isn't open source versus proprietary. Anyone who frames it that way has already decided and is looking for permission.

The question is: do you want to own your dependencies, and are you prepared to pay for that honestly?

If yes, the tooling is the easy part. You'll find the shape of your stack follows fairly quickly from there.

If no — and that's a completely legitimate answer for many projects — you should lean toward managed services, accept the lock-in consciously, and spend the time you saved on the part of the product that only you can build.

The mistake I'd avoid is picking one and then resenting it later. Either position is defensible. Being unable to afford the one you chose is not.

AnimeArray is at animearray.site if you want to see what the outcome looks like. It's free, it needs no account, and every decision I described above is visible in the finished product — including the compromises.

Selvedge 0.3.17: test your agent memory before you rely on it

Sat, 17 Oct 2026 16:10:57 +0000

I maintain Selvedge. This article was prepared with AI assistance and checked against the released v0.3.17 documentation.

A coding agent can tell you it saved a decision. The useful test comes later: close the session, start again, and retrieve the same record. Can you recover the reason you rejected an approach, or just a convincing explanation of the code that remains?

Selvedge gives compatible AI agents persistent decision memory through a local MCP server or the CLI. You save a choice, its reason, and the alternatives you ruled out against a named part of your project: a function, database column, API route, or dependency. Those records live in SQLite under .selvedge/, so another session can query the same history.

Version 0.3.17 makes two parts of that workflow easier to check: whether the local MCP server can retrieve a decision after restarting, and whether the Markdown digest you bring to review still matches the stored history.

Test the local MCP server

With uv installed, you can try the first check without connecting an agent or touching a project's decisions:

uv tool install --upgrade selvedge==0.3.17
selvedge demo --mcp

The command starts a real local stdio MCP server, saves a synthetic rejected approach through it, shuts that server down, and starts another. It then checks that retrieval returns the same record ID and content. Add --json to get the checked IDs and version information in machine-readable form.

The data is disposable. The demo uses a temporary database, skips background update and telemetry checks, and has a deadline followed by subprocess cleanup. That makes it a useful first step when evaluating the package: a small, concrete persistence check with no invented project history left behind.

It also has a precise boundary. A passing result checks the Python installation running Selvedge and that local MCP exchange. Your editor may launch a different executable, point at a different database, or require you to enable tools. The demo cannot establish that your agent's configuration or lifecycle hooks are active.

Try one real decision across two sessions

The next test belongs in your own workflow. Follow the quickstart, connect your agent, and ask it to save one real decision with the reason and any rejected alternative. Keep the entity path and record ID. Then open a fresh session in the same project and ask it to retrieve that decision. Compare the result with what you saved.

That is also where to test usefulness. Suppose you kept a dependency because its replacement lacked a feature you needed. Retrieving that constraint gives the next session something specific to check before attempting the replacement again. Only explicitly saved decisions can be recovered, and recorded reasoning still needs judgment: Selvedge stores the account supplied by you or your agent; it cannot establish that the account is correct or complete.

Check the digest before review

The second addition addresses what happens when those records reach a review. Selvedge already exports a deterministic Markdown digest. Once you have project history, generate it with:

selvedge export --format markdown -o DECISIONS.md

Version 0.3.17 adds a check you can run before review or in CI wherever that same history is available:

selvedge export --format markdown -o DECISIONS.md --check

If the file matches, the command exits successfully without output. If it is stale or missing, it exits with status 1 and a unified diff. The check preserves both the digest and the stored records; it does not initialize or migrate the database. Read failures produce guidance, and invalid arguments return status 2.

This gives a reviewer a straightforward consistency check. A digest can look reasonable while omitting a recently recorded decision. The check makes that drift visible. It does not validate the decisions themselves or fill gaps in capture. Review the exported reasoning before sharing or committing it.

There are smaller fixes with the same aim of making the record easier to interpret. Human-readable output now distinguishes an approach considered and rejected from a change tried and reverted. Literal bracket characters in logged text no longer cause the affected CLI rendering failures. The release adds no runtime dependencies, migrations, or MCP tools.

If you use a coding agent on a project you regularly return to, try one decision across two sessions. A local stdio MCP connection works; an agent with shell access can use the CLI. No hosted account is required, and core storage and retrieval make no LLM calls. The repository has the source and release notes. Feedback about where saving or retrieving that first real decision breaks is especially useful—share it in the existing trial discussion.

# 🧅 MyZubster: Our First Tor v3 Onion Pilot Is Running!

Sat, 17 Oct 2026 07:22:23 +0000

🧅 MyZubster: Our First Tor v3 Onion Pilot Is Running!

From an open-source marketplace to a network of independent services. One step at a time.

Hey Coder Legion community! 👋

We've reached a new technical milestone with MyZubster, our open-source ecosystem focused on connecting people, projects, knowledge, and independent infrastructure.

We recently deployed our first experimental Tor v3 Onion Service using Docker and HAProxy.

🚀 What works so far?

✅ Tor successfully bootstrapped to 100%
✅ A dedicated Onion v3 identity was generated
✅ An isolated HAProxy service serves our experimental page
✅ Docker networks separate the pilot from production services
✅ The test proxy returns HTTP 404 for /api and /admin
✅ The experimental page was displayed during testing

Our architecture:

Tor Browser
     ↓
Tor v3 Onion Service
     ↓
Isolated HAProxy
     ↓
MyZubster Pilot Page

Important: This is an experimental proof of concept, not a production-ready or independently audited service. Marketplace, Zorgax, wallets, and payment systems are not part of this pilot.

🌍 Why are we building this?

We want MyZubster to evolve into an ecosystem where contributors can:

Connect independent open-source projects.
Host services on their own infrastructure.
Share verifiable technical knowledge.
Build interoperable tools.
Participate in community-driven governance.
Explore privacy-conscious access through Tor.

We believe decentralization should be demonstrated through working infrastructure, not just promises.

👨💻 What's next?

We're collaborating with our contributor community, including @wasim-builds, on the next proposed development phase:

🔹 Reproducible Docker Compose deployment
🔹 Tor and HAProxy resilience testing
🔹 Network isolation and security documentation
🔹 Independent code reviews
🔹 Better monitoring and recovery procedures

🤝 Developers wanted!

Are you interested in Docker, Tor, cybersecurity, privacy, distributed systems, or open-source collaboration?

You can contribute through documentation, testing, code review, or pull requests.

No VPS or DAO membership is required to get started.

Explore the project:

🔗 GitHub: https://github.com/MyZubster-Ecosystem/myzubster

🧅 Tor Pilot Discussion: https://github.com/MyZubster-Ecosystem/myzubster/issues/1584

🌐 Website: https://www.myzubster.com/

Let's build independent infrastructure together, one verified component at a time.

A browser editor needs a file workflow, not just a canvas

Sat, 17 Oct 2026 03:15:25 +0000

A browser application can look ready long before you know whether it will work for your files. The canvas loads, the panels look familiar, and the temptation is to import an important project immediately. A better first test follows the file all the way from an untouched source to a result you can reopen.

Craft Apps is a useful setting for that discussion. Its public collection offers 13 browser-based tool entries, and its PhotoCraft page explains both the intended image workflow and several limits of the current web build. This article draws on those pages and an inspection of the loaded editor. No edit-and-export round trip was completed, so the checklist below is a proposed test, rather than a compatibility result.

Define an observable result before importing a file

Choose one task whose outcome can be checked outside the editor. For example, a small image with a readable title at its intended display size gives you a concrete question. “Try all the features” does not. Record the source dimensions and keep the original separate from the experiment.

The photocraft landing page discusses layered image editing, text and composition, and a PSD-oriented workflow. It also cautions that a PSD can contain features that do not translate perfectly. A reasonable test therefore starts with a modest file and a known expectation. The extension alone does not tell you whether a particular layer effect will survive a round trip.

If your task depends on editable text, check editable text. If it depends on transparency, check transparency. An attractive preview can hide a loss that only becomes obvious when somebody tries to use the file later.

Separate the landing-page examples from the running build

Documentation screenshots are useful for explaining an interface. They are weaker evidence for what a particular hosted version can do. PhotoCraft’s product page explicitly identifies its images as upstream examples and says that the browser integration may expose different controls and output options.

In the actual hosted editor, the opening workspace loaded with New document and Open controls. Opening the new-document dialog showed dimensions, resolution, RGB color mode, bit depth and background settings. That observation establishes that the controls were visible. It does not establish successful import, rendering fidelity or export behavior.

This separation is useful when reporting a bug, too. Name the current build and the exact file behavior you observed. A screenshot from a different release can help explain your expectation, but the report should still identify what happened in your session.

Treat saving as a separate acceptance step

The live product page says the web build opens files through the browser picker and saves by download. It also states that there is no web autosave or crash recovery. Those details change how you should structure a first test: keep it short enough to save and inspect before investing substantial work.

After using an available save or export command, locate the downloaded file. Reopen it in the application that will receive the work, or in a fresh editing session when continued editing is the requirement. Check the dimensions and the properties that mattered in your original task.

Keep a working version separate from a sharing copy when the available formats support that distinction. A flattened image and a reusable layered project serve different purposes. A file that opens successfully can still be unsuitable for the next step, so acceptance should follow the intended use.

Write down what passed and what remains unknown

A small test record can be a few lines: the source file, the intended change, the save option selected, the location of the download and the result of reopening it. Add any mismatch you saw. This makes the next decision easier than relying on whether the canvas looked convincing.

For this inspection, the public product notes, loaded workspace and new-document controls were observed. Import fidelity, export fidelity and recovery behavior were not independently tested. The site’s stated limits remain part of the decision.

A browser photo editor becomes useful for a particular job when its file workflow supports that job. Start with a source you can afford to experiment on, define a visible result, and finish the saving check before scaling up the work.

I Replaced $40/mo AI Job Trackers with a Local Python & Web Scraping Command Center (Zero API Key)

Fri, 16 Oct 2026 19:26:24 +0000

If you have looked for a remote role recently, you know the routine.

You wake up, open 40 browser tabs across Ashby, Lever, Greenhouse, Remotive, Welcome to the Jungle, We Work Remotely, and the monthly Hacker News Who is Hiring thread. Half the "remote" listings secretly say US Only - Must reside in Texas in paragraph four. Another third are ghost jobs reposted every Tuesday.

When I looked for tools to automate this, every commercial "AI job copilot" had the same three problems:

Another $29 to $49/month subscription at the exact moment you are looking for work.
Your resume and personal data live on someone else's cloud.
The double-billing trap: if you look at open-source tools, almost all of them require a paid, pay-per-token OpenAI or Anthropic API key, even though you already pay $20/month for a ChatGPT Plus, Claude Pro, or Gemini subscription.

I wanted something local, fast, and private that ran on my own machine. So over the last few weeks, I built and open-sourced Remote Job Hunter (rjh).

It is a local command center written in Python (standard library for the core engine + FastAPI and SQLite WAL) that scans 51+ job sources in parallel, scores every offer against a single profile.yaml, generates a 1-page ATS-safe PDF resume per company, and works even if you do not have an API key.

I just pushed v0.2 to GitHub, and I am looking for developers and job seekers to test it and tear it apart so I can make v0.3 better.

Built for Any Profession (Tech or Non-Tech, Remote or On-Site)

Despite the repo name (remote-job-hunter), the engine is completely domain-agnostic. It does not assume you are a software engineer, and it does not force you to look for remote-only roles:

search:                                    # A nurse in Lyon (on-site)                # A remote RevOps / Python engineer
  titles: {primary: [infirmier, IDE]}      #   healthcare, finance, sales, HR...      #   [automation engineer, revops]
  work_mode: {remote: any, cities: [Lyon]} #   on-site, hybrid, or 100% remote        #   {remote: required}

Whether you are a nurse in Lyon (profile.non-tech.example.yaml), an accountant in Paris, a sales manager, or a backend engineer, dropping your PDF resume into the Command Center automatically extracts your domain skills and calibrates the search and 1-page ATS resume generator for your field.

1. The "Wait, why do I need an API key?" realization

When I shared the first prototype with a friend who is a nurse in Lyon (not a developer), she asked a simple question: "I already have ChatGPT on my phone. Why do I have to create a developer account and put in a credit card for an API key?"

She was right. API keys are great for unattended cron jobs, terrible for normal people.

That conversation led to Zero-API-Key Manual Mode:

  51+ job sources ─▶ deterministic heuristic filter ─▶ 10 offers bundled into ONE prompt
                                                                      │
     scores, pitches & PoW diagrams ◀─ paste JSON back ◀─ paste into ChatGPT / Claude / Gemini

Here is how it works in practice:

rjh scan pulls offers from all your configured sources in parallel and runs a fast, deterministic local scorer (rjh/heuristic.py) that checks title match, location eligibility (Europe, Global, US Restricted), seniority, language, and your custom hard rules.
If you have an API key (Gemini, OpenAI, Anthropic, Groq, Mistral, OpenRouter) or a local Ollama model, it evaluates the top candidates automatically.
If you don't have an API key (or if your free quota hits 429), it automatically falls back to Manual Mode. You click Export a batch in the UI, paste the prompt into the ChatGPT/Claude/Gemini tab you already use, and paste the JSON reply back.

Handling truncated chat responses without losing work

Anyone who has pasted a large prompt into a web chat knows the main failure mode: the model stops generating at token 3,800 and leaves you with half a JSON array.

Instead of failing with JSONDecodeError, the parser in rjh/analysis.py salvages every completed JSON object from the truncated stream, saves those scores to SQLite immediately, and generates a follow-up ticket containing only the missing job IDs:

def salvage_json_objects(raw_text: str) -> list[dict]:
    """Extracts all complete top-level JSON objects from a truncated LLM array."""
    decoder = json.JSONDecoder()
    results = []
    idx = 0
    length = len(raw_text)

    while idx < length:
        brace = raw_text.find("{", idx)
        if brace == -1:
            break
        try:
            obj, end = decoder.raw_decode(raw_text, brace)
            if isinstance(obj, dict) and "id" in obj:
                results.append(obj)
            idx = end
        except json.JSONDecodeError:
            idx = brace + 1
    return results

Nothing gets lost, and you never re-run offers that were already scored.

2. Two-Stage Triage + Proof-of-Work Architecture Diagrams

Early on, I tried asking the LLM to score a job and write a custom pitch in a single pass. It was slow, burned tokens on mediocre roles, and produced generic pitches.

I split the pipeline into two distinct stages:

Stage 1 (Fast Triage): Evaluates up to 20 pre-filtered jobs per batch. Returns a fit_score (0.0 to 10.0), detected tech stack, and a 1-sentence reason.
Stage 2 (Deep Dossier for scores >= 7.5): Only for the roles worth applying to, the engine generates:
1. A 3-paragraph tailored pitch grounded in your actual metrics from profile.yaml.
2. A Proof-of-Work (Mermaid.js) architecture diagram proposing a concrete technical workflow for that company's stack, rendered directly inside the modal so you can walk through it during an interview.
3. A short founder/hiring-manager DM with a 1-click LinkedIn X-Ray search link.

3. Solving the ATS Resume Problem (`cv_tailor.py`)

When you apply on Workday, Taleo, Greenhouse, Lever, or Ashby, fancy two-column resumes with sidebars, progress bars, or floating boxes often get scrambled into unreadable text streams.

On the other hand, plain .txt-style resumes look awful when a human recruiter actually opens the PDF.

I built cv_tailor.py to solve both at once:

100% single-column linear DOM flow (Header -> Summary -> Core Stack -> Experience -> Education) so legacy and modern ATS parsers read every line in the exact right order.
Editorial typography (Newsreader serif headers + Plus Jakarta Sans body) that fits strictly on 1 page A4.
Zero hallucination rule: It extracts the exact technical keywords from the job description (n8n, Python, PostgreSQL, HubSpot, REST APIs), reorders your existing bullet points so the most relevant ones sit at the top, and bolds matching terms without inventing skills or metrics you don't have.
Built-in 7-point ATS self-audit: Every generated PDF is inspected with pypdf before returning a score (100/100, 1 page A4 verified) and automatically syncs with the 1-click Playwright form pre-filler.

4.Killing my own "Cyberpunk Terminal" UI

I have a confession: the first version of the dashboard looked like a 1990s hacker movie. Everything was neon green, uppercase monospace, glowing text shadows, [ BRACKETS EVERYWHERE ], and emojis on every button.

After staring at it for three days, my eyes hurt. A tool you use every morning shouldn't feel like a video game HUD.

I stripped out all the neon glow, brackets, and fake hacker jargon, and rebuilt the interface around a calm Linear / Raycast / Editorial aesthetic:

Dark Mode (#09090B) and Warm Paper Light Mode (#FAF8F5) switched via the browser View Transitions API circular ripple.
Plus Jakarta Sans for UI legibility, Newsreader for editorial hooks, and JetBrains Mono (tabular-nums) strictly reserved for scores, counters, and keyboard shortcuts (J / K to navigate cards, Enter for details, A to pre-fill, / to search).
I kept our mascot (Noir Webling) and the interactive dual-layer HTML5 Canvas spider web in the background, toned down into a subtle horology-inspired filigree with an elastic silk thread that connects to whichever job card you are inspecting.

Try it in 60 seconds

The entire project is MIT-licensed and runs locally on Linux, macOS, and Windows (Python 3.11+):

git clone https://github.com/manny-ruesch/remote-job-hunter.git
cd remote-job-hunter
pip install -e .

rjh init      # 4 quick questions (creates your profile.yaml)
rjh doctor    # verifies your sources, SQLite WAL database, and optional LLM key
rjh serve     # opens the Command Center on http://127.0.0.1:5070

GitHub Repository: https://github.com/manny-ruesch/remote-job-hunter

I Need Your Feedback (Help Me Break `v0.2`!)

This is a v0.2 release, and I want to shape the roadmap around real usage rather than guessing in a vacuum.

If you have 3 minutes to test it out, I would love your honest feedback in the comments (or via a GitHub Issue):

Try rjh init on your own job search (whether you are looking for Backend, DevOps, AI/Automation, Frontend, or even a non-tech role). Did the heuristic scorer rank offers the way you expected, or did noisy offers slip through?
Test the Zero-API-Key Manual Mode with your regular ChatGPT / Claude / Gemini chat. Was the copy-paste flow smooth, or is there friction I should remove?
Test the 1-Page ATS CV Tailor on a real job offer. How did the generated PDF look with your profile?
Which job boards or regional sources are missing? Right now it ships with Greenhouse, Ashby, Lever, Welcome to the Jungle, Remotive, We Work Remotely, Jobicy, Adzuna, and Hacker News. Tell me which board you check every week and I will add a connector for it in v0.3.

If you find this useful, a ⭐ on GitHub helps a ton, and every bug report or critique in the comments below goes straight into the next release!

What habits daily make you a really great software engineer?

Fri, 16 Oct 2026 17:09:05 +0000

Well, what do you think what are some top notch habits that makes you in top zone of engineering

Coder Legion - Recent posts tagged opensource

Trick or Type Guard? Surviving `unknown` with is-kit 🎃

🧟 Chapter 1: The Unknown Living Dead

🎃 Chapter 2: The Big Pumpkin of Unknown

🍬 Chapter 3: Trick or Type Guard!

🧛 Final Boss: The Vampire Called any

😸 Epilogue: We Survived Halloween!

Embeds: Putting a Live NitroIDE Playground Inside Your Docs

One parameter turns a share link into an embed

Where this actually belongs

The details that make an embed feel native, not bolted on

The limits, stated plainly

Why this matters more than a nicer code block

The Maintainer Who Wrote "Sorry, I Missed the Request!"

The world's least dramatic pull request

The strange psychology of an unanswered PR

Thirty-five minutes

We talk a lot about automation. We talk less about attention.

A reminder doesn't have to be a demand

Small contributions are still real contributions

The other side of the notification

One more thing before I close GitHub

Building Knemora: An Open-source, Local-first AI (SI) Second Brain

[OC] I built a free, open-source HIPAA DICOM anonymizer for medical imaging

The Problem

What It Does

1. Strips All 18 HIPAA Patient Identifiers

2. Deterministic UID Pseudonymization

3. Image Integrity

4. Date Reduction

Tech Stack

What It Looks Like

Directory Batch Processing

Robustness

Installation

Windows Standalone (No Python Required)

From Source

Design Tradeoffs

The DicomAnonymizer Class

What's Next

Feedback Welcome

A JSON-RPC Library With No Method Registration: How Does It Decide What Can Be Called?

1️⃣ What it covers

2️⃣ Getting started

ASP.NET Core server (Minimal API)

Client

3️⃣ With no registration, which methods can be called?

4️⃣ The client

5️⃣ Extension points: filters and interceptors

6️⃣ Encrypted payloads

7️⃣ How it differs from common libraries

8️⃣ Design trade-offs

✅ Wrapping up

Further reading

JSON-LD Recipes: BlogPosting, FAQPage, and SoftwareApplication Without a Plugin

MyZubster: Building an Open-Source Ecosystem with Human and AI Contributors

MyZubster: Building an Open-Source Ecosystem with Human and AI Contributors

What we're building

AI agents are beginning to participate in the conversation

How we want collaboration to work

Join us

OpenSource #AI #AIAgents #GitHub #Decentralization #Marketplace #Community

Thirteen PRs in one afternoon, and the boring rule that made it possible.

What was actually on the table

The rule

Who did what

The claim I stopped believing

The one I was afraid of

What I would keep

The Third Bombshell of the Night: I Wrote a Multi-Threaded ARP Network Scanner and Port Analyzer Usi

I’m back, and this time we’re coming out of the casino, not the mine! 😎

Here I am again, this time with a buddy of mine who’s a Monero miner.

--- KOZMO TITAN HIGH-SPEED SETTINGS ---

Güvenli ve stabil çalışan resmi XMRig C++ derlemesi

Seventeen Seconds to Parse One Name: A Security Scan Across Eleven PHP Projects

What the scans found, and what is fixed

Bugs that needed no attacker

Bugs a server, a file, or a document could trigger

The other high and medium findings

memory_limit stopped stopping things

🧛 Final Boss: The Vampire Called `any`

The `DicomAnonymizer` Class

🔍 Then `discriminatedUnion` Got Much More Serious

🤖 I Started Using `is-kit` in Other OSS Too

🚀 Then an `is-kit` Guard Ran Into an Effect Type Bug