[Language] Make server/client directive execution lanes explicit

[cssbruno]

Priority

Medium-high — language predictability, security reviewability, and refactor safety.

Context

Current docs describe lane inference for directives such as g:for and g:if: when an operand comes from server {} data, the directive renders server-side; when it comes from component state/store, the same directive binds a client island.

That design is compact, but the source code does not visibly state where execution happens.

Problem

The same directive spelling can have different execution, runtime, validation, and security behavior depending on where its data source is declared.

Examples of different behavior:

• g:key is accepted but ignored server-side;
• g:else and g:else-if are client-only;
• server expression evaluation failure hides the branch;
• server rows reject components and several client directives;
• moving data from state to server can change execution location without changing the directive.

This makes refactors risky and makes it harder for reviewers, tools, and users to answer: “does this run on the server or in the browser?”

Proposed direction

Make execution ownership explicit in source or in a required surrounding declaration.

Possible directions:

server view {
  <li g:for={item in items}>{item.title}</li>
}

client view {
  <li g:for={item in items}>{item.title}</li>
}

or explicit directive variants. The exact syntax can be designed separately, but the invariant should be: a source diff that changes execution location must show that change directly.

Acceptance criteria

• The language design has an explicit representation of server versus client execution for loops and conditionals.
• Compiler diagnostics identify ambiguous or mixed-lane directives.
• Refactoring data source ownership cannot silently change directive execution location.
• LSP/inspect output reports execution lane for each directive.
• Docs include migration guidance from inferred lanes.
• Tests cover equivalent server/client examples, mixed-lane errors, and old syntax diagnostics.

Related

• Move semantic validation and asset identity planning out of internal/parser #673 — Move semantic validation and asset identity planning out of internal/parser
• Define and enforce the v1 core versus optional product boundaries #677 — Define v1 core versus optional product boundaries