Multi-Venue Publishing Lifecycle and Canonical Ownership

Context and Problem Statement

joelclaw grew up with one obvious public venue: joelclaw.com.

That assumption is now wrong.

The system has multiple public venues with different audiences and product contracts:

• joelclaw.com
• wizardshit.ai
• Gremlin reference/operator surfaces
• future venue-specific sites that should not be forced through Joel’s personal site first

The current failure mode is subtle but nasty:

1. an operator asks to publish or migrate a piece,
2. the system defaults to the joelclaw pipeline because that path is best-developed,
3. the piece lands on the wrong venue,
4. downstream docs/ADRs start rationalizing the mistake instead of catching it.

Recent evidence made the bug obvious:

• the Wizard Frame / agent cantrips piece was supposed to become a Wizardshit article, not a joelclaw post
• Gremlin ADR-0056 then tried to explain the venue mistake by reclassifying the wrong Wizardshit resource (/local-ai-jobs-launchd) instead of fixing the publishing policy
• venue choice, content shape, deletion policy, and migration semantics were all getting blurred together

That is a control-plane bug, not just a content-model bug.

Decision

1. Venue selection is a first-class publishing decision

Before any public content is drafted, published, migrated, or republished, the system must resolve the intended venue explicitly.

Venue selection is not allowed to hide inside:

• a generic “write article” request
• a convenience fallback to joelclaw.com
• a repo-local default that happens to be implemented first

For public long-form content, the system must know:

• what the thing is (article, tutorial, page, note, etc.)
• where it belongs (joelclaw, Wizardshit, another venue)

These are separate decisions.

2. No implicit default-to-joelclaw publishing for cross-venue content

When venue is ambiguous, the system must stop and resolve it instead of silently publishing to joelclaw.com.

Acceptable resolution paths are:

• explicit operator instruction
• a workflow that already carries durable venue metadata
• a venue-specific command surface
• a structured clarification step

“joelclaw is the easiest path right now” is not a valid routing policy.

3. Each published resource has one canonical public venue at a time

A public resource may be mirrored temporarily during migration or recovery, but steady-state ownership is singular.

This means:

• one canonical public venue per piece at a time
• duplicate hosting across venues is migration debt, not normal operation
• documentation must describe the canonical venue truthfully

4. Migration is an explicit lifecycle, not an accidental duplicate

When a piece moves from one venue to another, the lifecycle is:

1. resolve destination venue
2. publish or stage in the destination venue
3. verify the destination surface
4. remove the old venue copy unless the operator explicitly asks for a redirect or a retained migration notice

The default posture is do not keep accidental duplicates alive.

For short-lived mistaken publishes, deletion from the old venue is the normal cleanup path.

5. Venue policy lives in joelclaw operator surfaces, not inside Gremlin content-shape ADRs

Gremlin decides content shape and product semantics. joelclaw decides publishing venue, migration policy, and operator routing.

This means Gremlin ADRs should not be forced to answer:

• which site should own a piece
• whether an old joelclaw URL should redirect or disappear
• whether a cross-site migration should preserve duplicate hosting

Those are joelclaw publishing-control decisions.

6. Operator-facing publish contracts must carry venue metadata

The gateway, CLI, content skills, and any publish orchestration must preserve venue choice as structured data, not just prose in a prompt.

At minimum, publish requests need enough contract to answer:

• target venue
• content kind
• canonical ownership state
• migration vs fresh publish
• old-venue cleanup policy when migration is involved

Implementation Plan

Required skills before implementation

• content-publish — current joelclaw publishing pipeline and where it over-assumes joelclaw surfaces
• joelclaw-web — joelclaw.com content/runtime behavior and removal rules
• gateway — operator-intent routing and clarification paths
• adr-skill — ADR grooming and follow-on decision hygiene
• gremlin-wizardshit-publishing — Wizardshit publish boundaries when the target venue is wizardshit.ai

Affected surfaces

• SYSTEM.md and TOOLS.md trigger language that currently defaults article intents into joelclaw flows
• skills/content-publish/SKILL.md
• skills/joelclaw-web/SKILL.md
• gateway intent-routing / clarification logic
• operator-facing CLI publish surfaces
• any content workflow that assumes public long-form means joelclaw.com

Required follow-on slices

1. Intent contract hardening

   • add explicit venue selection or venue clarification before public publish flows run
   • remove ambiguous prompt shortcuts that silently route to joelclaw

2. Venue-aware operator surfaces

   • extend CLI/gateway publish contracts so venue is structured and inspectable
   • ensure handoffs and background agents preserve that field

3. Migration lifecycle support

   • support explicit “migrate from X to Y” flows with destination verification and old-venue cleanup
   • default mistaken short-lived publishes to deletion rather than shadow duplicates

4. Skill and docs cleanup

   • update content/publishing skills so they stop promising a universal joelclaw-first route
   • document venue-selection rules in the canonical operator docs

Verification

• Ambiguous public-writing intents no longer auto-route to joelclaw.com
• Operator-facing publish commands/workflows preserve venue as structured data
• Migration flows distinguish destination publish from old-venue cleanup
• Content-shape ADRs in Gremlin stop carrying joelclaw venue policy
• A Wizardshit-bound article can be routed without first appearing as joelclaw content

Consequences

Positive

• wrong-venue publishes become harder to trigger accidentally
• content type and venue become separate, inspectable decisions
• migration cleanup stops being improvised after the fact
• Gremlin and joelclaw keep cleaner responsibility boundaries

Tradeoffs

• ambiguous operator asks now need clarification or durable venue metadata
• the simplest joelclaw-only content shortcut becomes less magical
• implementation touches multiple operator surfaces, not just one repo file

Neutral

• this ADR does not decide every future venue in advance
• this ADR does not force redirects as the default migration behavior
• this ADR does not replace venue-specific content models

Alternatives Considered

Alternative 1: Keep joelclaw.com as the implicit default venue

Description: continue routing generic article/publish asks to the joelclaw pipeline unless the operator says otherwise.

Why rejected: this is the bug. Convenience is producing wrong canonical ownership and leaking cleanup debt into downstream ADRs.

Alternative 2: Let each product repo solve venue choice locally

Description: treat venue selection as a repo-specific concern handled ad hoc in Gremlin, joelclaw, or elsewhere.

Why rejected: venue selection is a network-wide operator concern. Local fixes do not prevent the same wrong-default bug from reappearing elsewhere.

Alternative 3: Allow multi-venue duplicate hosting as a normal steady state

Description: let the same piece live on multiple public venues unless someone cleans it up manually.

Why rejected: that destroys canonical ownership, splits metadata responsibility, and makes migration indistinguishable from drift.

References

• skills/content-publish/SKILL.md
• skills/joelclaw-web/SKILL.md
• ~/.joelclaw/TOOLS.md
• ~/Vault/docs/decisions/0168-convex-canonical-content-lifecycle.md
• ~/Code/badass-courses/gremlin/docs/adr/0057-launchd-tutorial-and-imported-article-boundaries.md
• https://joelclaw.com/cool/agent-cantrips-zero-cost-primitives-wizard-frame