Standalone publishing studio

@citadelfoundation/kit-publishing is designed as a standalone publishing product, not as a Citadel-only admin surface.

Citadel Foundation is one workspace that uses the studio to build:

• citadel.foundation
• docs.citadel.foundation

The same studio should be usable for any other domain workspace without moving canonical content into a hosted control plane.

Local publish procedure

1. Run the studio on localhost.
2. Keep drafts in the local .studio/ directory.
3. Publish only after diff review and confirmation. Publish writes Git-tracked canonical files under content/.

The owner of the domain keeps canonical content. Static builds remain deployable to owner-chosen infrastructure. Workspace configuration, policy, and deploy targets stay portable.

The reusable product is the publishing system itself. Each site or docs project is a workspace running on top of it.

Design direction

The sections below are recommendations for a later shape. They are not steps in the local publish procedure.

Decentralized direction

Decentralization here means owner-controlled storage, portable deployment, and verifiable shared state, not “put every CMS record onchain.”

Recommended split:

• Keep page bodies, media, docs, and structured content offchain in owner-controlled storage.
• Use content-addressed or archival storage such as IPFS or Arweave when distribution or permanence matters.
• Use Sonic for compact, verifiable state that benefits from shared execution.

Sonic fits proofs, not page bodies

Sonic is a good fit for:

• publication registries for release hashes or content identifiers
• publisher approvals and multisig-governed release authorization
• membership entitlements tied to wallets or signer-controlled identities
• attribution or payout settlement based on offchain event batches

Sonic is not the right place for:

• raw markdown or MDX documents
• images and other large media
• private member records such as email addresses
• raw UTM or clickstream analytics

That data is better kept in owner-controlled systems, with only proofs, entitlements, or settlement data written onchain when needed.

Members and attribution

If the studio grows beyond editorial publishing, the clean architecture is:

• membership entitlement on Sonic
• customer relationship and private analytics offchain
• optional onchain settlement for referrals, rewards, or paid access

That keeps the product decentralized in custody and governance without turning the CMS into an onchain database.