fix(conformance): match the reference's content-sorted spec resolution order; retire the vacuous unknown-keys case name

F12 — Java/C#/Python's SourceResolver.resolveSources processed declared
source specs in DECLARED order, while each port's own comment claimed to
mirror the TypeScript reference's `orderedPathSpecs` (`sources.ts`), which
kind-validates in declared order but then resolves in CONTENT order
(`JSON.stringify(spec)`, ascending — for a validated `path`-only spec this
reduces to an ordinal sort of the path string). The three ports' comments
were half-true: they implemented the whole-list-kind-validation half but not
the sort. With two simultaneously-unresolvable declared paths, TS's
ERR_SOURCE_UNRESOLVED names the content-first one; the other three named
whichever was declared first instead.

Verified this changes ONLY which of several unresolvable paths gets named in
the raised error, never the resolved file SET: de-duplication into the
result is order-independent by construction (a Map/LinkedHashSet/HashSet
keyed on normalized path), and file order was already outside the cross-port
contract per the corpus README. All three now sort the validated path specs
ordinally before Pass 2 (matching JS's UTF-16 code-unit string comparison —
Java's `Collections.sort` on `String`, C#'s `StringComparer.Ordinal`,
Python's `sorted(..., key=...)` on `str` all agree with it for the ASCII
paths in scope). A new unit test per port (mirroring an empirical probe
against the TS reference) declares two unresolvable paths out of content
order and asserts the content-first one is named; reverted each fix,
confirmed the wrong path was named (RED), restored, confirmed the
content-first one is (GREEN). Full per-port suites (Python 1700, Java 1476,
C# 934) stay green, so no other behavior depends on the prior declared-order
processing.

F13 — the `unknown-top-level-keys-are-ignored` corpus case is vacuous for
TypeScript: all four keys it supplies (`pending_in_git`,
`confidence_thresholds`, `extract`, `migrate`) are TS's OWN recognized
top-level config keys, so TS's `ConfigSchema` (`config.ts`, `.strict()`)
passes the case by RECOGNIZING them, not by ignoring an unknown key — the
other three ports genuinely don't know these keys and correctly ignore them,
but the case can't tell that apart from TS's different reason for the same
outcome. Renamed to
`typescript-owned-top-level-keys-do-not-affect-source-resolution` (inputs
unchanged — not weakened) and the README section rewritten to state the
narrower, TRUE claim precisely.

A genuinely unrecognized key (e.g. `"foo": 1`, unknown to all four ports) IS
a real, confirmed cross-port divergence, verified empirically:
`resolveCollection` → `loadConfig` → `ConfigSchema.parse` is `.strict()` at
the top level, so an unrecognized key throws a ZodError before source
resolution is ever reached, while Java/C#/Python all resolve successfully,
silently ignoring it. NOT added as a shared corpus case and NOT fixed: doing
either would mean changing the reference implementation
(`config.ts`/`collection.ts`, explicitly out of scope) — loosening
`ConfigSchema`'s top-level strictness has a blast radius well beyond source
resolution (every `loadConfig` caller), which is a deliberate call for a
human to make, not one this pass should make unilaterally. Documented in the
README as an open, human-reviewable follow-up rather than silently dropped.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: dmealing

fixtures/source-resolution-conformance/README.md

@@ -93,9 +93,36 @@ README.md
   loop) reports whichever error comes first in declaration order instead,
   diverging on exactly one of the two cases depending on which order it
   happens to process first.
-- **Unknown top-level config keys are IGNORED.** The file carries
-  TypeScript-owned keys no other port models. `schema_version` and `sources` are
-  the neutral subset; each port validates those strictly and ignores the rest.
+- **A TypeScript-owned top-level key does not affect source resolution in any
+  port.** `schema_version` and `sources` are the neutral subset every port
+  models; `pending_in_git` / `confidence_thresholds` / `extract` / `migrate`
+  are TypeScript's own, and `typescript-owned-top-level-keys-do-not-affect-
+  source-resolution` pins that their presence resolves the same file set
+  everywhere. Read that case name literally — it is narrower than "unknown
+  keys are ignored" on purpose. Those four keys are UNKNOWN to Java/C#/Python
+  (which ignore any key outside `schema_version`/`sources`, by design) but
+  KNOWN to TypeScript's own `ConfigSchema` (`sdk/src/config.ts`), which
+  recognizes and validates them as part of its own project state. A case
+  built only from keys TS recognizes cannot tell "TS ignored this because it
+  doesn't affect resolution" apart from "TS ignored this because it doesn't
+  affect resolution AND happened to also validate it" — the two are
+  indistinguishable from the outside, and only the first is what every other
+  port's "ignore the rest" behavior demonstrates.
+  **A genuinely unrecognized key (e.g. `"foo": 1`, unknown to all four ports)
+  is a real, confirmed, cross-port DIVERGENCE, not covered by this corpus.**
+  Verified empirically: `resolveCollection` (`collection.ts`) calls
+  `loadConfig`, which parses the WHOLE file through `ConfigSchema.parse` —
+  `.strict()` at the top level (`config.ts`) — so a key no version of
+  TypeScript has ever declared throws a `ZodError` and resolution never
+  reaches the source-listing step at all, while Java/C#/Python all resolve
+  successfully, silently ignoring it. Not added as a shared `expectFiles`
+  case here because doing so would need EITHER loosening `ConfigSchema`'s
+  top-level strictness (a reference-implementation behavior change with a
+  blast radius well beyond source resolution — every `loadConfig` caller,
+  not just this corpus) OR asserting a `true`-sentinel `expectError` that
+  TypeScript alone would satisfy, contradicting the other three ports'
+  actual success — neither of which this corpus is positioned to decide
+  unilaterally. Left as an open, human-reviewable follow-up.
 
 ## Order is deliberately NOT pinned
 

fixtures/source-resolution-conformance/cases.json

@@ -178,7 +178,7 @@
       "expectError": "ERR_COLLECTION_NOT_FOUND"
     },
     {
-      "name": "unknown-top-level-keys-are-ignored",
+      "name": "typescript-owned-top-level-keys-do-not-affect-source-resolution",
       "tree": {
         "model/meta.a.json": "{\"metadata.root\":{\"children\":[]}}"
       },

server/csharp/MetaObjects.Conformance.Tests/SourceResolverTests.cs

@@ -0,0 +1,45 @@
+using System.Collections.Generic;
+using System.IO;
+using MetaObjects;
+using MetaObjects.Config;
+using Xunit;
+
+namespace MetaObjects.Conformance.Tests;
+
+/// <summary>
+/// Focused unit coverage for <see cref="SourceResolver.ResolveSources"/> shapes
+/// not gated by the shared <c>source-resolution-conformance</c> corpus.
+/// </summary>
+public sealed class SourceResolverTests
+{
+    // F12 — Pass 2 resolves in CONTENT order (ordinal path-string sort), not
+    // declared order, mirroring the TypeScript reference's `orderedPathSpecs`
+    // (`sources.ts`: kind-validated, then sorted by `JSON.stringify(spec)`,
+    // which for a validated `path`-only spec reduces to the path string alone
+    // — verified empirically: `resolveSources(dir, [{path:"zzz-missing"},
+    // {path:"aaa-missing"}])` names "aaa-missing", the content-first one, even
+    // though "zzz-missing" is declared first). With BOTH paths unresolvable,
+    // only a port that content-sorts before Pass 2 names "aaa-missing" here;
+    // a declared-order implementation names "zzz-missing" instead.
+    [Fact]
+    public void TwoUnresolvablePaths_ReportsTheContentFirstOne()
+    {
+        var root = Path.Combine(Path.GetTempPath(), "source-resolver-order-" + System.Guid.NewGuid().ToString("N"));
+        Directory.CreateDirectory(root);
+        try
+        {
+            var specs = new List<IReadOnlyDictionary<string, string>>
+            {
+                new Dictionary<string, string> { ["path"] = "zzz-missing" },
+                new Dictionary<string, string> { ["path"] = "aaa-missing" },
+            };
+            var ex = Assert.Throws<MetaModelException>(() => SourceResolver.ResolveSources(root, specs));
+            Assert.Contains("aaa-missing", ex.Message);
+            Assert.DoesNotContain("zzz-missing", ex.Message);
+        }
+        finally
+        {
+            Directory.Delete(root, recursive: true);
+        }
+    }
+}

server/csharp/MetaObjects/Config/SourceResolver.cs

@@ -24,7 +24,11 @@ public static class SourceResolver
     /// or missing path happens to sit first — the corpus pins that an unsupported
     /// KIND anywhere in the list wins over an unresolved PATH regardless of which
     /// is declared first (`unsupported-kind-precedes-unresolved-path-when-path-is-
-    /// declared-first`/`-second`).
+    /// declared-first`/`-second`). Pass 2 then resolves the validated specs in
+    /// CONTENT order (ordinal path-string sort), also matching `orderedPathSpecs`
+    /// — not the resolved file SET (de-dup is order-independent), only which
+    /// declared path's `ERR_SOURCE_UNRESOLVED` fires first when more than one is
+    /// simultaneously unresolvable.
     public static IReadOnlyList<string> ResolveSources(
         string configDir,
         IReadOnlyList<IReadOnlyDictionary<string, string>> specs)
@@ -45,6 +49,15 @@ public static IReadOnlyList<string> ResolveSources(
                     ErrorCode.ERR_SOURCE_KIND_UNSUPPORTED);
             }
         }
+        // Content order (ordinal — matches the reference's UTF-16 code-unit
+        // comparison), not declared order — mirrors `orderedPathSpecs` in
+        // `sources.ts` (kind-validated, then sorted by `JSON.stringify(spec)`,
+        // which for a validated `path`-only spec reduces to the path string
+        // alone). Does not change the resolved file SET (de-dup is
+        // order-independent); only decides which declared path's
+        // `ERR_SOURCE_UNRESOLVED` fires first when more than one is
+        // simultaneously unresolvable.
+        pathSpecs.Sort(StringComparer.Ordinal);
 
         // Pass 2 — resolve each validated path spec against the filesystem.
         var seen = new List<string>();

server/java/metadata/src/main/java/com/metaobjects/config/SourceResolver.java

@@ -23,6 +23,7 @@
 import java.nio.file.Files;
 import java.nio.file.Path;
 import java.util.ArrayList;
+import java.util.Collections;
 import java.util.LinkedHashSet;
 import java.util.List;
 import java.util.Map;
@@ -59,6 +60,16 @@ private SourceResolver() {}
      * an unresolved PATH regardless of which is declared first
      * ({@code unsupported-kind-precedes-unresolved-path-when-path-is-declared-first}/
      * {@code -second}).
+     *
+     * <p>Pass 2 processes the validated specs in CONTENT order (natural string
+     * ordering of each spec's {@code path}), not declared order — mirroring the
+     * reference implementation's {@code orderedPathSpecs}
+     * ({@code sources.ts}: kind-validated, then sorted by
+     * {@code JSON.stringify(spec)}, which for a validated {@code path}-only spec
+     * reduces to sorting by the path string alone). This does not change the
+     * resolved file SET — de-duplication is order-independent — only which
+     * declared path's {@code ERR_SOURCE_UNRESOLVED} fires first when more than one
+     * is simultaneously unresolvable, which order-independence alone cannot pin.
      */
     public static List<Path> resolveSources(Path configDir, List<Map<String, String>> specs) {
         // Pass 1 — kind validation across the WHOLE set, no filesystem I/O yet.
@@ -73,6 +84,7 @@ public static List<Path> resolveSources(Path configDir, List<Map<String, String>
             }
             pathSpecs.add(rawPath);
         }
+        Collections.sort(pathSpecs);
 
         // Pass 2 — resolve each validated path spec against the filesystem.
         LinkedHashSet<Path> seen = new LinkedHashSet<>();

server/java/metadata/src/test/java/com/metaobjects/config/SourceResolverTest.java

@@ -0,0 +1,68 @@
+/*
+ * Copyright 2003 Doug Mealing LLC dba Meta Objects
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ *     http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package com.metaobjects.config;
+
+import com.metaobjects.MetaDataException;
+import org.junit.Test;
+
+import java.io.IOException;
+import java.nio.file.Files;
+import java.nio.file.Path;
+import java.util.LinkedHashMap;
+import java.util.List;
+import java.util.Map;
+
+import static org.junit.Assert.assertThrows;
+import static org.junit.Assert.assertTrue;
+
+/**
+ * Focused unit coverage for {@link SourceResolver#resolveSources} shapes not gated
+ * by the shared {@code source-resolution-conformance} corpus.
+ */
+public class SourceResolverTest {
+
+    private static Map<String, String> pathSpec(String path) {
+        Map<String, String> m = new LinkedHashMap<>();
+        m.put("path", path);
+        return m;
+    }
+
+    // F12 — Pass 2 resolves in CONTENT order (natural string ordering of each
+    // spec's `path`), not declared order, mirroring the TypeScript reference's
+    // `orderedPathSpecs` (`sources.ts`: kind-validated, then sorted by
+    // `JSON.stringify(spec)`, which for a validated `path`-only spec reduces to
+    // the path string alone — verified empirically: `resolveSources(dir,
+    // [{path:"zzz-missing"},{path:"aaa-missing"}])` names "aaa-missing", the
+    // content-first one, even though "zzz-missing" is declared first). With
+    // BOTH paths unresolvable, only a port that content-sorts before Pass 2
+    // names "aaa-missing" here; a declared-order implementation names
+    // "zzz-missing" instead.
+    @Test
+    public void twoUnresolvablePathsReportsTheContentFirstOne() throws IOException {
+        Path root = Files.createTempDirectory("source-resolver-order-");
+        try {
+            List<Map<String, String>> specs = List.of(pathSpec("zzz-missing"), pathSpec("aaa-missing"));
+            MetaDataException ex = assertThrows(MetaDataException.class,
+                    () -> SourceResolver.resolveSources(root, specs));
+            assertTrue("expected \"aaa-missing\" (content-first) in: " + ex.getMessage(),
+                    ex.getMessage().contains("aaa-missing"));
+            assertTrue("must NOT name \"zzz-missing\" (declared-first, content-second): " + ex.getMessage(),
+                    !ex.getMessage().contains("zzz-missing"));
+        } finally {
+            Files.delete(root);
+        }
+    }
+}

server/python/src/metaobjects/config/source_resolver.py

@@ -72,9 +72,18 @@ def resolve_sources(config_dir: Path, specs: list[dict[str, str]]) -> list[Path]
     # Whole-list kind validation FIRST — see `_validate_kinds`.
     _validate_kinds(specs)
 
+    # Resolve in CONTENT order (ordinal path-string sort), not declared order —
+    # mirrors `orderedPathSpecs` in `sources.ts` (kind-validated, then sorted by
+    # `JSON.stringify(spec)`, which for a validated `path`-only spec reduces to
+    # the path string alone). Does not change the resolved file SET (the `seen`
+    # de-dup below is order-independent); only decides which declared path's
+    # `ERR_SOURCE_UNRESOLVED` fires first when more than one is simultaneously
+    # unresolvable.
+    ordered_specs = sorted(specs, key=lambda s: s["path"])
+
     seen: dict[Path, None] = {}
 
-    for spec in specs:
+    for spec in ordered_specs:
         raw = Path(spec["path"])
         target = raw if raw.is_absolute() else (config_dir / raw)
 

server/python/tests/config/test_source_resolver.py

@@ -65,6 +65,20 @@ def test_kind_error_precedes_unresolved_path_regardless_of_order(tmp_path: Path)
     assert e_resource_first.value.code == ErrorCode.ERR_SOURCE_KIND_UNSUPPORTED
 
 
+def test_two_unresolvable_paths_reports_the_content_first_one(tmp_path: Path) -> None:
+    # F12 — Pass 2 resolves in CONTENT order (ordinal path-string sort), not
+    # declared order, mirroring the TypeScript reference's `orderedPathSpecs`
+    # (verified empirically: `resolveSources(dir, [{path:"zzz-missing"},
+    # {path:"aaa-missing"}])` names "aaa-missing", the content-first one, even
+    # though "zzz-missing" is declared first). With BOTH paths unresolvable,
+    # only the port that content-sorts before Pass 2 names "aaa-missing" here;
+    # a declared-order implementation would name "zzz-missing" instead.
+    with pytest.raises(ParseError) as e:
+        resolve_sources(tmp_path, [{"path": "zzz-missing"}, {"path": "aaa-missing"}])
+    assert "aaa-missing" in str(e.value)
+    assert "zzz-missing" not in str(e.value)
+
+
 def test_collection_falls_back_to_default_dir(tmp_path: Path) -> None:
     (tmp_path / "metaobjects").mkdir()
     (tmp_path / "metaobjects" / "a.json").write_text("{}")