create-check-run.target is parsed by the compiler and documented, but rejected by the frontmatter schema

[microsasa]

Summary

safe-outputs.create-check-run accepts a target field in the Go compiler and documents it in the safe-outputs reference, but the frontmatter JSON schema omits it and sets additionalProperties: false. gh aw compile therefore rejects any workflow that follows the documented example.

Reproduced on v0.86.2 (current release at time of writing).

Reproduction

.github/workflows/t.md:

---
on:
  workflow_dispatch:
permissions:
  contents: read
engine: copilot
safe-outputs:
  create-check-run:
    name: "Test Check"
    target: "*"
---

# Test

Do nothing.

$ gh aw version
gh aw version v0.86.2

$ gh aw compile
✗ t.md (1 error(s)):
  • 1. .github/workflows/t.md:10:5: error: Unknown property: target. Did you mean 'staged'?.
       'target' belongs under 'tools/comment-memory', 'safe-outputs/submit-pull-request-review'
       or 'safe-outputs/dismiss-pull-request-review'
✗ compilation failed

Deleting only the target: line makes the identical file compile:

$ gh aw compile
✓ .github/workflows/t.md (104.9 KB)
✓ Compiled 1 workflow: 1 succeeded, 0 warnings

Root cause

Three sources describe this field; two agree and the third rejects it. All references below are at tag v0.86.2.

The compiler accepts it — pkg/workflow/create_check_run.go:16:

Target string `yaml:"target,omitempty"` // Target pull request for check run attachment: "triggering", "*", or explicit PR number

with parseCreateCheckRunConfig reading configMap["target"] at lines 41–47, including a warning branch for a non-string value.

The documentation describes it — docs/src/content/docs/reference/safe-outputs.md:956 shows target: "*" in the create-check-run example, followed by a Pull Request Targeting subsection covering all four modes (omitted, triggering, "*", explicit expression) and a permissions table stating that configuring target adds pull-requests: read.

The schema rejects it — pkg/parser/schemas/main_workflow_schema.json, at properties.safe-outputs.properties.create-check-run.oneOf[0]:

properties:           ["name", "max", "github-token", "staged", "samples", "github-app", "output"]
additionalProperties: false

This looks like an omission rather than a decision. 27 other safe outputs declare target in the same schema — add-comment, update-issue, submit-pull-request-review, push-to-pull-request-branch, merge-pull-request and others — and the error message itself points the user at three of them. The likely origin is #38237, which added PR-targeting support to create_check_run without a corresponding schema update.

Impact

The documented configuration cannot be compiled. Someone copying the reference example gets a validation error whose suggestions are all wrong for their situation: staged is unrelated, and the three keys named as owning target are different safe outputs entirely. The pull-requests: read permission the docs say is auto-added when target is configured is unreachable in practice, since no workflow declaring target can compile.

Suggested fix

Add target to the create-check-run schema object, matching the shape already used by the other 27 outputs.

Preventing recurrence

This is at least the third instance of the same drift:

• safe-outputs: merge-pull-request config schema rejects samples: (and target:) #39766 (fixed) — merge-pull-request schema rejected samples: and target:, with the same additionalProperties: false mechanism. That issue cites create-check-run as one of the outputs that correctly permits samples — while its target was missing the whole time.
• compiler: schema validator rejects sandbox.agent.sudo: false (schema not updated to match Go struct rename) #41679 (open) — schema validator rejects sandbox.agent.sudo: false after a Go struct rename left the schema behind.

scripts/check-safe-outputs-conformance.sh has a check_schema_consistency() function, but it verifies that schema-generation functions and static tool schemas exist; it does not check that every yaml: tag on a safe-output config struct has a matching property in the frontmatter schema. A check of that shape would catch the whole class rather than each instance as it is reported.

Happy to send a PR for the schema addition if that is useful.