[typespec-ts] Add Spector coverage report workflow

[Jialin Huang (JialinHuang803)]

Summary

Adds a scheduled Spector coverage workflow for the TypeScript emitter. The workflow:

• Runs every Monday at 09:00 UTC+8 and supports manual dispatch.
• Builds @azure-tools/typespec-ts, runs its Spector suite, and reads spector-coverage-typescript-azure.json.
• Groups not-implemented scenarios, links each group to its source Spector case, and highlights newly discovered groups and scenarios.
• Preserves manually selected Skip Implement checkboxes and comments across report updates.
• Reads the dashboard tier configuration and automatically marks full Backlog groups, annotates mixed groups, and excludes Backlog scenarios from implementation tasks.
• Limits implementation tasks to tests for behavior already supported by the emitter; unsupported scenarios are reported rather than fixed in the task.
• Reuses an existing inactive implementation task instead of creating duplicate issues.
• Does not create or update a task while any generated task is assigned to Copilot or linked to an open implementation PR.
• Assigns created or refreshed tasks to JialinHuang803 and kazrael2119.

Workflow outputs

The workflow writes its results to GitHub issues; it does not commit generated files or publish a build artifact.

1. Coverage report issue — Creates or updates the single [typespec-ts] Spector Coverage Report issue. It contains per-package pass/fail/not-implemented totals and coverage percentages, followed by grouped not-implemented scenarios with source links, preserved Skip Implement checkboxes, comments, and Backlog annotations. See the report produced in the fork.
2. Implementation task issue — When actionable scenarios remain and no task is active, updates the newest inactive generated task or creates one if none exists. The task lists non-Backlog, non-skipped scenarios, requires a per-group success/failure report, and permits only passing test additions. It is assigned to JialinHuang803 and kazrael2119. Manual runs can suppress this output with report_only. See the task produced in the fork.

A task is considered active when it is assigned to Copilot or linked to an open implementation PR. In that case, the workflow leaves all existing task issues unchanged and creates no replacement. This behavior was exercised in the fork with active task #4 and implementation PR #7.

The implementation task uses the typespec-ts-add-spector-test skill from #5282.

[github-actions]

No changes needing a change description found.

[azure-sdk-automation]

You can try these changes here

🛝 Playground	🌐 Website

[Timothee Guerin (timotheeguerin)]

Suggested change

	run: pnpm install
	run: pnpm install --filter "@azure-tools/typespec-ts..."

you can do that too for slight speed bonus

[Jialin Huang (JialinHuang803)]

Seems @typespec/monorepo is required, so "@azure-tools/typespec-ts..." --filter "@typespec/monorepo" is added

[Timothee Guerin (timotheeguerin)]

can this script be moved out of this into a ts file (and use modern js not common js)

[Jialin Huang (JialinHuang803)]

Moved the script to .github/scripts in 0dab7f7.

[Timothee Guerin (timotheeguerin)]

does the report job also need to check github api? feels a little of duplication/no good split between the job here

[Jialin Huang (JialinHuang803)]

The report job needs the GitHub api to locate the existing report and update the content. The task job uses the api for task detection and deduplication.
There is also a 'report-only' mode which can run only the report job when triggering the workflow manually.

[Timothee Guerin (timotheeguerin)]

can't it just find the issue in the next step and replace the content with the latest value, this all feels very complex here to reparse all the markdown expecting it to stay in the same format

[Jialin Huang (JialinHuang803)]

The idea of reparsing the existing markdown is to preserve manually edited Skip Implement checkboxes and Comments in the report and identify new scenarios. The report job doesn't fully replace the report content.

[Timothee Guerin (timotheeguerin)]

I mean is that really going to be reliable, this feels like if the comment is edited in the wrong way the parsing will fail and erase everything anyway.
There is explicit config you can have with spector to mark a test as unsupported we probably should rely on that instead no?

[Jialin Huang (JialinHuang803)]

Yes, that makes sense. Let me investigate if we can leverage the spector.config.yaml to make things easier.

Regarding the config to mark a test as unsupported, do you mean setting the scenario group to false as below?

# Disabled: multipart not yet supported
payload/multipart: false

I am thinking about marking the scenario group as skipped in the report if the scenario group is set to false in the config. However, this may introduce other problems. Seems we couldn't set a specific scenario to false in spector.config. If we want to implement some scenarios while leaving other scenarios in the same scenario group not-implemented, the scenario group in the config should still be set to true.

And the reason why I added a Comment column to the report is that we can quickly scan or edit why we need to skip the tests. We had been using the report workflow for a while in the previous autorest.typescript repo, and most comments we added are just some texts or links which are less likely to cause the parsing to fail. Maybe we can try this and see what problems we can have then fix it.

[Timothee Guerin (timotheeguerin)]

Do you actually need to run the test, can you not just simply check the config and compare with the tests from spector?

[Jialin Huang (JialinHuang803)]

The tests are run because the coverage JSON contains the most correct and direct status of the spector tests, while it's more complicated to check the spec config and search for tests that are skipped or partially implemented to get the final implementation results.

[Timothee Guerin (timotheeguerin)]

I see