@@ -166,7 +166,8 @@ drift at build time instead of letting a prompt silently degrade.
 `@textRef` is a 2-layer logical reference `group/source` (folder/file,
 table/key, collection/document). The prompt text itself **never lives in
 metadata** — at runtime a configured **provider** resolves the reference to the
-actual Mustache text:
+actual template text (Mustache in every port; Python and TypeScript also accept Jinja, see
+below):
 
 - a filesystem provider (L1 = folder, L2 = file) — the dev default:
   `lobby/welcome` → `<root>/lobby/welcome.mustache`. It is `FilesystemProvider` in every
@@ -181,6 +182,18 @@ actual Mustache text:
 Locale, A/B, dynamic, and evolutionary prompt variants all live behind the
 provider seam without touching metadata.
 
+**Jinja bodies (Python and TypeScript only, ADR-0061).** A body may be a Jinja file —
+`lobby/welcome.jinja` (or `.j2` / `.jinja2`) — instead of `welcome.mustache`; the
+`@textRef` does not change, and the metadata never names an engine. Python renders it with
+jinja2 (the `metaobjects[jinja]` extra), TypeScript with nunjucks. The same `verify` gate
+checks it against the payload, walking the parsed template, and reports what it cannot
+settle statically (`user[key]`, a computed include name) as `ERR_TEMPLATE_NOT_STATIC`. Java,
+Kotlin and C# refuse a Jinja body with `ERR_TEMPLATE_ENGINE_UNSUPPORTED`, so a model that
+must render in those ports keeps Mustache. Prefer Mustache for new templates: it is the
+cross-port engine, and its logic-less shape is what pushes conditionals into the payload
+(next sections). Jinja is for adopting existing Jinja templates without rewriting them; per
+port reference files say how.
+
 ## `render()` is deterministic + byte-stable
 
 Rendering is a pure function: `(payload VO, resolved text) → string`. Same inputs,
@@ -244,7 +257,8 @@ against each value of the dimension and snapshot every variant.
 ## `verify` fails the build on prompt-drift
 
 For every template, the verify step resolves the text, parses each `{{...}}`
-reference, and checks it exists on the payload VO. If the text references
+reference (Mustache, or a Jinja body in Python and TypeScript), and checks it exists on the
+payload VO. If the text references
 `{{authorName}}` but the payload only has `displayName`, **the build fails.** This
 is the prompt-vs-payload drift gate — run it in CI. It walks both `template.prompt`
 and `template.output` nodes the same way (both RENDER; only the direction of what comes
 
@@ -148,3 +148,9 @@ JUnit test in the Maven `test` phase to fail the build on prompt/payload drift.
 `metaobjects:verify` codegen-drift goal additionally catches a stale committed
 parser. The emitted parser imports Jackson (`com.fasterxml.jackson`), normally
 already on a Spring Boot classpath.
+
+**Mustache only (ADR-0061).** Jinja bodies are a Python and TypeScript engine. A ref whose
+only body is a `.jinja` / `.j2` / `.jinja2` file is refused here with
+`ERR_TEMPLATE_ENGINE_UNSUPPORTED` (by the filesystem provider, and as a drift line by
+`verify`), rather than reported as missing. Keep templates the JVM ports render in
+Mustache.
@@ -166,3 +166,9 @@ resolve against the payload — empty list = no drift. Assert it is empty in a J
 test in the Maven `test` phase to fail the build on prompt/payload drift. The
 `metaobjects:verify` codegen-drift goal additionally catches a stale committed
 parser.
+
+**Mustache only (ADR-0061).** Jinja bodies are a Python and TypeScript engine. A ref whose
+only body is a `.jinja` / `.j2` / `.jinja2` file is refused here with
+`ERR_TEMPLATE_ENGINE_UNSUPPORTED` (by the filesystem provider, and as a drift line by
+`verify`), rather than reported as missing. Keep templates the JVM ports render in
+Mustache.
@@ -166,7 +166,8 @@ drift at build time instead of letting a prompt silently degrade.
 `@textRef` is a 2-layer logical reference `group/source` (folder/file,
 table/key, collection/document). The prompt text itself **never lives in
 metadata** — at runtime a configured **provider** resolves the reference to the
-actual Mustache text:
+actual template text (Mustache in every port; Python and TypeScript also accept Jinja, see
+below):
 
 - a filesystem provider (L1 = folder, L2 = file) — the dev default:
   `lobby/welcome` → `<root>/lobby/welcome.mustache`. It is `FilesystemProvider` in every
@@ -181,6 +182,18 @@ actual Mustache text:
 Locale, A/B, dynamic, and evolutionary prompt variants all live behind the
 provider seam without touching metadata.
 
+**Jinja bodies (Python and TypeScript only, ADR-0061).** A body may be a Jinja file —
+`lobby/welcome.jinja` (or `.j2` / `.jinja2`) — instead of `welcome.mustache`; the
+`@textRef` does not change, and the metadata never names an engine. Python renders it with
+jinja2 (the `metaobjects[jinja]` extra), TypeScript with nunjucks. The same `verify` gate
+checks it against the payload, walking the parsed template, and reports what it cannot
+settle statically (`user[key]`, a computed include name) as `ERR_TEMPLATE_NOT_STATIC`. Java,
+Kotlin and C# refuse a Jinja body with `ERR_TEMPLATE_ENGINE_UNSUPPORTED`, so a model that
+must render in those ports keeps Mustache. Prefer Mustache for new templates: it is the
+cross-port engine, and its logic-less shape is what pushes conditionals into the payload
+(next sections). Jinja is for adopting existing Jinja templates without rewriting them; per
+port reference files say how.
+
 ## `render()` is deterministic + byte-stable
 
 Rendering is a pure function: `(payload VO, resolved text) → string`. Same inputs,
@@ -244,7 +257,8 @@ against each value of the dimension and snapshot every variant.
 ## `verify` fails the build on prompt-drift
 
 For every template, the verify step resolves the text, parses each `{{...}}`
-reference, and checks it exists on the payload VO. If the text references
+reference (Mustache, or a Jinja body in Python and TypeScript), and checks it exists on the
+payload VO. If the text references
 `{{authorName}}` but the payload only has `displayName`, **the build fails.** This
 is the prompt-vs-payload drift gate — run it in CI. It walks both `template.prompt`
 and `template.output` nodes the same way (both RENDER; only the direction of what comes
 
@@ -148,3 +148,9 @@ JUnit test in the Maven `test` phase to fail the build on prompt/payload drift.
 `metaobjects:verify` codegen-drift goal additionally catches a stale committed
 parser. The emitted parser imports Jackson (`com.fasterxml.jackson`), normally
 already on a Spring Boot classpath.
+
+**Mustache only (ADR-0061).** Jinja bodies are a Python and TypeScript engine. A ref whose
+only body is a `.jinja` / `.j2` / `.jinja2` file is refused here with
+`ERR_TEMPLATE_ENGINE_UNSUPPORTED` (by the filesystem provider, and as a drift line by
+`verify`), rather than reported as missing. Keep templates the JVM ports render in
+Mustache.
@@ -166,7 +166,8 @@ drift at build time instead of letting a prompt silently degrade.
 `@textRef` is a 2-layer logical reference `group/source` (folder/file,
 table/key, collection/document). The prompt text itself **never lives in
 metadata** — at runtime a configured **provider** resolves the reference to the
-actual Mustache text:
+actual template text (Mustache in every port; Python and TypeScript also accept Jinja, see
+below):
 
 - a filesystem provider (L1 = folder, L2 = file) — the dev default:
   `lobby/welcome` → `<root>/lobby/welcome.mustache`. It is `FilesystemProvider` in every
@@ -181,6 +182,18 @@ actual Mustache text:
 Locale, A/B, dynamic, and evolutionary prompt variants all live behind the
 provider seam without touching metadata.
 
+**Jinja bodies (Python and TypeScript only, ADR-0061).** A body may be a Jinja file —
+`lobby/welcome.jinja` (or `.j2` / `.jinja2`) — instead of `welcome.mustache`; the
+`@textRef` does not change, and the metadata never names an engine. Python renders it with
+jinja2 (the `metaobjects[jinja]` extra), TypeScript with nunjucks. The same `verify` gate
+checks it against the payload, walking the parsed template, and reports what it cannot
+settle statically (`user[key]`, a computed include name) as `ERR_TEMPLATE_NOT_STATIC`. Java,
+Kotlin and C# refuse a Jinja body with `ERR_TEMPLATE_ENGINE_UNSUPPORTED`, so a model that
+must render in those ports keeps Mustache. Prefer Mustache for new templates: it is the
+cross-port engine, and its logic-less shape is what pushes conditionals into the payload
+(next sections). Jinja is for adopting existing Jinja templates without rewriting them; per
+port reference files say how.
+
 ## `render()` is deterministic + byte-stable
 
 Rendering is a pure function: `(payload VO, resolved text) → string`. Same inputs,
@@ -244,7 +257,8 @@ against each value of the dimension and snapshot every variant.
 ## `verify` fails the build on prompt-drift
 
 For every template, the verify step resolves the text, parses each `{{...}}`
-reference, and checks it exists on the payload VO. If the text references
+reference (Mustache, or a Jinja body in Python and TypeScript), and checks it exists on the
+payload VO. If the text references
 `{{authorName}}` but the payload only has `displayName`, **the build fails.** This
 is the prompt-vs-payload drift gate — run it in CI. It walks both `template.prompt`
 and `template.output` nodes the same way (both RENDER; only the direction of what comes
 
@@ -18,6 +18,7 @@ silently drift.
 - Recommended LLM caller (bring-your-own)
 - Consumer dependency
 - Drift gate
+- Jinja templates
 
 ## Wire the generators
 
@@ -188,4 +189,27 @@ required_slots=None, required_tags=None) -> list[VerifyError]` walks a Mustache
 template's tokens against the payload field tree — each `{{...}}` reference that
 doesn't resolve yields a `VerifyError` (empty list = no drift). Assert it is empty in a
 pytest test to fail the build on prompt/payload drift; `metaobjects verify`
-additionally catches a stale committed parser.
+additionally catches a stale committed parser. Pass `engine="jinja"` to check a Jinja body.
+
+## Jinja templates
+
+Existing Jinja prompt templates adopt the gate as they are (ADR-0061). Install the extra,
+`pip install "metaobjects[jinja]"`, and keep the file as `<group>/<source>.jinja` (or `.j2`,
+`.jinja2`) under the template root; `@textRef` stays `group/source`. `FilesystemProvider`
+reads `.mustache` first, then the Jinja extensions, and `engine_of(ref)` reports which one it
+found; `render` and `metaobjects verify` pick the engine from it. For an
+`InMemoryProvider`, pass `InMemoryProvider(templates, engine="jinja")`, or pass `engine="jinja"`
+to `RenderRequest` / `verify` directly.
+
+- `verify` walks the parsed jinja2 template: paths per segment, `for` targets bound to element
+  fields, `set` / macro parameters as locals, filter arguments, and literal `include` /
+  `import` / `extends` through the provider. `ERR_TEMPLATE_NOT_STATIC` marks what it cannot
+  settle; `ERR_TEMPLATE_SYNTAX` a body that does not parse.
+- The generated render helper over a Jinja body passes `engine="jinja"` and the payload field
+  tree (`verify=[PayloadField(...)]`) to `render`, so a body that drifted after the build is
+  refused at runtime with `RenderError("render verify failed: ERR_… (path)")`.
+- A Pydantic payload renders as its JSON-mode dump, as with Mustache. Printed values follow
+  the Mustache renderer: `true` / `false`, a whole float as an integer, `None` as empty.
+- To render the same in TypeScript (nunjucks), stay inside the shared vocabulary in
+  `fixtures/jinja-render-conformance/`: test a list with `| length`, avoid `{% with %}`,
+  Python methods and printing whole lists or dicts.
@@ -166,7 +166,8 @@ drift at build time instead of letting a prompt silently degrade.
 `@textRef` is a 2-layer logical reference `group/source` (folder/file,
 table/key, collection/document). The prompt text itself **never lives in
 metadata** — at runtime a configured **provider** resolves the reference to the
-actual Mustache text:
+actual template text (Mustache in every port; Python and TypeScript also accept Jinja, see
+below):
 
 - a filesystem provider (L1 = folder, L2 = file) — the dev default:
   `lobby/welcome` → `<root>/lobby/welcome.mustache`. It is `FilesystemProvider` in every
@@ -181,6 +182,18 @@ actual Mustache text:
 Locale, A/B, dynamic, and evolutionary prompt variants all live behind the
 provider seam without touching metadata.
 
+**Jinja bodies (Python and TypeScript only, ADR-0061).** A body may be a Jinja file —
+`lobby/welcome.jinja` (or `.j2` / `.jinja2`) — instead of `welcome.mustache`; the
+`@textRef` does not change, and the metadata never names an engine. Python renders it with
+jinja2 (the `metaobjects[jinja]` extra), TypeScript with nunjucks. The same `verify` gate
+checks it against the payload, walking the parsed template, and reports what it cannot
+settle statically (`user[key]`, a computed include name) as `ERR_TEMPLATE_NOT_STATIC`. Java,
+Kotlin and C# refuse a Jinja body with `ERR_TEMPLATE_ENGINE_UNSUPPORTED`, so a model that
+must render in those ports keeps Mustache. Prefer Mustache for new templates: it is the
+cross-port engine, and its logic-less shape is what pushes conditionals into the payload
+(next sections). Jinja is for adopting existing Jinja templates without rewriting them; per
+port reference files say how.
+
 ## `render()` is deterministic + byte-stable
 
 Rendering is a pure function: `(payload VO, resolved text) → string`. Same inputs,
@@ -244,7 +257,8 @@ against each value of the dimension and snapshot every variant.
 ## `verify` fails the build on prompt-drift
 
 For every template, the verify step resolves the text, parses each `{{...}}`
-reference, and checks it exists on the payload VO. If the text references
+reference (Mustache, or a Jinja body in Python and TypeScript), and checks it exists on the
+payload VO. If the text references
 `{{authorName}}` but the payload only has `displayName`, **the build fails.** This
 is the prompt-vs-payload drift gate — run it in CI. It walks both `template.prompt`
 and `template.output` nodes the same way (both RENDER; only the direction of what comes
 
@@ -219,6 +219,18 @@ error in every port. The emitted parser imports `zod`;
 it's usually already a dependency (Drizzle / `runtime-ts` lean on it), else
 `npm i zod`.
 
+**Jinja bodies (ADR-0061).** A body may be `<group>/<source>.jinja` (or `.j2`, `.jinja2`)
+instead of `.mustache`; `@textRef` does not change. `@metaobjectsdev/render` renders it with
+nunjucks (a dependency of the package, nothing to install) and `meta verify` checks it the same
+way, walking the parsed template; it names the `.jinja` file and line on a drift.
+`FilesystemProvider.engineOf(ref)` reports the engine of the file it found; for an
+`InMemoryProvider` pass `new InMemoryProvider(map, { engine: "jinja" })`, or pass
+`engine: "jinja"` to `render` / `verify`. A generated `render<Name>()` helper over a Jinja body
+passes `engine: "jinja"`, so it renders as Jinja through any runtime provider, and the
+runtime check runs on it as on a Mustache body. What the check cannot settle statically is
+`ERR_TEMPLATE_NOT_STATIC`. nunjucks treats an empty list as true (jinja2 does not), so test a
+list with `{% if items | length %}` when the same template must render in Python.
+
 ## See which fields a template consumes
 
 List `docsFile()` in `generators` and run `meta gen` to emit the model surface to the
 
@@ -166,7 +166,8 @@ drift at build time instead of letting a prompt silently degrade.
 `@textRef` is a 2-layer logical reference `group/source` (folder/file,
 table/key, collection/document). The prompt text itself **never lives in
 metadata** — at runtime a configured **provider** resolves the reference to the
-actual Mustache text:
+actual template text (Mustache in every port; Python and TypeScript also accept Jinja, see
+below):
 
 - a filesystem provider (L1 = folder, L2 = file) — the dev default:
   `lobby/welcome` → `<root>/lobby/welcome.mustache`. It is `FilesystemProvider` in every
@@ -181,6 +182,18 @@ actual Mustache text:
 Locale, A/B, dynamic, and evolutionary prompt variants all live behind the
 provider seam without touching metadata.
 
+**Jinja bodies (Python and TypeScript only, ADR-0061).** A body may be a Jinja file —
+`lobby/welcome.jinja` (or `.j2` / `.jinja2`) — instead of `welcome.mustache`; the
+`@textRef` does not change, and the metadata never names an engine. Python renders it with
+jinja2 (the `metaobjects[jinja]` extra), TypeScript with nunjucks. The same `verify` gate
+checks it against the payload, walking the parsed template, and reports what it cannot
+settle statically (`user[key]`, a computed include name) as `ERR_TEMPLATE_NOT_STATIC`. Java,
+Kotlin and C# refuse a Jinja body with `ERR_TEMPLATE_ENGINE_UNSUPPORTED`, so a model that
+must render in those ports keeps Mustache. Prefer Mustache for new templates: it is the
+cross-port engine, and its logic-less shape is what pushes conditionals into the payload
+(next sections). Jinja is for adopting existing Jinja templates without rewriting them; per
+port reference files say how.
+
 ## `render()` is deterministic + byte-stable
 
 Rendering is a pure function: `(payload VO, resolved text) → string`. Same inputs,
@@ -244,7 +257,8 @@ against each value of the dimension and snapshot every variant.
 ## `verify` fails the build on prompt-drift
 
 For every template, the verify step resolves the text, parses each `{{...}}`
-reference, and checks it exists on the payload VO. If the text references
+reference (Mustache, or a Jinja body in Python and TypeScript), and checks it exists on the
+payload VO. If the text references
 `{{authorName}}` but the payload only has `displayName`, **the build fails.** This
 is the prompt-vs-payload drift gate — run it in CI. It walks both `template.prompt`
 and `template.output` nodes the same way (both RENDER; only the direction of what comes