Done as a "temporary chat" to avoid personal bias and memory

—

Prioritize draft-first. Add immediate publish as an opt-in fast path, not the default.

Why? Because your system has the exact properties that make immediate publish a bad default for agents:

That combo screams: stage locally, validate hard, publish once.

Build Option A first:

Then add a convenience mode for trivial cases:

So externally you support both, but architecturally drafts are the primitive.

A human might make one careful edit. An LLM usually does this instead:

That is not one mutation. It is a mini transaction. If every step publishes, the agent leaks its half-baked intermediate states into permanent history. That is dumb.

LLMs screw up. Regularly.

With drafts, the loop is:

Without drafts, the loop is:

For an immutable, distributed history, that is awful operational hygiene.

A “simple” instruction like “add a new section and move the summary under it” can require:

Immediate publish exposes broken intermediate states between those steps. Drafts let you publish the whole transformation as one coherent commit.

Agents benefit massively from transaction semantics even if you do not call it that.

Strict validation on individual blocks helps, but it does not solve higher-level consistency:

Draft validation can check document-level invariants, not just block shape.

Agents work better when the CLI maps to clear mental units:

That is much easier to orchestrate than “every mutation is final, be perfect every time.” LLMs are not perfect every time. News at 11.

In a peer-to-peer immutable system, every published intermediate state becomes shared cost:

Immediate publish turns agent trial-and-error into network spam.

History should reflect meaningful user intent, not the internal scratchpad of an agent.

A single publish that says:

is useful.

A series of publishes like:

is junk. Accurate junk, still junk.

If collaborators are active, immediate publish increases the chance that others see and react to transient states. Drafts narrow the collaboration window to one final publish event.

You still need merge/conflict semantics at publish time, obviously, but at least you are resolving one coherent change set, not a stream of accidental micro-edits.

A draft boundary is a great place to run:

Trying to bolt those onto every tiny publishable mutation is clumsy.

It is not useless. It is good for:

Examples:

So yes, support it. Just don’t make it your core model.

For AI agents, the right abstraction is not “command = publish.” It is “task = draft, publish = commit.”

Agents operate at task granularity. Your system’s permanence operates at publish granularity. Those should line up.

If they do not, the CLI forces agents to externalize their internal scratch work into permanent shared history. That is bad design, full stop.

Use drafts internally as the canonical mutation model. Then expose two UX layers:

Under the hood, the one-shot path can just:

That keeps one implementation model instead of two competing ones. Much less stupid.

If AI agents matter, the draft workflow should have:

Every command should support structured output:

No fluffy terminal prose. Agents do not need your artisanal CLI copy.

Agents need reliable ways to refer to blocks:

Not just “this block parses,” but:

Agents need to inspect what changed before publishing:

Publish the draft as one operation, with:

Agents retry. Networks fail.
You want:

If scope is tight, build this first:

Then add:

That ordering matches real risk.

Build draft workflow first. Make it the default.
Offer immediate publish as a convenience wrapper for trivial edits.

That gives agents:

And it gives the system:

Immediate publish as the default would be a nice way to turn LLM uncertainty into permanent distributed clutter. Don’t do that.