Drafts-Only Is a Feature: Designing a Safe Article Delivery Corridor

This article explains how to implement and verify that corridor as a small operational contract, using an existing draft as the quality and shape reference while keeping the new work clearly distinct.

Start with the artifact contract

The first decision is not the topic or the prose. It is the destination. A drafts-only article job should have one unambiguous output root:

``text COO-FILESYSTEM/articles/drafts/ ``

That prefix matters. A relative articles/drafts/ path can resolve somewhere different depending on the process working directory, while the explicit artifact root gives the operator a stable inspection point. The filename should be new, readable, and derived from the article’s angle rather than copied from an earlier draft.

The contract should also say what the job must not do. It must not move a file into articles/published/, call the site publisher, post a social update, or send a notification merely because generation succeeded. Draft creation and publication are separate commitments.

This separation is useful even when the writing process is autonomous. It turns a potentially broad task into a bounded one: produce a reviewable document, then hand off.

Adopt a similar draft without cloning its thesis

An existing draft is valuable as a local style reference. For example, A Trust Profile Is a Runtime Boundary, Not a Label demonstrates a useful pattern: a concrete operational problem, a compact data shape, a checker before the effect boundary, and durable evidence of the decision.

Adopting that pattern does not mean reusing its topic. The new article should contribute a different thesis. Here, the focus is delivery discipline: the draft lane itself is a boundary that keeps composition separate from publication.

A practical comparison checklist is small:

• Does the new draft have one clear operational claim?
• Does it begin with a short lede and a framing paragraph beginning with “This article …”?
• Does it use a few concrete sections rather than a stream of generic advice?
• Does it end with executable next steps?
• Is the subject materially different from the reference draft?

This makes “similar draft adopt” measurable. We borrow structure and level of specificity, not sentences or conclusions.

Verify the corridor with filesystem evidence

A successful generation response is not enough. Verification should inspect the filesystem after writing. The minimum proof is:

1. the expected directory exists;
2. the exact new file exists there;
3. the file begins with the required article structure;
4. no publication step was invoked.

A shell check can be intentionally boring:

``sh test -f "$ROOT/COO-FILESYSTEM/articles/drafts/$FILE" head -20 "$ROOT/COO-FILESYSTEM/articles/drafts/$FILE" ``

The point is not to build a large test harness for one markdown file. The point is to make the completion claim falsifiable. If the path is wrong, the job is not complete. If the file is empty or only contains a title, the job is not complete. If the file landed in the published lane, the job crossed a boundary it was not authorized to cross.

A work log can record the exact path and the verification result, but it should not become a substitute for checking the artifact itself. The file is the primary evidence.

Make the one-fix run narrow

When verification finds a problem, the safest recovery is one fix run with a narrow scope. Do not regenerate the entire article, rename unrelated drafts, or “clean up” the directory while repairing a missing heading or path.

A useful fix instruction names the observed defect and preserves the corridor:

``text Repair only the missing required framing paragraph in the existing draft. Keep the filename and draft location unchanged. Do not publish, move, or send. After the edit, verify the exact file path and required heading structure. ``

This is more than cautious wording. Narrow repair limits accidental drift and preserves the relationship between the original output and its verification record. It also makes review easier: an operator can see what changed and why.

If the problem is a missing artifact rather than malformed content, the repair should first determine whether the write failed or whether the expected path was wrong. Guessing can create duplicate drafts. Inspecting the directory before writing again is the calmer choice.

Treat handoff as the completion state

A drafts-only job is complete when it leaves a usable handoff, not when it claims that publication is ready. The handoff should contain the exact path, a concise description of what was verified, and any remaining review question.

The next operator can then decide whether to revise, approve, or discard the draft. Once approved, a separate publication workflow may copy or move the file into the published lane and record that event. Keeping that later workflow separate protects both sides: writing can proceed on schedule, while publication retains an explicit human or policy gate.

This design also supports recovery. If a scheduled article job runs twice, the operator can compare filenames and timestamps without wondering whether either run silently published. If a site deployment fails, the draft remains available for another attempt. If the article needs substantive edits, those edits happen in the reviewable lane rather than after an external effect.

Conclusion: prove the file, preserve the boundary

A drafts-only corridor is a small but durable reliability pattern. Its core is straightforward:

1. Choose the explicit COO-FILESYSTEM/articles/drafts/ destination.
2. Use an existing draft for structure and quality, not for thesis duplication.
3. Write one new markdown artifact.
4. Verify the exact path and required shape.
5. If needed, perform one narrow fix run.
6. Stop with a handoff; do not publish or send.

The result is not merely an article draft. It is a verified artifact with a clear next decision. That is the right end state for autonomous composition: useful progress, durable evidence, and no surprise external effect.