WEB / WEB-20.S02

BFF, SSR, hydration and server actions

Separate server/client data and operation boundaries.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

SSR view

Client ready
The client requested note-A’s initial SSR view; public HTML and initial title have not yet been produced by the server.
Client view
SSR view request ready
BFF / entry
Not evaluated yet
Public catalog
Fixed public record ready
Server received request
The server received the ordinary request; resource permission and current context still need separate evaluation.
Client view
SSR view request ready
BFF / entry
SSR request arrived; data gate pending
Public catalog
Fixed public record ready
Local gate decision
Current verified actor and object/action permission passed; the ordinary catalog read is ready.
Client view
SSR view request ready
BFF / entry
Current actor/object/action accepted; catalog read ready
Public catalog
Fixed public record ready
Catalog received request
The catalog received only the ordinary note-A read; its fixed public title reply is ready, without claiming a real network result.
Client view
SSR view request ready
BFF / entry
Current actor/object/action accepted; catalog read ready
Public catalog
Request arrived; public reply ready
Server received record
The server received the supplied public catalog title record; its local projection has not yet been constructed.
Client view
SSR view request ready
BFF / entry
Public record arrived; projection pending
Public catalog
Request arrived; public reply ready
Local projection
The BFF selected only title and locally prepared the fixed HTML text representation and the same initial DTO.
Client view
SSR view request ready
BFF / entry
Title selected; HTML/initial DTO ready
Public catalog
Request arrived; public reply ready
Public view arrived
The client received the Tea & Bread public reply; message arrival changed only its record and did not transfer server permission.
Client view
Public HTML/DTO arrived; initial view pending
BFF / entry
Title selected; HTML/initial DTO ready
Public catalog
Request arrived; public reply ready
Local view record
The client matched its initial view to the same DTO title; finite data equality is not actual React hydration.
Client view
Initial title matched; no actual hydration
BFF / entry
Title selected; HTML/initial DTO ready
Public catalog
Request arrived; public reply ready

Action read

Client ready
The client prepared a readTitle action intent; a previously rendered page is no permission document for the current operation.
Client view
readTitle action intent ready
BFF / entry
Not evaluated yet
Public catalog
Fixed public record ready
Server received request
The server received the ordinary request; resource permission and current context still need separate evaluation.
Client view
readTitle action intent ready
BFF / entry
Action intent arrived; current gate pending
Public catalog
Fixed public record ready
Local gate decision
Current verified actor and object/action permission passed; the ordinary catalog read is ready.
Client view
readTitle action intent ready
BFF / entry
Current actor/object/action accepted; catalog read ready
Public catalog
Fixed public record ready
Catalog received request
The catalog received only the ordinary note-A read; its fixed public title reply is ready, without claiming a real network result.
Client view
readTitle action intent ready
BFF / entry
Current actor/object/action accepted; catalog read ready
Public catalog
Request arrived; public reply ready
Server received record
The server received the supplied public catalog title record; its local projection has not yet been constructed.
Client view
readTitle action intent ready
BFF / entry
Public record arrived; projection pending
Public catalog
Request arrived; public reply ready
Local projection
The action prepared JSON for only the public title projection; server-only context was not added to the client result.
Client view
readTitle action intent ready
BFF / entry
Title selected; action JSON reply ready
Public catalog
Request arrived; public reply ready
Public view arrived
The client received the Tea & Bread public reply; message arrival changed only its record and did not transfer server permission.
Client view
Action title JSON arrived: Tea & Bread
BFF / entry
Title selected; action JSON reply ready
Public catalog
Request arrived; public reply ready
Local view record
The client completed its title record for the ordinary action result; a later action needs its own current permission decision.
Client view
Action result recorded locally
BFF / entry
Title selected; action JSON reply ready
Public catalog
Request arrived; public reply ready

Entry denied

Client ready
The client prepared a readTitle action intent; a previously rendered page is no permission document for the current operation.
Client view
readTitle action intent ready
BFF / entry
Not evaluated yet
Public catalog
Fixed public record ready
Server received request
The server received the ordinary request; resource permission and current context still need separate evaluation.
Client view
readTitle action intent ready
BFF / entry
Action intent arrived; current gate pending
Public catalog
Fixed public record ready
Local gate decision
Despite an earlier page render, current action permission is denied; no catalog dispatch or result body is prepared.
Client view
readTitle action intent ready
BFF / entry
Current action permission known ret; denial ready; no body
Public catalog
Fixed public record ready
Client received denial
The client received only the denial decision; no catalog dispatch, public title body, delivery or write occurred.
Client view
Denial arrived; no body/delivery/write
BFF / entry
Current action permission known ret; denial ready; no body
Public catalog
Fixed public record ready

Context missing

Client ready
The client prepared a readTitle action intent; a previously rendered page is no permission document for the current operation.
Client view
readTitle action intent ready
BFF / entry
Not evaluated yet
Public catalog
Fixed public record ready
Server received request
The server received the ordinary request; resource permission and current context still need separate evaluation.
Client view
readTitle action intent ready
BFF / entry
Action intent arrived; current gate pending
Public catalog
Fixed public record ready
Local gate decision
Current actor evidence is missing; an earlier page render cannot replace identity, and no dispatch or result body occurs.
Client view
readTitle action intent ready
BFF / entry
Current actor evidence unknown; denial ready; no body
Public catalog
Fixed public record ready
Client received denial
The client received only the denial decision; no catalog dispatch, public title body, delivery or write occurred.
Client view
Denial arrived; no body/delivery/write
BFF / entry
Current actor evidence unknown; denial ready; no body
Public catalog
Fixed public record ready

ACTORS · STATE · DATA FLOW

SPA, BFF and SSR do different jobs

A SPA can manage client navigation and view state; a BFF is a server adapter tailored to that interface. SSR constructs the initial HTML on the server. These roles may share a deployment without being mandatory names for one another. In public notes, the BFF selects only a title from the catalog record; mobile and web interfaces can need different projections. Shared domain permission remains part of the relevant service contract.

A BFF adds a network hop, failure boundary and context propagation decision. The browser actor and BFF service identity are different subjects. A service receiving a BFF call explicitly defines which business context and user authority it accepts. Here context-A is a harmless alias and no credential is transmitted. The BFF pattern mandates no single OAuth storage arrangement; a framework or GraphQL choice does not remove business permission.

When does server-produced data become public?

The server record contains title, internalReviewState and serverOnlyContextAlias. The latter two are not secrets in this example, but remain outside the public contract. An explicit public projection selects {title: Tea & Bread}. Serializing the complete record and hiding fields in the UI does not provide the same boundary: a field delivered to the browser has become browser data. Server-side computation does not make delivered props private again.

The fixed SSR output in an HTML text context is <h1>Tea & Bread</h1>. The separate JSON projection carries {"title":"Tea & Bread"} as data. HTML text escaping and JSON serialization follow different format rules; JSON.stringify alone is not an encoder for every HTML or inline-script context. No inline script is used here. Hydration is a distinct stage expecting the initial client view to match the server title; React hydrateRoot illustrates this behavior rather than being mandatory for every SSR architecture.

A server action is a new entry point

A previously rendered page is not evidence of current permission for a later operation. In modern frameworks, a client-invoked server function or action crosses the server boundary again with its own input and identity context. The Next.js guide makes this distinction through authentication and object permission inside the action. An action identifier, UI button or visibility in a client bundle is not a permission document.

The artifact’s readTitle action is an ordinary public-read contract; no real Next action endpoint is installed. Verified actor, current action permission and current object permission are separate supplied gates. PagePreviouslyRendered is true in every row, yet a denied action or missing context produces no body. A write action adds server-owned transitions and current domain conditions to these gates; the read example’s write=false outcome is not a general test of mutation safety.

Read every scenario without motion

Action denied

A page was previously rendered
The entry-denied row records pagePreviouslyRendered=true. This describes a previous render, not the current conditions for a new action.
Entry / UI
pagePreviouslyRendered=true
Current decision
mode=action
Trust boundary
Current decision not inspected yet
Actor and object predicates are positive
VerifiedActorDeclared=true and currentObjectPermissionDeclared=true are supplied. These fields do not establish action permission.
Entry / UI
verifiedActorDeclared=true
Current decision
currentObjectPermissionDeclared=true
Trust boundary
Action is required separately
The current action decision is denial
CurrentActionPermissionDeclared=false denies this new entry; a previous render cannot turn that current decision into true.
Entry / UI
currentActionPermissionDeclared=false
Current decision
pagePreviouslyRendered=true
Trust boundary
Previous render != current action permission
There is no dispatch or body
ExpectedDispatch=false, expectedDelivery=false and expectedBody=null keep this row from borrowing another entry’s successful title outcome.
Entry / UI
expectedDispatch=false
Current decision
expectedBody=null
Trust boundary
Stopped at action entry
A button or ID does not grant permission
ClientButtonIsPermission=false and actionIdIsPermission=false prevent treating a UI control or known action identifier as a server permission decision.
Entry / UI
clientButtonIsPermission=false
Current decision
actionIdIsPermission=false
Trust boundary
Decision required at the server entry
Do not expand admission scope
RenderAdmissionCoversAction=false summarizes the boundary. Ask which entry admitted which action at which time.
Entry / UI
mode=action / action permission=false
Current decision
renderAdmissionCoversAction=false
Trust boundary
Each entry uses its own conditions

Public projection

The server record is wider
ServerRecord includes title, internalReviewState and serverOnlyContextAlias. Server-side existence does not require client delivery of every field.
Entry / UI
serverRecord.title=Tea & Bread
Current decision
serverOnlyContextAlias=context-A
Trust boundary
Public selection not inspected yet
The public field is selected explicitly
PublicProjection contains only title; internalReviewState and serverOnlyContextAlias are excluded from this public DTO.
Entry / UI
publicProjection: title only
Current decision
title=Tea & Bread
Trust boundary
Narrow DTO
JSON is a separate representation
SerializedPublicJSON carries title in JSON format. Serialization does not keep delivered data server-only; the client can read it.
Entry / UI
serialized JSON: title only
Current decision
deliveredDataRemainsServerOnly=false
Trust boundary
Serialization does not provide secrecy
HTML text uses a different context
PublicHTML places Tea & Bread inside h1. HTML text-context encoding is not the same operation as JSON string escaping.
Entry / UI
htmlTextContext=true
Current decision
inlineScriptUsed=false
Trust boundary
Enclosing context matters separately
JSON is not universal HTML safety
JSONEncodingIsUniversalHTMLSafety=false prevents generalizing this fixed text example to every enclosing context.
Entry / UI
JSONEncodingIsUniversalHTMLSafety=false
Current decision
publicHTML=<h1>Tea & Bread</h1>
Trust boundary
Encoding must fit the context
A delivered title is client data
Server production or selection from a server-only record does not hide a delivered title from the client. The boundary lies in fields never delivered.
Entry / UI
publicProjection.title=Tea & Bread
Current decision
serverOnlyContextAlias excluded
Trust boundary
Undelivered and delivered fields differ

ASSUMPTION · BOUNDARY · CONTROL

Broken assumption: server production stays private

The Red review first asks what the record loses when projected. Displaying Tea & Bread needs neither an internal review field nor a service context alias. Including these fields in serialization crosses the data boundary even if the UI does not show them. Both compared objects are entirely harmless here; there is no extraction of real secrets or movement into another system.

The hydration mismatch row pairs server title Tea & Bread with client title Book Club and shows a broken initial-view contract. Local string equality is not an actual DOM hydration result. A framework’s recoverable error behavior does not imply automatic repair of every attribute. View consistency remains separate from the claim that authorization worked; matching titles authenticate no actor.

Broken assumption: the entry point inherits an earlier gate

A page permission decision covers that render request at that moment. Action-read and entry-denied share pagePreviouslyRendered but have different current action permission. The second row sends no catalog message. Missing current context is not reconstructed by guessing identity from old page state; unknown evidence stays visibly null and delivery stops.

The review does not call removing a UI button a server-side fix. The required control is a server decision about this operation’s subject, object, action and current context. Impact is measured using dispatch and body observed at that boundary. For action security, this lesson supplies inert acceptance/denial fixtures; it explains no endpoint invocation recipe, action discovery, identifier collection or framework vulnerability reproduction.

Read every scenario without motion

Actor unknown

The earlier render still exists
This record is produced by the local JSON serializer, HTML-context encoder and initial-title comparison; action-gate fields are selected policy inputs. It measures no actual React hydration or server-framework logs. The context-missing row still has pagePreviouslyRendered=true. That earlier render does not establish the current action actor.
Render record
pagePreviouslyRendered=true
Context / initial view
mode=action
Evidence boundary
Current actor not inspected yet
The actor predicate is null
VerifiedActorDeclared=null leaves verified actor evidence unknown. Null is not renamed as either false or true.
Render record
verifiedActorDeclared=null
Context / initial view
currentActionPermissionDeclared=true
Evidence boundary
Actor knowledge UNKNOWN
Object true does not supply a missing actor
CurrentObjectPermissionDeclared=true is a separate input. Positive permission predicates do not create verified actor context when it is missing.
Render record
currentObjectPermissionDeclared=true
Context / initial view
verifiedActorDeclared=null
Evidence boundary
Inputs cannot substitute for one another
This entry does not dispatch
ExpectedDispatch=false and expectedBody=null fail closed without establishing a definitive rejection by an identity service; evidence is missing here.
Render record
expectedDispatch=false
Context / initial view
expectedBody=null
Evidence boundary
Stopped for missing context
Denial and unknown differ
Entry-denied has action=false while context-missing has actor=null. Their equal no-delivery outcomes have different reasons.
Render record
actor=null / action=true
Context / initial view
delivery=false
Evidence boundary
Missing actor evidence
Inspect current context for the same entry
The needed observation is actor context for this new action call. Earlier HTML, a button or another request’s success cannot supply it.
Render record
current actor evidence required
Context / initial view
renderAdmissionCoversAction=false
Evidence boundary
Evidence must belong to the current entry

Initial title

The server initial title is specified
This record is produced by the local JSON serializer, HTML-context encoder and initial-title comparison; action-gate fields are selected policy inputs. It measures no actual React hydration or server-framework logs. HydrationLedger specifies serverInitialTitle=Tea & Bread. This is an initial-view input rather than a permission decision.
Render record
serverInitialTitle=Tea & Bread
Context / initial view
Client initial title not inspected yet
Evidence boundary
Initial-view input
Equal titles give the expected match
The row with clientInitialTitle=Tea & Bread has expectedMatch=true. This shows title consistency rather than real browser handler attachment.
Render record
server=Tea & Bread / client=Tea & Bread
Context / initial view
expectedMatch=true
Evidence boundary
Consistency observed
The other row has a different title
The row with clientInitialTitle=Book Club has expectedMatch=false. One matching row cannot make another row match.
Render record
server=Tea & Bread / client=Book Club
Context / initial view
expectedMatch=false
Evidence boundary
Rows remain separate
The framework was not executed
ActualHydration=false and actualFramework=false prevent presenting a fixed title comparison as a React hydration runtime outcome.
Render record
actualHydration=false
Context / initial view
actualFramework=false
Evidence boundary
Expected model consistency
View consistency does not solve private-cache boundaries
Private projections require viewer-context partitioning. Matching titles do not authorize reuse of another viewer’s representation.
Render record
viewerContextPartitionRequiredForPrivateProjection=true
Context / initial view
actualPrivateCache=false
Evidence boundary
View and privacy scope differ
Report the observed scope
Report the initial-title comparison alongside unexecuted framework scope. UI, permission and actual hydration require separate observations.
Render record
one expectedMatch=true / one=false
Context / initial view
actualBrowser=false
Evidence boundary
Evidence establishes title consistency only

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Minimal projection and matching initial state

This record is produced by the local JSON serializer, HTML-context encoder and initial-title comparison; action-gate fields are selected policy inputs. It measures no actual React hydration or server-framework logs. The Blue contract separates the server record from the public DTO. Build the public title projection with allowlisted fields rather than a generic spread or full-record serialization. Real systems using private projections need viewer-context cache partitioning; this public-title example implements no private cache. Finding a cached projection belonging to another actor does not replace current permission.

Create SSR text with its HTML-context encoder and JSON with its own serializer. Deriving the initial client state from the same approved DTO makes title consistency explainable. Keep the byte outputs of different formats separate and add no inline script to this example. Native observations verify the fixed Tea & Bread projection, JSON roundtrip and text escaping; no actual browser parsing, React attachment or hydration recovery is executed.

A current decision record for each operation

Write the action contract as input schema, verified actor, action permission, object permission and domain conditions. An assumption that the actor already logged in during page rendering does not shorten this list. Missing context means no dispatch; denied permission means no dispatch; an accepted public read produces only a title body. Regression fixtures preserve separate reasons and evidence for these outcomes.

A test must show that a true previous-page flag does not produce a body when current action permission is denied. A successful ordinary read returns only the public projection, excluding internalReviewState and the context alias. The shared reducer retains the previous receiver snapshot during motion and updates it on arrival. This visual evidence is not substituted for testing an action framework’s runtime security. A real application separately checks the contract in its own entry point, session and cache implementation.

NOW APPLY IT TO THE CASE

Does an earlier render decision authorize a new action call?

Atlas displays Tea & Bread through a public projection. Render and action are separate entries; sharing a title does not mean sharing a permission decision.

Which components contribute to the case response? Show where UI, service, platform and external-provider outcomes complete along their respective hops.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

Public projection and entry gate

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations

{
  "profile": {
    "title": "Tea & Bread",
    "resource": "note-A",
    "action": "readTitle",
    "actualFramework": false,
    "actualBrowser": false,
    "actualHydration": false,
    "actualNetwork": false
  },
  "rows": [
    {
      "case": "normal",
      "label": [
        "SSR görünümü",
        "SSR view"
      ],
      "mode": "render",
      "verifiedActorDeclared": true,
      "currentActionPermissionDeclared": true,
      "currentObjectPermissionDeclared": true,
      "pagePreviouslyRendered": true,
      "expectedDelivery": true,
      "expectedDispatch": true,
      "expectedWrite": false,
      "expectedBody": {
        "title": "Tea & Bread"
      }
    },
    {
      "case": "action-read",
      "label": [
        "Action okuma",
        "Action read"
      ],
      "mode": "action",
      "verifiedActorDeclared": true,
      "currentActionPermissionDeclared": true,
      "currentObjectPermissionDeclared": true,
      "pagePreviouslyRendered": true,
      "expectedDelivery": true,
      "expectedDispatch": true,
      "expectedWrite": false,
      "expectedBody": {
        "title": "Tea & Bread"
      }
    },
    {
      "case": "entry-denied",
      "label": [
        "Entry ret",
        "Entry denied"
      ],
      "mode": "action",
      "verifiedActorDeclared": true,
      "currentActionPermissionDeclared": false,
      "currentObjectPermissionDeclared": true,
      "pagePreviouslyRendered": true,
      "expectedDelivery": false,
      "expectedDispatch": false,
      "expectedWrite": false,
      "expectedBody": null
    },
    {
      "case": "context-missing",
      "label": [
        "Context eksik",
        "Context missing"
      ],
      "mode": "action",
      "verifiedActorDeclared": null,
      "currentActionPermissionDeclared": true,
      "currentObjectPermissionDeclared": true,
      "pagePreviouslyRendered": true,
      "expectedDelivery": false,
      "expectedDispatch": false,
      "expectedWrite": false,
      "expectedBody": null
    }
  ],
  "serverRecord": {
    "title": "Tea & Bread",
    "internalReviewState": "draft",
    "serverOnlyContextAlias": "context-A"
  },
  "publicProjection": {
    "title": "Tea & Bread"
  },
  "serializedPublicJSON": "{\"title\":\"Tea & Bread\"}",
  "publicHTML": "<h1>Tea &amp; Bread</h1>",
  "serializationBoundary": {
    "htmlTextContext": true,
    "inlineScriptUsed": false,
    "JSONEncodingIsUniversalHTMLSafety": false
  },
  "hydrationLedger": [
    {
      "serverInitialTitle": "Tea & Bread",
      "clientInitialTitle": "Tea & Bread",
      "expectedMatch": true
    },
    {
      "serverInitialTitle": "Tea & Bread",
      "clientInitialTitle": "Book Club",
      "expectedMatch": false
    }
  ],
  "architecture": {
    "SPA": "client-side view management",
    "BFF": "interface-specific server adapter",
    "SSR": "server creates initial markup",
    "hydration": "client attaches behavior to matching initial markup",
    "serverAction": "separate server entry requiring current gates"
  },
  "cacheBoundary": {
    "viewerContextPartitionRequiredForPrivateProjection": true,
    "actualPrivateCache": false
  },
  "boundaries": {
    "clientButtonIsPermission": false,
    "actionIdIsPermission": false,
    "renderAdmissionCoversAction": false,
    "deliveredDataRemainsServerOnly": false
  }
}

profile: Public note operation and actual framework/browser scope.
rows: Render/action mode, current actor/object/action evidence and no-write outcomes.
serverRecord: Harmless server record; not every field belongs in the public DTO.
publicProjection: The single title field selected for client delivery.
serializedPublicJSON: Byte text of the narrow DTO in separate JSON format.
publicHTML: HTML text-context representation of the fixed title.
serializationBoundary: JSON and HTML encoder scopes; no inline script is used.
hydrationLedger: Server/client initial-title match; not a real React hydration test.
architecture: Separation of SPA/BFF/SSR/hydration/action roles.
cacheBoundary: Viewer partition requirement for private projections; no actual cache.
boundaries: Buttons/action IDs/old renders are not permission; delivered data is client data.

Fixed HTML/JSON and supplied action gates; no real Next, React, browser or server-action endpoint.

Two reality checks

A prop computed on the server stays private.

A field serialized to the client is delivered data; restrict the public projection beforehand.

Page login also proves action permission.

An action is a separate entry point; evaluate the current actor and object/action permission again.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

The page was previously rendered, but currentActionPermissionDeclared=false for the server action. Is it dispatched?

No. There is no dispatch and body=null.
Yes. A rendered page gives a permanent grant for later actions.

Read the explained answer

No. There is no dispatch and body=null. — The entry-denied branch requires current action permission. Having a button or action ID is not permission.

Why are internalReviewState and serverOnlyContextAlias absent from the public JSON/HTML?

Selected lesson artifact fields; teaching example

serverRecord: {"title":"Tea & Bread","internalReviewState":"draft","serverOnlyContextAlias":"context-A"}
publicProjection: {"title":"Tea & Bread"}
serializedPublicJSON: {"title":"Tea & Bread"}
publicHTML: <h1>Tea & Bread</h1>

JSON serialization automatically hides every server field.
An explicit public projection carries title only.

Read the explained answer

An explicit public projection carries title only. — Being on the server does not require serialization of every field. A field delivered to the client is no longer server-only.

Server initial title is Tea & Bread while the client has Book Club. Why is hydration mismatch different from permission, and why is JSON not a universal HTML encoder?

Read the explained answer

Hydration expects initial markup to agree with the client’s initial state; different titles here yield expectedMatch=false. A mismatch neither grants nor removes user/object permission. JSON serialization is a data representation, not safe encoding for inline script or every HTML context. This example uses ordinary HTML-text encoding without inline script. No actual framework, browser or hydration runs.

□ I separated hydration agreement from authorization.

□ I did not treat JSON serialization as a universal HTML encoder.

Open the application console · request / response / browser

Also open request, URL, cookie and DOM examples

Sources and scope

Microsoft Backends for Frontends patternContext and problem; Solution; Problems and considerations: interface tailoring and additional hop
React hydrateRoot referenceReference / hydrateRoot: attach to existing server-rendered HTML; Caveats: initial content consistency and mismatch limits
Next.js Data Security guideData Access Layer: authorization and minimal DTOs; Component-level data access: explicit client props · Mutating Data / Built-in Server Actions Security features; Authentication and authorization: action is a separate entry point
RFC 8259 JSON§7 Strings: quotation/backslash/control escaping; §12 Security Considerations: JSON text is data
OWASP XSS Prevention: output contextsOutput Encoding for HTML Contexts: fixed element text and HTML entities · Output Encoding for JavaScript Contexts: different enclosing-context requirements

YOUR NOTES / THIS BROWSER

BFF, SSR, hydration and server actions

1. Core · Mechanism

SSR view

Action read

Entry denied

Context missing

SPA, BFF and SSR do different jobs

When does server-produced data become public?

A server action is a new entry point

2. Red · Trust & Impact

Action denied

Public projection

Broken assumption: server production stays private

Broken assumption: the entry point inherits an earlier gate

3. Blue · Secure development & defense

Actor unknown

Initial title

Minimal projection and matching initial state

A current decision record for each operation

Does an earlier render decision authorize a new action call?

Two reality checks

The page was previously rendered, but currentActionPermissionDeclared=false for the server action. Is it dispatched?

Why are internalReviewState and serverOnlyContextAlias absent from the public JSON/HTML?

Server initial title is Tea & Bread while the client has Book Club. Why is hydration mismatch different from permission, and why is JSON not a universal HTML encoder?

Sources and scope