m0lz.01 Research — Research

Thesis

m0lz.01 works best when framed as a local idea-to-distribution pipeline whose stable center is the standalone blog CLI. Codex and Claude are authoring surfaces over that CLI and its SQLite/file artifacts, not the publishing system themselves.

Key Findings

The launch question is personal fit, not abstract autonomy. The stronger story is "Does it make sense to me?" because the system exists to make Jacob's writing and distribution workflow inspectable, repeatable, and harder to lose between tools.
The public framing must be Codex-first and dual-client accurate. The repo now has .codex/commands/* wrappers and .agents/skills/source-command-* for Codex work, while .claude-plugin/ remains the packaged /blog Claude Code plugin. The article should not describe m0lz.01 as Claude-only.
The CLI is the safety boundary. Authoring surfaces can plan and review, but state changes run through blog subcommands and, for plan execution, the blog agent apply path.
Hash-gated plans reduce accidental drift. Approval records a SHA256 hash over canonical plan payload bytes. Post-approval edits reject with HASH_MISMATCH.
The gate is cooperative, not a sandbox. The authoring surface has enough blog access to bypass the path if prompted badly. A human can also bypass at the terminal. The guarantee is workflow discipline for a cooperative operator.
Evaluation pressure matters more than a green verdict. Dogfooding produced algorithmic passes with serious single-reviewer findings. Rejecting those passes is part of the system's value, because it made weak output visible instead of hiding it.
Dev.to cover support belongs in deterministic publish logic. Draft frontmatter can carry a devto_main_image, and the pipeline should resolve only safe URL or post-asset values into Forem payloads. Image generation itself should stay an authoring artifact, not a publish-time API dependency.
Research page branch marks depend on project metadata. The m0lz.00 research components already render a branch mark when meta.project resolves through data/projects.ts; the missing piece was the m0lz.01 project registry entry and generated research-page project frontmatter.

Sources

Methodology

This research page is a launch companion rather than a benchmark report. The evidence base is the current m0lz.01 implementation, the dogfood publish state for m0lz-01-launch, the m0lz.00 rendering contract, and the behavior required by Forem's article create/update payloads.

The key implementation checks are:

Generated research pages should include project: "m0lz.01" when the post row has project_id = "m0lz.01".
The m0lz.00 project registry should include m0lz.01 with variant: "blog-agent".
Dev.to POST and PUT payloads should include article.main_image only when frontmatter explicitly configures a safe image value.
The canonical slug should remain /writing/m0lz-01-launch.

Release notes and implementation context

Open Questions

Config binding. The plan hash still does not bind .blogrc.yaml. A future release should bind or snapshot workspace config so venue and path changes cannot drift after approval.
Codex packaging. Codex support is currently repo-local command and skill guidance plus the standalone CLI. A packaged Codex plugin would need separate packaging, install, and verify-pack coverage.
Cover generation. The launch cover is an authoring artifact. A future blog visuals cover command could make cover creation repeatable, but it should be explicit and should not add a hidden OpenAI dependency to blog publish.
Reviewer clustering. Serious single-reviewer findings can still pass synthesis when reviewers phrase similar concerns differently. The clustering heuristic needs a better identity model.
Venue URL capture. Dev.to URL capture is automatic. Medium, Substack, LinkedIn, and Hacker News remain paste-ready and manual, so their final URLs are not first-class state yet.

This research supports m0lz.01: Does it make sense to me?. companion repo