[geoffw0]

This phrasing bothered me when I saw it. "ignore these files" suggests Copilot should neither write nor read .expected files, whereas I think we only mean to ban writing them ("manually"). Reading them should be a perfectly normal thing to do.

I haven't witnessed the existing wording drive Copilot astray, and I don't know of a reasonable way to test the change I propose.

[Copilot]

🟢 Approval recommended

The wording resolves the ambiguity without weakening the restriction on direct edits.

No open issues 🎉

What changed in this PR

Clarifies Copilot guidance for generated .expected files, allowing reading while preserving the restriction on direct edits.

Changes:

• Replaces “Ignore these files” with an explicit instruction not to edit them directly.

File	Description
.github/​instructions/​expected-files.instructions.md	Clarifies guidance for generated test expectations.

_{Review effort: Max}

[owen-mc]

Another idea: tell it that for inline expectations tests, .expected files shouldn't be commited with a non-empty testFailures section.

[geoffw0]

Another idea: tell it that for inline expectations tests, .expected files shouldn't be commited with a non-empty testFailures section.

Good idea. How about:

Do not edit these files directly. They are generated by running the tests. If a .expected file has a non-empty testFailures section it should not be committed - you may want to update the inline expectation comments in the corresponding test source file (e.g. marking expected results as MISSING / SPURIOUS) then re-run the test.

[owen-mc]

That sounds good. I think there are some cases where it's very difficult to avoid a non-empty testFailures section, e.g. in files where we can't easily put a comment (yml? json?), or when the alerts change when you add a comment, so it's good that you didn't make it a hard requirement.