From 9aebc10ef070ac0d774adc5222c1c09a972c79a4 Mon Sep 17 00:00:00 2001
From: David Leong <116610336+leongdl@users.noreply.github.com>
Date: Sat, 25 Jul 2026 15:03:09 -0700
Subject: [PATCH] test: Add conformance fixture for Task.File property-access
 divergence [DO NOT MERGE YET]
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- 7.3--task-file-direct-property-access.test: direct property access on a
  path-typed Task.File reference inside a format string
  ({{Task.File.Run.name}} / .suffix) is valid per Template Schemas 7.3.1
  and Expression Language 2.3.1, with a pinned filename making both
  expected values deterministic. Pins the known validator divergence that
  mis-resolves the dotted tail as an embedded-file key.

Review: quorum-review fixes — dropped 3--int-literal-above-int64-max
.invalid (a plain <posinteger> schema field carries no expression; no
normative text bounds it at int64, so the rejection had no spec basis and
mis-used the section-number namespace). If literal schema fields should be
int64-bounded, that is a spec decision to make first.

Signed-off-by: David Leong <116610336+leongdl@users.noreply.github.com>
---
 ...task-file-direct-property-access.test.yaml | 44 +++++++++++++++++++
 1 file changed, 44 insertions(+)
 create mode 100644 conformance-tests/2023-09/EXPR/jobs/7.3--task-file-direct-property-access.test.yaml

diff --git a/conformance-tests/2023-09/EXPR/jobs/7.3--task-file-direct-property-access.test.yaml b/conformance-tests/2023-09/EXPR/jobs/7.3--task-file-direct-property-access.test.yaml
new file mode 100644
index 0000000..2e88062
--- /dev/null
+++ b/conformance-tests/2023-09/EXPR/jobs/7.3--task-file-direct-property-access.test.yaml
@@ -0,0 +1,44 @@
+# RFC 0005 declares `Task.File.<name>` and `Env.File.<name>` as `path` typed, and
+# shows property access on one directly inside a format string:
+#
+#     echo "Script: {{Task.File.Run.name}}"
+#
+# (rfcs/0005-expression-language.md, "Since Session.WorkingDirectory,
+# Task.File.<name>, and Env.File.<name> are path typed ...").
+#
+# The existing 7.3--task-file-expr-properties fixture only reaches the property
+# through a `let` binding (`cfg = Task.File.config`, then `cfg.parent`), and a
+# property reached inside a function call (`len(Task.File.Run.name)`) parses
+# differently again -- so neither covers the direct member-access form the RFC
+# uses. An implementation whose template validator resolves a `Task.File.*`
+# reference by looking the whole dotted tail up as an embedded-file key rejects
+# this template with "references undefined embedded file 'Run.name'", even though
+# its own runtime resolves the expression correctly and its environment-template
+# validator accepts the equivalent `Env.File.<name>.name`.
+#
+# `filename` is set so the expected value of `.name` is deterministic.
+template:
+  specificationVersion: jobtemplate-2023-09
+  extensions:
+  - EXPR
+  name: TestJob
+  steps:
+  - name: Step1
+    script:
+      embeddedFiles:
+      - name: Run
+        type: TEXT
+        filename: run.txt
+        data: "contents\n"
+      actions:
+        onRun:
+          command: python
+          args:
+          - -c
+          - |
+            print(r'NAME:{{Task.File.Run.name}}')
+            print(r'SUFFIX:{{Task.File.Run.suffix}}')
+expected:
+  output:
+  - "NAME:run.txt"
+  - "SUFFIX:.txt"