docs(tools): cite per-character Unicode ages and the ungated seam edit

packages/core/tools/src/index.ts

@@ -37,7 +37,9 @@ import { renderToolsSdkPy } from './py-types.ts'
  * its `run_code` schema strings — plus the renderer function this table points
  * at. The `satisfies` clause pins this table's key set to that union, which
  * the flavor table is checked against too, so any of the three left out is a
- * typecheck failure.
+ * typecheck failure. A fourth edit is not checked anywhere: the seam's
+ * well-known-value list (`dsh-code-runtime`'s README and its
+ * `CodeRuntime.language` JSDoc) names the languages this table presents.
  */
 const SDK_RENDERERS: Record<string, (schemas: ToolSdkSchema[]) => string> = {
   typescript: renderToolsSdk,

packages/core/tools/src/py-types.ts

@@ -52,9 +52,11 @@ const IDENTIFIER = /^[\p{XID_Start}_]\p{XID_Continue}*$/u
  * follow the running engine (Node 22.23.1 reports Unicode 17.0) while CPython
  * follows its own (3.9.6 reports 13.0.0). The skew is not symmetric. A CPython
  * older than the engine is the dangerous direction: a character added to
- * either property since its tables (U+1C89, U+10570, U+1E290, U+1E4D0 are all
- * NFKC-stable and accepted here, and all rejected by that 3.9.6) is emitted
- * bare and its tokenizer refuses the character, taking the whole SDK block
+ * either property since its tables (U+10570 Vithkuqi and U+1E290 Toto, 14.0;
+ * U+1E4D0 Nag Mundari, 15.0; U+1C89 Cyrillic TJE, 16.0 — ages per
+ * `DerivedAge.txt`; all four are NFKC-stable and accepted here, and all four
+ * are `Cn` on that 3.9.6, which rejects them) is emitted bare and its
+ * tokenizer refuses the character, taking the whole SDK block
  * down — the same parseability invariant {@link UNPRINTABLE},
  * {@link LONE_SURROGATE} and {@link MAX_LIST_NESTING} exist for. Both
  * properties carry it: a character added only to `XID_Continue` passes the
@@ -71,7 +73,8 @@ const IDENTIFIER = /^[\p{XID_Start}_]\p{XID_Continue}*$/u
  * shape in the tool's schema declares a `TypedDict`, including for a tool this
  * predicate rejected. A tool named `zz-\u{1E4D0}x` with such parameters never
  * reaches the skew here (the `-` rejects it outright) yet emits
- * `class Zz\u{1E4D0}xArgs`, which that same 3.9.6 refuses. The case mapping is
+ * `class Zz\u{1E4D0}xArgs`, which that same 3.9.6 refuses — Nag Mundari
+ * arrived two releases after its tables. The case mapping is
  * a separate table rather than an XID membership test, and it fails on names
  * both conditions above accept: `\u{019B}` is XID_Start and NFKC-stable, so
  * this predicate accepts it and `async def \u{019B}` compiles on 3.9.6, but

packages/core/tools/tests/code-mode.spec.ts

@@ -391,10 +391,13 @@ describe('mode-aware wire contribution', () => {
 
   it('resolves the run_code schema flavor lazily and fails loud on a language absent from the flavor table', async () => {
     // The flavor getter reads the runtime directly (peekRuntime), so it — not
-    // requireCodeRuntime — owns the flavor-table guard. A language with no
-    // flavor entry throws when the schema is projected, keeping
-    // RUN_CODE_FLAVORS coupled to SDK_RENDERERS. Assembly's requireCodeRuntime
-    // rejects such a language earlier; this reaches the guard on its own.
+    // requireCodeRuntime — owns the flavor-table guard. Keeping
+    // RUN_CODE_FLAVORS in step with SDK_RENDERERS is the compiler's job (both
+    // are `satisfies`-checked against CodeSdkLanguage), so what the guard
+    // covers is a mounted runtime naming a language absent from both tables,
+    // which throws when the schema is projected. Assembly's
+    // requireCodeRuntime rejects such a language earlier; this reaches the
+    // guard on its own.
     const { ctx } = await setup({ mode: 'code', runtime: { language: 'ruby' } })
     const definition = ctx.tools.get(RUN_CODE_NAME)
     // Names the known languages, symmetric with the SDK_RENDERERS guard: this