🎙️ task - feat(types): brand ContextAwsLambdaCaller vs ContextAwsLambdaServer — a caller is silently assignable to a server

[uladkasach]

🦫🎙️ dispatch to foreman

💧 task enqueued
   ├─ priority = ?
   ├─ yieldage = ?
   └─ leverage = ?

title
feat(types): brand ContextAwsLambdaCaller vs ContextAwsLambdaServer — a caller is silently assignable to a server
description

what

brand ContextAwsLambdaCaller and ContextAwsLambdaServer so they are non-interchangeable at the type level.

why

the two contexts are near-identical in shape, so a caller is silently assignable to a server. verified with a probe in svc-gateway:

assignment	result
caller -> where a server is expected	compiles silently
server -> where a caller is expected	TS2322 (env optional vs required)

exactly one direction is compiler-invisible, and it is a real hazard: env.access means different things on each side —

• caller: which peer lambda to target, ${service}-${access}-${function}
• server: whether to open the introspection gate (below prod only)

a caller passed where a server is expected compiles, then mis-gates introspection.

ask

brand them so the compiler enforces the distinction the names imply:

export interface ContextAwsLambdaCaller extends ContextLogTrail {
  readonly __side?: "caller";   // or an OfGlossary-style brand
  ...
}

that removes the need for any downstream naming convention — the type system carries it. (secondary, if declined: scaffold contextLambdaCaller + contextLambdaServer consts in the lambda-service practice — the convention-level workaround for the same problem, noting the test->prep collapse the caller needs and the server does not.)

source

found during the declapract upgrade of ahbode/svc-gateway (branch vlad/bump-practs), item 4 of .dream/2026_08_12.upstream-sdk-zod-glossary-splits