test: [expected failures] parameter-type fixtures needing implementation fixes

conformance-tests/2023-09/EXPR/job_templates/proposed/2.10--range-expr-endpoint-int64-max.yaml

@@ -0,0 +1,19 @@
+# Section 2.10 / 3.4.1.1.1: RANGE_EXPR endpoints at the int64 boundary.
+# 9223372036854775807 is 2^63-1, the largest representable endpoint.
+specificationVersion: jobtemplate-2023-09
+extensions:
+- EXPR
+name: TestJob
+parameterDefinitions:
+- name: Frames
+  type: RANGE_EXPR
+  default: "9223372036854775806-9223372036854775807"
+steps:
+- name: Step1
+  script:
+    actions:
+      onRun:
+        command: python
+        args:
+        - "-c"
+        - "print()"

conformance-tests/2023-09/EXPR/job_templates/proposed/2.13--list-int-item-int64-overflow.invalid.yaml

@@ -0,0 +1,17 @@
+specificationVersion: jobtemplate-2023-09
+extensions:
+- EXPR
+name: TestJob
+parameterDefinitions:
+- name: Values
+  type: LIST[INT]
+  default: [9223372036854775808]
+steps:
+- name: Step1
+  script:
+    actions:
+      onRun:
+        command: python
+        args:
+        - "-c"
+        - "print()"

conformance-tests/2023-09/EXPR/job_templates/proposed/2.16--list-list-int-inner-item-int64-overflow.invalid.yaml

@@ -0,0 +1,17 @@
+specificationVersion: jobtemplate-2023-09
+extensions:
+- EXPR
+name: TestJob
+parameterDefinitions:
+- name: Matrix
+  type: LIST[LIST[INT]]
+  default: [[9223372036854775808]]
+steps:
+- name: Step1
+  script:
+    actions:
+      onRun:
+        command: python
+        args:
+        - "-c"
+        - "print()"

conformance-tests/2023-09/EXPR/job_templates/proposed/3.4.1--task-param-type-case-insensitive.yaml

@@ -0,0 +1,31 @@
+# With EXPR enabled, task parameter type names are case-insensitive
+# (Template Schemas section 2: "job parameter and task parameter type names
+# become case-insensitive"). Task parameter types are INT, FLOAT, STRING,
+# and PATH (section 3.4.1); LIST forms are not task parameter types.
+specificationVersion: jobtemplate-2023-09
+extensions:
+- EXPR
+name: TestJob
+steps:
+- name: Step1
+  parameterSpace:
+    taskParameterDefinitions:
+    - name: Frame
+      type: int
+      range: "1-3"
+    - name: Scale
+      type: Float
+      range: ["1.0", "2.0"]
+    - name: Layer
+      type: sTrInG
+      range: ["fg", "bg"]
+    - name: Scene
+      type: pAtH
+      range: ["/tmp/a.blend", "/tmp/b.blend"]
+  script:
+    actions:
+      onRun:
+        command: python
+        args:
+        - "-c"
+        - "print()"

conformance-tests/2023-09/EXPR/job_templates/proposed/README.md

@@ -0,0 +1,61 @@
+# Proposed fixtures (parked: spec-correct, implementation fails)
+
+These fixtures are believed spec-correct but fail against the current `openjd`
+CLI. They are parked here (the runner does not descend into subdirectories)
+until the implementation is fixed, at which point they should move up one
+directory unchanged.
+
+## 2.13--list-int-item-int64-overflow.invalid.yaml
+## 2.16--list-list-int-inner-item-int64-overflow.invalid.yaml
+
+Both must be rejected: a `LIST[INT]` element / `LIST[LIST[INT]]` inner element
+of `9223372036854775808` (2^63) exceeds the int64 range that governs `int`
+values (Expression Language §1.2.1 "64-bit signed integer"; the EXPR literal
+fixtures `expr2.1.1--int64-overflow-*` pin the same bound for literals).
+Observed:
+
+```
+$ openjd check 2.13--list-int-item-int64-overflow.invalid.yaml
+Template ... passes validation checks.
+$ openjd check 2.16--list-list-int-inner-item-int64-overflow.invalid.yaml
+Template ... passes validation checks.
+```
+
+Classification: implementation bug, the known int64-in-data bug class (scalar
+INT parameter defaults have the same defect) one container deeper. The
+implementation validates int64 bounds for expression literals and arithmetic
+but not for values arriving as YAML data in list defaults.
+
+## 2.10--range-expr-endpoint-int64-max.yaml
+
+Must be accepted: Template Schemas §3.4.1.1.1 defines `<Int>` as "Any integer
+value (positive, negative, or zero)", and §2.10 requires only that a
+RANGE_EXPR default be a valid `<IntRangeExpr>`. Observed:
+
+```
+$ openjd check 2.10--range-expr-endpoint-int64-max.yaml
+ERROR: Model validation error: 1 validation error for JobTemplate
+parameterDefinitions[0]:
+	Parameter 'Frames': default '9223372036854775806-9223372036854775807' is not a valid range expression.
+```
+
+Probing shows the implementation accepts endpoints up to 2^62-1
+(4611686018427387903) and rejects 2^62 (4611686018427387904) and above.
+Classification: implementation bug (undocumented 2^62 endpoint cap; the spec
+grammar admits any int64 endpoint). Note: the companion negative
+`2.10--range-expr-endpoint-int64-overflow.invalid.yaml` (in the parent
+directory) currently passes because of this same over-rejection, so its
+rejection reason is wrong until this positive is green.
+
+## 3.4.1--task-param-type-case-insensitive.yaml
+
+Must be accepted: Template Schemas §2 states that with EXPR enabled "job
+parameter and task parameter type names become case-insensitive". Observed:
+
+```
+$ openjd check 3.4.1--task-param-type-case-insensitive.yaml
+ERROR: Validation error: 'jobtemplate-2023-09' failed checks: unknown variant `int`, expected one of `INT`, `FLOAT`, `STRING`, `PATH`, `CHUNK[INT]`
+```
+
+Classification: implementation bug. Task parameter type names are matched
+exactly; case-insensitivity is implemented for job parameter types only.

conformance-tests/2023-09/base/job_templates/proposed/2--type-lowercase-string.invalid.yaml

@@ -0,0 +1,17 @@
+# Base 2023-09 type names are case-sensitive. "string" (lowercase) is only
+# valid with the EXPR extension enabled; without it the template must be
+# rejected. Guards the case-sensitivity gate from RFC 0007.
+specificationVersion: jobtemplate-2023-09
+name: TestJob
+parameterDefinitions:
+- name: Param1
+  type: string
+steps:
+- name: Step1
+  script:
+    actions:
+      onRun:
+        command: python
+        args:
+        - "-c"
+        - "print()"

conformance-tests/2023-09/base/job_templates/proposed/README.md

@@ -0,0 +1,24 @@
+# Proposed fixtures (parked: spec-correct, implementation fails)
+
+These fixtures are believed spec-correct but fail against the current `openjd`
+CLI. They are parked here (the runner does not descend into subdirectories)
+until the implementation is fixed, at which point they should move up one
+directory unchanged.
+
+## 2--type-lowercase-string.invalid.yaml
+
+Must be rejected: base 2023-09 parameter type names are case-sensitive.
+Template Schemas §2 makes type names case-insensitive only "when the EXPR
+extension is enabled" (RFC 0007); this template uses `type: string` with no
+`extensions:` field. Observed:
+
+```
+$ openjd check 2--type-lowercase-string.invalid.yaml
+Template ... passes validation checks.
+```
+
+Classification: implementation bug. The implementation applies case-insensitive
+type-name matching unconditionally instead of gating it on EXPR, which is
+exactly the failure mode the case-sensitivity gate exists to catch: an
+unconditionally case-insensitive implementation is otherwise indistinguishable
+from a correct one across the entire suite.