feat(api-headless-cms): simple content entries

[brunozoric]

Changes

Adds simple content entries — a content entry with the revision and publishing dimensions
removed and the meta-field envelope cut to what is actually needed. Base code only: five operations
reached through code, no GraphQL, no admin UI.

A simple entry is still a normal CMS entry — same CmsModel, same storage operations, same table.
Nothing in the api-headless-cms-* storage packages changes. That was the design constraint, and
it is what makes the entry shape the interesting part of this PR.

The shape

ISimpleCmsEntry has eleven fields: seven carry identity and payload, four exist only because the
storage operations read them and are pinned to constants.

Identity / payload	id, entryId, tenant, modelId, values, createdOn, createdBy
Pinned	version: 1, status: "draft", locked: false, expiresAt: null

26 of the 28 entry- and revision-level meta fields are gone; createdOn and createdBy are the two
that survive. The field list was derived by auditing what each backend actually reads off the entry —
tenant because createBasePartitionKey throws without it, version because it feeds
REV#${zeroPad(version)}, modelId because of the DynamoDB GSI key, id because the key builders
run parseIdentifier over it.

The invariant

A simple entry is always a single unpublished draft — never published, never locked. Enforced
four ways, because a comment would not be enough:

1. Literal types — assigning another value does not compile.
2. readonly — reassigning one does not compile either.
3. assertSimpleEntryInvariants in both write repositories, so nothing reaches storage without
   passing it, whether the caller used CRUD or resolved a use case straight from the container.
4. assertRegularModel on the mutating regular repositories, so publishEntry and friends refuse a
   simple model outright.

The five operations

simpleCreateEntry, simpleUpdateEntry, simpleGetEntry, simpleListEntries,
simpleDeleteEntry — on the HeadlessCms facade, and as use cases via
exports/api/cms/simpleEntry.js. Every use case returns a Result and never throws for an expected
failure; getSimpleEntry returns SimpleEntryNotFoundError rather than null. Update changes only
values, creates no second revision, and has no savedOn/modifiedOn to refresh. Delete is
permanent — no bin.

contentEntry/ has 29 slices; this has five. No publish, unpublish, republish,
createRevisionFrom, bin operations, or singleton variants.

A model opts in with a tag

model.tags already exists, so this needs no type or model-builder change — .tags([SIMPLE_MODEL_TAG])
is the whole designation. It guards both directions: simple operations refuse an untagged model,
and the twelve mutating regular repositories refuse a tagged one. The ten read-only regular
repositories are deliberately left alone, so a simple entry stays readable through getEntry and
listEntries.

Changes to existing code — the review-worthy part

• Twelve mutating contentEntry repositories get one assertRegularModel(model) line. Landed in
  one commit on purpose: a partial rollout leaves exactly the gaps the guard exists to close.
  MoveEntryToBinRepository and DeleteEntryRevisionRepository take an inline object param, so the
  call sits after the destructure rather than first.
• New EntryDataProcessor (features/contentEntry/entryDataProcessor/) wraps entry validation
  and reference-field mapping behind DI, so data factories stop importing from ~/crud/.
  CreateEntryDataFactory uses it and loses its CmsContext dependency. The other four factories
  still import directly and can migrate separately.
• cleanInputValues extracted out of CreateEntryDataFactory so both factories share one copy.
• HeadlessCms now also extends ICmsSimpleEntryContext — a public type addition.

Two things worth knowing

Two items per entry, not one. SK = REV#0001 and SK = L. The L item cannot be dropped —
list reads the latest-item partition, so an entry without it would be invisible. The saving here is
envelope size, not item count.

sort is not string[]. It is restricted to id, createdOn and values.*. A simple model
gets its own OpenSearch index, so every dropped meta field is unmapped there and sorting on one
(savedOn_DESC, say) fails at query time. The type turns that into a compile error.

Listing must pin latest: true, and the backends disagree about that. OpenSearch requires
where.latest or where.published and deliberately refuses to default it — createInitialQuery
throws OPENSEARCH_UNSUPPORTED_QUERY, on the grounds that defaulting invites user error. DynamoDB
quietly defaults instead (const type = initialWhere.published ? "P" : "L"). So a list path that
passes neither works on one backend and throws on the other. ListSimpleEntriesRepository pins
latest: true — correct for a simple entry, which has one revision that is always latest and never
published — and spreads into a fresh object, because both backends delete those keys from whatever
they are handed. Worth knowing for anyone adding another list path.

Not in this PR

• No domain events. Use cases check AccessControl but publish nothing. Combined with no GraphQL
  layer, a simple entry write currently has no hook at all — anything needing to react to one has
  to add events to these slices first. Deliberate, and recorded in the docs rather than left implicit.
• No GraphQL, no admin UI, no migration for existing entries, no converting a model between
  regular and simple.

Note on branch contents

The branch also carries docs: add activity log design and inconsistency review, which is unrelated
to this feature — docs only, under docs/.bruno/. Say the word and I will strip it out.

How Has This Been Tested?

76 new tests across six files. The full package suite passes on every reachable backend at
the same totals — 996 passed, 16 skipped, 0 failed — against a 920 baseline:

Backend	Command	Result	Duration
DynamoDB	yarn test	996 / 0	412s
SQL	yarn test:sql	996 / 0	264s
Search-backed	yarn test:os	996 / 0	686s

Identical totals on all three, taken after the OpenSearch fix.

• Unit — __tests__/features/simpleContentEntries/: data factory (the produced shape, the pinned
  values, id format, defaults, that no meta field leaks), read path, write path, both model guards,
  the invariant guard, and the CRUD surface.
• Storage-backed — __tests__/storageOperations/simpleEntries.test.ts runs the use cases against
  a real backend: one revision per entry, readable as the latest revision, no dropped meta field
  persisted, update creates no second revision, delete leaves nothing.
• Guard wiring is asserted from disk, not hardcoded — the test walks contentEntry/ for
  *Repository.ts, so adding a mutating repository without the guard fails the suite. AGENTS.md notes
  two transports have shipped unwired with green per-transport tests; this is that check.
• Export surface is asserted to resolve, so a rotted re-export path fails here rather than in a
  consumer package.

Verified per-commit with yarn check, npx oxlint, npx oxfmt --check, yarn adio,
yarn check-ts-configs and yarn build.

The storage-backed suite passes on every backend that is reachable:

Backend	Selected by	Integration
DynamoDB	default / WEBINY_STORAGE=ddb	9 / 9
Search-backed (OpenSearch)	yarn test:os — also test:es, same package	9 / 9
SQL	WEBINY_STORAGE=sql / yarn test:sql	9 / 9
pg-os	yarn test:pg:os	not reachable — see below

Note that test:es and test:os select the same package (api-headless-cms-ddb-es carries both
keywords); Elasticsearch is no longer used, so there is one search-backed backend, not two.

Because a storage suite skips silently and still exits 0 without a flag, I confirmed the tests
are actually live by breaking an assertion and checking each backend fails. That is how the one
storage divergence surfaced: DynamoDB writes exactly the eleven declared fields, SQL writes
thirteen — the eleven plus isLatest and isPublished. Those are not inputs we supply, and they
reflect a modelling difference rather than extra state: DynamoDB duplicates the record per role and
puts the role in the sort key (REV#0001 / L / P), so a simple entry is two items, while SQL
keeps one row per revision and marks the roles with columns, so a simple entry is one row. Both
columns derive from status, which the shape pins. The test pins the persisted field set per backend
so a third extra cannot appear unnoticed.

Running against OpenSearch caught a real bug

Worth stating plainly, because it is the reason this PR is in better shape than the ddb/sql runs
suggested: simpleListEntries was broken on the search-backed backend and every ddb and sql run
was green throughout. It threw Cannot call Elasticsearch query when not setting "published" or "latest". Fixed as described above.

The gap was in the tests as much as the code — the integration suite covered revisions, latest-revision
reads and delete, all of which are DynamoDB paths even on the search-backed backend, and never
listed. It now has list and cursor-pagination tests with a bounded retry, since OpenSearch indexes
near-real-time and DdbEsListEntries silently returns an empty page on index_not_found_exception,
so a naive assertion could pass while proving nothing.

Remaining gap: pg-os

pg-os cannot be exercised through the test preset mechanism at all. WEBINY_STORAGE=pg-os
registers no CMS entry storage operations (No registration found for Cms/Entry/CreateEntryStorageOperation), because PgOsCreateEntry is a decorator over an inner
implementation and needs a base backend registered underneath — but the preset loop selects exactly
one storage-operations package and breaks. pg-os,sql fails identically, and sql,pg-os passes only
because SQL is what gets selected. This is a test-infrastructure limitation independent of this
feature: no CMS feature is currently verifiable on pg-os.

Documentation

• src/features/simpleContentEntries/DEVELOPERS.md — the shape and why each field is there, the
  invariant and its four enforcement points, each use case with its signature, access check, storage
  operation and failure modes, slice anatomy, the guards, how to declare a simple model, what lands
  in storage per backend, and what is deliberately absent.
• docs/.bruno/2026-09-10-simple-content-entries-{design,specs,plans} — the design, spec and
  plan, including the Phase 0 cross-backend field audit and its correction.

No changes needed on the documentation website: there is no public API surface yet — no GraphQL, and
the operations are reached through code. Worth a changelog entry once a consumer ships on top of it.

🤖 Generated with Claude Code

[github-actions]

🚓 Slop Cop

⚠️ 3 thing(s) worth a look before merging.

Coherent, well-tested feature PR; main issue is an author-acknowledged unrelated docs commit bundled into the branch, plus minor commit-history noise.

🚨 Should this be in the PR?

🟠 Medium — Branch carries an unrelated docs commit (activity-log inconsistency review)

The PR description itself flags that docs: add activity log design and inconsistency review (docs/.bruno/activity-log.md and activity-log-inconsistencies.md, ~726 lines) is unrelated to simple content entries and offers to strip it out. This is a footprint mismatch the author already acknowledged but did not resolve before opening the PR.

🟡 Low — History contains a revert-of-a-revert / cancel-out commit pair

Commit list includes fix(webiny): drop the orphaned event-handler-core dependency followed later by Revert "fix(webiny): drop the orphaned event-handler-core dependency", plus a chore: rebuild webiny package and chore: yarn lock — noise the author's own handoff doc says should be tidied before merge (packages/webiny/package.json net change is only +2/-1, consistent with this being resolved, but the noisy commits remain in history).

📏 Code-style rule checks

🟡 Low — Comment missing trailing period

packages/api-headless-cms/tests/features/simpleContentEntries/writePath.test.ts and readPath.test.ts use inline block comments like // Simulate a record that somehow became published and locked in storage. (this one is fine) but some short inline comments in crud.test.ts (e.g. // The re-exported abstraction must be the same token...) span multiple sentences without periods on each line — minor, low-confidence, so flagged only as low priority per comments.md.

_{Automated, non-blocking heads-up from an LLM. It can be wrong — use your judgment. Regenerates on every push.}