What ships next

storing the flag on the content type document.

content type names stop being the stable identity for content. If types are ever keyed by id with a mutable display name, this moves to that id.

documenting the erasure limitation and relying on operators to respect it; tombstone-and-rebuild; crypto-shredding.

crypto-shredding gets built. Then the restriction can be lifted for types that use it.

matching last-write-wins everywhere for API consistency.

returning raw events from the history endpoint, or adding an event-type discriminator to VersionResponse.

deriving the document's timestamps from Marten's IEvent.Timestamp at rebuild time; tolerating the drift.

endpoints appending events and storing documents themselves.

the obvious version of the test.

picking one mechanism for everyone, and letting an operator change mode freely.

If content turns out to hold personal data in the ordinary case rather than the exceptional one, the default is backwards: CryptoShred should be the default and Delete the opt-out. The signal to watch is what customers actually model in their first content type.

The obvious alternative, and the one the issue suggested: keep creating the user and carry an EmailVerified flag, then refuse login (or issue a restricted session) until it is set. That was rejected.

If the address ever stops being the join key, if external sign-in matched on a provider subject id recorded at first link instead, then a flag on User would be enough and the pending row would be ceremony. That is a better design for the external providers anyway (an address can change hands), and if it is ever built, this decision is the one to revisit.

the database-first backend shape. No PostgREST-style layer that maps HTTP straight onto SQL, no per-end-user Postgres role, no row-level security carrying business rules, and no browser holding a database connection.

If BarakoCMS ever grows a path where an untrusted client talks to Postgres directly (a realtime subscription, a published read replica, an embedded SQL surface for customers) then the database is the only boundary that exists on that path and the answer flips. The signal to watch is a feature request for direct data access that does not go through the API.

Leaving it derived, which is what the admin does today: a draft with a non-null ScheduledPublishAt is shown as scheduled by whoever is looking at it. That keeps the write path and the sweeper untouched and needs no migration, and it was the cheaper answer.

Writing the client by hand, which is where this started. It reads well and it drifts, and every module author has to be talked into contributing to it. Also ruled out: generating the whole thing, which produces one ApiClient class with every method on it and none of the ergonomics, and is the reason "generated clients are unpleasant" is a fair objection to the naive version of this.

A version segment in the URL (/api/v1/public), a version header, or a version query parameter. FastEndpoints supports all three and the issue named the URL form as the most legible and the easiest to cache, which is true.

A second consumer class with a long upgrade cycle, such as a native app store review queue, that cannot take a breaking change on the notice window and cannot pin the package version it talks to. If that appears, the door is still open: adding a v2 prefix later breaks nothing, while removing one that exists would.

leaving document types on last-write-wins indefinitely, which is what D3 accepted as an interim state; adding this after the 4.0 tag.

the 3.x upgrade path stops mattering, in which case the flag defaults to true immediately and there is no interim.

storing money as { "amount": 1200, "currency": "PHP" }.

a single field genuinely has to carry its own currency and a sibling field cannot express it. No requirement seen so far needs that.

inviting outside module authors while the only route to a projection is a hook we have announced we are deleting; changing an extension point without a deprecation window; treating MODULES.md as covering the module contract when it covers only part of it.

modules stop being a supported extension point and become an internal implementation detail, in which case none of this is owed to anybody.

a first-party Temporal module; a second durable execution engine shipped in core alongside the runner and the queue; wholesale replacement of the runner by a module, as opposed to per-definition routing; a workflow definition that can express iteration or recursion; treating Temporal Cloud as a supported deployment target for anything BaryoDev ships.

workflow definitions stop being documents and become code that developers write, compile and deploy. Then output binding, versioning and determinism replay all become real problems rather than avoided ones, and the calculus inverts completely. Also wrong if a single deployment ever needs concurrent runs at a volume where a Postgres-polling runner cannot keep up, which is a different argument from any made here and should be made with numbers.

Brew plugins. Business rules in the renderer. A console screen that only one deployment can use. Modules written for something a workflow already does.

Positioning this as a self-hosting product. That is a smaller market and a weaker argument, and it is not even accurate. The position is that you own the software and choose how much of the operating you want to do.

Per-site forks of barakoPress. press.config.ts literals for identity. Site specific code in a client repository. A module for something a workflow can do.

A site that cannot be expressed as blocks and settings without bending the block model out of shape. rckoronadal.org, baryo.dev and barakocms.com are the three tests (#722); if one of them needs site code, the ladder needs another rung, not an exception.

A cloud target whose deploy cannot be driven from its own CLI without BaryoVM holding a long-lived credential. That target stays the cloud pipeline's job.

A module or client needing an engine file under MIT to be usable at all. MPL-2.0 permits use in closed products, so that should not happen; if it does, it is a reason to revisit D24, not to copy the file.

A deployment where units share data rather than processes. That is one tenant with permissions, not several tenants.

The spike in #687 failing on transactional enqueue, conjoined tenancy or migrations. Then the seams stay and the implementation stays ours.