Inline code contexts are dynamic, so LINQ throws at runtime and autocompletion cannot work

[woksin]

Found while landing the four inline-code contexts (#61). The contexts now exist and are documented, but their payload members are dynamic — CommandContext.Command, QueryContext.Arguments, RuleContext.Artifact, RuleContext.Value, PolicyContext.Artifact — and dynamic is actively hostile to the code that has to live inside them.

Extension methods do not bind on dynamic, so LINQ fails at runtime

C# resolves extension methods statically; a dynamic receiver skips that lookup entirely. Verified with a minimal repro against .NET 10:

member access ok, count=2
LINQ on dynamic FAILED: RuntimeBinderException
  'System.Collections.Generic.List<Line>' does not contain a definition for 'Sum'
after static assignment, LINQ ok, total=42

So context.Artifact.Lines.Sum(l => l.Amount) compiles and then throws at runtime. The workaround is to assign to a static type first:

List<Line> lines = context.Artifact.Lines;   // now LINQ binds
var total = lines.Sum(l => l.Amount);

That works, but nothing about the API suggests it, and the failure arrives at runtime in a validation rule rather than at author time.

Why this matters more than it looks — measured

Measuring a large production Cratis application (Ada) against the current language:

• 92 whole-command validation rules will land as inline code no matter what the language does. 43 of those 92 call a method or use LINQ — precisely the shape that fails.
• 65 Must and 22 MustAsync predicates on top of that.
• 402 .Must( / .MustAsync( call sites in total.

The inline escape hatch is not a rare corner; it is where a real application's hardest domain logic lives. Making it awkward is a tax on the most important code in the document.

It also blocks two other issues

• No autocompletion for inline languages, scoped to the sandbox they run in #65 (autocompletion for inline languages, scoped to the sandbox) — you cannot offer meaningful completion against dynamic. There is no static shape to complete on, so the sandbox scoping this issue asks for cannot be delivered while the payload is dynamic. This is a hard blocker, not a quality concern.
• Query arguments are untyped and unchecked in the query context #78 (query arguments are untyped and unchecked) is the query-specific instance of exactly this problem. Whatever shape solves it should solve the other four members too, rather than being fixed one member at a time.

A secondary cost: dynamic is AOT- and trim-hostile

The same repro raises IL2026 and IL3050:

Using dynamic types might cause types or members to be removed by trimmer.
The 'dynamic' feature requires runtime-code generation, which is incompatible with AOT.

Anything rendered from a document whose inline code touches these contexts inherits that constraint.

Suggested direction

Syntax open, and this is deliberately not a proposal to remove the escape hatch's flexibility. Options worth weighing:

1. Generate a typed context per artifact. The document already declares the command's inputs, the rule's target and the read models in scope, so the shape is known at render time — the renderer could emit a context typed to that slice. This is the option that also unblocks No autocompletion for inline languages, scoped to the sandbox they run in #65.
2. Expose a typed accessor alongside the dynamic one — e.g. context.As<T>() — keeping the loose form for one-liners while giving real rules a static type.
3. Keep dynamic and document the assignment workaround. Cheapest, and what Define the rule and policy contexts for inline code #61 shipped for now, but it leaves No autocompletion for inline languages, scoped to the sandbox they run in #65 blocked and the failure mode at runtime.

Relationship to #81

This bears directly on the design-constraint ruling. The case for keeping Screenplay statement-shaped rather than growing an expression language rests on the inline block being a good place for real logic to live — that is the pressure valve the whole argument depends on. Today the valve makes LINQ throw at runtime and cannot be autocompleted. Whichever way #81 goes, this wants fixing; if it goes the statements-only way, it becomes load-bearing.

[einari]

Swept as part of a pass over the open set. Still valid at origin/main 7709d43 - and the surface grew rather than shrank.

dynamic now appears seven times across the contexts, not five: ReducerContext (added with the reducer work in #88) carries dynamic? State and dynamic Event on top of CommandContext.Command, QueryContext.Arguments, RuleContext.Artifact, RuleContext.Value and PolicyContext.Artifact. A reducer body is a fold - "current state plus event to next state" - which is the shape most likely of all of them to reach for LINQ over a collection on the state, so it inherits the failure this issue documents rather than avoiding it.

context.md documents the workaround ("assign it to a typed local first, as above, and LINQ works normally from there"), which is option 3 of the three this issue lists. That is where it stands: the failure is documented, not removed, and #65 stays blocked because there is no static shape to complete against.

Where I would take it

The three options are not alternatives so much as two layers, and I would do the cheap one now and the real one when the renderer needs it.

Now, and additive: a typed accessor on each context - context.Command<T>(), context.Artifact<T>() - beside the dynamic member rather than instead of it. It costs nothing at the call site for a one-liner, it gives a rule that does real work a static type without waiting for anything, and it is a pure addition: no positional record parameter changes, so no binary break (ast-compatibility.md). It does not unblock #65 - T is a type the consumer names, not one the document knows about.

The real fix, and what #65 needs: generate a context typed to the construct. The document already declares everything needed - a command's properties, a query's by/filter parameters, a rule's target, the read models a command reads - so a renderer can emit RegisterInvoiceContext with Command typed to the shape the document gives it. Notice this is the same shape #78 asks for on the query side; solving it per member is how you end up doing it four times.

Two things worth settling before that lands:

1. Who generates it. Screenplay compiles a document and hands over a tree; Stage renders. The typed context is a render artifact, so it belongs to whatever renders - which means this issue is partly a Stage issue, and the language's part is only to guarantee the tree carries enough to generate from. It does today.
2. What the sandbox compiles against while authoring. No autocompletion for inline languages, scoped to the sandbox they run in #65 wants completion inside the editor, where nothing has been rendered yet. That needs the same shape synthesized as an ambient declaration from the document, which is the step 2 that issue names. Same source, two consumers - so define the shape once, as a function of the syntax tree, rather than twice.

On AOT and trimming: IL2026/IL3050 follow dynamic wherever it goes, so the typed context is also what makes a rendered application trimmable. Worth stating as a requirement rather than a side effect, because it rules out "keep dynamic, document the workaround" as a permanent answer.

Related, and worth keeping in step: #119 adds identity details, which is a new payload the contexts have to carry. It should land as IReadOnlyDictionary<string, object?> (or the generated shape, once there is one) rather than as an eighth dynamic - noted there.

[cratis-direct]

Thanks for opening this - it has been received and will be looked at.

---

Posted by Stagehand (AI) - an autonomous agent, not a person. Review accordingly.

[woksin]

Work has started locally as part of the coordinated end-to-end Screenplay/Stage/Studio/CLI delivery effort tracked in #174. @woksin is coordinating implementation in dependency order with repository-specific AI corpus instructions and specifications. Existing work/PRs will be reconciled rather than duplicated. This is a kickoff, not a completion claim; focused progress, verification evidence and blockers will follow here.

[woksin]

Status after v4.20.0 (triage of what shipped in v4.18.0–v4.20.0):

Still open and slightly worse than filed: the dynamic surface is now seven members — CommandContext.cs:25, QueryContext.cs:26, RuleContext.cs:38-39, PolicyContext.cs:33, ReducerContext.cs:29-30. #78 was closed into this issue but QueryContext.Arguments is unchanged.
Only option 3 shipped (the workaround is documented in Documentation/screenplay/context.md). Option 2 (typed accessors beside the dynamic members) is a small, purely additive change with no binary break — but it does not unblock #65, because the type is named by the consumer rather than derived from the document.
Option 1 (generated typed context) is the one that unblocks #65 and needs an owner decision first.

[github-actions]

Closed by release v4.21.0.

[woksin]

Reopening: v4.21.0 delivered option 2, typed accessors beside every dynamic member (CommandAs<T>(), ArgumentsAs<T>(), ArtifactAs<T>(), ValueAs<T>(), StateAs<T>(), EventAs<T>()), so LINQ binds at compile time. The release job closed this issue because the release notes reference it. Option 1, a typed context generated per artifact, is still open. It is the option that unblocks #65, and it needs a decision from the renderer (Stage) owner.

[woksin]

Closing as superseded, per decision 0012. Option 2 shipped in v4.21.0: typed As<T>() accessors beside every dynamic member, so LINQ binds at compile time. Option 1, a context typed per artifact, is realized in two parts: Screenplay publishes a language-neutral typed-context descriptor (#139), and Stage generates the typed C# context from it (Cratis/Stage#151).