Content to action
Qubicweb keeps the discovery and trust-education layer lightweight. When you need governed account, commerce, service, or trust actions, continue in the canonical app without losing the article’s source context.
Content to action
Qubicweb keeps the discovery and trust-education layer lightweight. When you need governed account, commerce, service, or trust actions, continue in the canonical app without losing the article’s source context.
Brief points
Key points will appear here once TrustOps condenses this read. Use the source link below if you need the full article immediately.
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 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:
That sounds boring because it should. The durable value is not an agent personality. It is state that survives the chat window.
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.
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.
I do not trust first drafts. I trust pressure.
m0lz.01 runs a three-reviewer panel:
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.
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:
published: false
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.
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 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.
Spot something off?