Does it make sense to me?

That is the bar I wanted for m0lz.01.

I do not need another content calendar, another notes app, or another agent that says it can publish while leaving the real work scattered across terminals, drafts, browser tabs, and half-finished checklists. I wanted one local system that could take an idea, turn it into research, draft the post, challenge the argument, publish to my site, and prepare the distribution work without pretending the risky parts are magic.

m0lz.01 is that system. It is a standalone blog CLI with Codex and Claude authoring surfaces over the same SQLite state and file artifacts. The CLI owns the mechanical work. Codex and Claude help plan, write, review, and operate it.

The important part is not that it can write. The important part is that the system leaves me with a workflow I can inspect.

The Shape

The pipeline has six working phases: ideas, research, benchmark, draft, evaluate, and publish. published is the successful terminal state. unpublished is a rollback state that keeps the slug reserved because the canonical URL is permanent.

The hub is this site. Every post lands at https://m0lz.dev/writing/<slug>. Cross-posts point their canonical URL back here. Project repos and research pages are spokes around the hub, not competing sources of truth.

The CLI stores state in .blog-agent/state.db and writes phase artifacts next to it:

• research notes
• benchmark results
• MDX drafts
• evaluation reports
• generated research pages
• social paste files
• publish receipts

That sounds boring because it should. The durable value is not an agent personality. It is state that survives the chat window.

Codex First, Not Claude Only

The first version of this story over-indexed on the /blog Claude surface because that was the first polished interactive path. That is no longer the full picture.

The truth is simpler: m0lz.01 is a local CLI first. Codex is now a first-class way I work on and operate the system. This repo has Codex command wrappers under .codex/commands/* and migrated source-command skills under .agents/skills/source-command-*. Claude Code still has the packaged .claude-plugin/ /blog skill, and that plugin ships in the npm tarball.

Those are two clients over the same CLI boundary. Neither one gets to be the database. Neither one gets to be the publishing system. They propose work, inspect files, draft text, run checks, and hand off state changes to blog.

That distinction matters. If I am writing from Codex, I can run the same plan and evaluation discipline I use for code changes. If I am in Claude Code, I can use the packaged /blog flow. The content pipeline does not care which assistant helped produce the next approved step.

One Prompt Still Does Not Mean No Judgment

The pleasant demo is: ask for a launch post, get a published post.

The actual workflow is stricter. The authoring layer proposes a plan. The CLI validates that the plan is made of registered leaf commands. The operator approves it. blog agent apply executes the approved steps and writes a receipt.

For a project launch, the work is roughly:

blog research init m0lz-01-launch --topic "m0lz.01 launch"
blog research finalize m0lz-01-launch
blog benchmark skip m0lz-01-launch
blog draft init m0lz-01-launch
blog draft complete m0lz-01-launch
blog evaluate init m0lz-01-launch
blog evaluate structural-autocheck m0lz-01-launch
blog evaluate record m0lz-01-launch structural structural.json
blog evaluate record m0lz-01-launch adversarial adversarial.json
blog evaluate record m0lz-01-launch methodology methodology.json
blog evaluate synthesize m0lz-01-launch
blog evaluate complete m0lz-01-launch
blog publish start m0lz-01-launch

The plan path wraps those commands with a hash gate. Approval records a SHA256 hash of the canonical plan payload. If the plan changes after approval, verify and apply reject it with HASH_MISMATCH.

That gate is useful, but it is not a sandbox. The authoring surface can still ask to run blog commands. A human at the terminal can still bypass the plan system. The model is cooperative: a cooperative author, a cooperative assistant, and a CLI that makes the approved path hard to accidentally drift from.

Evaluation Is Where the System Earns Its Keep

I do not trust first drafts. I trust pressure.

m0lz.01 runs a three-reviewer panel:

• Structural review checks the content shape, MDX contract, sources, and publish readiness.
• Adversarial review uses Codex GPT-5.5 high to argue against the thesis.
• Methodology review uses Codex GPT-5.5 xhigh for benchmark validity, reproducibility, and evidence claims.

The synthesis step groups findings into consensus, majority, and single-reviewer issues. Consensus and majority issues block. Autocheck findings block. Single-reviewer issues can be advisory, but I rejected several algorithmic passes while dogfooding this post because serious findings were landing as single-reviewer advisories.

That is useful signal. The system did not merely produce a green check. It made the weakness visible enough for me to refuse the result.

What Ships Automatically

The publish pipeline is checkpointed. If step five fails, the next blog publish start <slug> resumes from step five. Each step is designed to be idempotent.

The pipeline can:

• create or update the canonical MDX in the hub repo
• generate the research companion page
• pause for the site pull request gate
• create a Dev.to draft with published: false
• attach the canonical URL to the Dev.to draft
• prepare paste-ready Medium, Substack, LinkedIn, and Hacker News text
• update companion repo links when a project repo exists

Dev.to is the one API cross-post path I am willing to automate right now. Medium, Substack, LinkedIn, and Hacker News remain paste-ready outputs because the manual review step is still useful and the APIs are not worth binding into the publish path yet.

What It Does Not Bind Yet

The plan hash does not bind .blogrc.yaml. If the workspace config changes between approval and apply, the plan hash does not catch it. The plan displays venues as operator-facing mitigation, but config-hash binding is still future work.

The SQLite database is local state, not protected state. Back it up before upgrades if a workspace matters.

The lock is slug-scoped and cooperative. It prevents two applies for the same slug from running at once. It does not defend against arbitrary filesystem edits inside .blog-agent/.

Those limitations do not make the system useless. They define the boundary. m0lz.01 is not a general-purpose secure agent runtime. It is a local publishing workflow with receipts, phase gates, and enough friction to keep me from shipping whatever the assistant wrote first.

Install

Install the CLI globally and verify that the binary resolves:

npm install -g m0lz-01
blog --help

Create a dedicated workspace outside your project repos:

mkdir -p ~/blog
cd ~/blog
blog init

Edit .blogrc.yaml with your hub site repo, base URL, content directories, author handles, and optional project map. Then edit .env with DEVTO_API_KEY if Dev.to publishing is enabled.

Use Codex from the m0lz.01 repo when you want the local command-wrapper workflow:

.codex/commands/prime.md
.codex/commands/plan-feature.md <topic>
.codex/commands/execute.md <plan-file>
.codex/commands/evaluate.md <plan-file>

Use the packaged Claude Code plugin when you want the /blog skill:

claude --plugin-dir "$(npm root -g)/m0lz-01/.claude-plugin"

Then start with the real question:

/blog launch a new project

Source is at github.com/jmolz/m0lz.01. The repo includes the CLI, the packaged Claude plugin, the Codex command wrappers, and the regression tests that keep the publishing path honest.