feat(publisher): resolve tokens in loop cell filters

[borskyj-symph]

What changed

A loop's cell filter took a literal value, so a filtered loop was unusable on an entry template. The one value that has to differ per rendered row was typed once into a template every row shares, which meant a course page could not list its own dates.

cellValue now accepts the same {...} tokens as any text binding. resolveFilterTokens in server/publish/loopPrefetch.ts interpolates it against the render's TemplateRenderDataContext before the source fetches, so the loop sources and cellFilterSql stay unaware that tokens exist.

A filter that cannot produce a usable value empties the loop instead of unfiltering it. parseCellFilter reads a blank cellValue as "not configured yet" and lists the whole table, which is right for a loop mid-edit and wrong on a published entry route, where it would spill every other row's data onto the page.

Two separate things make a value unusable, and both empty the loop.

A token that did not resolve is the obvious one, and the check runs per token rather than per string. interpolateTokensWithStatus reports whether any token failed, so a value mixing text with a token aborts as well. course-{currentEntry.missing} interpolates to course-, which is not blank, and with isNot that matches nearly every row in the table.

A value that resolved to nothing is the other. A token whose stored cell holds only whitespace is not "missing", so the per-token status stays clean, and an author-written empty fallback {a.b|} fires and counts as resolved for the same reason. Both leave the filter blank, so both abort. A fallback with actual text counts as resolved and is used. A malformed or unknown-source token still emits verbatim and is not treated as a failure.

The abort respects the operator. isTrue, isFalse, isSet and isEmpty never read cellValue, so an unusable value those operators ignore leaves the loop querying normally. cellFilterUsesValue resolves the raw stored operator exactly as parseCellFilter does, so the two cannot disagree.

The render context is threaded through every path that has one: public pages, branch preview, branch review, the Content workspace row preview, and the editor preview runtime. The public paths build the page and site frames themselves before the prefetch, because publishPage fills those frames too late for a filter to read them, and a {page.title} filter would otherwise empty the loop. What publishPage receives is unchanged, so its permalink route fallback still behaves as before. The hole endpoint builds a context with an empty entry stack, so {page.*} and {route.*} filters resolve inside a hole and a {currentEntry.*} one renders empty.

A {route.query.*} filter makes the loop request-dependent. checkInlineTokens in dynamicDetection.ts walks strings nested inside object and array props, so it sees filters.cellValue and defers the loop to a Layer C hole. The hole endpoint keys on the originating page's full query, so two visitors asking for different values never share a cache slot. Only route.query is request-dependent; {currentEntry.*}, {page.*}, {site.*}, route.path and route.slug all stay in the baked page.

What this does not do

A loop nested inside another loop cannot filter on the outer loop's current item. prefetchLoopData resolves every loop node once, keyed by node id, against one shared context, and the per-iteration entry stack is built later by the renderer. An inner {currentEntry.*} filter therefore reads the page's entry on every iteration of the outer loop.

A filter cannot mix {route.query.*} with {currentEntry.*}. The query token defers the loop to a hole, and a hole is fetched by node id with no entry in scope, so the entry half resolves to nothing and the loop renders empty. "{currentEntry.slug}-{route.query.region}" on a course page is the shape that hits this. Making it work needs the hole endpoint to resolve the entry from the request path, which is a separate change.

Both limitations are in docs/features/loops.md. The query and entry mix is tracked as #548.

Impact

An entry template can now carry a filtered loop, which is what lets one template replace a set of hand-maintained pages. A filter without tokens behaves exactly as before, and there is no schema migration.

Three editing surfaces differ, and the difference is the entry each one has in scope. The canvas sends the filter value to the loop-preview endpoint verbatim, matches nothing, and falls back to synthetic items so the loop body stays visible while it is laid out. Preview posts the canvas context to the runtime preview endpoint, which does resolve, against a real published row when the table has one and against a synthetic sample row when it does not. The Content workspace row preview has the edited row in scope and resolves exactly as the published page does.

Verification

• bun test src/__tests__/server/loopPrefetch.test.ts: 18 pass. The token cases cover a resolved filter, partial resolution with isNot, a whitespace-only resolve, an empty |fallback, a fired |fallback, a valueless operator with an unusable value, an unresolved filter rendering empty, a plain value left untouched, and {site.name} resolving on the public path. The two blank-value tests were confirmed to fail against the previous commit.
• bun test across dynamic detection, cell filter, loop SQL safety, public rendering, hole routing and the CMS runtime handlers: 135, 120 and 99 pass respectively. One run of apiSecurityBoundary timed out at 5000ms under parallel load and passes when that file runs alone. It touches nothing in this branch.
• bunx tsc -b
• bunx eslint on the changed files

🤖 Generated with Claude Code