Forem: crevilla2050

"Behold Dennis The Forge" (or how the chickens helped give DEX a home)

crevilla2050 — Sun, 12 Apr 2026 00:34:50 +0000

🐔 From Chickens to Code

A few weeks ago, I presented a very real problem:
chickens were being unnecessarily sacrificed in the process of applying code transformations.

Fortunately, after a long and exhausting legal battle, they secured a brand new coop.

DEX artifacts, however, were not so lucky.

They still had no home.

Before Dennis, code refactoring and patch delivery lived in a strange place —
critical, yet obscure. Necessary, yet often chaotic.

Scripts were written.
Commands were executed.
Changes happened.

And then… they disappeared.

Then came DEX.

A deterministic transformation artifact:
inspectable, transparent, reversible.

For the first time, transformations could be treated as something real —
something you could hold, examine, verify.

Not just something you ran.

But watching the chickens win their case raised an uncomfortable question:

If chickens could get a home…

why couldn’t transformations?

So I built one.

A place where DEX artifacts can live, be shared, inspected, downloaded, and trusted.

A place where transformations don’t vanish after execution.

A place where they become part of a system.

🔥 Behold: Dennis The Forge

Behold Dennis The Forge.

A repository where DEX artifacts can finally live.

A place where users can upload, store, share, and inspect transformations —
as long as they are marked public.

This is the first prototype.

It is not complete.
It is not polished.
And it is definitely missing a few important pieces —
a proper UI diff, online editing, and other goodies that are already on the horizon.

But the foundation is there.

In The Forge, users can organize their work into Workspaces,
group related efforts into Projects,
and attach individual DEX artifacts to each of them.

Today, this structure is simple.

Tomorrow, it evolves.

Users will be able to invite collaborators —
individuals, or entire organizations —
and transformations will stop being a solitary act.

Because that’s the real shift:

Transformations are no longer just something you execute.

They become something you share,
something you review,
something you can trust.

The Forge is already usable.

You can explore it.
You can upload artifacts.
You can see how this idea behaves in the real world.

And yes — it will change.

It will evolve.
It will probably break a few times along the way.

But that’s part of the point.

🧩 What the Hex is a DEX?

But if you are still wondering:

“What the hex is a DEX?”

I invite you to read the article with the same name.

Here’s the short version.

A DEX artifact represents a transformation.

It could be a code refactoring patch, a string translation,
or anything that modifies source code at its deepest levels.

But it’s not just the change.

It’s a radiography of the change:

what will happen
where it will happen
how it will happen
and, most importantly - why

Traceability has always been a problem.

Changes happen.
Context disappears.
And eventually, nobody remembers who did what — or why.

DEX changes that.

Each artifact carries its own lineage.

Every transformation can be traced, step by step,
back to the very first artifact in the chain.

And if something goes wrong?

You don’t guess.

You don’t patch over the patch.

You simply revert the transformation — cleanly, in one step.

This means that any change can be:

inspected
signed
approved
and only then applied

In that sense, it may feel a bit like Git.

But while Git tracks files…

DEX tracks intent.

🚀 How to Start Using The Forge

If you want to try it out, you can already do so:

📖 Project homepage: https://www.dennis-forge.com/

🌐 Forge (SaaS): https://www.dennis-forge.com/repo/

Basic flow:
Register (or enter as guest)
Create a Workspace
Create a Project
Upload a DEX artifact
Assign DEX artifact to project
Explore, inspect, and share

That’s it.

No magic. No hidden steps.

Just transformations becoming visible.

🧠 Why This Matters

DEX is, at its core, a form of quality assurance.

Not after the fact.
Not as an afterthought.

But embedded directly into the transformation itself.

It ensures:

traceability
reproducibility
and responsibility

Now imagine a different workflow.

Instead of shipping a simple link to a Git repository…

you could ship the story of the change.

A complete, inspectable narrative of what happened,
why it happened,
and how it will affect the system.

Not just code.

Intent.

DEX is not trying to replace Git.

They solve different problems.

DEX operates alongside your Git project, optionally integrating into your workflow, and focusing only on the transformations that matter—without getting in your way.

When used inside a Git repository, Dennis can even reuse your existing .gitignore rules to filter out irrelevant files.

But it does not depend on Git.

DEX can operate in environments where version control is absent — or simply not allowed — while preserving the same guarantees of traceability and reproducibility.

Together, they turn delivery into something cleaner,
more transparent,
and far less mysterious.

🔌 Current Scope (and What Comes Next)

Right now, Dennis is implemented in Python, and the available transformation engine is focused on Python projects.

But that’s not a limitation — it’s the starting point.

The system is designed to be extensible.

Support for other ecosystems — React, Java, C/C++, PHP, HTML/XML, Go, and more — will come through dedicated plugins that follow the same deterministic principles.

Today, there is one plugin. Tomorrow, there will be many.

Because the goal is not to solve transformations for one language.

It is to define a model that can work across all of them.

And The Forge?
It’s where those stories begin to live.
For the first time, transformations stop being ephemeral.

Now the DEX has its own coop.

The DEX was not a HEX. Why deterministic artifacts depend on deterministic classification

crevilla2050 — Sat, 21 Mar 2026 05:29:21 +0000

In a previous article, I introduced DEX — deterministic transformation artifacts.

https://dev.to/crevilla2050/what-the-hex-is-a-dex-introducing-deterministic-transformation-artifacts-397d

"What the Hex is a DEX? Introducing Deterministic Transformation Artifacts"

At the time, it looked like magic:

scan a codebase

generate a plan

package it

sign it

apply it

undo it

No chickens required. No rituals. No late-night debugging séances.
Clean. Surgical. Almost suspicious. But there was a missing piece.

DEX looks like a packaging format. It isn’t.

The Misunderstanding

It’s very easy — dangerously easy — to think:

“DEX is just a better codemod format.”

That’s how you end up in trouble. DEX is not about how transformations are stored.
DEX is about whether those transformations make any sense at all. The Real Problem Was Never Extraction

Let’s rewind.

You want to internationalize a codebase.
You run a string extractor.
And it obediently hands you… everything.

"btn btn-primary"
"SELECT * FROM users"
"/api/v1/orders"
"chr_nombre_prod"
"Error al guardar"

Beautiful.
Accurate.
Completely unhinged.

Because extraction is easy. Meaning is where things start to fall apart.

Signal vs Noise

Real codebases are not polite.
They are loud, chaotic ecosystems of:

SQL fragments pretending to be text
CSS classes cosplaying as language
URLs, identifiers, and paths everywhere
binary junk sneaking in like contraband
templating artifacts that look meaningful until they bite you

If you extract everything, you get noise.
If you filter too aggressively, you lose signal.
If you get it wrong…

You ship bugs with confidence.

This Is Where Dennis Actually begins to shine
Before DEX.
Before artifacts.
Before signatures and packaging and all the shiny machinery.
There is a moment where the system has to decide:

“Is this actually meaningful?”

Dennis is not just a scanner. It’s a decision engine. And it has opinions.

The Clean Engine (the quiet part that does all the work)

Inside Dennis there is a second pass.
No glamour. No marketing slides.
Just judgment.

It looks at a string and asks:

is this SQL pretending to be human language?
is this CSS dressed up as meaning?
is this code leaking into text?
is this something a human would actually read?

And then it makes a decision.

No guessing.
No vibes.
Same input → same verdict.
Every time.

Why This Matters

Because DEX artifacts don’t store strings. They store decisions that survived scrutiny.

Now imagine skipping that step.

You generate a transformation plan straight from raw extraction.
You package it.
You sign it.
You distribute it.
And then you apply it.
What happens?

CSS classes get rewritten
SQL fragments get “translated”
helpers get injected into places they should never exist
your codebase mutates into something… creative

Congratulations.

You have built a perfectly deterministic disaster.

DEX Needs Clean Input

This is the uncomfortable truth: DEX is only as good as the decisions that precede it.

Not the packaging.
Not the signatures.
Not the CLI.
The decisions.

From Extraction to Meaning

The pipeline people imagine:

scan → pack → apply

The pipeline that actually works:

scan → decide → plan → package → sign → apply

That second step?
That’s the whole game.

A Better Analogy

People like to say:

“DEX is like a Git commit + migration + signature.”

That’s fine. But here’s the one that actually sticks:

A DEX artifact is to transformations what a container image is to execution.

And just like containers:

you still need a clean build
you still need a sane base
you still need a history
and if you mess it up…
you get reproducible garbage at scale

The Point of Determinism

Determinism is not about rigidity. It’s about removing surprises.

Same input:

same extraction
same decisions
same plan
same artifact

No ghosts.
No hidden state.
No “it worked on my machine, I swear.”
No excuses.

Lineage (or: how to make transformations testify in court)

Determinism gives you consistency.

Lineage gives you memory.

Every DEX artifact produced by Dennis carries a trace of how it came to be:

the original inputs
the transformation plan
the resulting artifact
the signatures applied
and critically — the hash of the previous state

Each step is chained.
Each artifact knows where it came from.
Each transformation leaves a fingerprint.

This is not just versioning. This is forensic lineage.
It doesn’t just record history. It makes history verifiable.

You can take the latest artifact in a chain and walk it backwards:

what changed
when it changed
how it changed
who signed it
and which exact artifact caused it

No guesswork. No archaeology.
No “who ran that script three weeks ago?”

And because every step is hashed and linked:

tampering is not just difficult — it’s obvious

Break the chain, and the artifact tells on you.

This is where DEX stops being a developer convenience and starts becoming something else:

a system of record for transformations

At that point, you’re no longer just applying changes.

You’re building a history that can be:

inspected
verified
replayed
audited

Or, if things go sideways…

reversed with surgical precision

Determinism tells you what will happen.

Lineage tells you what already happened.

Together?

That’s trust.

And Then DEX Makes Sense

Once the input is clean:

the plan becomes inspectable
the artifact becomes trustworthy
the signature actually means something
the undo becomes real, not theoretical

DEX isn’t the magic trick.
DEX is what happens after you stop lying to yourself about your input.

The Shift

Before:
“Let’s run a script and hope this doesn’t ruin everything.”

After:
“Let’s generate a deterministic plan, inspect it, and then decide if we trust it.”

Final Thought

We’ve learned to version:

code
dependencies
infrastructure

But the transformations that shape them? Those usually vanish the moment they run.

Gone.
Untraceable.
Unrepeatable.

DEX artifacts don’t just package transformations. They force them into the light.

And Dennis?
Dennis is still the forge. But the forge was never the interesting part.

https://crevilla2050.github.io/dennis-forge/

The real power was deciding what was worth forging in the first place.

And yes…

The chickens have been officially retired.

No severance package.
Negotiations ongoing.
Legal is reviewing the chickens' case.

What the Hex is a Dex? Introducing Deterministic Transformation Artifacts

crevilla2050 — Fri, 13 Mar 2026 07:11:43 +0000

Large code refactors usually happen through fragile scripts, regex sorcery, and the occasional ritual chicken.

What if transformations themselves were portable, inspectable artifacts you could sign, verify, and undo?

Meet DEX — deterministic transformation artifacts, forged with a tool called Dennis.

The Problem: Code Transformations Are Usually Chaos

Software engineers constantly need to transform codebases.
Not just small edits. We're talking about massive structural changes:

API migrations
framework upgrades
localization rewrites
security patches across hundreds of repositories
refactors touching thousands of files

Most of the time these transformations are done with a mix of:

fragile scripts
regex sorcery
one-off codemods
questionable search-and-replace rituals involving chickens

And once the script runs… Well.
Good luck.

You often get:

no clear audit trail
no reproducibility
no safe rollback
no way to inspect the transformation beforehand

In other words: You just ran a very large mutation across your codebase and now you're praying to the CI gods that the chicken satisfied their thirst for bugs.

But... What If Code Transformations Were Artifacts?
Imagine this: Instead of executing transformations blindly, what if we treated them like first-class artifacts? Something you could:

inspect
verify
share
sign
reproduce
and even undo (without needing any chickens)

This is the idea behind DEX.
DEX: Deterministic Transformation Artifacts

A DEX artifact is a portable package that describes a code transformation in a deterministic way.

Think of it as something like:

Git commit
+
migration script
+
cryptographic signature
+
replayable transformation plan

But instead of being tied to a specific repository state, a DEX artifact describes the transformation itself.

Inside a DEX artifact you typically find:

DEX
├── manifest.json
├── payload/
│ └── plan.json
└── signatures/

The important piece is the transformation plan. That plan describes:

which files change
which lines are modified
what the original code was
what the replacement becomes
which helpers were injected
the exact hash of the source file

Everything needed to reproduce the change deterministically.
Given the same inputs, the artifact will always produce the same transformation output. No hidden state, no runtime surprises.

The Dennis Forge

DEX artifacts are produced by a tool called Dennis.
Dennis is a deterministic codemod engine designed around a simple philosophy:

"Transformations should be planned, inspectable, and reversible."

The workflow looks like this:

Scan → Plan → Package → Sign → Verify → Apply

Instead of modifying your project directly, Dennis first generates a plan.
It is safe enough to try at home. No chickens required.

So... enough theory.
Let’s forge an artifact.
To begin with, clone the small example repository:

git clone https://github.com/crevilla2050/hello-dennis
cd hello-dennis

Inside you will find a minimal Python program:

!/usr/bin/env python3

def main():

print("Hello world.")
print("Thank you for using Dennis. Love, the Dennis Team.")

if name == "main":
main()

Nothing fancy.
Just two hardcoded strings — exactly the kind of thing that quietly spreads across a codebase until someone eventually says:

“We should probably internationalize this.”

Generating the Transformation Plan

To build a new artifact, once the repository is on your local machine, run the following inside the project folder:

dennis plan run . --dict messages_en.json --add-helper helper.py --target-file hello.py --line 12

This command analyzes the project and produces a deterministic transformation plan describing exactly what changes will occur.

However, nothing is modified yet.

Dennis always starts with a plan.

The plan is simply a JSON document describing the transformation.
You can open it and inspect it directly.

Packaging the Artifact

Once the plan exists, you can package it into a DEX artifact:

dennis pack plan.json hello-dennis.dex

At this point the transformation becomes a portable artifact. It can be shared, inspected, versioned, and stored like any other build artifact.

Signing the Artifact

DEX artifacts can also be cryptographically signed.
First generate a signing key:

dennis keygen

Then sign the artifact:

dennis dex sign hello-dennis.dex --key dennis.key

Now the artifact contains a verifiable signature proving its origin. If someone modifies the artifact payload and signs it again, older signatures remain inside the artifact as part of its historical record. This creates a chain of custody for transformations.

Inspecting the Artifact

Before executing anything, you can inspect the artifact:

dennis inspect hello-dennis.dex

Dennis will display:

artifact metadata
payload type
payload hash
signatures
transformation information

This allows engineers to verify what the artifact contains before trusting it.

Applying the Transformation

To execute the transformation:

dennis rehydrate hello-dennis.dex
dennis apply rehydrated-plan.json

Your Python script will be transformed into a localization-ready structure. Instead of hardcoded strings, the program will now load messages from a dictionary.

Testing the Result

You can now try running the program with different language settings.
For example:

LANG=es python hello.py

LANG=de python hello.py

The program will automatically load the corresponding translation dictionary.
No chicken magic. Just deterministic, reversible transformations.

Undoing the Transformation

Dennis transformations are reversible by design. If something goes wrong, you can generate the inverse plan:

dennis invert rehydrated-plan.json
dennis apply rehydrated-plan.undo.json

Your project returns to its original state.

No Git resets.
No archaeology.
Just a deterministic undo.

Encrypted Artifacts: XDEX

In some situations you may want to distribute a transformation artifact without exposing the internal transformation logic.

For that purpose Dennis supports XDEX artifacts.
An XDEX artifact is simply an encrypted version of a DEX file.

DEX → XDEX

The payload is encrypted while the outer metadata remains visible.

This allows organizations to distribute verifiable transformation artifacts while keeping the transformation plan confidential.

You can encrypt an artifact like this:

dennis encrypt hello-dennis.dex

Why This Matters?

Modern software pipelines treat many things as artifacts:

container images
compiled binaries
dependency locks
signed releases

But strangely, code transformations themselves are often invisible. DEX artifacts change that. They turn transformations into portable, inspectable, verifiable objects. Which means software evolution itself becomes something we can track, audit, and reproduce.

Final Thoughts

Software history is written through transformations.

Refactors.
Migrations.
Patches.
Upgrades.

Most of the time those transformations vanish after they run.

DEX artifacts make them visible.

And Dennis is the forge where they are made.

The forge lives under: https://github.com/crevilla2050/string-audit

Install with pip or pipx, and start DEX-ing your code.
DEX artifacts turn transformations into something you can pass around, inspect, and trust.

And may chickens live forever!

My first Dev.to post: building a deterministic codemod engine (Dennis Forge)

crevilla2050 — Thu, 05 Mar 2026 06:22:32 +0000

Hello Dev.to!

This is my first post here, so I thought I would introduce a small open-source tool I've been working on called Dennis Forge.

The idea behind Dennis came from a very practical problem.

In one of my projects I ended up with a mixture of translated strings, hard-coded strings, and inconsistent localization logic. Fixing it with quick scripts felt risky, because those scripts modify files immediately and it is difficult to see exactly what they will change.

I started wondering if there was a safer workflow.

Instead of modifying code directly, what if the tool generated a plan first?

That idea eventually became Dennis.

The core idea: Dennis is a CLI tool that generates deterministic transformation plans for codebases. Simple as that, yet powerful.

Instead of immediately changing files, the workflow looks like this:

scan project
→ generate transformation plan
→ inspect or edit the plan
→ validate
→ apply changes

The plan is stored as human-readable JSON and becomes the source of truth for the transformation.
Because of that, changes are transparent and predictable.

Some design goals that while building Dennis, I tried to keep a few principles in mind:

Deterministic output
Human-readable plans
Reversible transformations
Fully offline operation
No hidden magic

In other words, Dennis tries to make large transformations inspectable before they happen.

DEX artifacts

Recently I added something called DEX artifacts.

A DEX file packages a transformation plan together with metadata and optional cryptographic signatures. This allows plans to be shared or verified across machines while preserving determinism.

The idea is still evolving, but it has been a fun architectural problem to explore.

The project

Dennis is fully open source.

GitHub
https://github.com/crevilla2050/string-audit

Project page
https://crevilla2050.github.io/dennis-forge/

Why I'm sharing it

Partly to introduce myself to the Dev.to community, and partly because I'm curious how other developers approach large refactors or codemods safely.

If you have experience with tools like this, I would love to hear your thoughts, if you have any comments, suggestions, questions or whatever your heart wants to say, I will be happy to hear from you.