[leonlaiyc]

Problem / Motivation

Goal: the three artifact-materialize tests listed as Windows xfails run on the Windows matrix: the two that need no symlink pass, and the one that does skips only where symlinks cannot be made.

The three test/test_artifact_materialize.py entries in test/windows-expected-failures.txt sit under a comment saying they need symlink-creation privilege because they "exercise copytree's handling of in-tree POSIX symlinks". None of them calls copytree, and two create no symlink. On a Windows host:

• test_materialize_recorded_document_succeeds: assert '# hello\r\n' == '# hello\n'
• test_safe_read_with_identity_authorized: assert b'# ok\r\n' == b'# ok\n'
• test_materialize_symlinked_request_resolves_to_recorded_inode: OSError: [WinError 1314] on a host without the privilege

The first two write their fixture with Path.write_text, which on Windows turns \n into \r\n, and then compare the bytes the code read with the LF the test meant.

Why it matters

The materialize path decides which recorded document an artifact may read, by inode identity. As strict xfails, its success path and the identity-checked byte read assert nothing on Windows.

Not a goal

• How _materialize_and_pin or safe_read_file_bytes_with_identity read a file; both return exactly the bytes on disk.
• Granting symlink privilege on any runner.

What changed (motivation → approach → change)

• Symptom: two tests compare CRLF bytes with an LF literal on Windows; the third cannot build its symlink without the privilege.
• Root cause: the fixtures are written in text mode, and the symlink case is listed instead of skipped.
• Change, in test/test_artifact_materialize.py: _write_doc writes encoding="utf-8", newline="\n", and the identity read's fixture is write_bytes(b"# ok\n"), so the file holds what the test asserts on every platform. test_materialize_symlinked_request_resolves_to_recorded_inode takes @requires_symlinks, the rootdir marker its refused-case sibling test_materialize_symlink_to_unrecorded_file_refused already carries. Where symlinks can be made it runs, now against an LF fixture, and elsewhere it skips with the marker's reason.
• The three strict-xfail lines and the inaccurate comment above them are gone from test/windows-expected-failures.txt.

Backwards compatibility

Compatible: test-only; no product code changes. On POSIX the fixtures hold the same bytes they did.

Removes nothing: three strict-xfail lines go; one test that needs a symlink now skips by the shared marker where none can be made, as its sibling does, and no assertion is dropped.

Tests

• test/test_artifact_materialize.py and test/test_windows_gap_list.py on a Windows host without symlink privilege: 27 passed, 2 skipped (the two @requires_symlinks tests), on Python 3.13.5 and on 3.12.13.
• flake8, black, check_comment_history pass. A trial merge with my other open list edits (test(windows): burn down six path-separator xfails #23777, test(windows): burn down the gateway-run xfails by patching the rlimit seam #23781, test(windows): pin USERPROFILE in the two subagent cwd tilde tests #23786) and with test: decode repository files as utf-8 in tests that read them as text #23775 is clean.

Proof: not provable -- test-only change

Manual verification

N/A — test-only change; the Windows run above is the check, and the Windows matrix runs these tests on this PR, including the symlink case where the runner can make one.

Related Issues

Fixes #23787

Checklist

• At most two commits (one is the norm), with a Conventional Commits title (feat|fix|docs|style|refactor|perf|test|chore|ci|build|revert: ...)
• Existing tests pass and new tests added for new functionality
• Self-review completed; code follows project style guidelines
• Documentation updated (if applicable)
• No secrets, credentials, or internal references in the diff

Contribution License Agreement

🤖 Generated with Claude Code

[github-actions]

UX Review (Opus 5.5, fork) — ⏭️ skipped

Revision fca6ca8aa288141818014e425afb6ec7cb7c32e4 touches no user-facing surface (no changes under website/ or committed screenshots), so the UX review was skipped. Does not block merge.

[github-actions]

First Principles Review (Opus 5.5, fork) — ⏭️ skipped

Revision fca6ca8aa288141818014e425afb6ec7cb7c32e4 ships no reviewable capability (docs, tests or generated files only), so there is nothing to inventory. Does not block merge.

[github-actions]

Design Review (Opus 5.5, fork) — ✅ PASS

Design-level review of fca6ca8aa288141818014e425afb6ec7cb7c32e4 via the fork AI-review pipeline — updated in place on each push. A BLOCK verdict blocks PR readiness; PASS does not.

Design-Verdict: PASS

No design-level concerns. This is a test-only change: the fixtures now write the exact bytes the tests assert, and the symlink case uses the same shared requires_symlinks marker its sibling already carries.

[DESIGN-REVIEWED] fca6ca8

Description read

[DESCRIPTION-READ] 6b30fdb6632d7960566fdb4495d80fe3351c9cc786b94e48c08410d55baa6e3e

That sha256 names everything this verdict read: the PR description, plus the 1 evidence file(s) the workflow collected from it and handed this review. It covers that evidence because the media strip replaces every attachment URL with the same placeholder, so an edit swapping one attachment for another would leave the description's captured text identical while what this review judged changed. Recompute it with .github/scripts/pr-description-capture.sh over the same inputs; if it differs, the description or that evidence changed after this verdict was formed and any finding drawn from either is unproven.

[github-actions]

Opus 5.5 Review (fork) — ✅ no blocking findings

Reviewed fca6ca8aa288141818014e425afb6ec7cb7c32e4 via the fork AI-review pipeline; updated in place on each push.

Review details

No findings.

[OPUS-REVIEWED] fca6ca8

[github-actions]

GPT 6.1 Review (fork) — ✅ no blocking findings

Reviewed fca6ca8aa288141818014e425afb6ec7cb7c32e4 via the fork AI-review pipeline; updated in place on each push.

Review details

No findings.
[GPT-REVIEWED] fca6ca8

[leonlaiyc]

CI on 86a2fd5cd6 is red for an infrastructure reason, not a verdict on the code.

• CI run 40113560393: Detect changed surface started at 17:02 UTC and was cancelled at its 15-minute job ceiling, and Coverage Gate then failed closed ("surface detection (changes) never reported -- failing closed").
• Fast Gate passed on this head, and the Design, Opus 5.5 and GPT 6.1 reviews have no blocking findings.

A fork cannot re-run workflows. Could a maintainer re-run CI run 40113560393? The same 17:01–17:02 stall cancelled Fast Gate on #23781.

[github-actions]

Security Scope Review (fork) — 🔴 BLOCK (blocking)

Which legitimate operations does fca6ca8aa288141818014e425afb6ec7cb7c32e4 newly refuse? Model proposes, scripts/deny_diff.py decides — updated in place on each push. A script-confirmed regression blocks PR readiness.

no leg reported, and this was not the nothing-to-adjudicate short circuit

No [SCOPE-REVIEWED] marker for this head was produced, so the model's text is withheld: it cannot be shown to describe this revision. See the job logs.

[KiroCrewCaptain]

Tier 1 auto-approve: test (2 files). Criteria: no conflict, no requested changes, security path denylist clean, design-doc gate clean, security checklist all-NO, no reviewer-lane findings, readiness signal fresh for this head SHA, declared category matches the diff. Category: Windows test fixtures write LF bytes and skip the symlink case without privilege; removes three now-passing entries from the Windows expected-failures list.